Subject: RE: Deprecation Proposal
From: Michael McNamara (mac@verisity.com)
Date: Mon Mar 18 2002 - 09:15:00 PST
I appreciate the research into the history of deprecation.
It is my opinion that we would be moving too fast to in the next
release of the Verilog standar state that feature 'xxx' and feature
'yyy' are no longer supported. I believe, that as was done with VHDL,
and also with Java, there should first be a publication of intention
to remove from the language, with justification much as that you
provide, and a time table for when it will no longer be a required
part of a compliant Verilog processing system.
-mac
Clifford E. Cummings writes:
> [1 <text/plain; us-ascii (7bit)>]
> My gratitude to Paul Menchini for sharing his experiences related to
> deprecating feature in the VHDL language. Paul's comments and experience
> follow.
>
> After Paul's remarks (and based on Paul's remarks), I have submitted a
> proposal to deprecate specified existing Verilog functionality from the
> SystemVerilog Standard. I have proposed stronger wording than that that was
> put in the VHDL Standard, to make a strong statement for those who will
> argue in favor of adhering to the recommendations to avoid certain coding
> styles and practices. I believe stating that a feature "may be removed from
> a future version" is too weak a statement and will encourage stubborn users
> to whine hoping that the Standards Group will change its mind.
>
> Regards - Cliff
>
> ----------------
>
> From: "Paul J. Menchini" <mench@mench.com>
> Subject: Re: Deprecation definition?
> To: cliffc@sunburst-design.com (Clifford E. Cummings)
> Date: Mon, 4 Mar 2002 11:35:19 -0500 (EST)
> Cc: mench@mench.com
> X-Mailer: ELM [version 2.5 PL2]
>
> Cliff,
>
> > On the Accellera SystremVerilog committee, we are looking to deprecate
> > some capabilities from the Verilog language and I have been charged
> > with making those proposals.
> >
> > In the VHDL-2001 Standard, did you use some clever wording to
> > introduce deprecation and its intent? Is it something that we could
> > borrow and massage to introduce deprecation in SystemVerilog? Could
> > you also provide an example section of one item that was deprecated
> > from VHDL?
>
> What I did was to note in the appropriate section (literally, in a note
> in that section) that "such-and-such-feature may be removed from a
> future version of the language." I also created a non-normative annex
> that listed all such features.
>
> For example, in the section on ports (1.1.1.2), the following note
> appears:
>
> -- Port of mode linkage may be removed from a future version of
> the language. See Annex F.
>
> And, in Annex F, entitled "Features under consideration for removal":
> The following features are being considered for removal from a
> future version of the language. Accordingly, modelers should
> refrain from using them when possible:
>
> -- Ports of mode linkage (1.1.1.2, and 4.3.2)
> -- ...
>
> To comment on these, or any other features of VHDL, please visit
> http://vhdl.org/vasg.
> Hope this helps,
> Paul
>
> ===========
>
> PROPOSAL: Add a non-normative annex entitled:
>
> Verilog features removed from SystemVerilog
>
> The following Verilog language features are simulation inefficient, easily
> abused and the source of numerous design problems and are therefore no
> longer supported in the SystemVerilog language. Support for these
> deprecated features is optional but a warning should be issued noting that
> these features have been deprecated from the SystemVerilog Standard.
> Vendors may optionally provide a switch to turn off the warnings.
>
> Defparam statements (x.x.x.x, and x.x.x)
>
>
> Prior to the acceptance of the Verilog-2001 Standard (IEEE Std 1364-2001),
> it was common practice to change one or more parameters of instantiated
> modules using a separate defparam statement. Defparam statements are the
> source of needless tool complexity and design problems.
>
> When a defparam statement is placed in the Verilog code adjacent to the
> instance whose parameters are to be modified, and if the defparam statement
> makes a simple modification to just the parameters of the instantiated
> module and not hierarchically to any other parameters, the defparam
> statement has been used as intended.
>
> The problem with the defparam is that a defparam statement can precede the
> instance to be modified, can follow the instance to be modified, can be at
> the end of the file with the instance to be modified, can be in a whole
> separate file from the instance to be modified, can modify parameters
> hierarchically that in turn must again be passed to other defparam
> statements to modify parameters for a specific instance and can modify the
> same parameter from two different defparam statements placed in the same or
> in two separate files (with undefined results). Due to the many ways that a
> defparam can modify parameters, a Verilog compiler cannot insure the final
> parameter values for an instance until after all of the design files are
> compiled. This abuse of the defparam statement causes compiler tool
> inefficiencies and difficult debugging of convoluted parameterized Verilog
> designs.
>
> Prior to Verilog-2001, the only other method available to change the values
> of parameters on instantiated modules was to use the #(parameter)
> redefinition syntax included as part of the instantiation itself. The
> disadvantage to using the #(parameter) redefinition syntax was that all
> parameters up to and including the parameter to be changed had to be placed
> in the correct order and assigned values, enclosed within the parentheses.
>
> Verilog-2001 introduced the capability to pass parameters by name in the
> instantiation, which supplied all of the necessary parameter information to
> the model in the instantiation itself.
>
> The practice of adding defparam statements to Verilog source files is
> highly discouraged and deprecated for the SystemVerilog Standard. Engineers
> are encouraged to take advantage of the new named parameter passing
> capability introduced by and added to the IEEE Verilog-2001 Standard.
>
> ============
>
> Verilog has long had the confusing capability to do procedural assign and
> deassign assignments (not to be confused with a continuous assignment,
> which is placed outside of procedural blocks). In particular, the assign
> statement has a strange behavior that most Verilog users don't understand
> and engineers either find the behavior confusing or they get lucky and the
> assign statement is coded in such a way as to yield correct simulation
> results, despite the incorrect usage of the statement.
>
> Most designs that include an assign statement inside of a procedural block
> should have been coded without the assign statement.
>
> The problem with the procedural assign and deassign statements is that they
> are often used to control the value of a variable from multiple procedural
> blocks. Although simple assign and deassgin statements can be understood,
> multiple assign statements are sometimes place in multiple procedural
> blocks to control the same variable and in large designs, it can be either
> difficult or impossible for a user to understand the priority of the
> multiple assign statements. Synthesis tools do not support the procedural
> assign and deassign statements because they can be coded in a manner that
> is impossible to implement in hardware.
>
> The procedural assign statement has the strange behavior that it will
> update the LHS procedural variable anytime the RHS variable changes, even
> if the RHS variable is not in the sensitivity list. The concept that last
> assign wins is also confusing and restoring other non-assign procedural
> assignments to activity after a deassign statement is similarly confusing.
>
> The force-release commands have the same functionality (on both procedural
> and net variables) but they are rarely abused, not synthesizable by any
> tool, and rather clearly documented to be intended mostly for debugging
> purposes. Having both assign-deassign and force-release where the latter
> has higher priority and can also assign to wire types is confusing to most
> Verilog users.
>
> The continuous assignment statement, placed outside of a procedural block,
> is still highly recommended for RTL coding of combinational logic.
>
> The practice of using the assign and deassign statements inside of
> procedural blocks is highly discouraged and deprecated for the
> SystemVerilog Standard. Any engineer caught using these statements should
> be flogged (in a professional way).
>
> ============
> [2 Deprecate_proposal.doc <application/msword>]
>
> [3 <text/plain; us-ascii (7bit)>]
> //*****************************************************************//
> // Cliff Cummings Phone: 503-641-8446 //
> // Sunburst Design, Inc. FAX: 503-641-8486 //
> // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> // PMB 501 Web: www.sunburst-design.com //
> // Beaverton, OR 97005 //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
This archive was generated by hypermail 2b28 : Mon Mar 18 2002 - 09:16:06 PST