Browse all content in Verification Academy: Articles, Cookbooks, Resources, Sessions, and Tracks

There are two similar experiences I’d like to share with you before we get into the great articles in this edition.

A few weeks ago, I attended the Ultimate Frisbee College National Championships to cheer on my son’s Georgetown team, who had qualified for the tournament for the first time ever. They were seeded 19th out of 20 teams and didn’t expect to qualify at all, so most of the team, fellow students, alumni and parents were just happy to be there to support them. No one really had any great expectations going into the tournament. Yet to our surprise, the team did well enough to find themselves in a qualifying match for the championship bracket. They played really well, but unfortunately lost the game 13-12.

I was struck by how everyone on the team and its “cheering section” was disappointed at coming so close to achieving what we all originally considered an unrealistic goal — even though the team had vastly exceeded expectations throughout the season.

On the same weekend, the Boston Celtics, playing without their two best players, lost Game 7 of the Eastern Conference Finals to the Cleveland LeBrons (also known as the Cleveland Cavaliers), thus falling one game short of reaching the NBA finals — a goal that seemed as unrealistic as Georgetown reaching the championship bracket. In both cases, it wasn’t until the previously-unrealistic goal came within reach that the disappointment of not attaining it (at least in the moment) eclipsed the pride and joy of a season filled with the successes required to even get that close.

As I sat down to write this note to you, it struck me that both teams and their fans experienced the dreaded “feature creep” that plagues all engineering projects. The project starts out with a set of requirements that the team works towards implementing and verifying. Then, as things start coming together the inevitable “why can’t we…” questions come up (usually from the marketing team), and we start adding more and more features that often become the bane of the verification team.

What may have appeared to be unrealistic (or even unnecessary) at the start of the project could, given how much has already been implemented, be added with just “incremental effort.” Of course, it rarely works out that way, especially for the verification team. We’ll see how it worked out for my son and his teammates a little later.

But now, on to the articles. Our lead article this time, “Comprehensive CDC Verification with Advanced Hierarchical Data Models,” comes from several of my colleagues on our Formal Verification Technology team. As with all verification, what works at the block level sometimes requires an adjusted approach to be applicable at the system level. In this article, we see how this problem is addressed for clock-domain crossing verification, where developing an abstract hierarchical model for each of the blocks, including integration rules, let’s you verify the system much more efficiently than trying to do flat verification of the entire design.

Next, we have “Creating SoC Integration Tests with Portable Stimulus and UVM Register Models,” by my colleague, Portable Stimulus Working Group cohort and all-around portable stimulus guru, Matthew Ballance. The article explores how the Accellera Portable Stimulus Standard (PSS) can be used to automate the creation of register-access tests at multiple integration levels by extracting information captured in a UVM register model. It also gives some great insight into the difference between test intent and test realization in PSS, which is a really important concept to grasp to be able to use PSS effectively.

In “It’s Not My Fault!” Doug Smith from our Consulting Division walks us through using formal verification to improve your fault verification for an ISO 26262 automotive safety-critical design. The keys to optimization lie in reducing the number of faults to be analyzed and then being able to reliably activate, propagate and observe their behavior and, most importantly, being able to automate the whole process. This article will show you what you need to know.

“Coverage Driven Verification of NVMe Using Questa QVIP” shows how to apply the functional coverage and verification plan built into Questa® VIP (QVIP) components to verify complex protocols. The approach shown here is consistent with our other QVIP components and can easily be extrapolated based on your environment. In addition, the article includes a nice overview of the NVMe protocol.

Part 2 of “Power Aware Static Verification—From Power Intent to Microarchitectural Checks of Low-Power Designs” (see Part 1 in our March 2018 edition) continues our discussion of power-aware static verification using the Unified Power Format (UPF). This portion of the article deals with how to analyze and debug the reports generated from static checks. I think you’ll find it to be a fairly comprehensive breakdown of this important technology.

In “Three Main Components to Look for in Your Emulation Platform,” my colleagues from our Emulation Division give a comprehensive overview of the critical components of an emulation platform and show how our new Veloce® Strato emulator fulfills these criteria.

We have several contributions to our Partners’ Corner this time around, starting with “Complex Addressable Registers in Mission Critical Applications” from our friends at Agnisys. In this article they share their experience in implementing several complex registers in mission-critical applications for their customers. You may find some of these to be applicable to your next design.

From our friends at Fishtail Design Automation, we have a great article on “RTL Glitch Verification” that shows how formal verification can be applied to this difficult and subtle problem. If you’re having glitch problems on critical signals in your design, you’ll want to check this one out.

Last but not least, we have an article by our friends at Codasip called “UVM-based Verification of a RISC-V Processor Core Using a Golden Predictor Model and a Configuration Layer.” I think you’ll find extremely helpful this comprehensive analysis of alternatives for creating configurable UVM environments that handle different configuration options for RISC-V. A big part of their solution is the ability to generate emulation-friendly verification environments and take advantage of a few other tricks to maximize productivity.

I am happy to report that my son and his teammates quickly rebounded from their heartbreaking loss (much quicker than the other parents and I) and had a great time watching the rest of the tournament, cheering on teams that they had lost to but also befriended. Once again, I was privileged to see my son interact with his peers in unguarded moments — an experience I have greatly enjoyed over the years.

If you’re at DAC, please make sure to stop by the Verification Academy booth (1622) and say, "Hi." We’ll have a full slate of presentations by users, partners and our experts. I hope to see you there.

Respectfully submitted,

Tom Fitzpatrick
Editor, Verification Horizons