4
\$\begingroup\$

How can I get Modelsim to run faster for simulation rather than something in the picosecond range (time interval)? Are there any other methods for speeding up simulation? It takes 45 minutes to get to 1ms as of now. I want the simulation to run for 20 ms to check on certain counters, timer modules and events. The system clock runs at 50 MHz.

And if there is an option will there be any drawbacks. For example missing events etc.?

\$\endgroup\$
9
  • \$\begingroup\$ The prime approach is unit testing : if you want to test a counter, test it in isolation. By the time you're running 20ms of full system operation you should have a high degree of confidence you won't need to run the test much more than once. \$\endgroup\$
    – user16324
    Jun 6, 2016 at 11:52
  • \$\begingroup\$ @BrianDrummond Yes I have done that already. And there are counters which depend on other counters too. Also events are triggered at specified time intervals which need to be tested. \$\endgroup\$
    – Alex Krish
    Jun 6, 2016 at 11:59
  • \$\begingroup\$ How many signals are you logging in the wave window? Does your design include code that is not necessarily relevant to the particular test you are running? For example, a UART test might not actually care what an SPI slave interface is doing. \$\endgroup\$
    – scary_jeff
    Jun 6, 2016 at 12:11
  • 1
    \$\begingroup\$ How much is your time worth? Upgrading to a "not-starter" version of Modelsim will probably get you 10x improvement... Or can you try GHDL? \$\endgroup\$ Jun 6, 2016 at 14:52
  • 2
    \$\begingroup\$ The resolution limit (IEEE 1076-2008 5.2.4 Predefined physical types) doesn't cause slower simulation. You don't 'execute' every time step, events are scheduled. Simulation time is advanced to the next scheduled event (14.7.5 Model execution). Slow simulation comes from the number of events (clock speed) vs. duration, model size, host platform performance, and can be intentional (Modelsim-Altera Starter Edition - the paid version is 33 percent faster). Use a slower clock where possible. \$\endgroup\$
    – user8352
    Jun 6, 2016 at 17:41

5 Answers 5

2
\$\begingroup\$

This is a really common issue for all FPGA developers. Here are my advice (there are probably many other).

First you can decide to watch only few signals, so that the calculation will run faster. You just need to separate your design into smaller modules (or only look at one process after one).

Or you can define different constants for simulation like this:

CONSTANT MY_CONSTANT : integer := 50; -- for simu
--CONSTANT MY_CONSTANT : integer := 500; -- for real

Doing this for every counter can really make you save time.

And finally you can obviously accelerate your clock too.

\$\endgroup\$
4
  • \$\begingroup\$ Yes. I am using only constants for the counters. Maybe yes accelerating the clock should help. \$\endgroup\$
    – Alex Krish
    Jun 6, 2016 at 12:19
  • \$\begingroup\$ Lowering the value of your constants will accelerate the simulation without changing the behavior \$\endgroup\$
    – A. Kieffer
    Jun 6, 2016 at 12:25
  • 3
    \$\begingroup\$ Initialise the constants with a function containing the following : -- pragma translate_off <return> return 50;<return> --pragma translate_on <return> return 500; instead of commenting things out... (scuse formatting in comments. Synthesis will ignore the simulation value. \$\endgroup\$
    – user16324
    Jun 6, 2016 at 14:23
  • 3
    \$\begingroup\$ I doubt that 'accelerating the clock' will do anything. These simulations are usually event driven, where the clock frequency is completely arbitrary, only the number of edges. \$\endgroup\$ Nov 17, 2016 at 2:15
0
\$\begingroup\$

Ensure that your timescale and time precision are set appropriately for your design. If the system clock is 50 Mhz, you do not need 1ps resolution. By reducing the time precision the simulator will evaluate fewer events and it should help the simulation speed.

For Verilog, use the timescale directive:

`timescale 1ns/100ps 

The first argument is the timescale - this will be used as the unit when using delays such as #10. The 2nd argument is the time precision.

For a 50 Mhz design where that is the highest frequency you need to simulate, 1ns/100ps would be appropriate.

For VHDL, I don't recall how this is controlled, and if it's a language construct or tool specific. But the same concept holds.

\$\endgroup\$
1
  • \$\begingroup\$ Is it the same as changing timescale resoluition in Modelsim. For example vsim -t 1ns ? \$\endgroup\$
    – Alex Krish
    Jun 6, 2016 at 13:40
0
\$\begingroup\$

Depending on your install, your simulator resolution may be picosecond by default. Check your modelsim.ini and look for the Resolution variable under the [vsim] header.

Alternatively you can force the resolution on the command line. Your are very close with your example. The syntax is vsim -t ns for nanosecond resolution.

Note that the Verilog timescale is very different in VHDL. Since time is a unit in VHDL, the time reference nature of timescale isn't meaningful (all wait for ... have an explicit time, not implicit like Verilog's #). The resolution parameter for Modelsim is more analogous to the precision in timescale, but rounded down to the smallest precision. So if you use a Verilog timescale that dwikle suggested, Modelsim will use picosecond resolution.

Now, if your clock cycle is 50MHz, then you'll need at least nanosecond precision.

\$\endgroup\$
0
\$\begingroup\$

i just come here to see the issue of simulation speed. i just disabled showing errors in Trascript section during simulation, and it got much faster. just try it

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Can you please elaborate, add some detail like how can you disable showing the errors. And please use punctuation, sentences starts with capital, etc. \$\endgroup\$ Nov 15, 2016 at 21:16
0
\$\begingroup\$

In case anyone sees this again, disabling messages by going into Simulate > Runtime Options > Message Severity and checking all boxes under "No Display Message For" sped up the simulation substantially for me. I think flushing the text to the terminal took substantial amounts of time.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.