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.

This article describes a methodology—parallel debug—as well as a supporting Jenkins framework, enabled by the availability of massive processor and disc farms which are commonplace among chip design projects. Parallel debug is an objective, disciplined methodology wherein the engineer changes one and only one aspect of a complex problem based on a hypothesis, and then tests the hypothesis. That is to say, it's the scientific method repackaged as a debug technique.

Portable Stimulus has become quite the buzz-word in the verification community in the last year or two, but like most 'new' concepts it has evolved from some already established tools and methodologies. For example, having a common stimulus model between different levels of design abstraction has been possible for many years with graph-based stimulus automation tools like Questa inFact.

Designs are becoming more complex and increasingly include a processor – and often multiple processors. Because the processor is an integral part of the design, it's important to verify the interactions between software running on the processor and the rest of the design.

Verification of complex SoC (System on Chip) requires tracking of all low-level data (i.e. regression results, functional and code coverage). Usually, verification engineers do this type of tracking manually or using some automation through scripting. Manual efforts in order to get above information while verifying complex SoC may lead us towards the delay in project execution.

The purpose of this article is to present the verification process of HDL Design House MIPI® CSI2 TX IP core using Questa Verification IPs by Siemens EDA.

Two common queries that customers pose to a design house is whether an existing or new IP can be made "low power" or if "power aware" verification can be carried out on an IP. The IEEE standard – P1801 captures what one may call the syntax and semantics to express the intent of the power architecture of a design.

The Unified Power Format (UPF) plays a central role in mitigating dynamic and static power in the battle for low-power in advanced process technology. A higher process node is definitely attractive as more functionality integration is possible in a smaller die area at a lower cost.

The Open RISC-V Instruction Set Architecture (ISA) managed by the RISC-V foundation¹ and backed by an ever increasing number of the who's who in the semiconductor and systems world, provides an alternative to legacy proprietary ISA's. It delivers a high level of flexibility to allow development of very effective application optimized processors, which are targeted to domains that require high performance, low area or low power.

There are many reasons why hardware-based emulation is a “must have” for an effective verification flow. Increased complexity, protocols, embedded software, power and verification at the system level all drive the need for the kind of performance, capacity, and “shift-left” methodology that only emulation delivers.

Clock-domain crossing (CDC) verification is a critical step in the design verification cycle. However, CDC verification is not only necessary on RTL; at 28nm nodes and below it is also essential on gate-level designs due to the possibility of the introduction of CDC errors during the synthesis phase that can lead to silicon failure. In this article we review the root cause of these challenges and introduce an automated approach to overcome these difficulties.

Formal property verification is sometimes considered a niche methodology ideal for control path applications. However, with a solid methodology base and upfront planning, the benefits of formal property verification, such as full path confidence and requirements based property definition, can also be leveraged for protocol driven datapaths.

For this issue of Verification Horizons, I have decided to do a deeper dive into our 2016 industry study and see what other non-intuitive observations could be uncovered. Specifically, I wanted to answer the following questions: (1) Does verification maturity impact silicon success (in terms of functional quality)? (2) Does the adoption of safety critical design practices improve silicon success?

In this article, we present a simple, easy step-by-step methodology to comprehend and achieve functional safety from random faults based on Questa® simulation and the fault-injection accelerator from Optima.

Portable stimulus seeks to raise the level of abstraction and enable users to automate testing of the complex scenarios that emerge in subsystem- and SoC-level verification. However, the PSS under development by the Accellera PSWG builds on the base of constraint-based, transaction-level verification, which is already well-understood and widely deployed today.

UVM is the most widely used Verification methodology for functional verification of digital hardware (described using Verilog, SystemVerilog or VHDL at appropriate abstraction level). It is based on OVM and is developed by Accellera. It consists of base libraries written in SystemVerilog which enables the end user to create testbench components faster using these base libraries.

The Questa Power Aware (PA) dynamic simulator (PA-SIM) provides a wide range of automated assertions in the form of dynamic sequence checkers that cover every possible PA dynamic verification scenario. However, design specific PA verification complexities may arise from adoption of one or a multiple of power dissipation reduction techniques, from a multitude of design features — like UPF strategies — as well as from target design implementation objectives.

