Re: Topics and Ideas for BS Project

I'm afraid that you are, and I'm trying to be polite here, completely
wrong. SystemC does not operate the way that you think it does, and
neither do VHDL nor Verilog. All three define simulation semantics in
what is fundamentally exactly the same way.

Some simple Googling might convince you. Look up any thread that
discusses an endless loop which hangs up a Verilog or VHDL simulator.
How is this even possible with your world view?

2 minutes on Google found a simple explanation of how event-driven
simulation works, from Janick Bergeron. This is exactly what I've said
several times in this thread, but you may find it more believable from
Janick; see
http://groups.google.co.uk/group/comp.lang.vhdl/browse_frm/thread/3941f0c5edac84fa/ae8567e741594acb?lnk=st&q=endless+loop+group%3Acomp.lang.vhdl&rnum=6&hl=en#ae8567e741594acb

I quote:

>Because simulators must emulate things that occur in parallel on a
>single thread machine, they must perform something similar to
>timesharing on the workstation you probably use. Each process gets the
>simulation engine (CPU) and runs until it explicitely suspends itself
>via a wait statement. Because all processes are run in a sequential
>fashion (since there is only 1 CPU), time must not advance between
>evaluation. If signals are assigned in zero-time, time must not
>advance for the next cycle either.
>
>Because simulators are not timeshared and assume that every process
>will cooperate and release the engine eventually, you might get stuck
>if a process fails to execute a wait statement. It is to prevent this
>common mistake and give an indication as to what is going wrong that
>some simulators have a delta cycle limit that cause a *break* when
>that limit is reached, not a time advance.

This really is pretty basic. Janick wrote this 12 years ago, so the
details of single-processor/single-thread have changed, but the basics
are exactly correct.

I'm happy to discuss this with you if you have a specific objection,
or can demonstrate that the SystemC kernel does not also behave in
this way (and it most emphatically *does*), but it really isn't
helpful to add lots of irrelevant extras when replying to posts.

Evan

In news:98c073t4kmbr3mcc4rqfdvuf1rjtouljpd@4ax.com timestamped Wed, 13
Jun 2007 19:31:14 +0100, Evan Lavelle <nospam@nospam.com> posted:
     "I'm afraid that you are, and I'm trying to be polite here,"

Thank you for being polite.

     "completely
     wrong. SystemC does not operate the way that you think it does,
     [..]

     [..]"

What did I say that is wrong?

     "Some simple Googling might convince you. Look up any thread that
     discusses an endless loop which hangs up a Verilog or VHDL simulator.
     How is this even possible with your world view?
     
     2 minutes on Google found a simple explanation of how event-driven
     simulation works, from Janick Bergeron. This is exactly what I've said
     several times in this thread, but you may find it more believable from
     Janick; see
     http://groups.google.co.uk/group/comp.lang.vhdl/browse_frm/thread/3941f0c5edac84fa/ae8567e741594acb?lnk=st&q=endless+loop+group%3Acomp.lang.vhdl&rnum=6&hl=en#ae8567e741594acb
     
     [..]"

Did I deny event-driven simulation exists? It is possible for
event-driven simulation to be implemented concurrently and for
simulated time to not advance at all due to an infinite number of
delta cycles stuck in a feedback loop. Paul J. Menchini gave an
example of such a feedback loop in the same thread you cited.

     "[..]
     
     I'm happy to discuss this with you if you have a specific
     objection,"

Thank you.

     "or can demonstrate that the SystemC kernel does not also behave in
     this way (and it most emphatically *does*),"

I never said that it does not also have delta cycles.

     " but it really isn't
     helpful to add lots of irrelevant extras when replying to posts."

Sorry, I did not intend to add irrelevant extras. I am not sure which
ones I did, but here may be a few examples which I did not think were
irrelevant but if you want you can save time by ignoring the rest of
this post: I was asked "what is SystemC(R)?" so I explained that I am
supposed to use a registered trademark symbol and that I am supposed
to refrain from using "SystemC" as a noun; it was claimed that Unix
runs one process at a time without an admission that Unix can run more
than one process at a time and I was asked am I "aware of any VHDL or
Verilog implementations which exploit 'concurrent hardware'?" so I
showed evidence that a Unix clone can run more than one process and
that unfortunately NCSim does not exploit this; and you did not recall
"any specific discussions" from one of the SystemC.org forums about
how using a multiprocessor computer with an OSCI reference implementation
does not scale whatsoever so I showed two examples of such discussions.

Regards,
Colin Paul Gloster