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.

P1800 Requirements Gathering Meeting 2/27/2010

P1800 Requirements Gathering Meeting 2/27/2010

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.

  1. Program blocks
  2. Reg data type – see above
  3. Wildcard associative array index types
  4. Un-typed mailboxes
  5. Dynamic array copy A = new[]B redundant with A = B
  6. always @(*) – superseded by always_comb

Post Author

Posted March 23rd, 2010, by

Post Tags

, ,

Post Comments

14 Comments

About Verification Horizons BLOG

This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool. Verification Horizons BLOG

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

@jhupcey Tweets

  • Loading tweets...

Comments

14 comments on this post | ↓ Add Your Own

Commented on March 23, 2010 at 12:39 pm
By Brad Pierce

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.

Commented on March 23, 2010 at 6:59 pm
By uberVU - social comments

Social comments and analytics for this post…

This post was mentioned on Twitter by dave_59: New blog entry:”The Art of Deprecation” Let’s make #SystemVerilog simpler. http://go.mentor.com/the-art-of-deprecation #IEEE-SA #eda…

Commented on March 24, 2010 at 10:54 am
By Kris Monsen

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.

Commented on March 24, 2010 at 1:00 pm
By David Rich

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

Commented on March 24, 2010 at 8:12 pm
By Amal

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

Commented on March 25, 2010 at 12:18 am
By Kevin Cameron

[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

Commented on March 25, 2010 at 2:45 am
By Jonathan Bromley

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

Commented on March 26, 2010 at 8:21 am
By Shalom Bresticker

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

Commented on March 26, 2010 at 12:14 pm
By Kevin Cameron

@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.

Commented on March 28, 2010 at 2:01 am
By Shalom Bresticker

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

Commented on March 28, 2010 at 2:35 am
By Kevin Cameron

@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).

Commented on March 31, 2010 at 1:13 pm
By Vivek Sagdeo

“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

Commented on April 1, 2010 at 4:07 pm
By Vivek Sagdeo

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

[…] Rich posted his blog on the meeting and shared a link that allowed everyone to see the top-3 items Users and Producers […]

Add Your Comment

Archives

