Verification Horizons

This article intends to propose a range of strategies that an RC might use to ‘generate’ addresses that fall outside the standard scope, along with a detailed examination of the subtle complexities involved. Initially, we will explore two relatively simple methods to accomplish this. Following that, we will analyze the limitations inherent in these methods.

Verification is one of the primary challenges in current times when designs are huge, and corresponding testbenches are equally large. Both the design and testbench work together to fulfill the desired expectations of the designer. Everything goes well until the simulation does not work as expected. This is where Visualizer, the debug platform, plays a crucial role in figuring out where the problem lies. Visualizer requires multiple databases to provide the debug features.

Hardware-Assisted verification (HAV) with emulation is widely regarded as crucial for successfully designing, verifying, and deploying large ASICs and even FPGAs. An emulator is a major capital investment, and customers are highly motivated to get the maximum benefit from their expenditure.

Nowadays, the formal verification is getting more popular compared to the conventional simulation-based verification. The main idea behind the formal verification is to mathematically prove or disprove the correctness of a design with respect to the specification or requirement and ensure that the design behaves as intended under all possible scenarios. To achieve this, the formal verification tools are using Satisfiability Modulo Theories (SMT) solver engines.

This article introduces a revolutionary 64-bit native Vedic multiplier design, inspired by the Urdhva Tiryagbhyam sutra-based algorithm by Scientist Bharati Krishna Tirtha. The architecture offers superior power, timing, and area optimization, showcasing its potential for Processors, multi-cores, and DSPs computation needs. The differentiator between the current implementation and to past is the vastly enhanced native implementation of the algorithm.

This is all made up. Except the true parts. It’s a murder mystery. Someone “murdered” my config setting – but I’m getting ahead of the story.

We’re verification engineers, and our testbench is running just fine, doing the things it does, but the system is running a bit slower than our System Architects predicted.

In this article, we will discuss the Display Data Bus of ARINC-708. The bus plays a critical role in terms of the pilot’s point of view. It requires a bi-phase Manchester encoding and decoding. For both Manchester coding and the bus protocol, some examples of possible error types are considered.

This article outlines a systematic approach to attain safety objectives and create a conducive environment for achieving them. It includes a comprehensive inventory of alarms, faults, and their corresponding categories, all presented in a step-by-step format.

Big data is a term that has been around for many years. The list of applications for big data is endless, but the process stays the same: capture, process, and analyze. With new, enabling verification solutions, big data technologies can improve your verification process efficiency and predict your next chip sign-off.

As the world of technology continues to evolve, the way we design and verify circuits is also evolving. The next-generation automotive, imaging, IoT, 5G, computing, and storage markets are driving the strong demand for increasing mixed-signal content in modern System-on-Chips (SoCs). Mixed-signal designs are a combination of tightly interwoven analog and digital circuitry. There are two main reasons for increased mixed-signal contents in today's SoC.

PCI Express® (PCIe) announced its fourth generation (PCIe 4.0 standard) in year 2017.With PCIe Gen 3 the speed of operation was 8 GT/s (giga transfers per second) and error rate is manageable (10-12) but with doubling the frequency with each successive generations performance degradation become more pronounced due to variety of reasons like losses in the channels due to different components, reflections in the channel, jitter and cross talk between lanes in a multi-lane system.

The open standard ISA of RISC-V is at the forefront of a new wave of design innovation. The flexibility to configure and optimize a processor for the unique target application requirements has a lot of appeal in emerging and established markets alike. RISC-V can address the full range of compute requirements such as an entry-level microcontroller, a support processor, right up to the state-of-the-art processor arrays with vector extensions for advanced AI applications and HPC.

The openness of RISC-V allows customizing and extending the architecture and microarchitecture of a RISC-V based core to meet specific requirements. This appetite for more design freedom is also shifting the verification responsibility to a growing community of developers. Processor verification, however, is never easy. The very novelty and flexibility of the new specification results in new functionality that inadvertently creates specification and design bugs.

