• Guides
  • Videos
  • Publications
  • API
  • Github
  • Community
  • Release Notes
  • Plugins
Installing Origen
  • Introduction
  • How to Install
  • How to Install (Windows)
  • Company Customization
  • Understanding Gems
  • Invoking Considerations
  • Workspace Management
Getting Started with Origen
  • Core concepts
  • Creating a New App
  • Directory Structure
  • The Initial Commit
  • Creating New Files
  • Understanding Blocks
  • Application Architecture
Runtime Environment
  • Introduction
  • Mode
  • Environment
  • Target
  • Production Targets
  • Global Setup
  • Load Order
  • Programming
Models
  • Introduction
  • Naming
  • Definition & Hierarchy
  • Adding Attributes
  • Versioning
  • Bugs & Features
  • Package, Mode & Configuration
  • Registers
  • Pins
  • Power Domains
  • Hardware Attributes
  • Parameters
  • Specifications
  • Fuses
  • Generic Components
  • Creating Your Own Components
Compiler (Views)
  • Introduction
  • Creating Templates
  • Using Sub-Templates
  • Helpers
  • Running The Compiler
  • Inline Compiler
Controllers
  • Introduction
  • Shadow Controllers
  • Direct Controllers
Pattern Generator
  • Introduction
  • Creating Patterns
  • Pins
  • Timing and Waiting
  • Registers
  • Documenting Patterns
  • Generating by Name
  • Common API
  • J750 API
  • V93K API
  • UltraFlex API
  • STIL & Other Formats
  • Custom Testers
  • Running The PatGen
  • Concurrent Patterns
Test Program Generator
  • Introduction
  • Philosophy
  • Creating Flows
  • Managing Flow Control
  • Creating an Interface
  • Additional Resources
  • Dynamic Custom Code
  • Characterization API
  • J750 API
  • V93K Common API
  • V93K SMT7 API
  • V93K SMT8 API
  • UltraFLEX API
  • Documenting the Program
  • Creating Custom Testers
  • Running the ProgGen
Decompilation
  • Overview & Example
  • Decompiling, Adding Pins, & Executing
  • Working with Decompiled Patterns
  • Platform Specifics
Simulation
  • Introduction
  • How It Works
  • Compiling the DUT
  • AMS Support
  • Environment Setup
  • Application Setup
  • Simulating Patterns
  • Simulating Flows
  • Direct DUT Manipulation
  • Simulator Log Output
  • Artifacts
  • Debugging
Documentation Generator
  • Introduction
  • Markdown
  • Linking
  • Styling
  • Testing
  • API Generation
  • Deploying
Plugins
  • Introduction
  • Using a Plugin
  • Creating a Plugin
  • Current & Default Plugins
  • Dev Environment
  • Dev Considerations
  • Paths & Origen.root
  • Config & Origen.app
Miscellaneous
  • Revision Control
  • Origen Remotes
  • Lint Testing
  • Session Store
  • LSF API
  • Users, Emails & Maillists
  • Utilities & Helpers
  • Ruby Extensions
  • Logger
  • Adding Commands
  • Overriding Commands
  • Callbacks
  • Application Callbacks
  • Miscellaneous Topics
Advanced Topics
  • Introduction
  • Invocation Customization
  • Custom App Generators

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 Markup

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):

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.

Test Number HBin SBin Attributes Description
measure_vreg
#45000 B45
  • Vdd: min

Any comments in here will attach as a description to the next test

vreg_func1
#50000 B50

This is a description of what this test does

vreg_func2
#55000 B55
  • iload: 50E-06

All comments can contain markdown, for example

  • A bulleted
  • list

Documenting Structure

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:

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.

Test Number HBin SBin Attributes Description
measure_vreg
#45000 B45
  • Vdd: min

Any comments in here will attach as a description to the next test

Functional Tests

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.

Test Number HBin SBin Attributes Description
vreg_func1
#50000 B50

This is a description of what this test does

vreg_func2
#55000 B55
  • iload: 50E-06

All comments can contain markdown, for example

  • A bulleted
  • list

Dynamic Documentation From Helpers

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

Creating A Documentation Interface

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.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license