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