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

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

Nick Patavalis wrote:
> On Mon, Sep 29, 2003 at 09:23:42PM +0200, Jan Decaluwe wrote:
> [[[ refers to an off-list discussion ]]]
> 
>>Very nice work! I would gladly add it as an example to future
>>MyHDL distributions.
>>
>>Some upfront comments:
>>
> 
> 
> Sorry for taking so long to answer, but I was engaged in other
> activities that kept me away for several days. As I was trying to
> address your comments, and write a test-framework for mu0 (which is
> turning out very nicely), I came upon this strange behavior:
> 
>   from myhdl import *
> 
>   def gen_tst (db):
>       while 1:
>           yield delay(10)
>           if db.val: print "now = %d" % (now())
> 
>   def mktst():
>       db=Signal(bool(0))
>       g = gen_tst(db)
>       return g, db
> 
>   g, db = mktst()
>   db.next = 1
>   sim = Simulation(g)
>   print "db.val=%d, db.next=%d" % (db.val, db.next)
>   sim.run(50)
> 
> When I run this, I get:
> 
>   $ python2.3 tst.py
>   db.val=0, db.next=1
>   now = 10
>   now = 20
>   now = 30
>   now = 40
>   now = 50
>   SuspendSimulation: Simulated for duration 50
> 
> Which is fine. Now, if I comment-out the "print" line like this:
> 
>   from myhdl import *
> 
>   def gen_tst (db):
>       while 1:
>           yield delay(10)
>           if db.val: print "now = %d" % (now())
> 
>   def mktst():
>       db=Signal(bool(0))
>       g = gen_tst(db)
>       return g, db
> 
>   g, db = mktst()
>   db.next = 1
>   sim = Simulation(g)
>   # print "db.val=%d, db.next=%d" % (db.val, db.next)
>   sim.run(50)
> 
> Then I strangely get:
> 
>   $ python2.3 tst.py
>   SuspendSimulation: Simulated for duration 50
> 
> Is this supposed to happen?

What happens is the following. The Simulation constructor
clears a number of lists that are used during simulation.
One of these is the list of signals scheduled for updating.
This is done to avoid interference between multiple 
Simulation's that a single program may set up and run.

Thus, 'db.next = 1' schedules signal db for updating, but
the Simulation constructor clears this. The difference
in observed behavior is because a *read* access to 
'db.next' also schedules the signal for updating - this
is why the print statement makes a difference.

Scheduling an update on read access is necessary to
support statements like 'sig.next[i] = 1'. Here, the
'next' value is obtained by a read access but may 
be modified by an index assignment.

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.

In this particular case, I don't think there's a need to
use a signal for 'db'. A plain variable or Python's 
'__debug__' variable should do.

Regards, Jan

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