Subject: Re: Clarification on NOW and BREAK
From: Mark Zwolinski (mz@ecs.soton.ac.uk)
Date: Fri Oct 12 2001 - 01:56:00 PDT
Craig,
I agree with what you're saying. You can't write sensible models without
redefining NOW. But at present, NOW with a return of type DELAY_LENGTH
and NOW with a return of type REAL will return the same time, (subject
to rounding). (This is aimed at the working group.) If the standard is
changed such that the REAL version of NOW returns Ti, then the two forms
of NOW may return different times. We need to tread very carefully -
this may not be a problem, but we don't yet know.
Craig Winters wrote:
>
> 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
-- =================================================================== Dr Mark Zwolinski Electronic System Design Group Tel. (+44) (0)23 8059 3528 Dept. of Electronics & Computer Science Fax. (+44) (0)23 8059 2901 University of Southampton Email. mz@ecs.soton.ac.uk Southampton SO17 1BJ, UK http://www.ecs.soton.ac.uk/~mz
This archive was generated by hypermail 2b28 : Fri Oct 12 2001 - 02:21:22 PDT