Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick - Mentor, A Siemens Business
We recently upgraded my son's phone. We were getting ready to upgrade anyway, but the thing that put us over the edge was that a couple of weeks ago his phone wouldn't charge. Now, we had recently replaced the battery in the phone, so the fact that it wouldn't charge was particularly concerning. We would have had to do the upgrade much sooner, but after a day of frustration, my son literally threw the phone against the wall and it started working. A visit to the tech center revealed that the charging problem was actually due to lint having collected in the charging cable connector slot, preventing the charger from connecting to the battery. The wall toss moved the lint just enough to complete the connection. The technician cleaned it out and, after upgrading my son's phone, we gave his old one — with the brand-new battery — to my daughter. Of course, the process of backup-and-restore for both phones didn't go as smoothly as the documentation would have suggested, but that's another story. Sometimes you have to try something "off the wall" when the way you've been trying to solve problems doesn't work. With that in mind, I am happy to share with you our Fall 2017 issue of Verification Horizons.
by Dan Alexandrescu, Adrian Evans and Maximilien Glorieux - IROC Technologies
Integrated circuits used in high-reliability applications must demonstrate low failure rates and high levels of fault detection coverage. Safety Integrity Level(SIL) metrics indicated by the general IEC 61508 standard and the derived Automotive Safety Integrity Level (ASIL) specified by the ISO 26262 standard specify specific failure (FIT) rates and fault coverage metrics (e.g., SPFM and LFM) that must be met. To demonstrate that an integrated circuit meets these expectations requires a combination of expert design analysis combined with fault injection (FI) simulations. During FI simulations, specific hardware faults (e.g., transients, stuck-at) are injected in specific nodes of the circuits (e.g., flip flops or logic gates).
by Marcela Zachariasova, Tomas Vanak and Lubos Moravec - Codasip Ltd.
Verification Intellectual Properties (VIPs) play a very important role in the verification flow of modern SoCs. They can check the correctness of communication over system buses and provide master, slave, decoder, or arbiter components if these are missing in the verification set-up. This article describes verification of RISC-V processors, focusing on the combination of automatically generated UVM verification environments by QVIP Configurator and Questa® VIP (QVIP) components. The section with step-by-step instructions will demonstrate how to add QVIP components into processor verification environments.
by Progyna Khondkar - Mentor, A Siemens Business
In post-synthesis, gate-level netlist (GL-netlist), power aware (PA) simulation, the fundamental focus is to identify PA specific cells already present in the netlist. The associated UPF with the netlist design, determines the supply network and power connectivity to these special PA cells, and aid to keep their outputs from being corrupted. Hence, the GL-netlist-based power aware simulation (PA-SIM) input requirements are mostly the same as for RTL simulation. However, the design-under-verification at this stage is the GL-netlist from synthesis, so logic gates from standard, multi-voltage (MV), and Macro cell Liberty libraries are already inserted or instantiated in the design. Hence PA-SIM at post synthesis also requires Liberty libraries as input in order to accumulate different cell-level attributes and power down functions. The Questa® PA-SIM tool utilizes the libraries to extract different attributes and functionalities which can be summarized as follows.
by Chris Kwok, Priya Viswanathan and Kurt Takara - Mentor, A Siemens Business
Today's SoC designs integrate many design IP blocks from various providers, each with their own implementation of reset. The reset architecture of a digital design can also be very complex. Designs have multiple sources of reset, such as power-on reset, hardware resets, debug resets, software resets, and watchdog timer reset. Errors in reset design can lead to metastability, glitches or other functional failures of the system. Furthermore, complex interactions can occur with the convergence of multiple resets, multiple clocks and multiple power domains. In many cases, this leads to a reset tree that is larger and more complex than the clock tree. Many of the concerns related to clock tree synthesis and load balancing now apply to the reset tree as well. Clearly, it's a challenge to ensure that all sources of reset propagate safely to the intended destinations under all conditions!
by Jin Hou - Mentor, A Siemens Business
Formal assertion-based verification uses formal technologies to analyze if a design satisfies a given set of properties. Formal verification doesn't need simulation testbenches and can start much earlier in the verification process. There are three possible results for an assertion after formal runs: "proven," "fired," and "inconclusive." Proven means that formal has done exhaustive mathematic analysis and proved the design satisfies the assertion and no legal stimulus sequence can violate the assertion. Fired means that formal has found an error trace showing the assertion violation. Inconclusive means that formal has only found bounded proof result, i.e., the assertion is true for the bounded cycle, but may be true or false for longer cycles. An inconclusive result cannot guarantee the design function associated with the assertion is correct.
by Matthew Ballance - Mentor, A Siemens Business
It's pretty typical to think about writing tests for a specific design. However, as the number of SoCs and SoC variants that a verification team is responsible for grows, creating tests that are specific to the design is becoming impractical. There has been a fair amount of innovation in this space recently. Some organizations are using design-configuration details to customize parameterized tests suites. Some have even gone as far as generating both the design and the test suite from the same description.
The emerging Accellera Portable Stimulus Standard (PSS) provides features that enable test writers to maintain a strong separation between test intent (the high-level rules bounding the test scenario to produce) and the design-specific tests that are run against a specific design. This article shows how Accellera PSS can be used to develop generic test intent for generating memory traffic in an SoC, and how that generic test intent is targeted to a specific design.
