New and Improved SystemVerilog 1800-2017
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.
So, what’s new and improved in the 1800-2017 standard?
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.
Comments
Leave a Reply
You must be logged in to post a comment.
While the other 3 reasons are worthy of being celebrated, the first one, “[no] new features to learn that you will never remember how to use anyway” is not something I would list as a benefit. There are so many useful things that are missing from the LRM and now we’ll have to way another 5 +/- 1 years to get them.
IMHO, what we really need is extending support of existing SV capabilities by tools’ vendors. There is still something to do. Also it would be just amazing to have wider synthesiable subset of SV since similar high-level C/C++ language expressions are supported by HLS tools. I feel like we all have stucked somewhere for too long time. I guess, problem is more related to users rather than to vendors, because “many users (and teachers) have yet to adopt many of the features from Verilog-2001”. Actually it makes me to worry about the industry future. It’s not that pace to make Elon Mask’s dreams come true. 🙂
“There are so many useful things that are missing from the LRM and now we’ll have to way another 5 +/- 1 years”
Yes, like multiple inheritance, regular expressions, function and operator overloading, and the real annoyance of method prototypes of derived classes having to match EXACTLY the base class (e.g. uvm_subscriber’s “write(T t)” method; wow “t” is so descriptive).
What about SystemVerilog-AMS and SystemVerilog Nettype? When they will merge Verilog-AMS to SystemVerilog Assertion?
System Verilog has no capability to do something I think is important, which is to pass parameters *up* the hierarchy. An example of what I want to do is to to have top-level code that uses a memory. I pass some parameters down the hierarchy, and depending on memory width and length a memory implementation is selected. Each type of memory has a different implicit read delay. I’d like the top level to be able to know the read delay of the memory (obviously). I don’t want all the messy details of memory selection to be at the top level — the top level doesn’t need to know this, and I don’t want to have to change the top level to reflect a bunch of low-level decisions. All the top level needs to know is the associated memory delay, and pushing other information up to the top level violates encapsulation. Yet System Verilog has no way to do this.
I understand that it does make the language implementation more complicated, and it does lead to the possibility of circular references, which are obviously an error. So the compiler needs to detect and handle more errors. However, I think this is something that System Verilog could and should support.