Virtual models speed up ASIC verification

Virtual models speed up ASIC verification

Technology News |
By Nick Flaherty

UK chip designer Sondrel has developed a verification flow to easily develop virtual models to check its custom ASIC designs.

The Performance Verification Environment (PVE) creates a 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.

Verification is a a critical stage in creating a custom ASIC, and usually done by synthesising the high level RTL code and running it to see how well it performs against the original specification. By adjusting the design, the performance is improved with each RTL run. However each iteration can take weeks to check. Using the virtual model allows the designers to reach an optimal configuration in a few days, which can then be checked once in the RTL flow.

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 tools. It can also support tools from other EDA vendors such as the Siemens EDA Questa and Cadence Xcelium.

The testbench compilation flow for PVE 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 available as open source. This creates a simulator snapshot as a single application, which is the final executable that is run to perform the test.

Use case traces are taken from a cycle-accurate, SystemC simulation of the architecture and the System Architect provides a script to read the sse 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.

This can identify subtle RTL issues that do not appear in the Exploration Platform and can be done in advance of the verification environment being ready to give early indication of whether the RTL will 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 System Verilog.

Related articles

Other articles on eeNews Europe 




If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles