Subject: Re: Clarification on NOW and BREAK
From: Tom Kazmierski (tjk@ecs.soton.ac.uk)
Date: Fri Oct 12 2001 - 02:22:57 PDT
Craig,
One might argue that since the semantics of the break statement
(and also other statements, such as the wait statement) have only been
defined for a process context, so it is implied that these
statements are banned from other contexts. However, I generally
agree with your point that we should state it explicitly.
We may want to add words such as "neither the simultaneous statement itself, nor
any procedure of which the simultaneous statement is a parent, may contain
a break statement, a wait statement, ( etc.) ". I shall liaise with Ken and Ernst
to see how we should go about corrections/clarifications of this kind formally.
Your point about NOW and Ti seems to highlight a genuine technical omission
and may require a change to the LRM more substantial than just a semantic
clarification. Ernst has already said he will set up a tracking procedure, which is
an important first step. We also need a good discussion on the reflector possibly
followed by a paper for the WG.
Thanks for raising these points.
Tom Kazmierski
At 16:56 11/10/2001, Craig Winters wrote:
>Tom Kazmierski wrote:
>
>>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."
>
>I am aware of this rule, but does it exclude the case of a break statement in a
>subprogram called from within the simultaneous procedural statement?
>
>More generally, is the following function valid:
>
>FUNCTION foo (x : Real) RETURN Real IS
>BEGIN
> BREAK WHEN x < 0.0;
> RETURN x;
>END;
>
>If it is, then could it be called from a simultaneous statement (simple or procedural)
>with the argument being a quantity value?
>
>If that is the case, then a break can occur between iterations of the
>analog solver, which is the case I am hoping to rule out.
>
>Thank you for your prompt response.
>
>Craig Winters
>Cadence Design Systems
>cwinters@cadence.com <mailto:cwinters@cadence.com>
This archive was generated by hypermail 2b28 : Fri Oct 12 2001 - 02:35:08 PDT