An advantage of using formal verification is how quickly a formal environment can be created with a few simple properties that immediately start finding design issues. However, not all design behaviors are easily modeled using SystemVerilog's property syntax, resulting in complex or numerous properties, or behaviors that require more than just SVA. Helper code can significantly reduce the complexity of properties as well as be used to constrain formal analysis.

This article aims to resolve metastability issues for multi-clock designs by noting the clock domains and the synchronization required for crossing the clock domains. The example SoC has an 8-bit simple Microcontroller and a Memory Module with a clock differently aligned (multi-clock) to the I2C Master and Slave. Leading to issues regarding metastability that needed to be resolved using synchronizers – currently two flip-flops using a closed-loop solution for sending and receiving clock domains.

A verification crisis is upon us that will not be solved solely through improvements in verification methodologies and techniques. The solution requires a holistic and philosophical change in the way we approach design with a foundation based on bug prevention. Our proposed first step in implementing this change tightly integrates static analysis into the design process, resulting in a decrease in bug density, which has a positive impact on downstream processes and consequently reduces cost.

In PCIe® 6.0, the data rate has doubled from 32 GT/s to 64 GT/s. This technology is a cost-effective and scalable interconnect solution that will continue to impact data-intensive markets like data centers, artificial intelligence/machine learning, HPC accelerators, and data center applications like high-end SSDs, automotive, IoT, and military/aerospace, while also maintaining backward compatibility with all previous generations of PCIe.

In today’s modern era, there has been an increase in the relentless push for higher-speed data transfers along with the security of the data to be transferred. The need for protecting the confidentiality of data is increasing day by day. The need to process higher data bandwidth is catered with the increased speed of PCIe®.

Increasing efficiency while debugging involves having access to the right tools, permissions, and the ability to use the debug tool to its fullest. We know how engineers spend their time debugging rather than verifying. Provide them with all the features of a debugging tool, and they would not have exited the tool while enjoying debugging.

Fault simulation replicates the typical sources of failures and analyzes them using the leading EDA tool. Testing is structured using fault simulator techniques to gain insight into fault effects and ensure defect coverage and quality testing are achieved. This article is based on standard fault Simulation and standard fault simulation techniques used in industry and applies intelligence and learning algorithms to reduce simulation cycles.

Immediate assertions are typically used to verify that expressions are within their required bounds, such as no overreach of the value of a counter or an illegal condition such a write without an enable. The action block is typically used for debug to display more information as to the cause of the error. However, immediate assertions can also be used to modify testbench variables for use in monitors or in other assertions, or to change the course of a testbench flow.

Back in 2010, I decided that instead of documenting a specific instance of applying formal property checking on a particular design, I would step back and look at the formal property checking process holistically. The goal was to define a set of repeatable steps that could be applied to any design. Fast forward to today, where I update the original by keeping the content that is still relevant and augmenting it with the new philosophies, methodologies, and technologies that have evolved since.

A mixed-signal design is a combination of tightly interlaced analog and digital circuitry. Next-generation automotive, imaging, IoT, 5G, computing, and storage markets are driving the strong demand for increasing mixed-signal content in modern systems on chips (SoCs). There are two critical reasons for this trend.

Since the advent of digitalization, there has been an exponential growth in the volume of data. With this boost in the amount of data, hard disk drives (HDDs) could not sustain the data transfer rates, leading to bottlenecks in data access. Solid state drives (SSDs) have come to the forefront as a promising solution to our modern-day storage demands. SSDs are constantly evolving with upgrades of their critical components to provide high access speeds.

Booming worldwide development activities for 5G NR create an increasing need for reference data and signal analysis. Recently launched Veloce X-STEP IQ Toolset (IQT) provides 3GPP compliant test data for radio unit (RU) testing needs. IQT workflow integrates with Siemens EDA tools such as Questa, Veloce and X-STEP. Being a standalone software solution, it is a cost-efficient solution to be installed in multiple workstations.

