From: Michael McNamara (firstname.lastname@example.org)
Date: Thu Apr 21 2005 - 08:43:36 PDT
-- On Apr 21 2005 at 06:06, Shalom.Bresticker@freescale.com sent a message:
> To: email@example.com, firstname.lastname@example.org, email@example.com
> Subject: "Re: [sv-bc] potential command line option"
> It is a fact that there are others who disagree with this interpretation of
> the written words, and it is not explicit.
> > If the meaning of the standard must be determined only by what is written
> > there, then configs are clearly not allowed in Verilog source files. This
> > is specified unambiguously in the BNF, and there is nothing in the text
> > that actually contradicts this.
> Shalom.Bresticker @freescale.com Tel: +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478
> [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
I believe we all appreciate Cliffs recounting of his recollection of
the events that lead up to the preparation of the 1364-2001 draft
My recollections of the events are vaguely similar to what he
recounts, albeit I can not affirm each detail as 100% accurate.
But we are where we are.
Shalom is quite right that the Standard is defined by solely the text
that was approved by the ballot committee. The Standard is not the
text plus thoughts and intentions and ideas held by one or more of the
members of the working group.
We can certainly apply these thoughts intentions and ideas, plus the
past years of experience, and make modifications to the text of the
standard, and propose these to a new ballot committee, and if/when
approved, this new text will be the standard.
We can also publish interpertations of the standard, where there is
some ambiguity, and state the working groups opinion on how they
should be resolved.
Vendors may also create tools which accept a superset of the language,
without fear of any recourse from the IEEE; and should these
extensions be deemed useful, we would all encourage the vendor to
submit these extentions to be included in the standard.
It is apparent here that we have is no ambiguity in the text about
where configurations may be included (the standard is self
consistant); we have some typos which should be fixed; and we have an
extention which should be considered at the appropriate time for
inclusion in the standard.
In the meantime market pressures may encourage other vendors to follow
the lead of Mentor; or perhaps these vendors may choose to wait for a
modification of the standard. That is the normal course of business.
-- Michael McNamara Vice President, Verification Division, Cadence E: firstname.lastname@example.org M: 408-348-7025
This archive was generated by hypermail 2.1.4
: Thu Apr 21 2005 - 08:20:36 PDT
sponsored by Boyd Technology, Inc.