Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source

From: Shalom Bresticker (Shalom.Bresticker@freescale.com)
Date: Sun May 16 2004 - 22:53:56 PDT

  • Next message: Vassilios.Gerousis@infineon.com: "RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source"

    Dennis,

    I believe your comments are out of place as well as violating IEEE rules,
    and I respectfully ask you to refrain from them, both in content and in style,
    and to avoiding impugning the ethics of committee members.

    Whatever may or may not be the commercial considerations of whatever Steven's employer may be,
    Steven has raised technical objections which need to be addressed. You are free to address them on
    a technical basis. In point of fact, the same objections have been raised a long time ago, and by many
    others as well as by employees of Steven's company.

    Sincerely,
    Shalom Bresticker

    "Brophy, Dennis" wrote:

    > 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
    >
    > 

    --
Shalom Bresticker                         Shalom.Bresticker @freescale.com
Design & Reuse Methodology                            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

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