In today's connected world, bandwidth requirements have shot up drastically due to the exponential growth in data communication. Optical Transfer Networks (OTN) today are the backbone of the tremendous amount of worldwide internet traffic. The ITU-T standards committee developed the OTN standard to address this data explosion with reliable infrastructure and low transmission costs in the optical world.

During my years of contributions to the Verification Academy SystemVerilog Forum, I have seen many trends in real users’ difficulties in the application of assertions, and misunderstandings of how SVA works. In Part 1 of this article, I addressed the difficulties in expressing requirements for assertions, and clarified some critical SVA concepts concerning terminology, threads, and vacuity.

As a Doulos ‘techie’, I train over 100 engineers in SystemVerilog and UVM each year. I do believe quite soundly, that the effort of simulation verification is an art, supported by the language. So, regardless of the language, I have a ready list of useful testbench coding strategies to achieve faster regression CPU cycle execution. This means more regression tests executed in the same amount of ‘wall-clock’ time!

In a semiconductor world, functional safety is all about data storage and data movement through the system. Electrical or magnetic interference inside hardware systems can cause a single bit to flip to the opposite state spontaneously. And this is a typical case for random failure, which we desperately need to analyze and see its effects on the functional behavior of the system we are verifying.

This article illustrates the implementation of Safety Mechanisms on an unsafe PCIe® sub-module and demonstrates the use of Siemens EDA Austemper tools to generate Alarms for fault list detection and ensure Safety using a Duplication Mechanism.

In this era of digitalization, we can manage most of our personal stuff online, such as handling bank transactions, ordering clothes, and booking cab rides. The COVID-19 pandemic has pushed us even closer to digitalization. We are now ordering groceries online and entertaining ourselves through the plethora of content available on various streaming platforms. Inevitably, there has been significant growth in the amount of data available online and the number of users consuming it.

Engineers can use Model-Based Design for requirements analysis, algorithm design, automatic HDL code generation, and verification to produce airborne electronic hardware that adheres to the DO-254 standard. The proposed Model-Based Design approach for DO-254 combines tools from MathWorks® and Siemens EDA for both design and verification. This workflow supports development phases from concept through implementation, streamlining development, and reducing costs.

Tools used in the design and verification of electronics have played a massive role in the dramatic evolution of these devices over the past few decades. After all, there is a limit to the amount of work and detail that even a good aerospace engineer can handle, but add the use of tools, and the sky (pun intended) is the limit.

In my years of contributions to the Verification Academy SystemVerilog Forum, I have seen trends in real users’ difficulties in the application of assertions, the expression of the requirements, the angle of attacks for verification, the misunderstandings of how SVA works, and the confusion as to which SVA option to use.

Preface: in May 2021 Siemens EDA acquired OneSpin Solutions, combining Siemens' Questa Formal products and expertise (with roots and team members from 0-In) with OneSpin’s “apps first” approach to key growth markets including Trust&Security, Safety, RISC-V, and FPGAs. The combination adds to a cohesive Siemens EDA verification solution spanning simulation, formal, emulation, and prototyping.

In October of 2020, the Air Force challenged Aerospace and Defense industry to adopt the suggestions presented in the 2018 Digital Engineering Strategy. The document, named "There is No Spoon: The New Digital Acquisition Reality”, warns that aircraft design and deployment must embrace “the digital trinity” of Digital Engineering and Management, Agile Software Development, and Open Architecture.

Developers of ICs, systems, and even vehicles are seeing some pretty significant shifts in the automotive industry. Recent estimates forecast that 50% of a vehicle’s Bill of Materials (BOM) will be electronics and electronic systems by the year 2030. Smart mobility is the root cause as the market demands features such as lane keep, adaptive cruise control, and emergency brake assist to name a few.

The adoption of tools into safety-critical workflows is often challenging as these new technologies must demonstrate sufficient safeness to use before being deployed in production environments. The demand for High-Level Synthesis capabilities within DO-254 projects is growing and this paper describes the requirements and considerations to successfully use High-Level Synthesis within a DO-254 workflow.