Since the advent of formal techniques, the application of formal analysis has helped designers achieve more in-depth analysis and coverage of functional verification activities in general. However what has spurred the growth and popularity of such techniques has been specific and targeted applications of formal analysis.

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.

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.

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.

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.

RTCA DO-254 - 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:

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 the Questa Verification Platform for designs with UVM DVE.

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.

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.

This article focuses on Assertion-Based Verification (ABV) methodology and discusses automation techniques for capturing verification results to accelerate the verification process. Also, it showcases how requirement traceability is maintained with use of assertions to comply with the mandatory DO-254 standards.

As the complexity of electronics for airborne applications continues to rise, an increasing number of applications need to comply with the RTCA DO-254/EUROCAE ED-80 standard for certification of complex electronic hardware, which includes FPGAs and ASICs.

Built-In Self-Test (BIST) is widely used to test embedded memories. This is necessary because of the large number of embedded memories in a circuit which could be in the thousands or even tens of thousands. It is impractical to provide access to all these memories and apply a high-quality test.

Planning is key to success in any major endeavor, and the same is true for meaningful formal applications. End-to-End formal, with the goal of achieving formal sign-off, is a task that usually takes weeks if not months to complete, depending on the size and complexity of the design under test (DUT).

The growing sophistication of verification environments has increased the amount of infrastructure that verification teams must develop. For instance, UVM environments offer scalability and flexibility at the cost of upfront efforts to create the UVM infrastructure, bus-functional models, coverage models, scoreboard, and test sequences.

This article describes an automated approach to improve design coverage by utilizing genetic algorithms added to standard UVM verification environments running in Questa. To demonstrate the effectiveness of the approach, the article will utilize real-world data from the verification of a 32-bit ASIP Codasip® processor.

Writing tests, particularly unit tests, can be a tedious chore. More tedious - not to mention frustrating - is debugging testbench code as project schedules tighten and release pressure builds. With quality being a non-negotiable aspect of hardware development, verification is a pay-me-now or pay-me-later activity that cannot be avoided.

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

Long simulation run times are a bottleneck in the verification process. Coding style has a significant effect on simulation run times. Therefore, it is imperative that the code writer examine his/her code, not only by asking the question “does the code produce the desired output?” but also “is the code economical, and if not, what can be done to improve it?”

In 2002 and 2004, Collett International Research, Inc. conducted its well-known ASIC/IC functional verification studies, which provided invaluable insight into the state of the electronic industry and its trends in design and verification at that point in time. However, after the 2004 study, no additional Collett studies were conducted, which left a void in identifying industry trends.

In this article, we present the UPF Successive Refinement methodology in detail. We explain how power management constraints can be specified for IP blocks to ensure correct usage in a power-managed system. We explain how a system’s power management architecture can be specified in a technology-independent manner and verified abstractly, before implementation. We also explain how implementation information can be added later.

This article describes a specific Power Management scheme used in a USB 3.0 Device IP controller. It also describes how Questa Power Aware helped IP designers realize reliable, accurate and scalable low power architectures and comprehensive verification of these architectures. Additionally, this also shares the experience in using the UPF to define various power domains, isolation strategies and methods to control power states from the testbench.

About 30 years ago, when computers revolutionized the semiconductor design process, a new verification technology appeared on the horizon under the name of hardware emulation. It was implemented in a big-box and billed as being able to verify and debug chip designs.

Project RAPID is a hardware-software co-design initiative in Oracle Labs that uses a heterogeneous hardware architecture combined with architecture-conscious software to improve the energy efficiency of database-processing systems.

In any verification environment it takes a significant amount of work to keep all the tests running and to ensure that each test continues to be effective. To make this job easier, tests need to be kept as short as possible and should be written at the highest level of abstraction possible for the feature being tested.

The fundamental goal of a verification engineer is to ensure that the Device Under Test (DUT) behaves correctly in its verification environment. As chip designs grow larger and more complex with thousands of possible states and transitions, a comprehensive verification environment must be created that minimizes development effort.

Here we present an architecture for verifying proper operation and performance of a complex AXI bus fabric in a dual-core ARM® processor system using a combination of SystemVerilog and C software-driven test techniques.

