why RTL simulation is slow?

[zhangpengyu]

Hi

I want to know why RTL simulation is slow.
Who can help me,or gvim me some materials.
Thanks a lot!



zhpy

 

[niuniu]

what is your simulator? how big is your design? have your read the document on all the options.

 

[yeewang]

compared with what?
RTL simulation is fast enough in most case.

 

[eeeraghu]

RTL Logic is, what we code for consider synthesizable logic, and in this the simulator tool needs to check the logic, whereas in behaviour simulation we code according to the functionality and its fast compared to RTL simulation.
Hope this is true and might help u

regards
raghu

 

[vivek]

hi
the speed of ur simulation depends on your design complexity, simulator and the kind of test bench you use. Generally simulators like VCS are fast.
When you use HVL like VERA/Specman for testbench they will employ PLI for connecting with the HDL. This can make your simulation slow.

when you use many constraints in your testbench(in case of HVL) it can considerably slow down simulation because of the constraint solver. I have even seen CPU timeout due to complex constraints given for a VERA test bench, in earlier versions of vera (6.2.8 snd below).

Can someone tell about hardware acceleration?

 

[xuanzhu]

Comparing System C Simulation, RTL Simulation is much more slow, because they stand for different level architecture

 

[jimjim2k]

Comparing System C Simulation, RTL Simulation is much more slow, because they stand for different level architecture

Hi

What is your benchmark?
Would you please give us some comparison tables?


tnx

 

[icon]

can u tell me why gate level simulation is faster than RTL simulation...i mean in the context of a 12M gate design.

 

[Thomson]

Of course, the higher level, the higher simulation performance because the simulator doesn't need to store the large event data (for the ordinary event-driven simulator such as Verilog-XL, VCS without cycle option). Due to the higher level such as behavioral description hides the detailed design implementation and eliminates some unnessary timing events such as the intermediate signal event and other @ events, thereby speeding the performance.

In addition, cycle-based simulaotr will perform faster than the event-driven simulator if you have used NC-verilog VS. verilog-XL. Since the cycle-based simulation only advance the simuating time in terms of @posedge clock or @negedge clock, assuming that the setup and hold timing is okay and only captures the sampled value of the D input of the register by hiding the internal events for this D input.

Moreover, behairoal description can utilize some 2-state instead of 4-state logic representation, which will on one hand reduce the stored data , on the hand improve the simulation performance. Of course, this way can be employed by some tool options,e.g. VCS +two-state alike.

In all, since RTL description mainly focuses on the detailed hardware connectivity and implementation, which will inevitably slow the simulation performance compared with high-level coding.

 

[icon]

ok thomson.but when we go for hardware acceleratiopn/simulation acceleration
we wil get more speed on gate-level than RTL level.why is it so.i am talking about any processor based Hardware Accelerator

 

[amaccormack]

Becuase hardware accelleration only works on gate-level netlists it cannot be used for RTL (unless you synthesise it, obviously, but then its gate-level anyway). Therefore RTL simualtion always has to be in software. But if you simulate gate-level in software, it will be slower than RTL.

 

[Thomson]

but when we go for hardware acceleratiopn/simulation acceleration
we wil get more speed on gate-level than RTL level.why is it so.i am talking about any processor based Hardware Accelerator

Okay, you said right. Although I've never used hardware acceleration/simulation acceleration techniques, according to what I've learned that this tecnique is quite different from that software-based simulation technique.

Till now, if you prototype you design using FPGA-alike techniques(the only hardware-based technique i have used), you will have such feeling that the simulation is rather fast because it utilizes the actual(of course somewhat different, but you know, the design is implemented with the actual hardware library, but not fabricated using ASIC) during which the simulation performance is determined by the actual hardware frequency( in fact, this frequency is lesser than the ASIC, because some of the interface penalty and the characteristics of FPGA). This technique will invariantly work faster than the simulator.


I consider that hardware accelleration's performance is between the simulator and the prototyping techniques.


May this help solve your confusion!

Thomson

 

[icon]

so let me conclude by saying what i understood is

"If u r simulating ur RTL design in simulator it will take some x time(assume ) when u r simulating the same Gate level of the design the simulator will take more x ( i mean to say more time).so when u r applying both the design to your simulation accelerators/Hardware accelerators we can achieve more acceleration in gate level when comapred to the gate level simulation in our normal simulators."

i am using a hardware accelerator which is based on processor based and not on FPGA based.

 

[stocking]

RTL stimulation shold be more fast than netlist stimulation .

 

[icon]

yes stocking its correct..netlist simulation is slower when compared to RTL.we are discussing about the acceleration/Hardware acceleratoprs for simulation.

go thru entire conversation thn u will get an idea

 

[naveen reddy]

RTL simulation is fast compared to net list simulation
You did not specify with which you are comparing

DC is more faster for RTL simulation

 

[Thomson]

we are discussing about the acceleration/Hardware acceleratoprs for simulation.

Hi, icon
I refered to some books according to the hardware acceleration, and after that, i thought that hardware acceleration is not always simulating faster than software-based simulation as this methods will require some other over-heads. Currently, i'm not very clear about these overheads. But as you know when you simulate your design, you first compile/debug/run your codes which will comprise the total time. Although for the hardware acceleartion mechansim, the run time is eliminated to such extent; however the previous two may account much large portion of the total time.


Therefore, the book provided that only when you software simulation exceeds about 30-50 miniutes, then the hardware simulation will surpass the software simulation.

For the same type of simulation mechansim, i argued that hardware-based accelaration will always be better than the software simulation.

From this perspective, if you run your netlist( which is quite large) using hardware-based simulation, then the time required may be less than that requird by the RTL software-based simulation.

In all, only utilize hardware-based simulation when your performance is decided by the runtime. Good Recommendation: create your database about your project running time, then at an appropriate time select the suitable simulation mechansim.


Thomson

 

[junchaoguo51888]

the speed depong on u design and tool, RTL simulation is good enough

Added after 1 minutes:

may be u can give us a compare table for us

 

[beckchm]

you must see you testbench .

 

[andromeda]

RTL simulation is slow because:
- it emulates concurrency on sequential CPU
and there are less significant reasons like:
- Verilog or VHDL signals have several posible states and are much more complex then native CPU variables (need to be resolved, ...)
- if VCD file generation is enabled (in any format), it is much more slower due to all task related to waveform store and compress

2-state simulators speed whole thing few times because remove all those things related to signal resolve and Z and X states.

Hardware emulators speed whole thing using really concurrent hardware: FPGAs or DSP arrays.