A quick glance in today’s design verification toolbox reveals a variety of point tools supporting the latest system-on-chip (SoC) design development. When combined and reinforced by effective verification methodologies, these tools trace even the most hard-to-find bug, whether in software or in hardware. The focus on tools and delivering a tightly woven integration between complementary tools is a strategic focus at Siemens EDA.

Though the term “shift-left” originated in the software industry, its importance is often cited in the hardware (semiconductor) industry where the end-product (chip) costs are skyrocketing. The increase in cost is driven by the global chip shortage, especially in the automotive industry.

Questa Visualizer Debug is our high performance, scalable, context-aware debugger supporting the complete logic verification flow including simulation, emulation, prototyping, testbench, low-power, and assertion analysis. Intuitive and easy to use, Visualizer improves debug productivity of today's complex SoCs and FPGAs.

The latest technologies and applications often demand more speed and performance. With the advancement in technologies such as multi-core CPUs and GPUs, the need for faster data processing is becoming a bottleneck for system performance. Applications such as Machine Learning and Data Centers rely upon high performance and lower latency. These applications need a memory that can offer high speed, better performance, high density, lower latency, and data integrity.

Rapid simulation turn-around time is critical for high-functioning SoC teams because it enables a tight feedback cycle that teams use to constantly validate progress. Whether the result is a failed compile, passing simulation or anything in between, the sooner you get that result, the sooner you get to the next step and closer you get to your ultimate objective: passing silicon.

All of us are involved with standards every day whether we realize it or not. From the day we are born, we interact with standards. In the US, a baby receives a standardized health assessment score called Apgar after 1 minute. You are weighed and measured to standards. You wear clothes sized to standards. Eventually, you learn to read and write according to some culturally accepted standards.

Version 1.0 of the UVM class library was released by Accellera at the end of February 2011, the result of a unique collaborative effort between fierce competitors (Siemens EDA, formerly Mentor Graphics, Cadence, and Synopsys) and a small number of activist user companies. The objective was to provide an industry standard SystemVerilog based verification methodology.

The massive growth in the production and consumption of data, particularly unstructured data, like images, digitized speech, and video, results in an enormous increase in accelerators' usage. The growing trend towards heterogeneous computing in the data center means that, increasingly, different processors and co-processors must work together efficiently, while sharing memory and utilizing caches for data sharing.

If you are a hardware design or verification engineer, you probably have a good idea of what verification entails. However, add compliance to RTCA/DO-254 as a requirement, and suddenly the definition of “verification” may not be so clear. First, the term “verification” must be understood alongside the synergistic term “validation.” Next, in a DO-254 context, verification spans a wider scope than it does traditionally, so understanding this is crucial.

Coverage closure is a key step in any IP design verification project. Code coverage is a much-needed metric in most modern-day IP designs. It helps teams to ensure that all RTL code written is indeed exercised and verified prior to tape-out. Without such a guarantee, a semiconductor design house may well be risking millions of dollars in a potential bug-escape to silicon. As the process of code coverage is well automated, it is widely used in the industry.

With more emphasis within the electronics industry on high-performance and shorter time to market, the need for high-confidence and high-quality end-to-end verification is becoming more and more important. This is especially true on the heavily optimized arithmetic datapath blocks most used in modern compute and neural network applications. Missed bugs can delay projects and be costly to reputations, and, at the very least, be likely to sap performance.

In this article, we discuss why formal verification adoption has been limited in industry, and how abstraction-based methodology in formal verification can help DV engineers become successful in adopting formal property checking more widely. Abstraction is the key to obtaining scalability and predictability. It provides an efficient bug-hunting technique and helps in establishing exhaustive proof convergence.

This article focuses on providing a jump start on RISC-V development. It shows how to build a verification environment quickly involving a RISC-V core and required peripherals based on selected applications.

The open standard ISA of RISC-V allows SoC developers to also build or modify a processor core optimized to the application requirements. The SoC verification tasks are adapting to address the significant increases in complexity. This article covers the 6 key components of RISC-V processor verification: The DV Plan, RTL DUT, Testbench, Tests, Reference model, and Siemens EDA Questa SystemVerilog simulation environment.

