Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick, Editor and Verification Technologist, Mentor Graphics Corporation
Hello, and welcome to our Autumn, 2013 edition of Verification Horizons. I love autumn here in New England. The air is crisp and clean, the trees are turning beautiful colors, and it's time for David and me to begin another year of camping and other fun activities with the Boy Scouts. David is an Eagle Scout and our troop's Senior Patrol Leader, which means that he's in charge of running troop meetings and campouts. I'm the Scoutmaster, so it's my job to support him and the other boys, make sure they're adequately trained and keep them safe. What that really means is that David and I have to work together to make sure that the troop functions well as a unit and that everyone has fun. Those of you with teenage sons may recognize the potential pitfalls of such an arrangement, but so far we've done pretty well, if I do say so myself. You'll see these ideas of teamwork, planning and safety in our articles for this issue.
by Mark Olen, Mentor Graphics
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.
Specifically, we describe deployment of an advanced graph-based solution that provides the capability for checking full protocol compliance, an engine for continuous traffic generation, precise control and configurability for shaping the form and type of traffic needed to test the fabric. These characteristics were easier to construct, easier to analyze and review, and were more efficient in terms of achieving coverage using a graph-based approach than constrained-random or directed OVM sequences. For us, this architecture yielded successful completion of the verification process ahead of schedule.
by Mark Peryer, Mentor Graphics
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. The scale and complexity of the interconnect varies from a single switching block, routing transactions between bus masters and bus slaves, to a hierarchy of switches organized to maximize through-put. Verifying that the interconnect works correctly requires that the various bus ports in the system adhere to the protocol specification; that the system address map has been implemented correctly; and that the overall interconnect fabric delivers on its performance goals.
The advent of heterogeneous, multi-processor systems with multiple caches sharing the same data has added significantly to the complexity of interconnect design and has prompted the development of cache coherent protocols such as AMBA® 4 ACETM and AMBA 5 CHITM. Questa SLI supports interconnect verification with a range of capabilities targeting interconnect verification for both simulation and emulation. These capabilities include testbench and instrumentation generation based on Questa VIP; stimulus targeting interconnect and cache coherency verification; and visualization and analysis techniques aimed at giving insight into system level behavior.
by Nikhil Jain, Mentor Graphics
This article describes how Mentor's verification IP (VIP) for various double-data rate (DDR) memory standards can act as a bus monitor and help yield fast, flexible verification and easy debugging. We discuss how to boost productivity using the inbuilt coverage collector and checking assertions by passively monitoring data on the bus. Mentor provides verification IP that spans multiple engines; simulation, formal and acceleration (emulation) allowing effective test re-use from simulation through to acceleration, but the article focuses on simulation using Questa Verification IP.
Verifying and debugging DDR SDRAM memory designs is challenging because of the speed and complex timing of the signals that need to be acquired and debugged. We can reduce this complexity using the DDRx Questa VIP (QVIP) as a bus monitor. In general, the bus monitor's task is to observe, so it should be configured to be passive and not inject errors. A monitor must have protocol knowledge in order to detect recognizable patterns in signal activity. QVIP has all these features and thus can be a boon to any verification team.
by Lanfranco Salinari, Alberto Allara, and Alessandro Daolio, STMicroelectronics
The fact is there's little that's simple about designing and verifying SoCs. One reason stems from the choice and flexibility — all benefits have a downside — that come with assembling the chips. In the case of ARM, for example, companies can either buy off-the-shelf processor designs made by the British company or build their own processors that run on the ARM instruction set. Then comes the task of linking these processors to other necessary components, including memory, which also can be purchased and tweaked or built from scratch. Eventually the paradox of choice kicks in — more options about the way to solve a given problem eventually can lead to engineering anxiety and almost always slows things down. The second reason has to do with Moore's Law, which continues to plod ahead, seemingly oblivious to regular reports of its impending demise. According to the 2012 Wilson Research Group Functional Verification Study sponsored by Mentor Graphics, about a third of new chip designs target a feature size of 28 nm or less and contain more than 20 million gates, and 17% of all new designs are greater than 60 million gates. About 78% of all new designs have one or more embedded processors. These numbers should give some pause, particularly given the rule of thumb that verification complexity scales exponentially with gate count.
by Roger Sabbagh, Mentor Graphics
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? Do you remember how some of us were "blessed" with acne, buck teeth and short sightedness, while others with seemingly perfect skin could spend the money they saved on skin cream, braces and eyeglasses to buy all the trendiest designer clothes? No, things are not always meted out in equal measures.
So it is with the effort required to achieve code coverage closure. A state-of-the-art, constrained-random simulation environment will achieve a fairly high level of coverage as a by-product of verifying the functionality of the design. It is typically expected to achieve >90% coverage quite rapidly. However, getting closure on the last few percent of the coverage bins is typically where the effort starts to balloon.
by Martin Vlach, Mentor Graphics
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.
The extremely successful digital abstraction allows us to decompose the problem of ensuring that a digital circuit "works" into the separate steps of functional and physical verification. EDA tools take the design either from an algorithm, or from RTL, all the way to implementation. Functional verification of digital systems is primarily concerned with verifying that the logic design at the algorithmic and RTL level conforms to specification, and as a final check, physical verification is performed to make sure that nothing in the automation went wrong. Verifying that the logic and its circuit implementation are correct are orthogonal problems.
by Ben Cohen, Accellera Systems Initiative, VhdlCohen Publishing
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. The basic concept involves using assertion statements along with functions, called from sequence match items, to collect the desired scoreboard information, to compare expected results to collected data, and to trigger covergroups. This concept is demonstrated using a UART transmitter as the DUT. Since the purpose of this model is to demonstrate the use of assertions to emulate verification logic, the driver for this DUT originates directly from a top level module. To demonstrate the difference between an assertion-verification solution versus a monitor/scoreboard-solution in classes, a monitor class was implemented.
