Re: [myhdl-list] Setting "sig.next" before starting the simulation
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2003-10-05 19:56:37
|
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 |