ModelSim & Multithreading

[Dek]

Hi all,

do you know anything about Multithreading with Modelsim PE student
edition? I'm simulating with a big testbanch and it takes a lot of
time, but I see that vsimk.exe uses just 50% of CPU; since I have a
dual core processor I think that for simulations Modelsim is using
just one core. The question is: is there a setting or something to use
both cores?


Thanks


Bye

 

[Kim Enkovaara]

Dek wrote:

dual core processor I think that for simulations Modelsim is using
just one core. The question is: is there a setting or something to use
both cores?

There is no such setting, not even in the SE version or Questa. If you
are heavily dumping waveforms etc. then the waveform writing can be
threaded, and at least in the expensive versions it is threaded as a
default.

--Kim

 

[Marcus Harnisch]

Dek <daniele.dequal@gmail.com> writes:

do you know anything about Multithreading with Modelsim PE student
edition? I'm simulating with a big testbanch and it takes a lot of
time, but I see that vsimk.exe uses just 50% of CPU; since I have a
dual core processor I think that for simulations Modelsim is using
just one core. The question is: is there a setting or something to use
both cores?

Currently EDA tool makers seem to agree that the overhead of
resynchronizing many individual simulation threads back to the HDL
timing model is simply too big to make it worthwhile.

But I am sure you have more than just one test... Just run simulations
concurrently.

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[Petter Gustad]

Marcus Harnisch <marcus.harnisch@gmx.net> writes:

Currently EDA tool makers seem to agree that the overhead of
resynchronizing many individual simulation threads back to the HDL
timing model is simply too big to make it worthwhile.

Synopsys VCS claims 2X performance increase on multicore CPU's:

"VCSŽ multicore technology delivers a 2x verification speed-up that
helps users find design bugs early in the product development cycle.
VCS multicore technology cuts down verification time by running the
design, testbench, assertions, coverage and debug in parallel on
machines with multiple cores."

http://www.synopsys.com/tools/verification/functionalverification/pages/vcs.aspx


If you can partition the design so that you minimize the latency
intensive communication (this might result in dynamic partition and
process migration) you should be able to archive a decent speed
increase.

An FPGA is a parallel processor where each LE is a small processor
element. However, the latency between each LE is extremely short,
which is not the case for some memory, or even network attached bus.
Hence the challenge is to hide the latency. A very complex problem,
which is very difficult to bolt-on to an existing simulator. Probably
easier to design from scratch, but still very complex. Hopefully we
will see more parallel simulators in the future.


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Marcus Harnisch]

Petter Gustad <newsmailcomp6@gustad.com> writes:

Marcus Harnisch <marcus.harnisch@gmx.net> writes:

Currently EDA tool makers seem to agree that the overhead of
resynchronizing many individual simulation threads back to the HDL
timing model is simply too big to make it worthwhile.

Synopsys VCS claims 2X performance increase on multicore CPU's:

"VCSŽ multicore technology delivers a 2x verification speed-up that
helps users find design bugs early in the product development cycle.
VCS multicore technology cuts down verification time by running the
design, testbench, assertions, coverage and debug in parallel on
machines with multiple cores."

But that's not really simulation threads. Other vendors claim similar
things (wave form dump in a separate thread).

If you can partition the design so that you minimize the latency
intensive communication (this might result in dynamic partition and
process migration) you should be able to archive a decent speed
increase.

I guess the "If" is a significant issue. The analysis might be
costly. But there is more than just this optimization task, which is
difficult enough I gather. Another requirement in simulation is the
capability to rerun a test *exactly* the same way it was executed
before. Having the simulation run in different threads in an
inherently non-deterministic environment (OS, other processes) and
putting these threads into a deterministic execution sequence almost
contradicts itself. I am sure EDA vendors are racking their heads for
a solution to this.

It is much less of an effort to running several simulations in
parallel. You can do that today.

Kind regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[Petter Gustad]

Marcus Harnisch <marcus.harnisch@gmx.net> writes:

"VCSŽ multicore technology delivers a 2x verification speed-up that
helps users find design bugs early in the product development cycle.
VCS multicore technology cuts down verification time by running the
design, testbench, assertions, coverage and debug in parallel on
machines with multiple cores."

But that's not really simulation threads. Other vendors claim similar
things (wave form dump in a separate thread).

Synopsys talks about both Application Level Parallelism (ALP) and
Design Level Parallelism (DLP). The latter is simulation threads. The
former might not be. However, I haven't used this version of VCS so I
can't verify what Synopsys are saying in their FAQ's, press releases
etc.

If you can partition the design so that you minimize the latency
intensive communication (this might result in dynamic partition and
process migration) you should be able to archive a decent speed
increase.

I guess the "If" is a significant issue. The analysis might be

Yes. It's easy to imagine a design consisting of two small modules
where one input is fed into the other and vice versa. Both depend upon
the others output and the latency would hurt the performance and you
would probably not split it across two cores/processors.

However a design where a testbench is generating stimuli for the DUT
and the data are all inputs to the DUT it would be feasible to split
the two across multiple processors depending upon the bandwidth of the
data to go from the stimuli generator to the DUT.

The analysis is costly and it might be difficult to determine on
compile time in many cases, e.g. the toggling frequency of some input
might be a function of external data.

difficult enough I gather. Another requirement in simulation is the
capability to rerun a test *exactly* the same way it was executed
before. Having the simulation run in different threads in an
inherently non-deterministic environment (OS, other processes) and
putting these threads into a deterministic execution sequence almost
contradicts itself. I am sure EDA vendors are racking their heads for
a solution to this.

I can't see why it's so difficult to keep track of thread statistics
and synchronization points (should probably be simulator option) so
you can re-run the simulation on the same processors etc. but possibly
resulting in lower performance since the loads of the other processors
might be different from the previous runs.


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Kim Enkovaara]

Marcus Harnisch wrote:

difficult enough I gather. Another requirement in simulation is the
capability to rerun a test *exactly* the same way it was executed
before. Having the simulation run in different threads in an
inherently non-deterministic environment (OS, other processes) and
putting these threads into a deterministic execution sequence almost
contradicts itself. I am sure EDA vendors are racking their heads for

In theory the language should protect from this, the event rules are
defined in the LRMs. And I think VHDL will be easier in this context
because it is harder to do hazards in VHDL.

But for Verilog this will be a real problem. Many commercial
behavioral verilog models very often assume many things that are not
guaranteed by the LRM (order of process execution etc.). Quite often
"-keep_delta -compat" flags are needed in modelsim to get verilog models
to work.

But I would guess that the parallel execution will be done at least on
design unit level. And most problematic language uses are usually
contained inside design units, and the perimeter is pure synchronous
logic.

--Kim

 

[Marcus Harnisch]

Kim Enkovaara <kim.enkovaara@iki.fi> writes:

In theory the language should protect from this, the event rules are
defined in the LRMs. And I think VHDL will be easier in this context
because it is harder to do hazards in VHDL.

Likely. But honestly, who cares.

But for Verilog this will be a real problem. Many commercial
behavioral verilog models very often assume many things that are not
guaranteed by the LRM (order of process execution etc.).

That is the point. EDA tools are written with Verilog in mind. It has
got to work with Verilog and, worse because of additional timing
phases, SystemVerilog. Everything else is secondary to EDA vendors.

Nobody would implement such a feature for VHDL, saying that Verilog
support was planned for a future release.

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)