"It's great to have a plan, but automation and tools are what make the plan into something usable."
Hi everyone, and welcome to another super-sized Verification Horizons issue for DVCon U.S.
Last spring, my wife and I decided to take a family vacation to Hawaii this February, which coincidentally is just before DVCon. We're celebrating several family milestones, including our 20th anniversary, my son's 18th birthday and my father-in-law's 80th, so we're all going. As I've mentioned before, my wife is great at planning and managing things like this, and there are many similarities between planning a vacation and managing a verification project. As we know, having a plan is critical to a project's success, so my endearingly "old-school" wife has all of our plans written out in a document, which she'll print out and bring with us. As a "tool guy," I showed her an app I use that will automatically load all our confirmation emails into a cool interactive itinerary. It's great to have a plan, but automation and tools are what make the plan into something usable. You'll see this theme throughout the following articles.
We begin this issue with two case study articles from users "in the trenches" of verification. First, our friends at Baker Hughes share "An Evaluation of the Advantages of Moving from a VHDL to a UVM Testbench," in which they discover the advantages of self-checking randomized testing in UVM, even for FPGA designs. For those of you doing FPGA designs in VHDL, this article should allay any fears you may have about moving to UVM as most of your competitors are doing.
Our second case study comes from our friends at Qualcomm, with an assist from XtremeEDA, where they share their "First Time Unit Testing Experience Report with SVUnit." Their methodology stresses unit testing critical testbench components to avoid the dreaded "is it a design bug or a testbench bug?" question that so often plagues verification engineers, particularly at the integration stage. As you'll see, this approach does require some up-front effort, but the payoff is clear. If you can prevent bugs from getting through to tapeout, why wouldn't you?
We begin a set of articles from my Mentor colleagues by introducing "The Verification Academy Patterns Library," a new feature of the Verification Academy website that documents a set of good design practices to solve often-recurring problems in verification. The concept of design patterns is not new, but we believe this is the first and most extensive effort to document a pattern library specifically for verification. As you'll see, the pattern library is clearly organized into categories so it will be easy to locate a pattern that may be applicable to your specific problem and allow you to take advantage of the knowledge provided by a diverse team of experts from assertion-based and formal verification to constrained-random and coverage-driven verification across simulation, hardware-assisted verification and emulation.
Next we learn how to achieve "Increased Efficiency with Questa® VRM and Jenkins Continuous Integration" by applying the software practice of Continuous Integration to verification management. Experience and common sense show that the longer a branch of code is checked out the more it drifts away from the previous version in the repository, making it more likely that problems will occur when checking it back in. The article shows how Jenkins, a free open-source tool, can be used to monitor the source repository and use Questa's Verification Run Manager (VRM) to handle the necessary verification tasks and supply results back to Jenkins for display in a dashboard.
Our next several articles highlight different aspects of Questa Verification IP (QVIP), beginning with "Verifying Display Standards: A Comprehensive UVM-Based Verification IP Solution." This article offers practical advice on how to set up your UVM environment to include QVIP as well as highlighting some of the benefits of QVIP in general. In "Nine Effective Features of NVMe® Questa® Verification IP to Help You Verify PCIe-Based SSD Storage," you'll get an overview of the new Non-Volatile Memory Express® (NVMe) specification and see how our new Questa NVMe VIP can help you accelerate the verification of your PCIe-based Solid State Drives that use the NVMe interface. In "MIPI C-PHY™: Man of the Hour," you'll get an introduction to the three physical layers used in the MIPI Alliance for mobile imaging systems and the tradeoffs between them, and learn what features Questa VIP provides to assist in their verification. We wrap up the QVIP articles with "Total Recall: What to Look for in a Memory Model Library," which provides an extremely useful analysis of the key features you should look for in evaluating a VIP Memory Library. It highlights some of the unique features of the QVIP Memory Library, including on-the-fly configuration.
Our next article, "Certus™ Silicon Debug: Don't Prototype Without It," addresses that age-old question of what to do once you've gotten your full SoC running as an FPGA prototype in the lab and you find a problem. It highlights the many layers of the debug problem and shows how our Certus™ Silicon Debug tool provides unsurpassed visibility into the inner workings of your FPGAs and lets you see the results in the Visualizer™ Debug Environment, just as if you were running in simulation. The idea of defining trigger conditions and capturing HW signals reminds me of my days designing logic analyzers back in the 80s (yes, I'm that old), and I find it fascinating that we can now do the same thing inside an FPGA with millions of gates. This is some really great technology that you have got to check out.
Next we have the first of several articles relating to DO-254 verification. We begin with "Simplified UVM for FPGA Reliability," where we see how the component-based nature of UVM can help with the auditing process in DO-254. This article also reiterates some of the conclusions from the Baker Hughes article.
In our Partners' Corner, we continue our DO-254 sub-theme with a discussion of "Complex Signal Processing Verification Under DO-254 Constraints," in which our friends at AEDVICES Consulting show how they combined assertions, UVM and functional coverage to support requirements-based verification for safety critical processes like DO-254 and ISO 26262.
Since no DO-254 project is complete without documentation, our friends at eInfochips walk us through "Simplifying Generation of DO-254 Compliant Verification Documents for Airborne Electronic Hardware (AEH) Devices." They show us a step-by-step process to go from a Verification Case Document (VCD) to importing a testplan into a UCDB in Questa, against which you can measure your functional coverage from your UVM simulation. We follow this with a discussion of "DO-254 Compliant UVM VIP Development" from ELECTRA IC, in which they provide a case study of putting together a UVM environment using Questa VIP and Verification Run Manager for a recently completed DO-254 project. And last but not least, we learn from our friends at Ensilica how to build a "Reusable Verification Framework," where they use UVM to build BFMs in the interface instead of virtual interfaces in the driver to simplify block-to-top reuse of interface components.
I hope to see you at DVCon. I'll be around in many of the sessions, speaking on a few panels, and you can always stop by booth 501 to say "Hi". I'm hoping to show off my tan.
Editor, Verification Horizons
Back to Top