RE: enhancement/287: `compatibility - backward compatibilitycompi lerdirectives

From: Brophy, Dennis (dennisb@model.com)
Date: Fri Jun 25 2004 - 07:20:01 PDT

  • Next message: Karen Pieper: "Reminder: ETF Meeting on Monday"

    The following reply was made to PR enhancement/287; it has been noted by GNATS.

    From: "Brophy, Dennis" <dennisb@model.com>
    To: Steven Sharp <sharp@cadence.com>, etf-bugs@boyd.com
    Cc:
    Subject: RE: enhancement/287: `compatibility - backward compatibilitycompi
            lerdirectives
    Date: Fri, 25 Jun 2004 07:16:22 -0700

     With respect to access to the older versions of the specification, one can get older versions of 1364 from IEEE Xplore. (Thankfully the Verilog 95 copy on Xplore is a PDF file generated directly from the source. There are other superseded standards that are mere PDF files from scanned pages that offer no search capabilities.)
     
     Now that patent LOAs are part of the mix, and they expire upon a specification being superseded. If you want to use an old version of the specification and the LOAs covered essential patents, one would presumably need to negotiate directly with the IPR holder. We all observe that this industry has ignored the status of superseded standards since the user community has come to expect all versions of the standard are supported to some degree or another. How many people use VHDL 87 or 93? How many solutions still reference OVI SDF 2.1 and not IEEE 1497? Verilog 95 & 2001 share this as well.
     
     It may be admiral to codify consumer and supplier practice, but if we go down the route of 'compatibility, we may have other issues that would need basic IEEE SA attention and support in the issues that Steven points out.
     
     -Dennis
     
     -----Original Message-----
     From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven Sharp
     Sent: Friday, June 18, 2004 11:10 AM
     To: etf-bugs@boyd.com
     Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives
     
     The following reply was made to PR enhancement/287; it has been noted by GNATS.
     
     From: Steven Sharp <sharp@cadence.com>
     To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com
     Cc:
     Subject: Re: enhancement/287: `compatibility - backward compatibilitycompilerdirectives
     Date: Fri, 18 Jun 2004 14:10:18 -0400 (EDT)
     
    > However, if "1364-2001 compatibility" would require
    > him to disable any and all features added in later versions of the
    > standard, that would be much harder for a vendor to implement,
      
      In fact, if the earlier versions of the standard are not readily
      available, this is a bigger issue than just implementation effort.
      
      I believe that if this directive is added to the standard, that the
      behavior required to be compliant needs to be fully specified in the
      standard also. I don't believe that referring to an earlier obsoleted
      version of the standard is a valid specification.
      
      Trying to specify everything that has changed from all previous versions
      of the standard is impractical. Restricting it to something smaller,
      such as just keywords, or just the things that are not backward-compatible,
      would make both specification and implementation much simpler.
      
      
    > It is true that there are a few things which actually change from one
    > version of the standard to the next, as opposed to added extensions,
    > such as the use of bit 31 of an MCD, but those cases have been quite few
    > and relatively unimportant.
      
      The change in x/z-extension behavior for unsized literals is the only other
      one I can think of.
      
      Steven Sharp
      sharp@cadence.com
      
     

    This archive was generated by hypermail 2.1.4 : Fri Jun 25 2004 - 07:20:08 PDT and
    sponsored by Boyd Technology, Inc.