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

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

On Mon, Oct 06, 2003 at 08:50:24PM +0200, Jan Decaluwe wrote:
> Nick Patavalis wrote: 
> >Why doesn't sim.run() or the Simulation() construction simply set "sig.val
> >= sig.next" before starting? 
> 
> sim.run() will cause this for all signals that are in the list of 
> signals to be updated, as usual. As long as signal assigments are
> done after Simulation construction, they should work as expected.
> 

As long as this is a "sanctioned" feature, and not an implementation
by-product, then I'm fully covered! (in your previous post you seemed
to imply the later, rather than the former).

What I still fail to see, is that since you *do* allow signals to be
scheduled for update before a "sim.run()", how would this be different
if you *also* allowed signals to be scheduled for update before the
simulation construction?

> >To state it differently what I would like to do, is:
> >
> >A function creates some signals, instantiates some blocks, and
> >connects them to the signals. Obviously the signals have some default
> >initial values. The function then returns the instances (the
> >generators) and the signals (some of them) to the caller. The caller
> >changes the *initial values* of some of the signals returned to it,
> >and starts the simulation.
> >
> >>From what you say this isn't possible.
> 
> All this should be possible! However the paragraph above seems to
> touch another issue: exposing internal signals, as you have described
> in another post - correct? I will answer that issue there.

Yes, indeed. Lets keep things separate.

> Coming back to the original issue. The implementation is perhaps
> overly restrictive by always clearing the signals-to-be-updated list
> in a Simulation construction. What I want to avoid is that pending
> events from a suspended simulation interfere with a new one. But this
> can also be done as follows:
> 
> - a Simulation construction does not clear the list, but bails out
> with an error when it is not empty; 
>
> ... AND there is a still another 
> non-stopped Simulation object around. (Otherwise there would be no gain.)
>
> - a Simulation that stops "naturally" should not have any pending
> events, so the list should be empty (check with an assertion);
> - a suspended simulation can have pending events because it can be
> resumed. Add a stop() method to the Simulation class that clears
> the list and makes the Simulation unrunnable. Thus: suspended 
> simulations need to be stopped explicitly before a new Simulation
> can be constructed.
>

Sorry but this is a bit over my head!

How exactly do you define a "stopped" and how a "suspended"
simulation?  How can a simulation enter one or the other state?
Furthermore, how can a simulation know at construction-time whether
there *is* another simulation around (let alone know whether it is
stopped or not)?

I assume that "stopped" is a simulation that finished its
"sim.run(1000)", and returned; so there are no related signals for
which "sig.val != sig.next", so to speak. In this sense a stopped
simulation is in no-way different from a just-constructed, never-ran
simulation.

A suspended simulation, on the other hand, should be one which was
stopped by a "StopSimulation" exception, so for some related signals
(the ones modified by the block that raised the exception) it might be
that "sig.val != sig.next".

But wait! I have more fundamental problems than this!

Assuming that you have two simulation objects (in the same interpreter
I presume), how can they *both* be running at the same time? How could
they interact?

/npat

-- 
Developing skills that depend on a proprietary product makes you a
sharecropper on your own brain.
  -- Donald B. Marti Jr.