Re: [sv-bc] potential command line option

From: Randy Misustin (ram@model.com)
Date: Thu Apr 21 2005 - 09:41:27 PDT

  • Next message: Mark Hartoog: "RE: [sv-bc] potential command line option"

    Mac,

    I feel there is at least some ambiguity and discussions of intent are
    inevitable (and probably helpful) in resolving ambiguity in the
    specfication. The ambiguity is introduced by the complete reliance on
    the BNF to implement this restriction and then no guidance on what BNF
    productions were intended to go into what files. The fact that there is
    a single list of keywords also seems to support an interpretation of
    merged grammars. Truly, we didn't set out to create a nonconforming
    implementation (obviously, I hope!), we simply attempted to support
    configurations as we interpreted them in the most flexible way we could
    reasonably implement.

    If the committee wants to deliberate this issue and decide that there is
    no ambiguity and to render an interpretation that marks ModelSim's
    implementation a "vendor extension", fine. I can live with that and
    would probably then move to donate our "extension" to the next feasible
    version of the language.

    Except, there's the niggling issue of Steven's 4th quarter desire to
    bifurcate the current keyword list into 2 lists. This would work to
    hinder such an extension and uliimately decides the issue for now and
    the future.

    -randy.

    Michael McNamara wrote:

    >-- On Apr 21 2005 at 06:06, Shalom.Bresticker@freescale.com sent a message:
    > > To: sharp@cadence.com, btf@boyd.com, etf@boyd.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.
    > >
    > > Shalom
    > >
    > >
    > > > 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
    >standard.
    >
    >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: mcnamara@cadence.com M: 408-348-7025
    >
    >
    >
    >

    This archive was generated by hypermail 2.1.4 : Thu Apr 21 2005 - 09:17:57 PDT and
    sponsored by Boyd Technology, Inc.