The 2019 global semiconductor market was valued at $385.4 billion after experiencing a 15% decline due to a 32% drop in the memory IC market, which is expected to recover in 2021^[1]. The FPGA portion of the semiconductor market is valued at about $5 billion^[2]. The FPGA semiconductor market is expected to reach a value of $7.5 billion by 2030, growing at a compounded annual growth rate (CAGR) of 4.4% during this forecast period.

This article describes the verification process of the ARASAN MIPI® CSI-2-RX IP core using Questa Verification IPs.

As always, we must continue to reduce the time-to-market of SoCs and complex systems. An FPGA prototype implementation of these systems can be used as a basis for early software or firmware development, hardware-software co-verification and system validation, and all this can be achieved before actual silicon is available.

The efforts to apply constrained randomization to create test cases is based on the developer or verification engineer’s perception of what test vectors are required and can easily lead to hidden bugs being overlooked. Traditionally, the coverage goals would have been reached by writing more test cases with unpredictable schedules, often impacting time-to-market goals. Functional coverage defines critical states and constrained randomization tests those states in unpredictable ways.

The purpose of this article is to share a strategy on how to verify any simple or complex FSM in an organized, robust, manageable, and efficient way. To verify such FSMs thoroughly we need random scenarios that cover all the possible state transition conditions, corner and boundary conditions, and relevant functional behavior. For that, we require a strong base entity that helps to generate random scenarios to cover all FSM entry-exit conditions and erroneous scenarios easily.

As the RISC-V architecture becomes increasingly popular, it is being adopted across a diverse range of products. From the development of in-house cores with specialized instructions, to functionally safe SoCs and security processors for a variety of verticals – RISC-V adoption brings several verification challenges that are discussed in this article, along with potential approaches and solutions.

Formal verification is now pervasive in many chip design verification projects. Key to this widespread adoption is the availability of automated “apps” that makes it easy to deploy Formal in hitherto simulation-only projects. We at VerifWorks have a long history of formal deployment at many design houses and have seen the challenges engineers face while adopting the same. We have also trained hundreds of engineers to use Formal with ABV (Assertion-Based Verification) through CVC.

SVA (SystemVerilog Assertions) is a powerful short-handed assertion language with many constructs; it is built as an integral part of SystemVerilog but with a specific syntax and sets of rules. Unlike a scoreboard that tends to focus on a model implementation that mimics the DUT, SVA addresses the requirements; that brings out a better understanding of the requirements, along with its weaknesses for lack of definitions.

This article focuses mostly on the vertical reuse of the test intent from IP-block to Sub-System and study of reusability from Sub-system to SoC level. The example taken to demonstrate vertical reusability is a single master and slave SPI Core IP configuration. A UVM layered testbench is wrapped around the design to verify and validate proper functioning of SPI Core IP.

PCI Express® (PCIe®) is a dominant technology for hardware applications requiring high-speed connectivity between networking, storage, FPGA, and GPGPU boards to servers and desktop systems. It is a robust technology that has evolved over decades to keep up with advancements in throughput and speed for I/O connectivity for computing requirements.

Most people don't think of VHDL as a verification language. However, with the Open Source VHDL Verification Methodology (OSVVM) utility and verification component libraries it is. Using OSVVM we can create readable, powerful, and concise VHDL verification environments (testbenches) whose capabilities are similar to other verification languages, such as SystemVerilog and UVM.

As SoC developers adopt RISC-V and the design freedoms that an Open ISA (Instruction Set Architecture) offers, DV teams will need to address the new verification challenges of RISC-V based SoCs. The established SoC verifications tasks and methods are well proven, yet depend on the industry wide assumption of ‘known good processor IP’ based on the quality expectations associated with IP providers such as Arm or MIPS Technologies.

The metrics to measure the effectiveness of Safety Mechanisms include code coverage rate, SPFM (Single- point failure metric) and LFM (Latent failure metric). Especially in SPFM and LFM, if the specified value is not reached on the Fault Injection Simulation (using Gate Level) at the end of verification, it will cause iterations, which will cause a significant increase in time and cost compared to consumer LSIs.

