Subject: RE: VOTE - Two Deprecation Proposals - Votes due Wed., April 17
From: Michael McNamara (mac@verisity.com)
Date: Mon Apr 15 2002 - 16:45:47 PDT
Clifford E. Cummings writes:
> [1 <text/plain; us-ascii (7bit)>]
> E-MAIL VOTES - DUE BY END OF DAY ON WEDNESDAY, APRIL 17TH
>
> Any person who has attended three of the last four SystemVerilog committee
> meetings or 75% of all of the SystemVerilog committee meetings is eligible
> to vote.
>
> All eligible SystemVerilog committee members should separately vote "yes,"
> "no" or "abstain" on the following TWO proposals (see attached file).
>
> PROPOSAL #1 - Deprecate defparam
> PROPOSAL #2 - Deprecate procedural assign & deassign
I have significant problems with the proposed wording these proposals
add to the specification; but I do not disagree with their intent.
The nature of my disagreement with the wording is that it is in the
first person, is primarily editorial, and includes signifigant
repetition. While this quite accurately captures the nature of a one
on one discussion with a colleague; and follows good debating
techniques (Cliff: you could write screen plays!); it is not (in my
opinion) the right style for a standard document.
So with the understanding that the editor will significantly tighten
up the justification, to a target that is close to my proposal below,
I vote in favor of these two proposals.
--------------------------------
14.1 Introduction (informative)
Verilog-2001 provides three constructs for defining compile time
constants: the parameter, localparam and specparam statements.
The language provides four methods for setting the value of parameters
in a design. (1) Each parameter when declared must be assigned a
default value. Further, the default value of a parameter of an
instanced module can be overridden in the module instanced either
using (2) a positional syntax, or (3) in a name=value syntax.
Finally, (4) defparam statements can be included anywhere in the
design, each naming a specific hierarchical path to a parameter, and
specifying a value for that parameter.
14.1.1
The SystemVerilog committee has determined, based on the solicitation
of input from tool implementers and tools users, that this last method
of specifying the value of a parameter in a design is (1) a
significant source of design errors; (2) a significant impediment to
fast simulation; and (3) does not provide a capability that can not be
done by another method, which avoids these first two problems.
Therefore the committee has placed the defparam statement on the
Deprecation List. What this means is that the next revision of the
Verilog standard (scheduled for 2010) will not require support for
this feature.
This current standard still requires tools to support the defparam
feature; however users are strongly encouraged to migrate their code
to use one of the alternate methods for obtaining the same result
-------------------------------
8.10 Introduction (informative)
Verilog-2001 provides two overlapping methods for procedurally adding
and removing drivers for registers: (1) the Force/Release statements
and the (2) Assign/Deassign statements. The Force/Release statements
can also be used to add or remove drivers for nets in addition to
registers.
A force statement targeting a register that is currently the target of
an assign will override that assign; however, once the force is
released, the assign's effect again will be visible. Once deassigned,
the old value in the register will again be in effect.
The keyword assign is much more commonly used in user designs for the
somewhat similar, yet quite different purpose of defining permanent
drivers of values to nets.
8.10.1
The SystemVerilog committee has determined, based on solicitation of
input from tool implementers and tools users, that the procedural
assignment of registers is (1) a significant source of design errors;
(2) a significant impediment to fast simulation; and (3) does not
provide a capability that can not be done by another method, which
avoids these first two problems.
Therefore the committee has placed the procedural continuous assign
and deassign statements on the Deprecation List. What this means is
that the next revision of the Verilog standard (scheduled for 2010)
will not require support for this feature.
This current standard still requires tools to support the procedural
continuous assign and deassign feature; however users are strongly
encouraged to migrate their code to use one of the alternate methods
for obtaining the same result
This archive was generated by hypermail 2b28 : Mon Apr 15 2002 - 16:47:13 PDT