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

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

Nick Patavalis wrote:
> On Sun, Oct 05, 2003 at 09:55:58PM +0200, Jan Decaluwe wrote:
> 
>>Nick Patavalis wrote:
>>
>>The confusion can be avoided by only accessing 'next'
>>attributes after Simulation construction. My implicit
>>HDL-inspired assumption is even that this should only
>>happen after starting the simulation. This is easily
>>implemented by only accessing a signal's 'next' 
>>attribute within generators registered with the Simulation.
>>
> 
> 
> My intention was for it to be possible to control the "debugging"
> behavior of blocks, *while* the simulation is running (f.e. when a
> complex system enters a certain state, then a special block that
> monitors this enables the "debugging" controls of other blocks). Of
> course in the simplest case I would like to be able to *initialize*
> the debugging signals before starting the simulation, without having a
> special block for this. What I'm looking for is a way to set initial
> signal values at a post-construction, but pre-simulation time. 

[terminology note: in the following, I will use the term 'signal assignment'
to refer to an access to a Signal's 'next' attribute.]

Assuming that what you mean is post Simulation construction, that
should work with the tool as it stands today. Only assigning signals
after simulation start is just how I tend to think about it, but 
it's not a requirement.

Your original issue was caused by a signal assignment
pre Simulation construction.

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

This would allow one to do things like:
> 
>   sig = Signal(bool(0))
>   sig.next = 1
> 
> which would be *functionally identical* to:
> 
>   sig = Signal(bool(0))
>   sig.val = 1
> 
> without having to make "val" writable.
> 
> 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.

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

What do you think?

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