Test Program Generator

Documenting the Program

Origen allows test descriptions to be entered quickly and easily within the test flow source file, enabling a test program document to be produced that is extremely accurate due to it being derived from the same source as the program itself.

The application must also define a documentation interface in order to do the translation between the application-specific flow API and the Origen test program documentation back end - this is the exact same principle as generating an interface for a specific ATE platform.

Typically creating a documentation interface is much easier than creating an ATE platform interface and is discussed later in this guide. Note that if you don’t initially have time to set up the documentation interface you should still try and document the program as described here since the code it produces will still be compatible with any tester interface. Then when time allows you can setup the documentation interface with the hard part of actually describing the tests already done.

The Documentation Helpers plugin provides off the shelf test flow helpers to render such documentation metadata as a well formatted web document.

Flow sections and individual tests should be documented like this:

# A Test Sub Module
# Test flow modules like this will collapse and nest when they are included in a parent
# flow via the import command. The first line will be the name assigned to the collapsible
# area, the rest of these comments will be shown when it expands. **It will be parsed for
# markdown.**
Flow.create do
  # Any comments in here will attach as a description to the next test
  func :measure_vreg, bin: 45, vdd: min

  # This is a description of what this test does
  #- Prefixing the line with a '-' will cause it to be private, so this is how you would
  #- record some implementation detail that is of interest to engineers working on this
  #- flow, but which is not relevant to its overall operation
  func :vreg_func1, bin: 50

  # All comments can contain markdown, for example
  #
  # * A bulleted
  # * list
  func :vreg_func2, bin: 55, iload: 50.uA
end

When generated against an appropriate documentation interface and passed to the Documentation Helpers plugin, this would generate a flow section like this (click to expand):

Tests can be grouped together by wrapping them with the pp helper, here are the two functional tests grouped together with some description added about what the group contains:

# A Test Sub Module
# Test flow modules like this will collapse and nest when they are included in a parent
# flow via the import command. The first line will be the name assigned to the collapsible
# area, the rest of these comments will be shown when it expands. **It will be parsed for
# markdown.**
Flow.create do
  # Any comments in here will attach as a description to the next test
  func :measure_vreg, bin: 45, vdd: min

  # Within flow sections should be marked like this (this is the same API to indicate
  # structure in pattern logic to). This text will appear when the collapsible area is
  # shown and will be parsed for markdown.
  pp "Functional Tests" do
    # This is a description of what this test does
    #- Prefixing the line with a '-' will cause it to be private, so this is how you would
    #- record some implementation detail that is of interest to engineers working on this
    #- flow, but which is not relevant to its overall operation
    func :vreg_func1, bin: 50

    # All comments can contain markdown, for example
    #
    # * A bulleted
    # * list
    func :vreg_func2, bin: 55, iload: 50.uA
  end
end

The functional tests will now be nested in a collapsible group:

Helper methods can be added to your interface to generate multiple tests or to otherwise dynamically generate a section of the flow.

Within these methods the cc method can be used to stage comments that will be attached to the next test to be generated:

def program_sequence
  cc "Issue a pulse"
  func :program_20us
  cc "Do a verify"
  func :read_margin0
end

A documentation interface can be thought of as an interface for a really simple tester which only has the concept of a flow and a collection of tests.

Here is the basic starting point for any documentation interface:

class DocInterface
  include OrigenTesters::Doc::Generator

  # Add a test to the collection
  def add_test(name, options)
    tests.add(name, options)
  end

  # Add a flow entry
  def add_flow_entry(test, options)
    flow.test(test, options)
  end
end

As with any interface it is then required to create methods to translate your domain specific flow API into calls to these two key methods to add a test and a flow entry.

Our example flow here has a func method, we might implement the handler for that like this:

def func(name, options={})
  add_test(name, options)
  add_flow_entry(name, options)
end

Over and above that what happens next is very domain specific and depends if any processing or sanitizing of the options or names are required to produce an accurate document. Some domain specific examples from the simple flow in this guide would be:

By default any options passed to the add_test method will be rendered into the attributes column. In our case we are supplying the bin as a flow line option and that will already be displayed in the dedicated column when it is passed to the flow entry. To inhibit the bin appearing in the test attributes we can screen the options like this:

# Add a test to the collection
def add_test(name, options)
  # Delete any keys that we don't want to assign to the instance, this keeps
  # the attributes column clean, flow control keys will be screened by Origen automatically
  [:bin, :some, :other, :keys,
  ].each { |k| options.delete(k) }
  tests.add(name, options)
end

As noted in the above comment any keys related to flow control will be automatically screened and handled by Origen (doc helpers knows how to display this information to).

Another convention from the above example was that we did not supply a test number and it was automatically set to a multiple of the bin number, we can handle that like this:

# Add a flow entry
def add_flow_entry(test, options)
  options = sanitize_flow_options(options)
  flow.test(test, options)
end

def sanitize_flow_options(options)
  # If the number has not been set in the flow then set it to a multiple of the bin, if present
  options[:number] ||= options[:bin] ? options[:bin] * 1000 : nil
  options
end

Note that many of the methods involved in processing the test options such as the sanitize_flow_options method here would be common to all interfaces and therefore should not need special handling specifically for documentation. Rather you should create a common module that gets included into all interfaces to handle the non-tester-platform specific concerns like these.