Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick - Mentor, A Siemens Business
In preparing this issue of Verification Horizons, I was planning to write my Editor's Note, once again, about the Patriots winning the Super Bowl. I had it all worked out how I was going to write about the need for preparation, planning, and execution and how a long-established methodology can bring disparate pieces of a project together to meet requirements and achieve your team goals. It was going to be great.
And then the Patriots lost.
To be fair, as a former colleague of mine wrote to me after the game, it was the most impressive losing effort in Super Bowl history, but it was still a loss. With the Patriots driving for what would have been the winning touchdown in the closing minutes, the Eagles—for the first and only time in the game—got to Tom Brady and forced a fumble that effectively ended the game. From the perspective of a Patriots fan, it was the football equivalent of a bug escaping into production hardware: a disaster.
by Matthew Ballance - Mentor, A Siemens Business
If you work in functional verification, you've likely become quite familiar with random constraints from functional verification languages such as SystemVerilog. Using a constraint solver to automate stimulus generation is key to quickly generating lots of stimulus that hits cases that weren't envisioned by the test writer. When using constrained-random generation, constraints are the mechanism by which we customize what is legal and interesting in the stimulus space.
Accellera's Portable Stimulus Standard (PSS) introduces some new constraint capabilities, in addition to supporting the capabilities that we've become familiar with in SystemVerilog. This article provides a guided tour of one of these new constraint features, along with examples that highlight their benefits.
If you've used SystemVerilog, you're likely very familiar with the constraint construct; random constraints declared within a class along with random fields. When an instance of the class is randomized, the constraints limit the available range of values.
by Arushi Jain and Rajat Rastogi - Mentor, A Siemens Business
PCI Express® (PCIe) is a point-to-point serial transceiver interconnect that provides higher transfer rates, increased bandwidth, and, hence, higher performance than its precursors: PCI and PCI-X. Its basic topology consists of an active root complex (downstream port) and an active endpoint (upstream port) device, wherein root complex signifies the root of an I/O hierarchy that connects the processor/memory subsystem to an I/O.
To a large extent, PCIe uses memory and completion request layer packets (TLP) to communicate information between memory mapped devices (transmitter and receiver). Memory requests transfer data to and from a memory mapped location and are typically categorized into memory write and memory read requests. Memory read requests must be completed by the receiver, also known as the completer. The size of memory read requests are limited by the transmitter configuration setting, known as maximum read request size (MRS).
OOB signaling is responsible for initializing the SATA interface as well as recovery from low power states. Initialization is the process of synchronous handshaking using OOB signals between two connected physical units. An important aspect of initialization is the speed negotiation process, which helps in establishing a common data transfer speed between host and device for effective communication.
by Naman Saxena, Nitish Goel, and Rajat Rastogi - Mentor, A Siemens Business
Developed to supersede Parallel ATA (PATA), the Serial ATA (SATA) protocol provides higher signaling rates, reduced cable sizes, and optimized data transfers for the connections between host bus adaptors and mass storage devices. SATA is a highspeed
serial protocol with a point to point connection between the host and each of its connected devices. It is a layered protocol comprising of a command and application layer, transport layer, link layer, and physical layer.
Starting with SATA GEN1's data transfer speeds of 1.5 Gbps, the speed has gone up to 6 Gbps in SATA GEN3. The physical layer is responsible for transmitting and receiving serial data streams. It employs gigabit technology, 8b/10b encoding, and Out-Of-Band (OOB) signaling that forms the
essence of high-speed serial communication.
by Progyna Khondkar - Mentor, A Siemens Business
PA-Static verification, more popularly known as PAStatic checks, are performed on designs that adopt certain power dissipation reduction techniques through the power intent or UPF. The term static originates from verification tools and methodologies that applies a set of pre-defined power aware (PA) or multi-voltage (MV) rules based on the power requirements, statically on the structure of the design. More precisely, the rule sets are applied on the physical structure, architecture, and microarchitecture of the design, in conjunction with the UPF specification but without the requirements of any external stimulus or testbenches.
PA-Static verification is primarily targeted to uncover the power aware structural issues that affects designs physically in architectural and microarchitectural aspects. The structural changes that occur in a PA design are mostly due to physical insertions of special power management and MV cells; such as power switches (PSW), isolation (ISO), level shifter (LS), enable level shifter (ELS), repeaters (RPT), and retentions flops (RFF). These power management MV cells are essential for powershutdown. The generic functionalities of these cells may be best summarized as follows.
by Ben Cohen, VHDL Cohen Publishing
Assertion-based verification has been an integral part of modern-day design verification. Concurrent SVA is a powerful assertion language that expresses the definition of properties in a concise set of notations and rules; its use is very wide spread and is definitely encouraged. However, SVA is designed for a static world; it fails to easily address the use of delays and repetitions based on the values of unit variables (module, checker, interface); it cannot reference non-static class properties or methods; care should be taken when accessing large data structures, especially large dynamic data structures; sequence_ match_item cannot directly modify unit variables; there are very strict rules on how property local variables are processed in the ORing and ANDing of sequences, and the flow through of those variables. It is important to note that those restrictions should not be viewed as a discount of SVA because SVA easily addresses most common cases of chip design requirements. In addition, the alternative presented in this article is only applicable for simulation, but definitely not for formal verification, as that is only supported by assertion languages (SVA, PSL).
This article first explains the concepts, and then by example, how a relatively simple assertion can be written without SVA with the use of SystemVerilog tasks; this provides the basis for understanding the concepts of multi-threading and exit of threads upon a condition, such as vacuity or an error in the assertion. The article then provides examples that demonstrate how some of the SVA limitations can be overcome with the use of tasks, but yet maintain the spirit (but not vendor's implementations) of SVA. Another possibility to handle these issues is to use checker libraries such as OVL, Go2UVM2; those checkers are not addressed in this article. Again, it is important to emphasize that this alternate solution with tasks should only be used when those difficult situations arise.
by Arun Chandra and Mike Bartley, T&VS
RISC-V (pronounced "risk-five") is an open, free ISA enabling a new era of processor innovation through open standard collaboration. Born in academia and research, RISC-V ISA delivers a new level of free, extensible software and hardware freedom on
architecture, paving the way for the next 50 years of computing design and innovation.
A RISC-V microprocessor can be configured in several architectural modes depending upon the target market and applications. Further, each microprocessor implementation can have different micro-architectural parameters depending upon performance, and power considerations. Examples of such micro-architectural parameters are cache sizes, the use of branch prediction, result forwarding, and pre-fetch to name a few.
This article outlines a hierarchical and configurable verification strategy for RISC-V based IP and SoCs. A three-level (unit, core and SoC) hierarchy is proposed for testbenches. Each level of the hierarchical testbench is configurable for both architectural and micro-architectural parameters. At the heart of the verification strategy is an ISG (Instruction Stream Generator) and a UVM testbench. The ISG can be configured according to the RISC-V architecture and then constrained to verify micro-architectural features. The generation of the specific configurable UVM testbench is automated based on a configuration file. The checkers, active testbench items like injectors, and coverage objects, are mostly portable across the various hierarchical levels, and are configurable based on the configuration file.