Typically an Origen application will contain source code to generate IP that can be applied to many different products, and/or which can run on many different test platforms. It is the job of the target and the environment to setup the runtime conditions that will define what combination of product and tester platform will be targeted by the generated output.
The target is normally used to define the product side of the runtime environment, with one
target file existing for every product/device that the application supports.
Target files are usually very short and normally just instantiate the model of the target
device, assigning it to the global variable
For test engineering applications, the test platform selection is usually handled by environment
files. These are very similar to target files and there is usually one per supported test
platform. Each environment will typically instantiate the target tester model/driver, assigning it
to the global variable
For non-test engineering applications, the environment layer can either be omitted or
else it can be used to define whatever other global state makes sense to be applied across
multiple device targets.
Additionally, Origen has the concept of an operating mode and this can be considered a third component of the runtime environment.
Before compiling any template, or generating any pattern, test program or other source file, Origen will do the following:
- Apply the active mode
- Execute the active environment file
- Execute the active target file
This means that the active environment can override the active mode, and that the active target can override both the mode and the environment.
This sequence will be repeated between jobs if multiple files are being compiled/generated by a given Origen thread of execution (each source files is an individual job). This prevents model state from a previous job from carrying over to the next one and ensures that the output is never affected by generation order.