Re: [myhdl-list] Setting "sig.next" before starting the simulation
Brought to you by:
jandecaluwe
From: Nick P. <np...@in...> - 2003-10-06 20:17:14
|
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). 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? > >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! 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)? 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". 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? /npat -- Developing skills that depend on a proprietary product makes you a sharecropper on your own brain. -- Donald B. Marti Jr. |