Subject: Re: Clarification on NOW and BREAK
From: Craig Winters (cwinters@cadence.com)
Date: Thu Oct 11 2001 - 12:55:36 PDT
Mark Zwolinski wrote:
> Therefore the Tc=Tn step synchronizes the two simulator
> cores.
Mark,
I agree this is a core concept that ought not to be tampered with.
However, in the example from the LRM, section 5.4, p 87:
library IEEE;
use Ieee.Math_real.all;
entity source is
generic (Amplitude: REAL; Freq: REAL);
port (quantity Sine: out REAL);
end entity source;
architecture Sinusoid of source is
limit Sine: REAL with 0.05/Freq;
-- ensures that there are at least 20 analog
-- solution points per period of the sine wave
begin
Sine == Amplitude * sin ( Math_2_pi * Freq * NOW );
end architecture Sinusoid;
it seems clear that NOW is intended to return the analog solver time when
used in an analog context. This code would not make sense if NOW was
stuck at Tc for an arbitrary sequence of analog solution points. We need
some way to access analog time either through redefinition of NOW or by
a new builtin function.
>
>
>> 2. Can a break occur in a simultaneous statement?
>>
> The definition of a sequential_statement includes wait, break etc
> statements. This is contradicted by the note quoted by Tom. By reading
> the text you can see that these statements cannot occur in a procedural
> and (to respond to Craig's follow-up email) by implication (!!) in
> subprograms called from a procedural.
I am glad to see the implicit ban on breaks in subprograms called from a
procedural. There is still the question of simple simultaneous statements
calling functions that contain breaks. The wait statement contains a
specific ban on occurrences in functions or their descendants.
A similar ban on the break statement would close off that path and
constrain breaks to the digital context.
Thank you for your attention to this issue,
Craig Winters
Cadence Design Systems
cwinters@cadence.com
This archive was generated by hypermail 2b28 : Thu Oct 11 2001 - 13:03:28 PDT