origen_sim is an Origen plugin that enables semiconductor test patterns written in Origen/Ruby to be run in a dynamic Verilog simulation.

It provides a simulation tester driver which replaces the conventional Origen ATE tester drivers in order to pass requests to drive or expect pin values onto a simulator intead of rendering them to an ASCII file. Since the application-level Origen code is the same in both cases it guarantees that what happens in the simulation and in the final pattern are the same.

For debugging, origen_sim supports the injection of regular Ruby debugger breakpoints anywhere in the pattern source code. This will halt the simulation at the given point in time and thereby allow it to be interatively debugged at the Ruby-source-code level.

For further documentation on how to use origen_sim and to learn about its capabilities, see the website: http://origen-sdk.org/sim

How To Create a Simulation Object For Development of OrigenSim

From an OrigenSim workspace:

Select the environment you wish to use, e.g.:

origen e environment/cadence.rb

Run the following command to build a simulation object from this example device:

origen sim:build_example

Run a simulation to check that it is working:

origen g test

Repeat the above steps to recompile after making any changes to the VPI extension.

Summary Of Operation

Here are some technical details on how origen_sim works, hopefully with enough detail to enable other engineers to contribute to its future development.

origen_sim provides components that can be compiled into a simulation object along with the design under test (DUT), a high level view of the process looks like this:

The main Origen Ruby process is invoked by generating a pattern as usual, e.g. origen g my_pattern, but with the environment setup to instantiate an instance of OrigenSim::Tester instead of say OrigenTesters::V93K. The origen_sim tester will start off a Verilog process in parallel which will run a simulation on an object that has been created beforehand. This simulation object contains the DUT wrapped in an Origen testbench, and which has been compiled into a snapshot/object that also includes a Verilog VPI extension which provides a communication interface between Origen and the simulation world.

When the simulation process starts, the VPI extension immediately takes control and halts the simulator while it listens for further instructions from a Linux socket which was setup by origen_sim at the same time that the simulation was started. As the Origen pattern generation process executes, the OrigenSim::Tester will translate any requests to drive or expect pin values, or to generate a cycle, into messages which are passed into the Linux socket. Upon receving these messages, the VPI process will manipulate the testbench's pin drivers to drive or read from the DUT and it will advance time by a cycle period every time a cycle is generated in the pattern. The testbench to wrap and instantiate the DUT is generated by origen_sim and it provides a standard interface through which Origen can access any DUT.

In principle the DUT object can be any design that is wrapped by a conventional top-level RTL description. Meaning that origen_sim can be used to run digital simulations, or mixed-signal simulations on DUT objects that contain more complex analog modelling.

The Testbench

The testbench is quite simple and it does little more than instantiate the DUT module and connects all of its pins to instances of this pin driver module. The testbench module is named 'origen' and all origen_sim simulation dumps have this same top-level structure:

origen
     |--debug        # Contains an error count and other debug aids
     |--dut          # The DUT top-level
     |--pins         
           |--tdi    # Driver for the TDI pin (for example)
           |--tdo    # Driven for the TDO pin and so on
           |--tck

The driver contains a number of registers which are written to directly by the VPI process, allowing it to drive or expect a given data value (stored in origen.pins.<pin>.data) by writing a 1 to origen.pins.<pin>.drive or origen.pins.<pin>.compare respectively. If the value being driven by the pin does match the expect data during a cycle, then an error signal will be asserted by the driver and this will increment an error counter that lives in origen.debug.errors[31:0].

The VPI Extension

Register Syncing