Event Driven vs Cycle Accurate Simulators

[Frank]

Hi,

Thanks for this community, I learned a lot. As I dived more in this field, I got confused on two different types of architecture simulators. Could anyone explain me what's the difference between event-driven simulators and cycle-accurate simulators?

My understanding is, like SimpleScalar and GEM5, they simulate every cycle of the computer system, regardless there's an event or not in each cycle. But for the event-driven ones, there's an event queue that *stores* different events in the system, so from simulation perspective, the sim_cycle can jump A to B without going through every cycle between A and B.

Then it raises my question.. if what I says above is correct, why people still using cycle-accurate ones? Obviously event-driven simulators are more efficient.

Or, what's the disadvantage for event-driven simulators?

I tried Google, but haven't found an answer that is clear enough I think..

Thanks,
Frank

[Ivan Godard]

There are more than two possibilities. The distinction between
event-driven and non-event driven (also call a polling sim) is, as you
state, the maintenance of a future event queue in an event-driven, which
can improve sim performance if events are relatively sparse. On the
other hand, if events are dense then maintaining the queue has its own
costs.

The difference between cycle-accurate and non-cycle-accurate (also
called a functional sim) is whether timing is significant in the matter
being sim'd, or if only behavior is necessary. In some cases the timing
is needed to determine the function, and a timeless functional sim is
impossible. The Mill is an examply - the whole machine is statically
scheduled with exposed latency, so to discover what the program is doing
it is necessary to track how many cycles are spent doing what. A
machine without exposed timing, an x86 for example, need not care and
programs can be run on a pure functional sim.

For hardware sim, it usually necessary to go beyond cycle-accurate to
wall-clock accurate simulation because the behavior of the machine
depends on times that are not denominated in cycles. The Mill sim is a
pico-accurate sim, because it models the clock distribution system of
the machine, including the crystal frequency and the settings of the
PLLs. Asa a result, a simulated Mill program can use simulated MMIO to
change the setting of the simulated PLLs to change the simulated clock
frequency that it itself is running under. This approach is faurly
common in hardware sims where the goal is to explore the hardware
behavior as opposed to exploring the program behavior.

Lastly, the hardware guys use gate-level sims that have an even finer
window into the circuit layer than something like the Mill sim. Do not
hold your breath waiting for a gate-levekl sim to finish though.

Obviously the cross-product of the possibilities exist.

[Joe Pfeiffer]

It sounds like you've got the picture on what the difference actually
is: the one simulates all the events (if any) on each time step, while
the other maintains an event queue and processes the events as they come
to the head of the queue. I've written both, for different purposes...

When you're writing something like a register transfer level
hardware simulation, there will indeed be *something* happening on
every time step. It's a lot easier to just maintain the state of
something modelling the control for the whole system and update it every
cycle (and use it to control the simulated computational units), than to
try to maintain an event queue. Since the event queue ends up
triggering one or more events every cycle anyway, the effort spent
maintaining the queue is wasted.

[Frank]

Thank you all, I think I understand what you mean.

Frank

On Wednesday, February 12, 2014 8:54:00 PM UTC-8, Joe Pfeiffer wrote: