Accelerate your verification

Why my regression testing consumes more time? How can I reduce the run time of my regressions? Verification engineers usually ask these questions to EDA vendors. They even push the EDA vendors to increase the speed of simulator as much as possible. Yes its possible they can tune the simulator engine and achieve more performance. But this performance gain can't reduce week long regressions into hours. After all your simulator is a software that is executing everything sequentially on the processor.

You have increased the speed of simulator to its maximum limit. You are making the LSF load free and running the simulation. Still If you feel that your simulation is dead slow, then you need to think of your verification methodology and analyze your simulation process .

There are various other factors mentioned here impact the performance of your simulator.

Design Abstraction
-Behavioral models do not work at the signal level. They run much faster than RTLs and netlists.
- Well proven RTLs/IPs at the system levels can be replaced by their functional models.
- Verilog netlists are better than VITAL.
- Memory modeling - Huge memories can be modeled efficiently using dynamic memories. Memories modeled in HDLs occupy the RAM.

Testing mode
- Are you running simulation on performance mode or debug mode? - Refer my blog "Slow and Fast simulators"
- Assertions are good for 'White Box Verification' but they slow down the simulation speed.
Assertions at the subsystem/module level can be disabled for the SoC verification, especially for the regression testing.
Assertions that verify the interfaces, port connections and system protocols are sufficient to verify the system.
Based on the testcase failures, one can rerun the simulation in debug mode by enabling the assertions of buggy modules.
- Avoid using simulator TCL commands to generate stimuli.
Using TCL commands like 'force' need read & write access permissions which again reduces the performance
Enable the read/write access permissions selectively based on the need Ex: PLI access to particular design instance does not need read/write permission for the entire system.
- Avoid dumping log file and doing post processing
Testbench should be self-checking
- Avoid the compilation of DUT for every testcase

Verification Methodologies
- Avoid using HDLs for implementing complex testbenches
Ex: Testbench that needs to generate transactions like frames, packets etc
- Avoid using ad-hoc & traditional methodologies
Ex: Using C/C++ language based protocol checkers/ testcases, Using PLIs, Creating random stimuli using C functions etc.
- Use standard HVLs like SYSTEMVERILOG that works seamlessly with HDLs, without using PLIs. It provides DPI, OOP, Assertions, CDV etc., almost everything that you need for your verification ...

Most of the time we need to make use of the legacy testbenches. I also agree that you can't easily move away from the existing verification stuff. But if the project is a long term project, I urge you to consider seriously on re-architecting the testbench using latest verification technologies. One needs to plan meticulously on introducing the new methodologies. The best approach would be trying out these technologies on existing IPs and introducing them step by step.

Slow and fast simulators

I am not talking about the benchmarks that you do on different simulators and classify them as slow and fast simulators. I am talking about running the simulators on debug and high performance modes.

Play with your simulator switches and understand how you can run it at different speeds. Its like running your car at different speeds using different gears. You need to change the gear based on power and speed requirements. Similarly you need to change the simulator options based on verification requirements.

Why you need this debug and performance mode?
Generally all the simulators run on high performance mode by default. In this mode the simulator does not have to instrument the code and log many details. So this performance mode enables the simulator to run at its highest speed. But in this mode, you cannot debug your design through line stepping, break point setting, delta cycle analysis, wave form dumping etc. Always
run your regression tests on high performance mode. Finally rerun your failing testcases on debug mode.

I have seen many of my customers who run the simulator on debug mode which is normally 2X slower than running on performance mode, for their regressions. Sometimes they enable waveform dumping too that again slows down the simulator. Usually verification engineers use the scripts written by some PERL or shell script experts. Only few guys want to take a look on the simulator options that have been used in the script, before running the regressions.

As a smart engineer, you should always scan your script before using it. Talk to CAD team, EDA guy and the script owner and make sure that you understand the simulator options and script very well. Even if you are so busy with your project verification, still you have to spend some time on analyzing the scripts.

Hardware and Software configurations

Before measuring the efficiency of a simulator, one needs to check whether he has chosen the right hardware and software configuration.


The general guidelines for choosing HW & SW configuration which can increase the simulator performance are:
[1] Faster the processor, better performance. Multi-core processors can give more.
[2] L2 cache matters a lot for run-time
[3] Linux is better
[4] Opteron processors have built-in memory controller which helps simulators
[5] High speed disk drives like 10000 rpm would be very useful
[6] Fast DDR memory is critical
[7] Make sure that you have enough RAM so that the process does not swap - as it kills all performance.
[8] Large cache

Let us discuss about the various other factors that also affect the speed of the simulators in my next article.

SIMULATORS - Are they really fast enough?

Week long regressions are the main concerns of CAD and verification engineers when they have to deliver the product on time and meet TTM.CAD team will always look for high speed simulators and demand EDA vendors to tune their software engine to meet their run time requirements.


By looking at the technology changes of processors, memories and OS, I would say EDA vendors should really come up with new innovative methods and technologies to make their simulators powerful enough to exploit these new features of the latest hardware and software technologies. For example, if the simulator is not capable of utilizing all the cores of a processor innovatively to execute parallel processes and reduce the run time, then there is no benefit of changing the technology, like single core processor to core duo. If the technology of the simulator is not changing, it might even treat your big servers and machines that have high-end processors as only your old desktop PC.


At the same time, one should also understand that updating the hardwares and softwares of the simulation form is highly needed to expect more out of simulators. CAD team has to work closely with the EDA vendors and understand about their technology road map. They have to guide the project teams to use the right version of the EDA tools, understand the flows and methodologies. This will really help the design and verification engineers to use the EDA tools to the full extent.


Do you know how much you are paying for the EDA tools? Are you utilizing the EDA tools efficiently?


I am really surprised about the fact that many of the semiconductor industries do not even have proper CAD teams. Especially in India, we think that CAD team is needed just for managing the licensing issues. In many organizations, IT guys do the license management. But IT team cannot replace CAD team and CAD engineers can do much more on jobs like evaluating EDA tools, methodologies, integrating various point tools and creating the design flow etc. They can actually guide their management team to choose their preferred EDA vendor.


In my next article, I am going to explain how you can tune your simulator engine and run it at its maximum speed.