The Art of Deprecation
At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.
I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:
Deprecate:
1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>
In computer science standards and documentation, deprecation has come to mean to supersede or discourage use of a feature. It does not mean a feature has to be removed to be compliant with the standard. You can’t remove a feature from an existing standard; you can only remove a feature from being documented in a future standard. No vendor is going to immediately remove a feature from a tool that it has already implemented and in widespread use without ample warning and without providing a practical alternative to the user. Typically, a deprecated feature is never removed from support in a tool unless in the rare case it’s needed to allow for a future enhancement.
The current standard lists in Annex C.4 the defparam and the procedural continuous assignment statements as candidates for deprecation. Listing candidates for deprecation seems to be almost the same as actually deprecating them without removing the LRM. No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.
Q: So why go though the trouble of deprecating a feature in a standard?
A: Well, to discourage use of that feature.
Q: And why is that a good thing to do?
A: It makes learning the language and maintaining existing code much easier.
Take an example from the current Verilog and SystemVerilog LRMs. The logic data type was added to supersede the reg data types; they both have the same semantics. Anyone with a history of Verilog will understand the change in keywords, but someone new to SystemVerilog will be left wondering why there are two keywords for the same thing. And then there is the issue of trying to maintain the LRM so that all references to reg also include logic and the other way around. If someone misses that in one place, people will begin to think the two keywords have different behaviors.
It seems it’s always easier to add new features than to remove them. There are many places to create lists of your favorite enhancements. At the same time, people complain about the size of the Language Reference Manual – it’s over 1200 pages. Doug Smith of Doulos writes “Will this language ever stop exploding?”
So here is my list for deprecation, as well as a place for other to add their list by commenting here.
- Program blocks
- Reg data type – see above
- Wildcard associative array index types
- Un-typed mailboxes
- Dynamic array copy A = new[]B redundant with A = B
- always @(*) – superseded by always_comb
- $random/$dist_uniform replaced by $urandom/$urandom_range for better stability and seed control
- Stochastic $q_ tasks replaced with queue array type
Comments
Leave a Reply
You must be logged in to post a comment.
Dave,
Deprecation is hard to get enthusiastic about. I think you’re right that most people don’t understand the term accurately, and, I’d guess that the advocates for simplification wanted a bolder move.
If we want to discourage usage of a feature, why not simply strip it out of the standard? As long we don’t strip out a reserved keyword, then, if a tool continues to support the old features, that would not make it out of compliance with the new revision, the tool would just be implementing an extension.
What’s the reason for wanting to deprecate defparam? It’s actually a very useful feature:
Many times vendor IP models have parameters that control the behavior of a model (for example, to indicate whether a RAM should check for read-write contention on an address). When the design instantiates the RAM model, we don’t want to pass in these behavioral parameters (otherwise, synthesis tools will have problems with elaboration), but a separate test bench module can use defparam to set the parameter values the way we want.
Brad, Simply stripping it out of the standard is exactly what I would like to have happen. Because people do not understand deprecation, they are worried about backward compatibility.
Kris,
There are two major problems with defparam
1. They make code less re-usable by relying on hierarchical references to specific environments. Also difficult to debug since reading the code, you don’t always know which parameters have been defparamed.
2. There are many cases with multiple defparam overrides, directly or indirectly, that have been left unspecified in the LRM
SystemVerilog as added a few features that make defparam unnecessary. Packages can be used to set global parameters. When you simulate or synthesize, you can point your tool to the version of the package you want to use.
You can also use the Verilog config statement to set different parameter overrides (This is new in 1800-2009
)
Dave
I don’t mind the deprecation and I understand there must be good reasons to do so. The only thing that is disappointing to me is the fact that there was little design aspects that went to this standard but rather so much attention was given to the verification aspects.
I feel we have enough of the verification features we all wanted in a language and more. It’s time fore more design features.
— Amal
[Hey – looks like me right at the back in the photo :)]
I’ve been working on deprecating ‘wreal’ in Verilog-AMS – an ugly piece of syntax/semantics, whose functionality could have been achieved more cleanly in the first place. However, I’m happy to put money on it surviving any merger with SystemVerilog and having more dysfunctional syntax/semantics layered on top (Cadence’s current plan).
More than decade working with language committees has convinced me that deprecating syntax is pointless (it never happens), and the best you can hope for is a redefinition of semantics such that the underlying model is simpler.
It seems most EDA companies prefer to add new features rather than fix underlying problems. Not to pick on SV: VHDL doesn’t handle bidirectional signal flow in models (you can’t do pass gates), the fix is fairly simple but nobody appears to want to do it (I tried a decade ago).
Kev.
PS: Don’t have anything against defparam
PPS: reg & logic are not the same thing
Kevin, what makes you say in your PPS that reg and logic are not the same? There’s a minor syntactic restriction forbidding the use of “reg” in a specific place where “logic” is acceptable, but in every other sense they are exactly identical (though this has not always been the case in earlier versions of SV).
I take the point about VHDL’s limitations, and I think it’s actually rather important. Our industry seems to have a suicidal desire to “enhance” its tools and techniques not by the addition of really powerful general facilities, but by demanding addition of some magical special feature to solve one specific problem that happens to be the flavor of the month. The recently-offered raft of suggestions for X-handling in SV seem to me to fall into this category. The resultant language bloat and explosion of hard-to-remember features, with endless tiresome special cases, muscles-out the calls for smaller, very general enhancements that would make the language more expressive for everyone (but would not allow lazy users to get a complete solution to their own very special problem in just one line of code).
Worst of all, SV still falls woefully short of the best we could achieve when it comes to separation of interface and implementation. We can’t fix that by ripping out features. I think there is a decent amount of momentum behind the idea of using Java-style interfaces on classes, which is definitely a step in the right direction; but RTL designers are still stuck in the Stone Age with no really satisfactory tools for isolation, abstraction and composition of the interfaces that a design presents to the outside world.
Jonathan
The term ‘deprecation’ is actually inconsistently in the LRM. I filed a Mantis item on that issue. I don’t have the number right now.
Shalom
@Jonathan, re: reg/logic
‘reg’ was not really a type declaration because there was only one wire type in Verilog (and degenerate cases), it is/was really a driver declaration – i.e. it declares a driver common to processes in a module (required in some cases with behavioral code). Other HDLs (e.g. VHDL) tend to do all driver declaration implicitly. ‘logic’ is a type that was added so that built-in wire type and the degenerate cases could be differentiated. Using ‘logic’ instead of ‘reg’ actually means you are letting the compiler work out for itself that a driver is required (or not).
The difference is immaterial to most digital designers, but is significant in Verilog-AMS, and the whole driver/receiver declaration issue is important if you want to add user-defined types and do cross-type resolution.
Kev.
Kevin,
Today, “logic” and “reg” are the same data type in SV. The LRM says so explicitly in 6.11.2: “logic and reg denote the same type.”
The Mantis item I mentioned describing deprecation inconsistency is 2651 (http://www.eda-stds.org/mantis/view.php?id=2651)
Shalom
@Shalom, re: reg/logic
Yes, I know everybody treats them the same now, but that kind of misses the point that “reg” was not there as a type identifier in the first place. The differentiation of “wire” and “reg” was originally made so that the simulator/compiler can tell if a driver is required without having to analyze the code – since “reg” implies a “wire” you don’t need both.
Another way to look at it: “reg” is the declaration of a wire/driver pair, the type of the driver is “logic”.
People seem to have trouble with the concepts in this area of simulation semantics and syntax, that’s why the resolution scheme and mixed signal behavior in VHDL is fairly dysfunctional (it doesn’t work with transistors in digital), and [System]Verilog still has only the one wire type (0/1/X/strength and subsets thereof).
“No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.”
As Brad Pierce has written earlier, it is hard to get excited about deprecation. When we developed Verilog HDL, upward compatibility was paid utmost importance too. The talk of deprecation creates confusion and fear about the new version of a standard and distracts us from concentrating on adding value to the standard.
Moreover, the people on a committee at a particular time may not understand the significance of a feature and the use model and have been burnt from wrong usage. ‘defparam’ deprecation talk is one such feature.
Originally it was developed to support back annotation which now SDF back annotation has taken its place and apparently there is no reason to support it. On the other hand, it embodies an important concept of compile time changes. There has been over use of ‘defines and macros in today’s Verilog and SytemVerilog world. We need to able to add more features like defparam rather than take these out and discourage use of preprocessor based constructs. Let us add syntax such as `define within the language to say that these function and parameters are meant for in line expansion.
The defparam negatives are same as hierarchical name negatives. To really address the concerns, hierarchical names should be used with caution and so are defparams.
I find defparams quite useful and `defines as syntactically and semantically uninteresting. `define has no semantics and defparam is clearly well defined.
And lastly, tools should follow standards and standards should also follow tools. Intellectual divergence between the 2 is not beneficial to anybody and adds to confusion and misunderstanding.
Tolerate features that you may not exactly like….and move on to new and better things…
Leave deprecation to tools and vendors not languages.
The whole idea of adding usage to standard is not sound. We only define standards and let the industry and academics figure out the full usage. We only need to have sound theory. There is no semantic issue with defparams.
Dave, good to see your blog…
Just like statute of limitations, there should be a rule for deprecaton – cannot deprecate a feature after 10 years of its inception.
Vivek
Vivek
reg and wire types
We designed this in Verilog HDL to distinguish structural and behavioral constructs. wire is structural and can be set from continuous assignments or ports or gates. regs are set from other constructs.
Synthesis came later and wire can result in wire and reg can result in wire or flip flop. The synthesis is usage dependent. In verification, we are at behavioral level and so will use reg most of the times. For connectivity to modules, wires may be needed. Continuous assignments are also useful in testbenches and wires are used.
reg and wires have been understood and used by Verilog users for many years. VHDL does not have builtin gates or notion of hardware types or resolution functions.
We need to enhance the design description capabilities of Verilog(SV). wire and reg types are ok. Power capabilities is one area where the language can be enhanced. Raising synthesis level is really the key to make Verilog better.
Vivek