The IEEE-SA has a policy of keeping standards active by making sure they get a cycle of updates every 10 years. Including Verilog, SystemVerilog has been going on a cycle of updates every 5±1 years since 1995. I wrote here about the updates to 1800-2009 and 1800-2012, and now I’m writing about the upcoming release of 1800-2017.
The standard is new and improved. By that I mean the document that supposedly describes the behavior of the code you write. It resolves over 100 issues and probably 100s of editorial issues. Does this sound exciting? Probably not to most people. But here are the benefits and why it may be exciting to you:
- No new features to learn that you will never remember how to use anyway
- No forward or backward compatibility issues with your code from different versions of the standard.
- A document more accurately reflecting the behavior you are already getting from your tool
- Updated examples reflecting the recommended way of using SystemVerilog
For example, one issue defines the behavior of a call to a virtual method in a constructor. Different languages handle this inconsistently. Some do not allow it, others only consider it virtual up to the point where the method gets called from the constructor. Or does it call the fully extended method base on the final constructed object? The problem is the construction and initialization of a class object always starts at the base class and works its way up to the actual extended class. In the following code, when you construct class B, the call to print() from the base class constructor is now defined to call the print method B. But be aware, the values it displays for m and n will be 1 and 0 because the extended class B has yet to be initialized.
It’s a lot more work releasing a standard with no enhancements than you might think. It’s hard getting participation in a group tasked with just making clarifications and fixing bugs. People naturally want to be creative, and as engineers, love to add features. But in the end, I think this revision of the standard serves end users very well. They want to have a document that reflects the behavior they see in their tools.
What makes me say this?
I track all the articles I’ve written on this blog covering many different SystemVerilog topics. Surprisingly, there’s one article that consistently gets more hits than any other article on the site: What’s the deal with those wire’s and reg’s in Verilog. Users still struggle with one of the most basic concepts of Verilog from its initial release in 1985. Many users (and teachers) have yet to adopt many of the features from Verilog-2001 that were supposed to make writing HDL code easier. So, do we really need to add more features to the language to make people more productive?
Of course, the answer to that is always going to be yes. In fact, tool vendors are constantly correcting and extending SystemVerilog support without waiting for a new standard. It’s the nature of the industry and a tough balancing act.