RE: [Fwd: Re: Is there an ISAC meeting today?]

I have some concerns regarding IR2123.

1. Permitting implementations to optimize process wake up 
   so that the callbacks need not trigger when the wait 
   condition is false, will lead to differences in behavior 
   between tools. 

2. I think the LRM should describe expected behavior, and not 
   be concerned about optimization that implementations can 
   potentially do. 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 
   things in such a way that there is no observable 
   difference for a user. Why should the current issue be 
   treated differently? 

These were the only two issues I initially had. However, after 
reading the proposed changes to the LRM wording again, I have 
an additional concern. If you really look at it, this issue 
should only have an observable impact on VHPI users. 

However, the proposed wording in the LRM is:

  "An implementation may optimize execution of a wait statement in such
  a way as to obviate some or all resumptions of the suspended process
  due to events on signals in the sensitivity set provided that, when
  an event occurs on any signal in the sensitivity set and that event
  would result in the condition in the condition clause evaluating to
  TRUE, the process does resume."

Process resumption is a key concept in VHDL, and I would like to 
see a simple and clear definition. I am concerned that the LRM 
has to mention implementation-specific optimizations. I do realize 
that the only observable impact this can have at the moment is on 
the VHPI callbacks. But for conceptual clarity and to avoid 
possible semantic issues in future, I would prefer not to mention
the permissible optimization at this place. I would be much less 
concerned if we say elsewhere that the VHPI callbacks may be 
optimized away when the condition is not true.

Having said that, I have always believed that the VHPI is the most 
competent body to address the callbacks issue. While I was 
personally not happy about the decision, I voted in the ISAC to 
approve the VHPI recommendation. However, I do believe that the 
concerns voiced in the ISAC should be captured in the IR when it 
goes for vote to the VASG. 

Regards,

-ajay
 
 

-----Original Message-----
From: owner-isac@eda.org [mailto:owner-isac@eda.org] On Behalf Of Peter
Ashenden
Sent: Friday, April 04, 2008 3:51 AM
To: isac@eda.org; vhpi-pilot@eda.org
Subject: RE: [Fwd: Re: Is there an ISAC meeting today?]

Since John and Francoise cannot attend and it's well-nigh impossible to
find a reasonable time for a meeting in all four timezones, can we try
to work through the issue by email? Perhaps we could start with each
interested party summarizing their understanding and providing a
position statement indicating how they would like the issue resolved
(which may mean no change from the current IR wording). If you do a
reply-all to this message, you'll cover both the ISAC and VHPI groups.

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, 4 April 2008 08:04
> To: isac@server.eda.org
> Cc: Francoise Martinolle; Shields, John
> Subject: [Fwd: Re: Is there an ISAC meeting today?]
> 
> 
> Should we meet?
> John and Francoise can't attend,  and
> the primary reason for the meeting is to get feedback from VHPI.
> 
> Chuck Swart
> 
> 
> --
> 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.