RE: Clarification on NOW and BREAK


Subject: RE: Clarification on NOW and BREAK
From: Bakalar, Kenneth (kenneth_bakalar@mentorg.com)
Date: Thu Oct 11 2001 - 12:15:57 PDT


All,

I am the guilty party as far as errors in the definition of time in VHDL-AMS
is concerned. On first glance, I think Craig is correct: the definition of
the real function "now" should reference Ti, not Tc. But I have not gone
over all of the detail with enough attention to convince myself this is
necessary and sufficient.

In any case, it was our intent that "now" return the current simulation time
during the calculation of an ASP, not the simulation time of the last
digital event. For example, q==sin(math2pi*f*now); should create a clean sin
wave, with an accurate value during any ASP between two digital events no
matter how far apart those events are. The values of Ti depend on the
simulator time step between asp's(which is implementation dependent), but it
has a well-defined value at each asp -- it is the current value of the
independent variable.

I am also looking at the definitional problem with the break statement.
Craig is right, they must be forbidden in a subprogram whose parent
(recursively -- see analogous definition of parent at LRM 2.2) is a
simultaneous statement. A procedural is just a special case of a
simulataneous statement. I need to work out language to do that.

Ken

-----Original Message-----
From: Mark Zwolinski [mailto:mz@ecs.soton.ac.uk]
Sent: Thursday, October 11, 2001 2:08 PM
To: vhdl-ams@eda.org
Cc: Craig Winters
Subject: Re: Clarification on NOW and BREAK

Tom Kazmierski wrote:
>
> At 15:10 11/10/2001, Craig Winters wrote:
>
> 1. Definition of NOW and Tc
> | (...)
> | when the analog solver resumes at time Tc it simultaneously
> | resets Tn to a new value Tn' and determines a sequence of times
> | Ti in the interval [Tc , Tn']. Tn' is the lesser of Tn and the
> | least value in the interval [Tc , Tn] at which any signal
> | Q'Above(E) becomes contradictory. The times Ti must include Tn'.
> | At each time Ti the following steps occur:
> | ...
> | [none of these steps updates Tc]
>
> I believe you are right. The steps listed in section 12.6.6 should include
> an update of Tc=Ti in each cycle. This looks like a genuine omission so
> I would like to invite more comments from 1076.1 WG members.
>

I disagree. Tc is updated as part of the mixed-signal simulation cycle.
(12.6.4, step b). The analog simulator can run ahead of the digital
part. That is deliberate, because the analog simulator must be able to
backtrack (in the sense of rejecting a time step, cutting the step and
trying again). Therefore the Tc=Tn step synchronizes the two simulator
cores.

The NOW function is therefore defined (12.7) to return the last time at
which the analog and digital cores synchronized. It might be suggested
that NOW should return Ti, but note 2 of 12.6.6 says that Ti is not
specified by the language and are solely a function of the analog
solver. That might seem to be a mistake or limitation, but I think it's
entirely consistent with the design philosophy of VHDL-AMS.

The (digital) VHDL simulation cycle is (almost) entirely deterministic.
The simulation results returned by one VHDL simulator are defined to be
exactly the same as the results returned by another. In designing
VHDL-AMS, it was accepted that different analog solution algorithms
might be used. (More to the point, even if the algorithm had been
defined, there is no way that two implementations could be guaranteed to
produce identical results to the n-th decimal place, or indeed use the
same time steps.) This definition of NOW says, I think, that you will
get the same results for a mixed-signal simulation using different
simulators.

If you perform a purely analog simulation Ti takes the value of Tn and
Tc is updated to Tn, so NOW behaves as expected by Craig. If you perform
a mixed-signal simulation, NOW does not behave as expected. I don't
think there's any way round this within the language as defined. I would
be very wary of suggesting a change to the definition of NOW, because I
think there is a danger of starting down the road of defining the
algorithm used in the analog solver. However if the users of VHDL-AMS
say that the language as defined is not useful, then changes should be
considered.

> 2. Can a break occur in a simultaneous statement?
>
> You suggest further, that the LRM does not prevent a break from
> occurring in a procedural simultaneous statement. This is incorrect,
> as section 15.4 of the LRM quite specific:
>
> "(...) It is also an error if a wait statement, a break statement,
> or a signal assignment statement occurs in the procedural
> statement part."
>

Again I disagree. I don't think section 15.4 is worded as clearly as it
might be. (Hindsight is a wonderful gift here!) The syntax definition
says:

procedural_statement_part ::=
  {sequential_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. But it is not clearly stated.
What's needed is a definition of sequential statements allowed in a
procedural. When the standard is revised, the restrictions on sequential
statements needs to be stated explicitly in the syntax definitions.

-- 
===================================================================
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 : Thu Oct 11 2001 - 12:29:40 PDT