Subject: Re: Resolving timer/cross scheduling ambiguity using posttimestep
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Jul 09 2001 - 17:17:54 PDT
> From owner-verilog-ams@eda.org Mon Jul 9 09:38:14 2001
>
> Such a proposed mechanism would probably cause more
> trouble than worth. For example,
> period = 5;
> @(timer(start_time,period)) begin
> period=10;
> end
> V(xxx)<+ F(period):
>
> which "period" does it use in F?
Thanks for boiling it down :-)
> The problem can be solved through careful implimentation
> or use of bound_step in the timer block.
>
> In any language, complications occure if not used correctly.
> We tried to eliminate such in the Verilog_a LRM.
> The mechanism proposed below would open up new problems
> which would need new proposed mechanisims. For example,
> to solve the above ambiguity, we may have to define a new
> type of variable which is set temporarily in a block, then reset
> to the original value (which would probably lead to even more
> complicated rules).
I'm not sure that it is that unclear, looking at it from a "digital"
perspective for the deltas in which the 'timer(start_time,period)' is
active I would expect the statements in the block apply in sequence
with the rest of the process i.e. at the timer statement it is 5 and
at the assignment it is 10. As far as I can tell the parameters to
timer are pass-by-value, not pass-by-reference (in this case?).
If you called it 'x' instead of 'period', you would just assume that
whoever coded it was being lazy about declaring extra variables.
The question for the original example is then: can 'initial step' and
'timer(...)' be active at the same time, and is the '@(timer(...))'
block active for all deltas at a given real time and/or all those
within the given tolerance, or just the first?
Also, can you stop a timer by giving it a period like NaN or something
<= 0.0?
Kev.
> Peter Liebmann
>
> > Reply To: schandra@asc.corp.mot.com
> > Organization: Motorola Australia Software Center
> > X-Mailer: ELM [version 2.5 PL5]
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> >
> > Hi Committee Members,
> >
> > This is regarding the ambiguity in the LRM regarding scheduling mechanism
> > for cross and timer events.
> >
> > Problem: LRM does not specifically clarify when events (cross/timer) should
> > be evaluated and scheduled.
> >
> > The arguments start_time and period are dynamic expressions and it should be
> > clarified how the changes to these arguments affect the simulation and when
> > these values are evaluated and scheduled.
> >
> > Example:
> >
> > module blackbox(...);
> > ...
> > ....
> > rreal start_time;
> > real period;
> >
> > analog begin
> > @(initial_step) begin
> > start_time = 0.0;
> > period = 3.0;
> > end
> > ...
> > ...
> > period = 4.0;
> >
> > @(timer(start_time, period) begin
> > period = 6.0;
> > ...
> > end
> > ...
> > period = 5.0;
> > ...
> > end
> > endmodule
> >
> > In the above example it is not very clear what the period would be when the
> > timer statement is evaluated...
> > If the timer "fires", is the next event scheduled with period=3.0, 4.0, 5.0
> > or 6.0?
> >
> > We are trying the address the above scheduling problem with the following
> > proposal:
> >
> > Scheduling of Events as Post-TimeStep Operation:
> > -----------------------------------------------
> > Event statements inside an analog block would be evaluated post timestep to
> > avoid ambiguity in the values assigned to the dynamic expressions namely
> > start_time and period.
> > The event statement "@" would be evaluated after evaluating all the statements
> > inside the "begin-end" analog block and the latest value for the dynamic
> > expression would be used. In the case of the event "firing" and these dynamic
> > expressions changing inside the event block (period=6.0) in the above set of
> > statements, the values set inside the event block would be used to schedule the
> > future events.
> >
> > The changes to the dynamic expressions would not affect the current time step
> > and would take effect only on the next time step.
> >
> > <Include above example>
> >
> > In the above example, the statement @timer(...) would be evaluated after all
> > the statements are evaluated in the analog block as a post timestep operation.
> > When the timer statement is evaluated the value of start_time will be 1.0,
> > and events would be scheduled with a period of 5.0 (last evaluated value of
> > variable "period"). In case the timer event fires on that time step, the timer
> > events would be scheduled with a period = 6.0.
> >
> > cheers,
> > Sri
> > --
> > Srikanth Chandrasekaran
> > EDA Solutions and Products SBU
> > Phone: +61-8-8168 3592 Fax: x3501
> > email: schandra@asc.corp.mot.com
> --
> Peter Liebmann
>
> Antrim Design Systems, Inc.
> Tel. 831-430-4804
> Fax. 831-430-1904
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop D3-677, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Jul 09 2001 - 17:20:50 PDT