RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce

From: Brophy, Dennis (dennisb@model.com)
Date: Sun May 16 2004 - 22:00:00 PDT

  • Next message: Shalom Bresticker: "Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source"

    The following reply was made to PR enhancement/350; 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/350: PROPOSAL - Deprecate configs in Verilog sour
             ce
    Date: Sun, 16 May 2004 22:10:51 -0700

     Steven,
     
       I don't agree.
     
       I see no need to regress from the approved IEEE Std. 1364-2001 specification.
     
       With all due respect, config is being supported and used in a manner which you wish to deprecate. I don't think this is wise. And pointing to the fact that you may not have an implementation of the same is no reason to support a change. It only shows your lack of interest in the standard or ability to support it.
     
       Users have this option today, are using it and can create their own coding rules if they wish to enforce restricted use. There is no reason to restrict the combination of config in Verilog source files. This is permitted today. It is supported today. It is used today.
     
       I think your motivation is clear. In these technical forums you have publicly stated your next product release has limitations that would render it to still not comply with the Verilog-2001 specification unless you can change the specification in Verilog-2005 per what is proposed. (See: http://www.boyd.com/1364_btf/report/full_pr/350.html)
     
       I think I see your motivation and I don't think it has a place here.
     
     -Dennis
     
     -----Original Message-----
     From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven Sharp
     Sent: Friday, May 14, 2004 6:20 PM
     To: etf-bugs@boyd.com
     Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce
     
     The following reply was made to PR enhancement/350; it has been noted by GNATS.
     
     From: Steven Sharp <sharp@cadence.com>
     To: etf-bugs@boyd.com, dennisb@model.com
     Cc:
     Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce
     Date: Fri, 14 May 2004 21:34:12 -0400 (EDT)
     
      Dennis,
      
      Your concern may be partly due to unclear wording in my proposal, which may have made it seem more restrictive than I intended.
      
      You wrote:
      
    > Users have come to use configs in other places other than library map files and I am hard pressed to see how we can now rationalize it out of being used in other places moving forward.
      
      As I pointed out in my response to Jayaram Bhasker's comments, any file containing configs could be regarded as a library map file and fed into a tool as such. As long as users have kept configs in separate files from their Verilog source, they can provide them to the tools as library map files instead of Verilog source files. My proposal explicitly allowed for the possibility that tools could compile configs from these library map files into libraries, just as they could have if they were allowed in Verilog source files.
      
      The only restriction that this imposes is that configs cannot be combined with Verilog HDL source in the same file. My VHDL contacts tell me that VHDL configs are almost invariably kept in separate files. There are reasons why it is generally undesirable to keep them in the same files as the HDL source.
      
      I agree that it is a question of what will cause the least hardship for users. I believe that configs are still implemented in very few tools at this point. As a result, very few users are probably using them yet. If they have used them the way VHDL users do, only a tiny fraction of those would have combined them with Verilog source in the same file. This means that the restrictions from this proposal would have minimal impact on users.
      
      On the other hand, reserving the config keywords in Verilog source causes 15% of the customer designs in our customer test suite to fail to compile.
      Assuming that this is representative of designs out there, there is a lot of legacy code out there that would need to be modified or handled specially.
      
      I believe that this proposal is in the best interests of Verilog users overall. Now that I have clarified the amount of restriction that it actually involves, perhaps you will agree. If you have contact with users who would be negatively impacted by this change, please encourage them to contact us and tell us about it.
      
      Steven Sharp
      sharp@cadence.com
      
     

    This archive was generated by hypermail 2.1.4 : Sun May 16 2004 - 22:00:13 PDT and
    sponsored by Boyd Technology, Inc.