Test Program Generator

Introduction

Origen provides a powerful object-oriented test program generator which has a unique architecture which fully separates an application’s test flow logic from its implementation on a given test platform.

This architecture offers many advantages but most notably:

• It is extremely efficient. Adding additional tests is very quick after you have initially bootstrapped your program generator, in many cases only requiring one line to be added to your source code.
• It keeps you sane. As test flows and programs get larger and larger it really helps to be able to use object-oriented programming techniques to keep everything organized.
• It eliminates bugs. The architecture encourages you to write the least amount of code possible to create a new test, this maximizes the re-use of working code and reduces the number of moving parts and opportunities for bugs to occur.
• It supports multi-platform and documentation. The same test flow source file can be used to generate the program on different platforms, including creating documentation of the test program.
• Dynamic custom code is supported. Custom VB/C++ code can be compiled through Origen, this eliminates the need to keep DUT configuration information in your test program code - write it to support a single device, then modify it later to work with another configuration with Origen.

An overview of the program generator architecture is shown below:

Origen provides a rich generator for each supported platform, this takes care of all formatting concerns and tries to automate some details of the platform API which can be particularly error prone - for example flow control logic.

The application then provides a Flow file which contains a behavioural description of each test and the order that they should be executed in. Note that there should be no consideration given to the underlying platform implementation of the test at this level, the job of the flow is to describe the electrical properties of each test and pattern dependencies, but should not worry about things like test instances, interpose functions, test methods, etc.

The application must then provide an interface which has the job of translating the flow definition to the one or more of the target test platform APIs. For example the interface may say “ok when the flow asks for a functional test then create a new patset, create a new functional test instance which will reference that patset, setup the instance based on the electrical properties of the test, and then finally add an entry in the flow sheet”.

In this way the tedium of having to create a test instance, then a pattern set, then a flow entry, then go back to the test instance because you named the pattern set wrong, etc, etc…is eliminated along with many opportunities for errors.