Feed on
Posts
Comments

Archive for the ‘SystemVerilog’ Category

IEEE Std.1800-2017 for SystemVerilog: What Changed?

Sunday, February 25th, 2018 by Paul Marriott

Thoughts on the updated standard, by Principal Consultant Jonathan Bromley

A new revision

On Thursday 22nd 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:

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:

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

Silicon Valley SNUG: Sub-cycle Functional Timing Verification Using SystemVerilog Assertions

Tuesday, March 26th, 2013 by Paul Marriott

Verilab’s Anders Nordstrom will be presenting his paper “Sub-cycle Functional Timing Verification using SystemVerilog Assertions” at the Tuesday March 26th session at 10:30 am of SNUG Silicon Valley 2013.

This presentation shows a novel, more complete approach to functional verification of sub-cycle timing using SystemVerilog assertions in an OVM verification environment. This approach found many bugs which otherwise were missed in OVM-only simulations that didn’t include assertions.

This functional sub-cycle timing behaviour includes maintaining fixed delays and phase relationships between inputs and outputs and ensuring there are no glitches on clocks or delayed signals.

SystemVerilog assertions are evaluated on successive occurrences of an event or timing expression. This presents a challenge for sub-cycle timing verification, where there is no obvious reference clock suitable for triggering the assertions. Assertions sample their expressions in the preponed region of the simulation timestep, but the requirements called for sampling both before and after each triggering point. Examples of assertions showing how to overcome this and many other issues will be shown along with recommendations on how to write assertions for functional timing verification.

This paper is complementary to the paper presented by Paul Marriott at DVCon 2013 entitled Run-time Configuration of a Verification Environment - A Novel Use of the OVM/UVM Analysis Pattern. The sub-cycle timing relationships were dynamically varied during simulation and the assertions used were required to check for correctness as the actual relationships varied during the simulation.

UVM Phasing Survey

Tuesday, December 4th, 2012 by JL Gray

Verilab is currently conducting a survey to find out how SystemVerilog/UVM users are, well, using phasing and phase jumping. We would greatly appreciate your feedback! Click on the link below to take the survey.

UVM Runtime Phasing and Phase Jumping Survey

Verilab at DAC, SNUG Technical Committee Award

Tuesday, May 29th, 2012 by Paul Marriott

With the 49th DAC almost upon us, design and verification engineers will inevitably be thinking of the latest and greatest tools on offer from the EDA vendors. Despite complaints of ever increasing complexity being a problem, somehow the tools we’ve been using for the past several decades have been good enough to allow Moore’s Law to continue unabated, with 22nm technology being the latest production point on this exponential curve. Verilab will be there, as usual, to cover this important event and our VP and blogger-in-chief, JL Gray will be covering this over on Cool Verification.

As much as new shiny tools are interesting, sometimes it’s interesting to focus on some more mundane aspect of verification. Often verifiers are faced with what appears to be a simple problem, but which isn’t implemented in any vendor-neutral methodology. It’s always tempting to use tool-specific code, but fewer companies have the ability to restrict themselves to only one vendor over the lifetime of a product and its subsequent revisions. This is where methodologies such as the UVM are particularly useful. However, as much as they are touted as the solution to today’s verification problem, they often are missing some features which make a verifier’s job easier.

One such example is the ability to monitor value changes on arbitrary signals in the DUT without having to have a lot of hard-coded cross-module references. Such references make re-usability difficult, either when a block is reused in a top-level environment or in a completely different environment altogether. It would be nice if such references could be simply specified as strings and then advantage could be taken of the UVM’s configuration database to set and appropriate string for the use-case in question. However, such a facility is not part of the UVM right now.

Fortunately, Verilab’s Jonathan Bromley was motivated enough, when faced with this problem in a real project, to come up with a novel package that uses the SystemVerilog VPI/DPI to neatly provide a solution that works in the three major simulators that support the UVM. Jonathan  presented his paper on this at SNUG Munich on May 23rd and at SNUG UK on May 24th. His paper received the Technical Committee’s “Best Paper Award”.

