4

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.?

uint128_t
  • 8,664
  • 6
  • 26
  • 28
Alex Krish
  • 49
  • 1
  • 1
  • 7
  • 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. –  Jun 06 '16 at 11:52
  • @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. – Alex Krish Jun 06 '16 at 11:59
  • 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. – scary_jeff Jun 06 '16 at 12:11
  • Around 50 signals. The trigger and timer events sum upto around 32 signals. I have only the required code running. I have a separate testbench with the required modules. – Alex Krish Jun 06 '16 at 12:17
  • It seems like a relatively small design so I am very surprised at this simulation speed. What version of ModelSim is it and what processor/RAM have you got? Are you running in a VM? – scary_jeff Jun 06 '16 at 12:25
  • Are you using a full version of ModelSim Altera Edition (AE)? The Starter Edition (ASE) has no optimization. – Paebbels Jun 06 '16 at 12:31
  • Unfortunately, its a starter edition. And the signals are upto 50 after removing the unwanted signals for the test. Its Modelsim Altera Starter Edition 10.4b. – Alex Krish Jun 06 '16 at 12:49
  • 1
    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? – Martin Thompson Jun 06 '16 at 14:52
  • 2
    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](https://www.altera.com/products/design-software/model---simulation/modelsim-altera-software.html) faster). Use a slower clock where possible. –  Jun 06 '16 at 17:41

5 Answers5

2

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.

A. Kieffer
  • 289
  • 1
  • 8
  • Yes. I am using only constants for the counters. Maybe yes accelerating the clock should help. – Alex Krish Jun 06 '16 at 12:19
  • Lowering the value of your constants will accelerate the simulation without changing the behavior – A. Kieffer Jun 06 '16 at 12:25
  • 2
    Initialise the constants with a function containing the following : `-- pragma translate_off return 50; --pragma translate_on return 500;` instead of commenting things out... (scuse formatting in comments. Synthesis will ignore the simulation value. –  Jun 06 '16 at 14:23
  • 2
    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. – alex.forencich Nov 17 '16 at 02:15
0

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.

dwikle
  • 966
  • 7
  • 7
0

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.

PlayDough
  • 188
  • 6
0

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

houssemus
  • 1
  • 2
    Can you please elaborate, add some detail like how can you disable showing the errors. And please use punctuation, sentences starts with capital, etc. – Bence Kaulics Nov 15 '16 at 21:16
0

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.

LimpingGabriel
  • 1
  • 1