Subject: Re: Resolving timer/cross scheduling ambiguity using post timestep
From: Dan FitzPatrick (dkf@synopsys.com)
Date: Tue Jul 31 2001 - 16:36:32 PDT
Hi,
Since I made some un-specific comments on the teleconference
regarding this thread I think I should follow up in more detail.
In looking at the follow-ups to this, I believe Kevin hit the
source of confusion by pointing out that arguments to the
timer operator (and others for that matter) are pass-by-value
and not pass-by-reference. I don't believe that this is a
divergence from Verilog behavioral semantics (not the same for
structural).
Whether we need to elaborate the manual or not someone else can
determine.
So the answer to the question posed below is always '4.0'.
The following based on pass-by-reference would be an unecessary
complication.
Regards,
--Dan
PS: Kevin's other comment re: confusion of '@' operator is
also valid - although probably doesn't make much sense to do
something about it at this point. particularily w/o an
alternative.
Srikanth Chandrasekaran wrote:
>
> 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(...);
> ...
> ...
> real 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
--Dan FitzPatrick | Voice: (425) 576-4105
This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 16:45:26 PDT