[Fwd: FW: ISAC: [Fwd: Issues resolution recommendation from VHPI]]

From: Chuck Swart - MTI <cswart_at_.....>
Date: Thu Mar 20 2008 - 19:28:57 PDT
I am forwarding Ajay's response to the VHPI issues for discussion at 
today's meeting.
Chuck


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


attached mail follows:



 

 
Peter and others,

I have a few comments, though the decisions appear to have already been
made by the VHPI team (who, I agree, are the most qualified to do this).

2123: I like the recommendation that a process should resume whenever
there is an event on a signal in the wait sensitivity. However, I am not
entirely happy about making the callback triggers optional. If this is
allowed, there are bound to be differences in simulator behavior, and at
a minimum, vendors will have to do some explaining. I also feel that the
LRM should just specify behavior, and not be concerned about aspects of
optimizing the language. There are many other areas where implementers
have optimized the actions that a tool has to do, either in a
non-compliant mode, or by modifying algorithms intelligently so that
there is no observable difference for a user. Why should the current
issue be any different? I think the best place to resolve this would
probably have been within VHPI itself. For example, the resume callbacks
could have an optional parameter to specify whether they should trigger
whenever the process resumes, or only when the wait expression evaluates
to true. This way, the choice is left with the user.

2124: I personally disagree with the recommendation from VHPI. The
relaxed ordering will mean that there is no way a VHPI user can
determine process ordering. I can think of situations where this may be
required, like when a shared variable is updated by multiple processes.
Also, if we go with the more constrained behavior, it can easily be
relaxed later. Once we allow the relaxed behavior, it may be more
difficult to constrain it.

Thoughts, anyone else?

-ajay




-----Original Message-----
From: owner-isac@eda.org [mailto:owner-isac@eda.org] On Behalf Of Peter
Ashenden
Sent: Saturday, March 15, 2008 3:30 PM
To: 'Chuck Swart - MTI'; isac@eda.org
Subject: RE: ISAC: [Fwd: Issues resolution recommendation from VHPI]

Folks,

Attached are draft analyses and recommendations for IR 2123 and IR2124
based on the VHPI team's recommendations.

For IR2123, their initial recommendation was that the LRM remain
ambiguous about whether a process is resumed to evaluate the condition
of a wait statement. However, on subsequent discussion, I think the
intention was that the resumption semantics be clarified, but that an
implementation be permitted to optimize resumption away. I've drafted
ISAC recommendations based on the latter approach.

For IR2124, the recommendation is clear that the relaxed ordering should
be permitted. I've drafted LRM changes accordingly.

I'd be pleased to discuss these by email ahead of next week's ISAC
telecon.

Cheers,

PA

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP:
sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106
 

> -----Original Message-----
> From: owner-isac@server.eda.org
> [mailto:owner-isac@server.eda.org] On Behalf Of Chuck Swart - MTI
> Sent: Friday, 14 March 2008 13:07
> To: isac@server.eda.org
> Subject: ISAC: [Fwd: Issues resolution recommendation from VHPI]
> 
> 
> These emails reflect conversations, mostly involving Peter, Francoise 
> and John concerning IRs 2123 and 2124
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 
> 

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Mar 20 19:29:34 2008

This archive was generated by hypermail 2.1.8 : Thu Mar 20 2008 - 19:29:37 PDT