Thoughts on the updated standard, by Principal Consultant Jonathan Bromley

A new revision

On Thursday 22^nd February 2018, the latest revision of the IEEE standard for the SystemVerilog language was published as IEEE Std.1800-2017 (yeah, I know that’s so last year, but you can’t fight the way these things work). Thanks to the generosity of Accellera www.accellera.com and its member companies, the full standard document – the language reference manual, or LRM –is available free of charge through the GetIEEE program at http://ieeexplore.ieee.org/document/8299595/. You’ll need an IEEE login to download it, but you can get one for free by following the links on that page.

How can I figure out what’s different?

Within hours of publication, colleagues were asking me the reasonable question “what’s new?” In principle you shouldn’t need to ask. The SystemVerilog standards development process is highly transparent. Anyone can read the LRM, and anyone can follow the progress of committee discussion by watching the Mantis bug tracker https://accellera.mantishub.io. In practice, though, I’ve saved you a load of trouble by slugging my way through all the issues that made the cut into 1800-2017 and creating the summary of changes that you’ll find later in this post.

How did we get to where we are today?

SystemVerilog first saw public light of day as an Accellera standard way back in 2003. Vendors rallied behind it, users were enthusiastic, and Accellera wisely passed the standard into the care of the IEEE. The first gold-plated, fully-official IEEE SystemVerilog standard appeared in 2005. There were significant revisions in 2009 and 2012, each adding important new features and functionality to an already large and rich language. Spurred on by the development and rapid adoption of the Universal Verification Methodology, commercial implementations of SystemVerilog became increasingly mature so that everyone could use the language with confidence (and, of course, with caution to avoid a few things that didn’t enjoy perfect support from all the available tools).

So, what happened since 1800-2012?

How can you have a SystemVerilog revision with no new features? Everyone has pet features that they would like to see in SystemVerilog. A ton of them got added in the 2009 and 2012 revisions – here are a few that I use routinely:

• fancy new coverage features
• new Linear Temporal Logic operators in SystemVerilog Assertions
• interface classes
• unpacked array concatenations

For 2017, though, the remit was clear: no new features. Boy, did we have to bite our tongues in the committee discussions (and no, I’m not allowed to tell you anything about what happened in them). The focus? Corrections, clarifications and improvements of LRM text – great news for anyone who tries to write code that will work reliably on any commercially available tools.

C’mon, spill the beans: How many changes?

As far as I can tell, 108 distinct Mantis issues made the cut and were fully resolved in time for incorporation into 1800-2017 by the editor. This is a good moment for a hat-tip to the tireless Shalom Bresticker, who served as LRM editor for this revision. His encyclopaedic knowledge of SystemVerilog, razor-sharp attention to detail, and diligent curation of the Mantis issue tracker made a huge contribution to the project’s success.

Just the words

Of those 108 issues, 69 were purely editorial or wordsmithing changes, improving LRM text or internal consistency without any technical controversy.

Whoops, we missed a few things in the VPI

There were three changes to the VPI header file vpi_user.h to fix some minor oversights.

Clarifications to provide a solid base for vendors and users

30 issues were minor clarifications that are probably only of interest to the most dedicated and obsessive LRM wonk. Stuff like typesetting of the BNF syntax rules in Annex A, a tightening-up of the strict definition of property vacuity, and improvements or corrections of a few code examples. However, some of these clarifications are worth a closer look. Take a peek at these Mantis items to learn more:

• clarification that it’s wrong to try to wait for an event’s .triggeredproperty to go false
• clear definition of what happens when the result of a streaming concatenation isn’t big enough to fit into its target
• array shuffle() method is now defined to exhibit random stability
• better definition of how to use local variables in an SVA sequence
• SVA’s property case construct requires a semicolon after each case item

But that was just the small stuff. What about the big-ticket items?

