Feed on
Posts
Comments

Archive for the ‘SystemVerilog’ Category

Verilab at DVCon 2020

Tuesday, February 25th, 2020 by Alex Melikian

The month of march is coming up and that means the DVCon US conference is around the corner. Once again, Verilab will be running a Short Workshop at this year’s conference, entitled “Parameterize Like a Pro”, to be held on Monday March 2nd at 3:30pm.

Our award winning  consultants, Jeff Montesano and Paul Marriott, will be doing the honors and hosting the session. They will present field-tested techniques,  as well as the tricks, skills and insight needed by verification engineers dealing with the challenges of verifying a highly configurable parameterized RTL designs and IP. Full details are available here:

https://dvcon.org/content/event-details?id=292-5-SW

On Wednesday March 4th, Paul Marriott, member of the DVCon technical program committee, will host the technical session entitled SystemVerilog Solutions taking place in the Fir Room from 3:00 until 4:30pm.

(more…)

SNUG Austin 2019

Thursday, September 5th, 2019 by Alex Melikian

Continuing a tradition, Verilab is proud to participate in our hometown conference at SNUG Austin 2019. Seasoned consultants Jeff Vance and Alex Melikian will present “All Your Base Transactions Belong to Us” on Wednesday, September 11th.

Based on their conference paper, the presentation will cover how the mixin design pattern can be utilized in SystemVerilog to supplement any transaction class in a UVM project with centrally defined metadata and functionality. The solutions presented can be applied to any verification project with minimal effort to achieve better management of code dealing with transaction processing. These can enhance control of system-wide dataflow, improve the quality of debug information and increase overall verification efficiency over the course of a project.

Complete details on the proceedings of this conference can be found here:

https://event.synopsys.com/ehome/468341/agenda/

As always, Verilab looks forward to sharing ideas and engaging with the verification community. All our past published conference papers and presentations can be found here:

http://www.verilab.com/resources/papers-and-presentations/

See you at SNUG Austin 2019!

Verilab at DVCon 2019

Thursday, February 21st, 2019 by Alex Melikian

Verilab is proud to be returning to DVCon in 2019 and will be running the “Be a Sequence Pro” workshop on Thursday February 28th. Last year’s best paper award winning co-authors Jeff Montesano and Jeff Vance will give a lecture style workshop covering guidelines of managing large-scale UVM sequence libraries. Topics covered will include sequence implementation guidelines, tips for streaming data applications, improving verification productivity and support for a Portable Stimulus workflow. Full details are available here:
https://dvcon.org/content/event-details?id=264-7-SW

Also in attendance at the conference will be our CTO Jason Sprott and vice president Vanessa Cooper. As always, we look forward to meeting you and sharing ideas in the verification community.

For a look at our past conference papers and presentations, follow the link here.

See you at DVCon 2019!

DVCon EU & SNUG Austin 2018

Thursday, October 18th, 2018 by Alex Melikian

This month, Verilab consultants will be participating in, and presenting at two conferences on two continents.

On October 23rd, award-winning authors Jeffrey Montesano and Jeff Vance will present “Use the Sequence, Luke! Guidelines to Reach the Full Potential of UVM Sequences” at SNUG Austin 2018. This presentation covers guidelines for optimizing control, effectiveness, debugging and reuse of UVM sequences, based on extensive project experience of complex designs. More details here.

Furthermore, multi-award winning consultant Mark Litterick will run a “UVM Audit: Assessing UVM Testbenches” tutorial at DVCon Europe on October 24th. This tutorial presents strategies and guidelines for auditing UVM code to identify and address reuse, flexibility and effectiveness of a testbench. More details here.

As always, we look forward to meeting people and sharing ideas in the verification community. For a look at our past conference papers and presentation, follow the link here:
http://www.verilab.com/resources/papers-and-presentations/

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

Work For Verilab