The on-chip bus interconnect has become a critical subsystem of a System On a Chip (SoC). Its function is to route data between different parts of the system at a rate that allows the system to meet its performance goals.

This track introduces a set of steps for advancing an organization’s assertion-based-verification (ABV) skills, infrastructure, and metrics.

Most things in life are not evenly distributed. Consider for example, the sun and the rain. The city of Portland, Oregon gets much more than its fair share of rainy days per year at 164 on average, while in Yuma, Arizona, 90% of all daylight hours are sunny¹. Or, how about life as an adolescent?

Today, very high expectations are placed on electronic systems in terms of functional safety and reliability. Users expect their planes, automobiles, and pacemakers to work perfectly, and keep on working for years. A reboot of a smartphone is annoying, but rebooting the airplane or car electronics while underway could be catastrophic, and a glitch in an implanted medical device could be life threatening.

Monitors, scoreboards, and verification logic are typically implemented using FSMs, logic, and tasks. With UVM, this logic is hosted in classes. This article demonstrates another option of implementing some monitors and scoreboards using SVA assertions hosted in SV interfaces.

A key challenge today is choosing the right staff for achieving excellent verification results. Indeed, the defining moment for most projects is when the staff is selected, since the right combination of skills and personality can lead to outstanding technical outcomes (while the wrong combination can lead to disaster). Verification engineers differ significantly from other engineers in terms of skill sets required for success.

With the SoCs now supporting Multi-Core processors, complex ASICs and combinations that include systems on a board, SoC implementations now become an ever-growing challenge for software development. Software development has to be supported not only by the inclusion of an RTOS, but, many SoC providers now have to leverage upon the Bare-Metal concept to achieve the necessary demands of today's SoCs.

Until recently, the semiconductor industry religiously followed Moore's Law by doubling the number of transistors on a given die approximately every two years. This predictable growth allowed ecosystem partners to plan and deal with rising demands on tools, flows and methodologies. Then came the mobile revolution, which opened up new markets and further shifted the industry's focus to consumers.

In this article, Silicon IP and platform enabled solution provider Mobiveil shares its story of verifying high speed bus protocol standards like PCI Express and Serial RapidIO, including what considerations are required when verifying high speed designs.

Unknown signal values in simulation are represented as X-state logic levels, while the same X-states are interpreted as don't care values by synthesis. This can result in the hazardous situation where silicon behaves differently than what was observed in simulation. Although the general awareness of X-state issues among designers is good, gotchas remain a risk that traditional verification flows are not well equipped to guard against.

This article describes an UVM approach reducing testbench implementation effort, guaranteeing an early success and streamlining the processing of the test results. Depending on the number of functional interfaces and the design complexity up to 6 weeks of implementation effort or even more can be saved. A runnable UVM testbench will be handed over to the verification team at the very beginning of the project.

The increase of SoC complexity with more cores, IPs and other subsystems has led SoC architects to demand more from the main interconnect or network-on-chip (NoC), which is thus becoming a key component of the system.

This article shows a way to write BFMs in such a way that they can be configured like any other UVM component using uvm_config_db. This allows a uniform configuration approach and eases reuse. All code examples use UVM, but work equally with the set_config_*() functions in OVM.

The reader of this article should be interested in predicting or monitoring the behavior of his hardware. This article will review phase-level monitoring, transaction-level monitoring, general monitoring, in-order and out-of-order transaction-level monitors, A protocol specific AXI monitor written at the transaction-level of abstraction will be demonstrated. Under certain AXI usages, problems arise.

The intent of this article is to educate customers and guide them to understand what makes a design multicore friendly. This can help customers write designs and testbenches to be more suited for parallel simulations. Cases of success and failures of QuestaSim MC2 deployments and the lessons learned from them form the basis of our analysis and substantiate our suggestions in this article.

This article will explain how we applied formal analysis at the block level, extended this to full chip and describe how we significantly reduced verification time at both the block and chip level. Just like a block and tackle provides a mechanical advantage, the formal connectivity flow provides a verification advantage

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.

This article presents an interesting OVM to UVM migration story where we successfully translated a whole family of verification components from OVM 2.1.2 to UVM, assessed the impact, and then reworked the original OVM code, which was still live in a series of ongoing derivative projects, to make the ongoing translations totally automatic and part of the project release mechanism.