Verification Horizons Articles:
by Tom Fitzpatrick, Siemens EDA
Welcome to our exciting DAC 2022 issue of Verification Horizons.
My family was finally able to mark an important milestone a few weeks ago when we attended my son’s delayed-due-to-Covid graduation ceremony at Georgetown University. David actually graduated in 2020 magna cum laude with a Bachelor of Science degree in Physics and a minor in Mandarin, and we really appreciated the university giving us the opportunity to recognize this accomplishment formally by hosting the in-person ceremony when they were able. We were impressed at how many of the 2020 graduates came back to celebrate with their former classmates.
by Harry Foster, Siemens EDA
I recently stumbled across an article I wrote for Verification Horizons 12 years ago, titled: Time to Adopt Formal Property Checking.1 What fascinated me about it was how well the content withstood the test of time. 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 2010.
by Rich Edelman, Siemens EDA
Welcome to part 2 of our overview of the Visualizer Debug Environment, the user interface to debug, analyze and verify all our Siemens functional verification tools.
As we saw in part 1, Visualizer is first and foremost a waveform debugger, with a host of other powerful debug capabilities also provided and supporting Verilog, SystemVerilog, VHDL, System C and C/C++. In this part of the article, we’ll look at driver tracing, X tracing, schematics, glitch debug, low power debug and coverage analysis and coverage debug – all It supports debugging simulation with Questasim, emulation with Veloce and prototyping with VPS.
by Sumit Vishwakarma, Siemens EDA
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. First, machines today are consuming more and more real-world analog information, such as light, touch, sound, vibration, pressure, or temperature, and bringing it into the digital world for processing. The second reason for this growing mixed-signal trend is technology scaling. The improved PPA (Power Performance Area) efficiency realized by digital circuits due to CMOS scaling has not translated to similar performance improvements for analog circuits. Integrated circuits that were primarily analog are now transitioning into an emerging category of “digitally-assisted analog” to realize the benefits of scaling.
by Himani Kaushik, Siemens EDA
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. One such component is created by the division of non-volatile memory (NVM), commonly known as namespaces, for the NVMe specification.
by Yrjö Keränen, Siemens EDA
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. Typical uses include driving RU transmission with 3GPP Test Models and analyzing captured reception containing 3GPP Fixed Reference Channel (FRC) transmission.
by Pradeep Gupta and Saurabh Khaitan, Siemens EDA
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. OTN provides transport, aggregation, routing, supervision, and survivability of client signals processed in the digital domain and carried across the optical domain. It addresses the data explosion by mapping non-OTU signals into OTN signals and then multiplexing multiple OTN signals (referred to as Constant Bit Rate) onto a single fiber. To ensure data correctness, it provides Forward Error Correction (FEC) codes like Reed Solomon RS (255,239) for speed up to 100G and RS(544,514) for beyond 100G speed.
by Ben Cohen, SystemVerilog Assertions Expert
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.
In Part 2 of this article, I will address the usage of these four relationship operators: throughout, until, intersect, implies.
by Eileen Hickey, Doulos Inc.
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!
Often, an engineer wants to write testbench code by looking at online examples. However, these examples are usually written more to indicate what you could do, rather than what you should do, in the interests of CPU cycle usage. Now, if you start at the unit test level, which is excellent because you get to wiggle ALL the inputs (appropriately) and thoroughly test the unit design behavior, it also gives you excellent monitors and scoreboards that help, in the larger system, to isolate errors introduced within that design block.
by Mihajlo Katona, Veriest
At Veriest, as an ASIC services company, we handle many different automotive projects with varying safety level requirements. In this article, I'd like to share some of the "lessons learned" in these projects.
The verification problem we are targeting here is that state-of-the-art functional verification methodology is not directly supporting verification of random failures within ISO 26262 requirements for functional safety. We believe a verification methodology is required to distinguish functional safety verification from classical functional verification flow. For this, we need new tools and verification approaches, and stricter and well-documented verification procedures. And our particular focus is transient faults that can randomly upset the state of a system we are verifying.
by Avnita Pal, Silicon Interfaces
For many, it is an uphill battle to achieve zero tolerance for errors in a design, particularly when attempting to satisfy the requirements of a standard, such as ISO 26262 for Autonomous and Electrical Vehicles. This article illustrates a step-by-step process to achieve safety goals. Of course, Fault Simulation does require some upfront work on the code, the testbench, and the environment to achieve these goals, but the payoff of having a neatly recorded list of Alarms and their classifications will be more than worth the effort. We will use a familiar interface, like PCIe®, to effectively illustrate this process. We will focus on creating and injecting faults and fault/path lists, developing and running fault campaigns, and building the safety mechanism to ensure Safety. The reader should be able to apply the same step-by-step procedure to their own design.
