RE: Proposed response to your P1076 ballot comment

Bill,
 
Thanks very much for responding so quickly. I think option 2 is the most
likely to succeed. The ballot resolution committee is firmly of the view
that making VHPI completely optional is not feasible.
 
In a sense, the statement in option 2 is already implicit in the
specification of the VHPI. However, a Note to that effect in subclause 17.3
(where capability sets are described) would certainly make the implication
clear. I'd suggest the following wording:
 
Note---A minimal implementation of the VHPI need only provide the function
interface described in Clause 23 and Annex B, with none of the capability
sets described in this subclause being implemented by the tool. In such a
minimal implementation, calls to functions would, in most cases, raise a
VHPI error condition.
 
I would be grateful if you would confirm agreement with this compromise at
your earliest convenience.
 
Many thanks, and best regards,
 
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: Hanna, William A [mailto:william.a.hanna@boeing.com] 
Sent: Monday, 14 July 2008 23:19
To: Peter Ashenden
Subject: RE: Proposed response to your P1076 ballot comment



Dr. Ashenden: 

How R U? 

1. I have a lot of appreciation for VHPI, however, I find it difficult for
the average user/provider of VHDL to implement and use. For this reason, I
would like to see a language saying that a proper VDL implementation does
not have to include VHPI.

2. I would accept the compromise your E-mail suggests: "The ISAC notes that
a minimal implementation of the VHPI need not be burdensome. The VHPI
provides a means for a tool to provide a subset of the full VHPI capability
and for VHPI programs to query the capabilities provided by the tool (see
subclause 17.3 of D4.2). A minimal implementation need only provide the
function interface described in Clause 23 and Annex B, with none of the
capabilities described in 17.3 being implemented by the tool. Calls to the
functions would generally return an error indication."

If language is added to that effect, otherwise I will be compelled to keep
my No Vote. 

I look forwar to hear from you. Thanks. 

P.S. There is some typo's in the standard, I did not care to mention, and I
recommend informally a final check for typing errors and a final check for
consistency in numbering. Thanks again.

William A. (Bill) Hanna; Ph.D.EE 
Technical Fellow - Electronics Design&Analysis 
Boeing-IDS Programs                                   Phone: (314) 232-0714 
MC S106-3060                                                Mobile: (314)
302-8039 
St. Louis, MO 63166-0516    E-Mail: william.a.hanna@boeing.com 






-----Original Message----- 
From: Peter Ashenden [ <mailto:peter@ashenden.com.au>
mailto:peter@ashenden.com.au] 
Sent: Saturday, July 12, 2008 6:29 AM 
To: Hanna, William A 
Cc: isac@eda.org 
Subject: Proposed response to your P1076 ballot comment 

Dear Dr Hanna, 

Thank you for participating in the recent IEEE ballot on the revision of the
VHDL standard. As part of the ballot resolution process, the ISAC needs to
discuss with you the proposed response to your negative comment. Your
comment was:

  All references to VHPI should be made optional - should be removed 
  from body of the LRM into an Appendix. 

And your proposed resolution was: 

  Move VHPI to an Appendix - Annex and state that it is optional 

The ISAC has considered your comment and proposes not to implement your
suggestion. The rationale is as follows: 

The VHPI was incorporated into VHDL as an amendment, 1076c. Its inclusion as
an integral, non-optional part of the standard was approved by the balloting
body for the amendment project, and the amended standard was approved by
IEEE in 2007.

Specification of the VHPI requires some significant changes to details of
aspects of the language, notably, to the simulation cycle as specified in
Clause 12 of IEEE 1076c-2007. Making the VHPI optional would require
specifying and maintaining two versions of the simulation cycle, one without
VHPI and one with VHPI. This would be difficult and error prone.

The ISAC notes that a minimal implementation of the VHPI need not be
burdensome. The VHPI provides a means for a tool to provide a subset of the
full VHPI capability and for VHPI programs to query the capabilities
provided by the tool (see subclause 17.3 of D4.2). A minimal implementation
need only provide the function interface described in Clause 23 and Annex B,
with none of the capabilities described in 17.3 being implemented by the
tool. Calls to the functions would generally return an error indication.

I would be grateful if you would indicate whether this is acceptable to you
and whether, as a consequence, you would change your vote from Disapprove to
Approve. If not, would you like to offer any alternative proposal that the
ISAC could consider?

Once again, thank you for your participation. The ISAC very much appreciates
your longstanding involvement with the VHDL standard.

Best regards, 

Peter Ashenden 
P1076 Technical Editor 

-- 
Dr. Peter J. Ashenden         peter@ashenden.com.au 
Ashenden Designs Pty. Ltd.     <file://www.ashenden.com.au>
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 


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