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

[Jan D. <ja...@ja...>]

Nick Patavalis wrote:
> 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).

It's a feature :-), no problem.
 
> 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?

I could do that, as long as I can make sure that no pending events
from a previous Simulation carry over to the next one. 

> 
> 
>>>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!

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.

> 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)?

A Simulation constructor could register it's object in some
"global" (user-hidden of course) place. 

> 
> 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".

Mm, the way I defined it, it's the other way around. "Stopped" is 
what happens when all events are exhausted, or when a StopSimulation
exception is raised by the user. Such as simulation cannot be 
resumed; it's done forever. "Suspended" is when there are still
pending events, but the specified duration has been reached. Such
a simulation can be resumed.

> 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?

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. 

In fact, as long as there is a living, suspended simulation, it should
not be possible to create a new one - I think I'll need to implement that.

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Bored with EDA the way it is? Check this:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html