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

From: Vassilios.Gerousis@infineon.com
Date: Sun May 16 2004 - 23:40:30 PDT

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

    Dennis email points out certain facts about backward compatibility of
    IEEE standard versions. Does the committee plan to build an IEEE 2005
    version that is not backward compatible with IEEE 2001 version? Dennis
    pointed out that there are existing models and tools that support the
    current Verilog 2001 version. The question that should be answered by
    this committee, do you want to allow non-compliance to existing
    standards (i.e. Verilog 2001)? Shall tool implementers wait for Verilog
    2010 to ensure that certain functionality in 2005 is not deprecated?

    Backward compatibility is an extremely serious matter and should be
    addressed in an "equitable" manner that give confidence to users and
    tool vendors alike. By obsolescing backward compatibility, you are
    rewarding non-early adopters of Virology 2001 rather than awarding early
    adopters.

    -----Original Message-----
    From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Shalom
    Bresticker
    Sent: Monday, May 17, 2004 7:54 AM
    To: Brophy, Dennis
    Cc: etf@boyd.com
    Subject: 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 - 23:19:55 PDT and
    sponsored by Boyd Technology, Inc.