Verification is a critical stage in creating a custom ASIC as it ensures what it is supposed to do and in the best way possible. Typically, this is done by synthesising RTL and running it to see how well it performs against the performance specification that were defined at the start of the design. By adjusting the design, the performance is improved with each RTL run but each iteration can take weeks to affect.
Sondrel's PVE enables it to create a Synopsys SystemC simulation model where various parameters can be 'tweaked' to see what effect this has on the meeting of the desired performance specification.
Each variant can easily be set up on the model and run in a few hours whereas trying to do each one with RTL simulations would take weeks for each variant. There is a trade-off between accuracy and speed as RTL simulations are more accurate but the speed of this new modelling approach in reaching an optimal configuration in only days far outweighs this and will enable Sondrel to create many projects for customers as it is easy to deploy, faster and with less risk.
The methodology uses the Exploration Platform to capture and export all the transaction traces into Sondrel’s PVE that uses a Python-in-SystemC embedding technology built on top of Synopsys VCS, Synopsis DVE and Synopsys Verdi products. It is also capable of supporting tools from other EDA vendors, namely, Mentor Questa and Cadence Xcelium.
The testbench compilation flow for PVE is shown in the PVE illustration below, and uses an RTL Compiler from one of the established EDA vendors, that takes the Sondrel PVE (formed from SystemC and Python code) and combines it with Generated RTL and Python 3.9 binary (that is available as Opensource). This creates a simulator snapshot as a single application, which is the final executable that is run to perform the test.
To run it, Use case traces are taken from a cycle-accurate, SystemC Simulation of the Architecture, and the System Architect provides a script to read the Use case traces and exercise the simulation with the output being FSDB Waveform Databases. These can be de-bugged, if necessary, using standard tools and methodologies defined by Verdi, DVE, Questa and Xcelium.
The benefits of this approach, according to Sondrel, are that subtle RTL issues become apparent that have not appeared in the Exploration Platform. This is because of the detailed simulations that the RTL simulation provides.
Also, this can be done in advance of the UVM environment being ready which gives early indication of whether the RTL can perform well or not. It is also quite easy for Architects and Performance Engineers to use this methodology as it mostly requires Python knowledge that is easier to acquire than, say, System Verilog - UVM.