Questa SLEC, the formal analysis app from Siemens EDA, was designed to automatically compare a block of code ("specification" RTL) with its functional equivalent that has been slightly modified ("implementation" RTL), helping design teams save considerable amounts of time and resources. Codasip, the leading provider of configurable RISC-V® IP, has come up with a new use of this tool: the verification team uses it to compare a fully UVM-verified HDL code.

In this era of automation, significant advantages can be gained by automatically generating verification and validation sequences from natural language text using artificial intelligence (AI) based sequence detection techniques, and then using those sequences in C/UVM code. This article talks about the current state of development in this area and gives ideas about how you can implement your own solution to achieve true specification-driven software development.

The Big Data technology has evolved to handle both volume and velocity of data, currently being generated by the chip design and verification activities. The core challenge of effective data management and hence actionable insight generation is still not available to the industry in the true sense. Connecting data islands as created by various tools in various formats across digital design and verification workflows and creating a Unified Data Lake is an important missing piece.

Modern electronic systems are complex, and economics dictate that the design, manufacturing, testing, integration and deployment of Application Specific Integrated Circuits (ASICs), System on Chips (SoCs) and Field Programmable Gate Arrays (FPGAs) span companies and countries. Security and trust in this diverse landscape of 3rd party IP providers, processor vendors, SoC integrators and fabrication facilities, is both challenging and introduces security risks.

The verification of modern-day processors is a non-trivial exercise, and RISC-V® is no exception. In this article, we present a formal verification methodology for verifying a family of RISC-V® “low-power” processors. Our methodology is both new and unique in the way we address the challenges of verification going beyond just functional verification.

There is no doubt that computers have changed our lives forever. Still, as much as computers outperform humans at complex tasks such as solving complex mathematical equations in almost zero time, they may underperform when solving what humans can do easily — image identification, for instance. Anyone in the world can identify a picture of a cat in no time at all. The most powerful PC in the world may take hours to get the same answer.

You are about to go into a planning meeting for a new project when you get a call from one of your company’s Customer Advocate Managers: a product that you worked on just started shipping in volume, and there are a growing number of field reports that the system randomly freezes-up after a few weeks in operation. While a soft reset “works,” it will run anywhere from 5 to 10 days before it has to be rebooted again.

Almost every non-trivial design contains at least one state machine, and exercising that state machine through its legal states, state transitions, and the different reasons for state transitions is key to verifying the design’s functionality. In some cases, we can exercise a state machine simply as a side-effect of performing normal operations on the design.

The PSS language was designed with the requirements of test intent reuse, and automated test creation in mind. The requirement to allow test intent to be reused across a variety of very different platforms drove the PSS language to enable a clean and clear distinction between test intent and test realization, as shown in Figure 1. In a PSS description, test intent specifies the high-level view of what behavior is to be exercised.

In this article, we will discuss the difficulties encountered with traditional CDC protocol verification methodologies and present a complete methodology to overcome the current challenges.

An integrated framework to simulate electronic systems (including digital and analog devices) with the mechanical parts of a heterogeneous automotive system is presented. The electronic system, consisting of many electronic control units (ECUs), is modeled to simulate the mechatronic system functionality. The recently developed functional mock-up interface standard approach is used to create a model for a complex cyber-physical automotive system.

In a SystemVerilog UVM² testbench, most activity is generated from writing sequences. This article will outline how to build and write basic sequences, and then extend into more advanced usage. The reader will learn about sequences that generate sequence items; sequences that cause other sequences to occur and sequences that manage sequences on other sequencers. Sequences to generate out of order transactions will be investigated. Self-checking sequences will be written.

Portable Stimulus is one of the latest hot topics in the verification space. Siemens EDA, and other vendors, have had tools in this space for some time, and Accellera just recently released the Portable Test and Stimulus Standard, a standard language that can be used to capture Portable Stimulus semantics.

