Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick, Editor and Verification Technologist, Mentor Graphics
Welcome to our special DAC 2016 Edition of Verification Horizons.
As I've said many times, DAC is undoubtedly my favorite work-related week of the year. In giving us all the opportunity to see the amazing technology that Mentor Graphics, our partners and even our competitors introduce and the chance to catch up with old friends and colleagues, it serves as an annual milestone by which we measure both the progress of our industry and the passing of time. This year, DAC happens to follow closely on the heels of a personal milestone as well. By the time you read this, my son, David, will have graduated from high school. I hope you'll forgive a little paternal pride and allow me to tell you that he completed high school as the valedictorian of his class and will be attending Georgetown University in the fall. His mother, sister and I are, as you can imagine, extremely proud of him. I feel in some ways like we've reached "tape out" with this amazing young man as he goes out into the world, but of course our job is nowhere near complete. And, fortunately, we still have the summer with him.
by Joe Hupcey III and Bryan Ramirez, Mentor Graphics
The number one priority in vehicle security is to harden the root-of-trust; from which everything else — the hardware, firmware, OS, and application layer's security — is derived. If the root-of-trust can be compromised, then the whole system is vulnerable. In the near future the root-of-trust will effectively be an encryption key — a digital signature for each vehicle — that will be stored in a secure memory element inside all vehicles. In this article we will show how a mathematical, formal analysis technique can be applied to ensure that this secure storage cannot (A) be read by an unauthorized party or accidentally "leak" to the outputs or (B) be altered, overwritten, or erased by unauthorized entities. We will include a real-world case study from a consumer electronics maker that has successfully used this technology to secure their products from attacks 24/7/365.
Note that the techniques and solutions described herein are focused exclusively on digital circuitry specified in a register transfer level (RTL) language, such as Verilog or VHDL – i.e. the most fundamental level of digital design. This article does not go into any physical design and verification issues or related "side-channel" attacks, nor do we address firmware or higher level software security best practices.
by Raman Jain and Priya Minocha, Mentor Graphics
Since the advent of television, transference of video data from source to display has been a challenging task. Video by nature contains large amounts of information that needs to be transferred quickly. As modern digital displays were introduced, new standards to transfer the video were also introduced; such as Digital Visual Interface (DVI), High-Definition Multimedia Interface (HDMI), DisplayPort, UDI, GVIF, etc.
Digital transmission of audiovisual content is desirable when pursuing the highest possible quality, as it allows perfect reproduction of the source content on displays. But that data must be kept secure from unauthorized parties. High-Bandwidth Digital Content Protection (HDCP), developed by Intel®, provided a solution to prevent copying of digital audio and video content as it travels across the devices. HDCP involves multiple standards that contain various complex algorithms used during authentication, which itself is a multi-step flow and hence makes it difficult to use. This article describes various challenges in the field of verifying and debugging HDCP protected interfaces (HDMI and DisplayPort), and how Mentor's QVIP makes this task easier for users by providing simple to use APIs and debug messages.
by Rich Edelman, Mentor Graphics
SystemVerilog is a powerful language which can be used to build models of RTL in order to facilitate early testbench testing. The early RTL model uses higher level abstractions like SystemVerilog threads, queues, dynamic arrays and associative arrays. Using high level abstractions allows a functional model to be created with little effort. A simple fabric model is created implementing AXI-like READY/VALID channels.
Building a UVM [1] testbench is a hard job, made harder when operational RTL is not yet available to test. SystemVerilog [2] is a powerful modeling language that can be used to build a high level model of hardware before RTL is available. This model is fast to write, and can be as functionally complete as needed. This article will describe the creation and use of a fabric model to build and bring up a testbench. When the RTL is available it can be plugged into the testbench model with little change required.
The main contributions of this article are: showing a fully functional model of a medium complexity communication fabric; writing the model using SystemVerilog; and building a reusable testbench that can support block testing as well as support system level tests. The testbench implementation is not discussed in this article.
by Lauro Rizzatti, Rizzatti LLC
Take a step down the stack beyond optical networks, switches, routers and software-defined networking to consider the networking system on chip (SoC), the brains of the network infrastructure.
Networking SoCs, integrated circuits (ICs) that combine all components of an electronic system, such as an Ethernet switch or router, onto a single chip, are more complex these days than any one human could imagine. In fact, they have replaced the graphics chips found in mobile phones, personal computers, workstations and game consoles as the largest and most complex chip designs. Project teams report that they consume 500,000 or more application specific integrated circuit (ASIC)-equivalent gates.
The reasons for the massive size and extreme complexity are the large number of Ethernet ports, soon crossing over the 1,000 ceiling; expanded throughput, up to 400Gbps; sub-microsecond latency; and improved redundancy and resiliency to minimize performance degradation due to network congestion, failures and resource exhaustion during maximum utilization.
by Francis Raguin, Barco N.V.
"RTCA DO254 - Guidance document for the development of hardware components for airborne equipment – requires the functional behavior of FPGAs to be silicon proven on the final application hardware:
§6.3.1: "When it is not feasible to verify specific requirements by exercising the hardware item in its intended operational environment, other verification means should be provided and justified."
Furthermore the guidance requests evidence of the FPGA functional requirements coverage – as explicitly mentioned in FAA Order 208110.105 §6.2d: "We support RTCA/DO-254 when we require applicants to measure and record the verification coverage of the requirements achieved by test on the component itself in its operational environment."
So the verification of an FPGA in a DO254 context must:
- Be performed on the device itself on its final application board
- Be quantified in terms of functional requirement coverage
This article shows how the Barco Silex AVP254 uses Mentor Graphics to solve this challenge, giving credibility toward certification authorities and much more."
by Dan Alexandrescu and Adrian Evans, IROC Technologies
In high-reliability and safety-critical applications, RT and gate-level fault-injection simulations are often performed in order to ensure a certain level of fault detection coverage which is necessary to ensure compliance with standards such as ISO 26262. There are many techniques available for accelerating the simulations including emulation platforms, however, in most cases, classifying the failing scenarios remains a manual task and is often the limiting factor in the number of fault injections that can be performed.
In this article, we show how the components of a UVM functional verification environment can easily be extended to record additional information about the types of errors that have occurred. This additional information can be used to classify failing tests based on their system level impact (e.g. Silent Data Corruption, Detected Uncorrected Error, etc.). We present an architecture that can be implemented on Mentor's Questa® Verification Platform for designs with UVM DVE.
by Kiran Sharma and Bhavna Agarwal, Agnisys Technology Pvt. Ltd.
Using the design of an Ethernet (media access control) MAC as a sample, this case study will examine how complete verification can be done in an integrated and automated manner, saving time while improving quality.
Two software tools will be highlighted that offer ease of use and thoroughness for users to verify an IP/SoC with certainty. The first creates tests for a variety of scenarios in a way that is more efficient and exhaustive than a pure constrained random methodology. The other forms a layer of abstraction around the IP/SoC from a specification.
ISequenceSpec™ (ISS) is used to create a specification of the sequences in the design. These sequences can be transformed into UVM sequences, firmware code, validation sequences, etc. from a common format. The UVM sequences generated by ISS can be imported into inFact™ from Mentor Graphics®. Next we show how to create exhaustive tests using these low level generated sequences using the inFact tool. As a sample we created a library of Ethernet sequences as follows:
Media Independent Interface Management (MIIM) module sequences (MIIM initialization and PHY access), Flow Control sequences (automatic, manual), Ethernet transmit packet sequences, Ethernet receive packet sequences, Ethernet initialization sequences (i.e., Ethernet controller initialization and Ethernet controller wake-up on ISR sequence). inFact is used to randomize these sequences and prove that the device will work in all practical scenarios.
by Srinivasan Venkataramanan and Ajeetha Kumari, VerifWorks
Universal Verification Methodology (UVM) is the industry standard verification methodology for Verification using SystemVerilog (SV). UVM provides means of doing verification in a well-defined and structured way. It is a culmination of well-known ideas, thoughts and best practices.
Given the major adoption of UVM across the globe and across the industry, advanced users are looking for tips and tricks to improve their productivity. UVM does define a structured framework for building complex testbenches. It is built on strong OOP principles and design patterns using underlying SystemVerilog language features. This strong OOP nature presents certain challenges to the end users. Recall that many Design-Verification (DV) engineers come from hardware, electronics backgrounds and not heavy Software backgrounds. Hence at times it gets tricky for users to debug UVM based testbenches when things do not work as expected.
In this article the authors share their long experience of assisting customers with run time debug of common UVM issues and potential solutions to them. During our various training and consulting engagements using UVM we have seen DV engineers struggling to debug relatively simple UVM issues. It will be unfair to blame the users as many a times, the error messages are cryptic and do not point to the actual source code, rather somewhere from the base classes, making the debug difficult. We have captured a series of such common issues and error messages into a collateral form that we call "UVM Vault". As part of our QVP engagement with Mentor Graphics, we are integrating this UVM Vault to Questa® in the near future.
