Runtime Environment

Introduction

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 $dut.

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 $tester. 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.