Formal verification has been used successfully to verify today’s SoC designs. Traditional formal verification, which starts from time 0, is good for early design verification, but it is inefficient for hunting complex functional bugs. Based on our experience, complex bugs happen when there are multiple interactions of events happening under uncommon scenarios.

The Portable Test and Stimulus Standard (PSS) v1.0a aims to help the user describe the high-level test intent and create code for any downstream verification platform.

About four years ago I gave a couple of talks on the myths surrounding formal. Although, formal has seen more adoption since then, we have a long way to go before it is recognized as a mainstream technology used throughout design and verification. I still see some of these myths clouding the judgement of end users and their managers.

When we spend hours, days, or even weeks putting our hearts and minds into creating something, we have a tendency to emphasize its strengths and minimize its weaknesses. This is why verification engineers have a blind spot for their own verification platforms. This blind spot, or bias, often leads to overlooking those areas where bugs may lurk, only to emerge at the worst possible time when errors are most costly and take longer to fix.

An assertion is a conditional statement that indicates the incorrect behavior of a design by flagging an error and thereby catching bugs. Assertions are used for validating a hardware design at different stages of its life-cycle, such as formal verification, dynamic validation, runtime monitoring, and emulation.

In this article, we provide a simplistic approach to find inherent links between UPF commands-options through their transitive nature. We also explain how these inherent features help to foster and establish exact relationships between UPF and DUT objects in order to develop UPF for power management and implementation as well as conduct power aware verification.

As designs, especially System on Chip designs, have become more complex, the need for generated good, automated stimulus across the verification spectrum has increased. Today, the need for verification reuse and automated stimulus is clearly seen from block to subsystem to SoC-level verification.

There have been multiple studies on IC/ASIC functional verification trends published over the years.^[1][2][3][4] However, there are no published studies specifically focused on Field-Programmable Gate Array (FPGA) verification trends.

When using the Universal Verification Methodology (UVM), sequences are the primary mechanism by which stimulus is generated in the testbench. Sequences come in two flavors: simple sequences for driving a single interface, and virtual sequences that control more complex behavior. Simple sequences tend to work with a single sequence item, while virtual sequences often spawn off multiple sub-sequences to accomplish their intended task.

The effective verification of low-power designs has been a challenge for many years now. The IEEE Std 1801-2015 Unified Power Format (UPF) standard for modeling low-power objects and concepts is continuously evolving to address the low-power challenges of today’s complex designs.

Mixed-signal design is the art of taking real world analog information, such as light, touch, sound, vibration, pressure, or temperature, and bringing it into the digital world for processing.

The size and complexity of designs, and the way they are assembled, is changing the clock-domain crossing (CDC) verification landscape. It is now common for these complex SoCs to have hundreds of asynchronous clocks.

Writing and reading registers is the primary way that the behavior of most IPs is controlled and queried. As a consequence of how fundamental registers are to the correct operation of designs, register tests are a seemingly-simple but important aspect of design verification and bring-up. At IP level, the correct implementation of registers must be verified – that they are accessible from the interfaces on the IP block and that they have the correct reset levels.

The ISO 26262 automotive safety standard requires evaluation of safety goal violations due to random hardware faults to determine diagnostic coverages (DC) for calculating safety metrics. Injecting faults using simulation may be time-consuming, tedious, and may not activate the design in a way to propagate the faults for testing.

Verification planning requires identification of the key features from the design specification along with prioritization and testing of the functionality that leads to the development of a coverage model.

Part I of this article provided a consolidated approach to understand 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 structures of the design.

In this article, we will discuss some complex registers that we have seen our customers use in mission-critical applications.

It is important that certain timing endpoints on a design are safe from glitches. For example, it is necessary that an asynchronous reset never have a glitch that momentarily resets a flop. It is also necessary that multi-cycle paths are safe from glitches, i.e., it should not be the case that while a cycle accurate simulation of the RTL shows correct multi-cycle behavior, once delays are accounted for a glitch can propagate along the path resulting in a single-cycle path.

