A critical stage in creating a custom ASIC is verifying that it does 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 was 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 has developed a methodology that it calls its Performance Verification Environment (PVE) that enables it to create a Synopsys SystemC simulation model where various parameters can be easily tweaked to see what effect this has on the meeting of the desired performance specification. Each variant does not take long to 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. This enables Sondrel to successfully create many projects for customers as it is easy to deploy, faster and with less risk.

The methodology starts with using 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 on the left of the PVE illustration 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, as shown on the right of the flows illustration, 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 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 an 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.