{"id":12125,"date":"2016-03-02T23:06:40","date_gmt":"2016-03-03T06:06:40","guid":{"rendered":"https:\/\/blogs.mentor.com\/verificationhorizons\/?p=12125"},"modified":"2026-03-27T08:41:17","modified_gmt":"2026-03-27T12:41:17","slug":"verification-horizons-newsletter-dvcon-edition-available","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2016\/03\/02\/verification-horizons-newsletter-dvcon-edition-available\/","title":{"rendered":"Verification Horizons Newsletter DVCon Edition Available"},"content":{"rendered":"

Just wanted to take a minute from DVCon to let you know that the latest super-sized Verification Horizons<\/a><\/strong> is now available. If you read the editor’s note<\/a>, you’ll be able to read about my recent family vacation to Hawaii (which was awesome!), but you should really check out the articles:<\/p>\n

We begin this issue with two case study articles from users \u201cin the trenches\u201d of verification. First, our friends at Baker Hughes share \u201cAn Evaluation of the Advantages of Moving from a VHDL to a UVM Testbench<\/a>,\u201d 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.<\/p>\n

Our second case study comes from our friends at Qualcomm, with an assist from XtremeEDA, where they share their \u201cFirst Time Unit Testing Experience Report with SVUnit<\/a>.\u201d Their methodology stresses unit testing critical testbench components to avoid the dreaded \u201cis it a design bug or a testbench bug?\u201d question that so often plagues verification engineers, particularly at the integration stage. As you\u2019ll 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\u2019t you?<\/p>\n

We begin a set of articles from my Mentor colleagues by introducing \u201cThe Verification Academy Patterns Library<\/a>,\u201d a new feature of the Verification Academy<\/a> website\u00a0that documents 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\u2019ll 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.<\/p>\n

Next we learn how to achieve \u201cIncreased Efficiency with Questa VRM and Jenkins Continuous Integration<\/a>\u201d 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\u2019s Verification Run Manager (VRM) to handle the necessary verification tasks and supply results back to Jenkins for display in a dashboard.<\/p>\n

Our next several articles highlight different aspects of Questa Verification IP, beginning with \u201cVerifying Display Standards: A Comprehensive UVM-Based Verification IP Solution<\/a>.\u201d 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 \u201c9 Effective Features of NVMe\u00ae Questa Verification IP to Help You Verify PCIe-Based SSD Storage<\/a>,\u201d you\u2019ll get an overview of the new Non-Volatile Memory Express\u00ae (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 \u201cMIPI C-PHY: Man of the Hour<\/a>,\u201d you\u2019ll 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 \u201cTotal Recall: What to Look for in a Memory Model Library<\/a>,\u201d 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.<\/p>\n

Our next article, \u201cCertus Silicon Debug: Don\u2019t Prototype Without It<\/a>,\u201d addresses that age-old question of what do once you\u2019ve 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 CertusTM<\/sup> Silicon Debug tool provides unsurpassed visibility into the inner workings of your FPGAs and lets you see the results in the VisualizerTM<\/sup> 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\u2019m 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.<\/p>\n

Next we have the first of several articles relating to DO-254 verification. We begin with \u201cSimplified UVM for FPGA Reliability<\/a>,\u201d 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.<\/p>\n

In our Partners\u2019 Corner, we continue our DO-254 sub-theme with a discussion of \u201cComplex Signal Processing Verification Under DO-254 Constraints<\/a>,\u201d 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.<\/p>\n

Since no DO-254 project is complete without documentation, our friends at eInfochips walk us through \u201cSimplifying Generation of DO-254 Compliant Verification Documents for Airborne Electronic Hardware (AEH) Devices<\/a>.\u201d 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 \u201cDO-254 Compliant UVM VIP Development<\/a>\u201d 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 \u201cReusable Verification Framework<\/a>,\u201d 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.<\/p>\n

DVCon U.S. has been a great show this week. If you weren’t able to attend, I hope you’ll be able to join us next year. In the meantime, we’ll continue to keep you up to date with all the latest information you need to expand your Verification Horizons.<\/p>\n","protected":false},"excerpt":{"rendered":"

Just wanted to take a minute from DVCon to let you know that the latest super-sized Verification Horizons is now…<\/p>\n","protected":false},"author":71936,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-12125","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/12125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/71936"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=12125"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/12125\/revisions"}],"predecessor-version":[{"id":14523,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/12125\/revisions\/14523"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=12125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=12125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=12125"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=12125"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=12125"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=12125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}