Re: [sv-bc] potential command line option

From: Michael McNamara (mac@verisity.com)
Date: Thu Apr 21 2005 - 08:43:36 PDT

  • Next message: Randy Misustin: "Re: [sv-bc] potential command line option"

    -- 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 - 08:20:37 PDT and
    sponsored by Boyd Technology, Inc.