Of the 108 changes, just five by my reckoning were significant changes of definition. None of these are new language features. They’re just cleanups of areas of the standard that were too sloppy or just plain wrong. Some of those problem areas had led to incompatible divergence between different vendors’ implementations. Some were wrinkles in the language that were effectively un-implementable or too error-prone, and needed to be ironed out. Here they are, one by one:

1. Issue 343: modport declarations in generate blocks

   In the early days of SystemVerilog, a few brave engineers tried to use interfaces to Do Interesting Things in RTL design. Yes, you guessed it – I’m guilty, along with a few others. One of the things we thought was cool: representing a set of connections to an interface by using a modport, which could then be instantiated more than once in the interface. So you define a modport to represent – let’s say – a slave device’s connection to a bus fabric. And then you instantiate an array of those modports, so that an array of slaves can connect to them.

   Oh my, were we wrong. Brave, but wrong.

   A modport isn’t a thing you can instantiate.

   If you ever thought that using modports like this was a good idea, then read the Mantis ticket and weep. It isn’t. And you’re not allowed to do it any more. Modports are no longer allowed to appear inside a generate block.

   There are other, better ways to get the same result that will make good material for a future blog post.

2. Issue 2488: calling virtual methods from a class’s constructor

   Wise programmers know that it’s a bad idea to call a virtual method of any class from the class’s constructor. Different object-oriented languages deal with this situation in different ways, and it’s tricky. Unfortunately it was never properly defined in SystemVerilog – until now. Thanks to that lack of definition, different simulators behaved in different, incompatible ways. The required behaviour is now clearly defined, although it may take a while before tools converge on that behaviour.

   Wise programmers will continue to avoid calling virtual methods from the constructor. The effects are gnarly and far from intuitive.

3. Issue 4939 and 5540: randomization of enums

   These two corrections deal with some interesting issues about randomization of enum variables. The enum literals define a set of possible values. Should that be treated as a constraint on the enum? What happens if the enum is a member of a packed struct? Once again these are questions that weren’t properly answered, and simulators had begun to diverge. There’s now a clear definition of how it all works. Check your favourite simulator to see how it stacks up against the new definition.

4. Issue 5183: syntax of pragma expressions

   This fixes some problems in the definition of “protected envelopes”, SystemVerilog’s mechanism for delivering encrypted source code. It’s likely to be of interest mainly to IP vendors.

5. Issue 5217: operator overloading removed

   Yes, you read it correctly. The operator overloading feature, which has never been implemented by any tool that I know about, has been removed from the LRM. The feature was never properly defined, and there were too many difficulties with the definition for it to be retained.

   This isn’t the first time a feature has been completely deleted from SystemVerilog, but it’s probably the most significant.

So Long, And Thanks For All The Syntax

Thanks for reading this roundup of the changes in SystemVerilog for the 2017 revision. That revision also marks the end of my own involvement with SystemVerilog standardization, as I stand down from the standardization process.

I’ve been honoured (with a U, me being a Brit – apologies to anyone west of Iceland who doesn’t like the spelling) to serve on SystemVerilog standards working groups for nearly 14 years. I don’t use the word “honour” lightly. It’s been a huge privilege to work alongside the exceptionally smart and dedicated people who, supported by their employers, have given time and expertise to make SystemVerilog better for the whole EDA community – an enormous effort in which I’ve made a few tiny contributions. It’s been an amazing journey, engaging with the development of a programming language that is almost synonymous with digital hardware design and verification. It’s introduced me to an astonishing group of talented, enthusiastic, generous-spirited experts from vendor and user companies. Many of those people – you know who you are – have taught me a huge amount, and I’m deeply grateful.

Any errors in this summary are mine alone; if you find any, please get in touch at jonathan.bromley@verilab.com and I’ll be happy to correct them and acknowledge your contribution.

25 February 2018

This entry was posted by Paul Marriott on Sunday, February 25, 2018 at 8:28 am and is filed under Info, Methodology, News, SystemVerilog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.