This is a significant feature addition to Origen sim which allows pin output values for a subset of pins/vectors to be sampled during an Origen simulation. This is then captured and converted to the corresponding expect data when generating the pattern for the ATE.
The intended use case is to make it extremely easy to use Origen to generate patterns in cases where the DUT response is hard to predict and/or complex to model.
Capturing is really easy, just wrap the operation you want to capture in your pattern source code like this:
tester.sim_capture :cmd55, :dout, :test_bus, :tdo do
dut.pins(:din_port).drive!(0x1234_5678)
dut.cmd.write!(0x55)
60.cycles
end
The first argument is an ID for the capture, this can be anything but the user must assign it.
Then supply a list of pin/pin_group IDs (or pin objects) that you want to capture.
If you use the same ID more than once it means that the same captured data will be used in multiple places.
When you add this to the pattern an error will be raised if you try to generate an ATE pattern, this will advise that the data has not been captured yet and it must be run in a simulation first.
When you run it in a simulation for the first time, the data will be captured and stored to your application in the pattern/sim_capture directory. These files should be checked into your application as if they were regular patterns.
On subsequent simulation runs, the data will not be captured but instead will be re-played from the simulation - i.e. the pattern will assert that the DUT outputs what is in the capture file.
In other words, by adding this and then simulating twice using the same command, you are both capturing and then verifying the captured data.
Add this switch to update the captures during a subsequent simulation run:
origen g my_pattern --sim_capture
To use the captured data in an ATE pattern, simply switch to an ATE target and generate as normal.
Below are the current known limitations of this feature. All could be resolved with additional effort, but not sure if it is really required.
The pin state data is sampled at the end of a cycle, not at the point during the cycle where it is read by the pattern. Note that if this was to be a problem you would see it when re-playing the captured data in simulation.
Nested capture blocks are not supported and will raise an error.
Other general improvements:
Re-enabled support for Icarus Verilog under the new build system from #5, including wave prompt/preparation like we have had for Cadence.
Added a command to easily re-compile the verilog extension and then compile it into the example DUT that is used for testing this plugin - origen sim:build_example. See the README for more info.
Removed the example RTL into its own repo. This eliminates any licensing concerns from including such 3rd party code in this repository - https://github.com/Origen-SDK/example_rtl
Significantly improved the origen sim:build command. It gives better output advice on what the user should do next and it should now automatically identify the top-level DUT RTL module in most cases.
Made pin forces defined within Origen application code be applied by the Origen process instead of being hardcoded into the generated testbench. This makes it universal for all simulators and means that it can be changed at Origen application level without having to recompile the simulation object.
Documentation - None is included here, but once this is released I am going to so some videos and add a proper simulation section to origen-sdk.org
xnappo
commented
6 years ago
This is a significant feature addition to Origen sim which allows pin output values for a subset of pins/vectors to be sampled during an Origen simulation. This is then captured and converted to the corresponding expect data when generating the pattern for the ATE.
The intended use case is to make it extremely easy to use Origen to generate patterns in cases where the DUT response is hard to predict and/or complex to model.
Capturing is really easy, just wrap the operation you want to capture in your pattern source code like this:
The first argument is an ID for the capture, this can be anything but the user must assign it. Then supply a list of pin/pin_group IDs (or pin objects) that you want to capture.
If you use the same ID more than once it means that the same captured data will be used in multiple places.
When you add this to the pattern an error will be raised if you try to generate an ATE pattern, this will advise that the data has not been captured yet and it must be run in a simulation first.
When you run it in a simulation for the first time, the data will be captured and stored to your application in the
pattern/sim_capturedirectory. These files should be checked into your application as if they were regular patterns.On subsequent simulation runs, the data will not be captured but instead will be re-played from the simulation - i.e. the pattern will assert that the DUT outputs what is in the capture file. In other words, by adding this and then simulating twice using the same command, you are both capturing and then verifying the captured data.
Add this switch to update the captures during a subsequent simulation run:
To use the captured data in an ATE pattern, simply switch to an ATE target and generate as normal.
An Origen vector pattern format has been introduced to capture the data, here is the example from this application's test case: https://github.com/Origen-SDK/origen_sim/blob/4788459f695e5f26ada6e85f8dd6fba80a8780d0/pattern/sim_capture/default/cmd55.org I'm going to document this in an RFC soon, so won't discuss further here.
Below are the current known limitations of this feature. All could be resolved with additional effort, but not sure if it is really required.
Other general improvements:
origen sim:build_example. See the README for more info.origen sim:buildcommand. It gives better output advice on what the user should do next and it should now automatically identify the top-level DUT RTL module in most cases.Documentation - None is included here, but once this is released I am going to so some videos and add a proper simulation section to origen-sdk.org