Subject: Re: Resolving timer/cross scheduling ambiguity using post timestep
From: S. Peter Liebmann (spl@antrim.com)
Date: Mon Jul 09 2001 - 09:08:24 PDT
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?
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).
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 LiebmannAntrim Design Systems, Inc. Tel. 831-430-4804 Fax. 831-430-1904
This archive was generated by hypermail 2b28 : Mon Jul 09 2001 - 09:25:17 PDT