ModelSim & Multithreading

Discussion in 'VHDL' started by Dek, May 7, 2009.

  1. Dek

    Dek Guest

    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
     
    Dek, May 7, 2009
    #1
    1. Advertising

  2. 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
     
    Kim Enkovaara, May 7, 2009
    #2
    1. Advertising

  3. Dek <> 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)
     
    Marcus Harnisch, May 7, 2009
    #3
  4. Marcus Harnisch <> 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?
     
    Petter Gustad, May 8, 2009
    #4
  5. Petter Gustad <> writes:

    > Marcus Harnisch <> 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)
     
    Marcus Harnisch, May 11, 2009
    #5
  6. Marcus Harnisch <> 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?
     
    Petter Gustad, May 11, 2009
    #6
  7. 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
     
    Kim Enkovaara, May 12, 2009
    #7
  8. Kim Enkovaara <> 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)
     
    Marcus Harnisch, May 12, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Boris Condarco

    Multithreading

    Boris Condarco, Jun 28, 2003, in forum: ASP .Net
    Replies:
    5
    Views:
    605
    Boris Condarco
    Jun 30, 2003
  2. Ilia
    Replies:
    6
    Views:
    3,009
    John Saunders
    Nov 4, 2003
  3. Fieldadvice

    Multithreading with HttpWebRequest

    Fieldadvice, Nov 6, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    1,349
  4. Muralidharan Ramakrishnan

    MultiThreading

    Muralidharan Ramakrishnan, Nov 10, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    415
    Kevin Spencer
    Nov 10, 2003
  5. BoomWackaBoom

    Asynchronous requests vs. multithreading

    BoomWackaBoom, Nov 14, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    636
    Alvin Bruney
    Nov 15, 2003
Loading...

Share This Page