October 2014
  • DVCon India: A Smashing Hit!
  • September 2014
  • Portable and Productive Test Creation with Graph-Based Stimulus
  • Supporting A Season of Learning
  • August 2014
  • DVCon Goes Global!
  • Better Late Than Never: Magical Verification Horizons DAC Edition
  • July 2014
  • Accellera Approves UVM 1.2
  • May 2014
  • Getting More Value from your Stimulus Constraints
  • The FPGA Verification Window Is Open
  • April 2014
  • UVM DVCon 2014 Tutorial Video Online
  • Mentor Enterprise Verification Platform Debuts
  • March 2014
  • New Verification Academy ABV Course
  • DVCon 2014 Issue of Verification Horizons Now Available
  • February 2014
  • DVCon–The FREE Side
  • More DVCon–More Mentor Tutorials!
  • UVM 1.2: Open Public Review
  • DVCon 2014: Standards on Display
  • Just because FPGAs are programmable doesn’t mean verification is dead
  • January 2014
  • Managing Verification Coverage Information
  • November 2013
  • Epilogue: The 2012 Wilson Research Group Functional Verification Study
  • New Verification Horizons Issue Available
  • October 2013
  • Happy Halloween from ARM TechCon
  • IEEE Standards Association Symposium on EDA Interoperability
  • STMicroelectronics: Simulation + Emulation = Verification Success
  • September 2013
  • A Decade of SystemVerilog: Unifying Design and Verification?
  • Part 12: The 2012 Wilson Research Group Functional Verification Study
  • August 2013
  • Part 11: The 2012 Wilson Research Group Functional Verification Study
  • Part 10: The 2012 Wilson Research Group Functional Verification Study
  • Part 9: The 2012 Wilson Research Group Functional Verification Study
  • Part 8: The 2012 Wilson Research Group Functional Verification Study
  • July 2013
  • Part 7: The 2012 Wilson Research Group Functional Verification Study
  • Walking in the Desert or Drinking from a Fire Hose?
  • Part 6: The 2012 Wilson Research Group Functional Verification Study
  • A Short Class on SystemVerilog Classes
  • Part 5: The 2012 Wilson Research Group Functional Verification Study
  • Part 4: The 2012 Wilson Research Group Functional Verification Study
  • June 2013
  • Part 3: The 2012 Wilson Research Group Functional Verification Study
  • Part 2: The 2012 Wilson Research Group Functional Verification Study
  • May 2013
  • Texas-Sized DAC Edition of Verification Horizons Now Up on Verification Academy
  • IEEE 1801™-2013 UPF Standard Is Published
  • Part 1: The 2012 Wilson Research Group Functional Verification Study
  • What’s the deal with those wire’s and reg’s in Verilog
  • April 2013
  • Getting AMP’ed Up on the IEEE Low-Power Standard
  • Prologue: The 2012 Wilson Research Group Functional Verification Study
  • March 2013
  • Even More UVM Debug in Questa 10.2
  • IEEE Approves New Low Power Standard
  • February 2013
  • Verification Horizons DVCon Issue Now Available
  • Get your IEEE 1800-2012 SystemVerilog LRM at no charge
  • IEEE 1800™-2012 SystemVerilog Standard Is Published
  • See You at DVCon 2013!
  • Get Ready for SystemVerilog 2012
  • January 2013
  • VHDL Update Comes to Verification Academy!
  • December 2012
  • IEEE Approves Revised SystemVerilog Standard
  • November 2012
  • Coverage Cookbook Debuts
  • October 2012
  • IoT: Internet of Things
  • Check out the October, 2012 Verification Horizons
  • Improving simulation results with formal-based technology
  • Introducing “Verification Academy 2.0”
  • September 2012
  • OVM Gets Connected
  • August 2012
  • OpenStand & EDA Standardization
  • July 2012
  • Synthesizing Hardware Assertions and Post-Silicon Debug
  • Virtual Emulation for Debugging
  • Verification Academy: Up Close & Personal
  • SystemC Standardization Cycle Completes
  • Verification Standards Take Another Step Forward
  • New UVM Recipe of the Month: Scoreboarding in UVM
  • June 2012
  • Intelligent Testbench Automation – Catching on Fast
  • May 2012
  • Two Articles You Need to Check Out
  • Off to DAC!
  • Dave Rich Featured on EEWeb
  • March 2012
  • How Did I Get Here?
  • February 2012
  • Expanding the Verification Academy!
  • Get on the Fast Track to Advanced Verification with UVM Express
  • Introducing UVM Connect
  • Tornado Alert!!!
  • UVM: Some Thoughts Before DVCon
  • UVM™ at DVCon 2012
  • January 2012
  • SystemC 2011 Standard Published
  • Verification solutions that help reduce bug cost
  • December 2011
  • Instant Replay for Debugging SoC Level Simulations
  • 2011 IEEE Design Automation Standards Awards
  • November 2011
  • Getting started with the UVM – Using the Register Modeling package
  • TLM Becomes an IEEE Standard
  • October 2011
  • Worlds Standards Day 2011
  • VHS or Betamax?
  • Verification Issues Take Center Stage
  • September 2011
  • New UVM Recipe-of-the-Month: Sequence Layering
  • July 2011
  • Combining Intelligent Testbench Automation with Constrained Random Testing
  • Going from “Standards Development” to “Standards Practice”
  • Verification Academy Now Includes OVMWorld Content
  • June 2011
  • Intelligent Testbench Automation Delivers 10X to 100X Faster Functional Verification
  • Part 9: The 2010 Wilson Research Group Functional Verification Study
  • Verification Horizons DAC Issue Now Available Online
  • Accellera & OSCI Unite
  • The IEEE’s Most Popular EDA Standards
  • UVM Register Kit Available for OVM 2.1.2
  • May 2011
  • Part 8: The 2010 Wilson Research Group Functional Verification Study
  • Getting Your Standards Update @ DAC 2011
  • April 2011
  • User-2-User’s Functional Verification Track
  • Part 7: The 2010 Wilson Research Group Functional Verification Study
  • Part 6: The 2010 Wilson Research Group Functional Verification Study
  • SystemC Day 2011 Videos Available Now
  • Part 5: The 2010 Wilson Research Group Functional Verification Study
  • Part 4: The 2010 Wilson Research Group Functional Verification Study
  • Part 3: The 2010 Wilson Research Group Functional Verification Study
  • March 2011
  • Part 2: The 2010 Wilson Research Group Functional Verification Study
  • Part 1: The 2010 Wilson Research Group Functional Verification Study
  • Prologue: The 2010 Wilson Research Group Functional Verification Study
  • Language Transitions: The Dawning of Age of Aquarius
  • Using the UVM libraries with Questa
  • February 2011
  • DVCon: The Present and the Future
  • Free at Last! UVM1.0 is Here!
  • Parameterized Classes, Static Members and the Factory Macros
  • IEEE Standards in India
  • January 2011
  • Accellera Approves New Co-Emulation Standard
  • December 2010
  • New Verification Horizons: Methodologies Don’t Have to be Scary
  • The Survey Says: Verification Planning
  • October 2010
  • Towards UVM Register Package Interoperability
  • IEC’s 47th General Assembly Meeting Opens
  • UVM: Giving Users What They Want
  • September 2010
  • UVM Takes Shape in the Accellera VIP-TSC
  • Accellera VIP-TSC Selects RAL for UVM 1.0 Register Package
  • OVM Cookbook Available from OVMWorld.org
  • UVM Register Package Candidate News
  • August 2010
  • Redefining Verification Performance (Part 2)
  • July 2010
  • Making formal property checking easy to use
  • Redefining Verification Performance (Part 1)
  • SystemVerilog Coding Guidelines: Package import versus `include
  • June 2010
  • The reports of OVM’s death are greatly exaggerated (with apologies to Mark Twain)
  • New Verification Academy Advanced OVM (&UVM) Module
  • OVM/UVM @DAC: The Dog That Didn’t Bark
  • DAC: Day 1; An Ode to an Old Friend
  • UVM: Joint Statement Issued by Mentor, Cadence & Synopsys
  • Static Verification
  • OVM/UVM at DAC 2010
  • DAC Panel: Bridging Pre-Silicon Verification and Post-Silicon Validation
  • Accellera’s DAC Breakfast & Panel Discussion
  • May 2010
  • Easier UVM Testbench Construction – UVM Sequence Layering
  • North American SystemC User Group (NASCUG) Meeting at DAC
  • An Extension to UVM: The UVM Container
  • UVM Register Package 2.0 Available for Download
  • Accellera’s OVM: Omnimodus Verification Methodology
  • High-Level Design Validation and Test (HLDVT) 2010
  • New OVM Sequence Layering Package – For Easier Tests
  • OVM 2.0 Register Package Released
  • OVM Extensions for Testbench Reuse
  • April 2010
  • SystemC Day Videos from DVCon Available Now
  • On Committees and Motivations
  • The Final Signatures (the meeting during the meeting)
  • UVM Adoption: Go Native-UVM or use OVM Compatibility Kit?
  • UVM-EA (Early Adopter) Starter Kit Available for Download
  • Accellera Adopts OVM 2.1.1 for its Universal Verification Methodology (UVM)
  • March 2010
  • The Art of Deprecation
  • OVM 2.1.1 Now Ready for Download
  • February 2010 Verification Horizons Newsletter Now Available
  • IEEE Standards Meetings in India
  • February 2010
  • I Do It …
  • SystemVerilog: A time for change? Maybe not.
  • Partners Offer Support for OVM 1.0 Register Package
  • SystemC Day at DVCon
  • OVM/VMM Interoperability Kit: It’s Ready!
  • January 2010
  • Three Perfect 10’s
  • OVM 1.0 Register Package Released
  • Accellera Adopts OVM
  • SystemC (IEEE Std. 1666™) Comes to YouTube
  • Debugging requires a multifaceted solution
  • December 2009
  • A Cliffhanger ABV Seminar, Jan 19, Santa Clara, CA
  • Truth in Labeling: VMM2.0
  • IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
  • December Verification Horizons Issue Out
  • Evolution is a tinkerer
  • It Is Better to Give than It Is to Receive
  • Zombie Alert! (Can the CEDA DTC “User Voice” Be Heard When They Won’t Let You Listen)
  • DVCon is Just Around the Corner
  • The “Standards Corner” Becomes a Blog
  • I Am Honored to Honor
  • IEEE Standards Association Awards Ceremony
  • ABV and being from Missouri…
  • Time hogs, blogs, and evolving underdogs…
  • Full House – and this is no gamble!
  • Welcome to the Verification Horizons Blog!
  • September 2009
  • SystemVerilog: The finer details of $unit versus $root.
  • SystemVerilog Coding Guidelines
  • July 2009
  • The Language versus The Methodology
  • May 2009
  • Are Program Blocks Necessary?