Subject: arguments on removal of "static"
From: Steven Sharp (sharp@cadence.com)
Date: Mon Oct 14 2002 - 18:05:56 PDT
Here is my attempt to describe the arguments on the removal of the "static"
keyword from SystemVerilog 3.0. Please look it over to see if you agree
that it captures the discussion we had before voting, and the decision we
want to present to Vassilios.
Steven Sharp
sharp@cadence.com
Some features in SystemVerilog 3.0 appear to have been developed in parallel
with equivalent features in IEEE 1364-2001. In some cases, this has resulted
in differences between the two specifications. Since SystemVerilog 3.0 is
intended to be an extension to IEEE Std 1364-2001, these differences should
be resolved by changing the SystemVerilog 3.0 specification to match the
IEEE standard.
One of these differences is the existence of the "static" keyword in
SystemVerilog. This keyword was included in the original proposal to the
IEEE VSG for reentrant tasks and functions. After much discussion, it was
decided to exclude it from the standard. None of the reasons have changed
since then.
The purpose of the "static" keyword is to allow declaring static variables
in automatic tasks or functions. Some kinds of subroutines need some static
storage. The argument in favor of the "static" keyword is that it allows
declaring that static storage inside the subroutine, making its scope more
local. This is generally considered to be good software engineering practice.
However, this argument is much weaker for Verilog than for C.
First of all, static variables are never really local in Verilog. A static
variable can be referenced from anywhere by using a hierarchical path name.
Internal static variables are already unusual in C. The kinds of things
they tend to be used for are even less likely to be needed in Verilog.
Using a static variable generally prevents a subroutine from being reentrant.
If a subroutine does not need to be reentrant, a normal Verilog subroutine
will work, and all of its variables are static. If a user believes they need
to declare a subroutine as automatic but also need local static variables,
they are probably wrong. If they wrote such a thing, it would probably not
work as expected. However, if there really is a valid reason for needing
this, there is an adequate solution.
In any block structured language other than C and its descendents, if a
variable is needed with a longer lifespan than its scope, it is declared
in a surrounding scope. This is considered reasonable, even though most
of these languages place a greater emphasis on supporting good software
engineering practices than C does. Avoiding an extra mechanism to support
local static variables is considered to be worth the slight reduction in
locality. In Verilog, the scope just above the subroutine scope is always
sufficient. Variables there are completely static.
There is actually an advantage to requiring the subroutine to use a static
variable declared outside of itself. It makes clear that there is a single
shared variable that is being referenced by all activations of the subroutine.
This is a major issue since Verilog is inherently multi-threaded. It could
have multiple processes executing the same task at the same time, accessing
the same variable. This is a form of nonlocality that the user may not
have considered. The false appearance of locality is more dangerous than
requiring clear and explicit nonlocality.
The other major argument against including this mechanism is the need to
reserve the extra keyword "static". Any time a new reserved word is added,
it creates a potential backward compatibility issue. New keywords need
strong justification. The name "static" may be used in existing designs,
especially since static discharge protection circuitry may be included in
netlists.
Based on these arguments and the fact that the IEEE VSG already decided to
exclude the "static" keyword, the SystemVerilog Basic Committee agreed almost
unanimously that the SystemVerilog 3.0 specification should be adjusted to
match.
This archive was generated by hypermail 2b28 : Mon Oct 14 2002 - 18:06:31 PDT