Re: [myhdl-list] Setting "sig.next" before starting the simulation

[Nick P. <np...@in...>]

On Tue, Oct 07, 2003 at 11:28:52AM +0200, Jan Decaluwe wrote:
> 
> Yes, sorry, I got carried away with implementation issues.
> In fact, the real question to you is: is it important that
> you can schedule signal updates pre Simulation construction
> time, or can you live with the way it is now.
>

No, scheduling updates before the construction of Simulation is not
important. I'm perfectly ok with being able to schedule events after
constructing but before starting the simulation.
 
> 
> They cannot (in a single thread) nor would this be intended behavior.
> The only issue is that a suspended simulation may have pending events.
> In the implementation, the event lists are "global" - they don't belong
> to the Simulation object. The only problem is that pending events from
> a suspended simulation should not carry over to a new fresh one. 
>

Oh, now I see. Before starting a simulation, one should make sure that
there are no "residue" signal-updates from a *previous* simulation
run. If this previous run is from the same simulation-object, then
it's ok to simply resume. If it's from another object then it would be
better to "clear" any pending updates. Currently you achieve this by
clearing all pending updates when the simulation is constructed:

This is ok:

  sim1 = Simulation(...)
  sim1.run(100)
        <------------------ suspended
  sim1.run(100) <---------- safe!


  sim1 = Simulation(...)
  sim1.run(100)
        <------------------ suspended
  sim2 = Simulation(...)
        <------------------ pending events cleared
  sin2.run(100) <---------- safe!

But what if:

  sim1 = Simulation(...)
  sim2 = Simulation(..)
  sim1.run(100)
        <------------------ suspended
  sin2.run(100) <---------- not safe!

If I'm getting this right, then I would personally prefer to have the
least amount of "hidden" behavior. That is no hidden global
"simulation object registries and such". Furthermore I would lean
towards doing everything explicitly (though not very
strongly). Something like this:

  sim1 = Simulation() <---- scheduled updates not cleared
  sim1.clear()        <---- clear pending updates
  sim1.run()

Better still, since scheduled updates are *global* "clear" should not
be a method of the simulation object:

  sim1 = Simulation() <---- scheduled updates not cleared
  sim_clear_pending() <---- clear pending updates
  sim1.run()

/npat

-- 
A commune is where people join together to share their lack of wealth.
  -- Richard M. Stallman