SNUG 2009 Multi-Stream Scenario Paper Now Available

Saturday, April 18th, 2009 by JL Gray

Verilab’s award-winning paper entitled “Using the New Features in VMM 1.1 for Multi-Stream Scenarios” is now available for download from the Verilab website. Please let us know if you have any questions!

Litterick’s OCP-IP newsletter article uses Verilab’s OCP uVC VIP as an example

Wednesday, January 7th, 2009 by Jason Sprott

Mark Litterick’s OCP-IP December 2008 newsletter article demonstrates how two key aspects of OCP – profiles and transactions — were adopted as fundamental building blocks for the architecture of a verification component targeted at constrained-random validation of OCP components and systems.

The article uses the Verilab OCP uVC as an example. This uVC is a mixed-language OCP compliant verification component that supports a major subset of Open Core Protocol Specification 2.2. The OCP uVC is implemented using SystemVerilog and e verification languages and complies with both the Open Verification Methodology (OVM) and e Reuse Methodology (eRM). The verification component can be used in SystemVerilog only applications without the Specman layer (or license), or it can be used in Specman-based verification environments as a regular eVC.

The OCP-IP article can be downloaded here

The full whitepaper can be downloaded here

DAC 2008 Presentations Now Posted

Wednesday, July 30th, 2008 by JL Gray

Just a quick FYI… both David Robinson and I have posted our DAC presentations on Verification Planning and SystemVerilog Interoperability on the Verilab website. Please check them out and let us know if you have any questions or comments!

SystemVerilog Gotcha: (when copying) a struct is not a class by another name

Sunday, January 20th, 2008 by Jason Sprott

SystemVerilog has two “similar” data types that allow variables to be grouped together in a handy package: the struct and the class. I’ve heard it often said, when explaining what a class (an object-oriented data type) is, that it is just like a C struct with functions. I used to have no problem with that, until, when reviewing and debugging testbench code, I started seeing some problems related to the way classes have to be treated differently to structs. One of the most common errors I’ve found is when data structures composed of classes are copied.

Consider the following: (more…)

SystemVerilog User Group 2007 Fall Meeting Stats

Wednesday, November 7th, 2007 by Jason Sprott

SVUG started in March 2007 and has had a total of 8 meetings so far. It’s been a great first year for all of us involved with SVUG. The meetings and forum have been met with real enthusiasm. We’ve had some interesting technical discussions with new and experienced developers using SystemVerilog on their projects. We had some great presentations and tutorials, including me banging on about functional coverage, and Verilab’s Mark Litterick presenting some cool Assertion Based Verification techniques. We even managed to get some users to share their own tips and tricks, including our very own JL Gray.

I just got the stats for the fall 2007 meetings. 480 registered in total, 280 attended. Of the people surveyed (nearly everyone that attended the 5 meetings), 60% were using SystemVerilog today. Verification did pretty well out of that, with 67% of the share. Design got 10% and 23% said they used SystemVerilog for both design and verification. From a verification point of view another interesting stat was that 33% of the verification slice, were using the advanced testbench features of the language, and 32% were using SVA. It’s nice to see that more people are starting to use the HVL portion of the language for verification, not just writing assertions. I think this is due in no small to much better tool support and stability by all the vendors.

The growing attendance numbers of the SVUG meetings is a reflection of the interest and uptake of SystemVerilog by the design/verification community. I’m seeing an increase in our client projects using SystemVerilog Verification IP, and finding ways to hook SystemVerilog into their verification environments. Finally, it’s really beginning to feel like SystemVerilog is starting to make a bit of an impact.

Casting Strings to Enums in SystemVerilog

Sunday, October 21st, 2007 by JL Gray

Every once and awhile, I want to convert a string to an enumeration in SystemVerilog.  Casting from strings to enums is not supported in SystemVerilog, but luckily, it is possible to implement a function to do the appropriate conversion using built in methods designed for iterating over the enum values: 

(more…)

Work For Verilab