In this article, Codasip and Siemens EDA aim to describe their methodology of effective verification of RISC-V processors, based on a combination of standard techniques, such as UVM and emulation, and new concepts that focus on the specifics of the RISC-V verification, such as configuration layer, golden predictor model, and FlexMem approach.

In real hardware systems, the read completion sizes for upstream read requests (initiated towards the root complex) are characteristics of the processor in use and the maximum payload size (request payload size) limitations of endpoint as a receiver. Out of various aspects to be considered while creating a read completion, important aspects of data associated with it are byte enables (valid data to be read), value of the read request, and address at which the request is initiated.

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 high-speed 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.

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).

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 multithreading and exit of threads upon a condition, such as vacuity or an error in the assertion, providing 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.

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.

One of the most common requirements for the verification of a chip, board or system is to be able to model the behavior of memory components, and this is why memory models are one of the most prevalent types of Verification IP (VIP).

Verifying that a specific implementation of a processor is fully compliant with the specification is a difficult task. Due to the very large total stimuli space it is difficult, if not impossible, to ensure that every architectural and micro-architectural feature has been exercised. Typical approaches involve collecting large test-suites of real SW, as well as using program generators based on constrained- random generation of instruction streams, but there are drawbacks to each.

With ASIC complexity on the increase and unrelenting time-to-market pressure, many silicon design teams still face serious schedule risk from unplanned spins and long post-silicon debug cycles. However, there are opportunities on both the pre-silicon and post-silicon sides that can be systematically improved using on-chip debug solutions.

At the beginning of the third decade, circa 2005, system and chip engineers were developing evermore complex designs that mixed many interconnected blocks, embedded multicore processors, digital signal processors (DSPs) and a plethora of peripherals, supported by large memories. The combination of all of these components gave real meaning to the designation system on chip (SoC).

The present day designs use standard interfaces for the connection and management of functional blocks in System on Chips (SoCs). These interface protocols are so complex that, creating in-house VIPs could take a lot of engineer’s development time. A fully verified interface should include all the complex protocol compliance checking, generation and application of different test case scenarios, etc.

All UVM engineers employ scoreboarding for checking DUT/reference model behavior, but only few spend their time wisely by employing an existing scoreboard architecture. The main reason is that existing frameworks have inadequately served user needs and have failed to improve user effectiveness in the debug situation. This article presents a better UVM scoreboard framework, focusing on scalability, architectural separation and connectivity to foreign environments.

The standard practice of developing RTL verification and validation platforms as separate flows, forgoes large opportunities to improve productivity and quality that could be gained through the sharing of modules and methods between the two. Bringing these two flows together would save an immense amount of duplicate effort and time while reducing the introduction of errors, because less code needs to be developed and maintained.

SoC are constantly becoming more and more complex forcing design teams to eke out as much performance as possible just to stay competitive. Design teams need to get it right from the start and can't wait until it's built to find out how it truly performs. This is where System Level Modeling and SystemC/TLM shine.

Usage of the Unified Power Format (UPF) is growing rapidly as low power design and verification becomes increasingly necessary. In parallel, the UPF standard has continued to evolve. A previous article1 described and compared the initial UPF standard, defined by Accellera, and the more recent IEEE 1801-2009 UPF standard, also known as UPF 2.0. The IEEE definition of UPF is the current version of the standard, at least for now, but that is about to change.

SystemVerilog has become the most widely deployed Verification language over the last several years. Starting with the early Accellera release of 3.1a standard, the first IEEE 1800-2005 standard fueled the widespread adoption in tools and user base. Since 2005 there is no look-back to this "all encompassing" standard that tries to satisfy and do more for RTL Designers and Verification engineers alike.

This article demonstrates how SVA complements a UVM class-based environment. It also demonstrates how the UVM severity levels can be used in all SVA action blocks instead of the SystemVerilog native severity levels.

There are two approaches to the verification of design constraints: formal verification and structural analysis. Structural analysis refers to the type of analysis performed by a static timing tool where timing paths either exist or not based on constant settings and constant propagation.