Validating STIL Files Before Sending to Test Teams
STIL files that are unvalidated could contain hidden issues downstream and only be discovered late by the test team on the physical tester. Not only the time span can be lengthy and causing schedule slippage, but also the problems are more expensive to fix; let alone having a process that is not efficient. TSSI’s high performance software tools have unique capabilities to automate this pre-silicon validation process.
Step-by-Step Validating Process Using TSSI Solstice-PV Module
1. Launch WaveMakerPLUS GUI
Change directory to where your test cases are (in this case ‘tssi-cisco’), and assuming a successful installation
of Solstice-TDS was done, the following command will launch its GUI:
2. Select a Pre-set Flow
On the left-hand pane (the File Browser), look for a pre-set flow (“Scenario”) named solstice-pv-stil0404.scn and double click on it to open.
A flow should appear on the right-hand (“Scenario Canvas”) as shown in the screen shot above.
3. Working with the Scenario
In the Scenario, you’ll see the left most item is the STIL file with the older date indicating a prior version you would like to validate against a newer revision.
To its right is an operation called “still in” (stands for STIL In-Converter) which will read the source STIL file into a database named “gb0404.wdb”.
The database will, in turn, be fed into a “solstice pv” operation so it can be instantiated in a Verilog testbench for re-simulation. We named it “testbench-04040.v”.
Click on the icon highlighted in the screenshot below to run the Scenario and the source STIL file will be converted to the database, and a Verilog testbench will also be produced.
Similarly, the second STIL file can be converted the same way. You can try to construct a Scenario yourself as an exercise, or use our pre-set Scenario, solstice-pv-stil1609.scn. Just double click on it to open the Scenario.
Click on “Run Scenario” to convert the second (newer date) STIL file to its corresponding database (gb1609.wdb) and testbench file (testbench-1609.v).
4. Validation Methodologies
TSSI offers 3 ways of checking your STIL patterns.
4.a. Instant Waveform Comparison
After running the two pre-set Scenarios, you should now have two databases corresponding to the two source STIL files: gb0404.wdb and gb1609.wdb.
Double click to open one database, say, gb0404.wdb, and you’ll get a visualization of the waveforms from the “04042019.stil” file.
Now select and drag the gb1609.wdb onto the gb0404.wdb waveform display, and you’ll get a composite waveform display like the screenshot below.
This is our 1st methodology: instant waveform comparison.
Click on the highlighted “Find” icon, and select “Difference”, and the Waveform editor will advance to each discrepancy of the two waveform databases (as in the screenshot below).
This methodology gives you a quick way to identify differences from STIL to STIL generation.
4.b. "NullDUT" re-simulation
NullDUT, as the name implies, is a Verilog DUT model with all the pad-level port definitions, yet without the actual functionalities of the DUT. NullDUT is automatically generated by Solstice-PV based on the signals found in the source STIL file.
There’s a dual purpose for this NullDUT. 1) As simulation usually takes a long time, in the first set up, a NullDUT can provide a quick way to validate the simulation set up and the proper connectivity between the test patterns and the DUT top module; 2) Users of test patterns validation (such as in this case) normally don’t get easy access to the DUT model and the simulation environment.
So in this set up, we have produced, merely from the STIL file, a NullDUT (to represent the Verilog model of the device-under-test), and the Verilog testbench to connect the NullDUT to the test patterns (in this case, the database which will supply the sstimulus/responses to the DUT at runtime).
NOTE: A NullDUT re-simulation is expected to fail because there won't be responses coming from the "empty" DUT. However, the drive activities can be validated as the first inspection via simulation reports and visualization.
4.c. STIL Patterns Re-simulation with the Actual DUT Model
In our set-up sent back to design, because we don’t know the DUT environment, we have followed the NullDUT re-simulation route.
Also, because we don’t know which simulator your design team is using, we picked Mentor Questa.
After running one of the TSSI Scenarios mentioned above, a script is generated. In this case, it’s named runMentor (because we selected Mentor simulator).
To re-simulate the STIL pattern against the design’s DUT model, the designer can modify the runMentor script to plug in the real DUT (as opposed to the NullDUT), include all the dependent libraries, and the re-simulation can reveal the quality of the STIL pattern in question.
5. Advanced Topics
Solstice-TDS is designed to process enterprise strength design-to-test applications. There are many advanced methodologies in the tool suite to process hundreds of incoming STIL files automatically and optimizing common timings.
Also, once you have access to the real DUT’s simulation environment, you can specify the DUT name and related information to Solstice-pv for automatic generation of a testbench and script that’s ready for a complete re-simulation with the real DUT as described in 4.c above.
The actual test case is available for download here: [tssi-cisco.tgz]
Contact firstname.lastname@example.org for any questions you have.