Our featured article “Design and Verifi cation verifi cation of Low Power Designs,” focuses on the problem of how to verify low- HORIZONS power designs. see page 5 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS Q2 ‘07—VOL. 3, ISSUE 2

Welcome to our super-sized DAC issue of Verifi cation Horizons.

Clock Domain Crossing...page 10 By Tom Fitzpatrick, Editor Discusses formal verification of multiple clock and Verifi cation Technologist domains using our CDC solution. Read more

Complex Clock Modeling...page 13 Our new VeloceTM emulator assists in verifying In addition to all the fun I get to have at just a bit further. Just as baseball starts with designs with multiple clock domains. Read more work, I’m also the coach of my 9 year-old a set of rules, verifi cation starts (or at least Advancing the AVM...page 16 son’s baseball team. So, it is with somewhat should start) with a Verifi cation Plan that lays Introduce AVM 3.0, which upgrades the mixed emotions that I welcome DAC back to functionality and usability of the AVM. Read more its traditional early-June time slot. In other words, it’s now smack dab in the midst of Processor Driven Testbenches... “In the case of baseball season—a problem we avoided last page 20 Discussing Questa’s use of actual Verifi cation Horizons, year by having DAC in July. The good news is processor code to stimulate the design. Read more success is defi ned that I’ll miss only one game; the bad news in terms of providing Solving the Verification IP Re-Use is it’ll be the last game of the season. Oh well, Paradox...page 23 Resource scheduling at least I’ll make it back in time for the playoffs. interesting, educational capability in Questa. Read more and sometimes enter- I’m reminded of coaching a group of 9 taining articles for Bringing Visibility to Verification and 10 year-olds when I think of the process Management...page 26 How to manage of putting together a publication such as your enjoyment and all of the information now generated. Read more Verifi cation Horizons. This is not, in any way, edifi cation.” to suggest that our contributing authors behave OVL & VSI Article Updates... in any way like children. Rather, I think of it —Tom Fitzpatrick pages 30 & 31 Two brief articles to update more in terms of taking a group of individuals you on the status of some key standards-based and guiding, encouraging and possibly cajoling issues. Read more them into contributing to the success of the out the goals and the processes to follow. Verification for Companies Large team. In the case of Verifi cation Horizons, Then, just as players must hit, throw and and Small...page 32 Helping startup success is defi ned in terms of providing catch to play the game, the job of verifi cation companies entering the world of “advanced interesting, educational and sometimes engineers is to deploy their tools and meth- verification”. Read more entertaining articles for your enjoyment and odologies to do the verifi cation. Progress in baseball is measured by scoring runs. Denali VIP + Mentor AVM...page 37 edifi cation. If I do say so myself, we’ve got Progress in verifi cation is measured via Best-in-Class Functional Verification with a championship-caliber roster for this issue. functional coverage and other metrics. One of SystemVerilog. Read more With apologies to those of you unfamiliar my jobs as coach is to keep score and make with baseball, I’m going to stretch this analogy strategic decisions about where to position A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

players in the fi eld, whether to bunt or steal, in large part to contributions from AVM users. We’ve also got two brief articles to update and things of that nature. As a verifi cation This is just one of the advantages of having you on the status of some key standards- manager, you also need to keep score and made the AVM open-source, and I’m sure based issues. The fi rst discusses recent make strategic decisions about where to focus you’ll see more information along these lines advances and activity in the Accellera OVL resources and, ultimately, when to tape-out. in the weeks and months ahead. committee, where they’ve been working

From the technology perspective, the In addition to the AVM, Questa also provides towards the release of OVL v2.0. The other two keys to verifi cation are 1) the ability to two unique ways of generating interesting article is an overview of the VSIA Quality IP generate more information about whether the and useful stimulus. In “Considerations for (VSI-QIP) metric, which lets you measure and design conforms to the spec (hopefully while Effective Implementation of Processor Driven ensure the reusability of IP components. minimizing the effort of the verifi cation team), Testbenches,” we discuss Questa’s ability to In our “Partners’ Corner” section, we’re and 2) the ability to manage that information to use actual processor code to stimulate the proud to feature two articles from some of guide the verifi cation process to a successful design, giving you the ability to reuse the code our earliest AVM partners. Our friends at (and quick) conclusion. The more information in simulation and on the actual hardware. XtremeEDA share their experience of helping a that is generated, the more important Combining this stimulus source with existing startup company enter the world of “advanced verifi cation management becomes. You’ll functional coverage and other metrics gives verifi cation” by incrementally adopting pieces notice these themes repeatedly throughout this you a measure of the effectiveness of these of the AVM, laying the groundwork for more issue. “live target” tests, which were previously success in the future. And our friends at Denali

Our feature article this time around, “Design unmeasurable when the code was only run tell how they used the AVM to verify their and Verifi cation of Low Power Designs,” on the actual hardware. Similarly, when code PureSpec VIP library, and how that not only focuses on the problem of how to verify low- is found to fail on the hardware in the lab, it improves the quality of PureSpec but also power designs. These verifi cation concerns are can now be run in simulation and debugged makes it easier for you to use in your AVM discussed in the context of the Unifi ed Power much more easily, including single-stepping environment. through the processor code while also having Format (UPF) for specifying power-related So, batter up! I hope you’ll fi nd plenty of full visibility into the behavior of the RTL information. The UPF helps tools like Questa useful information in this issue, and keep in through Questa’s powerful integrated debug model the functional effects of low-power mind the important aspects of verifi cation environment. design techniques, such as clock domains and as you’re wandering through that vast maze clock gating, as well as the management of The next new strategy for stimulus that we call DAC. Remember, it’s all about distinct power islands. This theme is carried generation is discussed in the next article, gathering information about what your design through in our next two articles that discuss which describes our new Questa Algorithmic is doing and how it behaves under the broadest formal verifi cation of multiple clock domains Testbench Synthesis capability. The basics set of scenarios; being able to model those using our CDC solution and introduce our new of this technology were discussed in our scenarios as succinctly and automatically as Veloce emulator, which assists in verifying February issue. This article shows how the possible; and managing all of the information designs with multiple clock domains. Each of resource scheduling capability in Questa so you can answer the two most important these tools provides more information about allows you to take disparate block-level verifi cation questions that everyone asks: the ability of your design to handle these testbenches and automatically coordinate their “Does it work?” and “Are we done?” Then give various low-power strategies. activity at the system level to ensure maximum your mind a chance to unwind and go watch

Another form of information required by coverage with minimal engineering time. The some kids play baseball. verifi cation is the ability to model and exercise last of our new technology articles in this issue deals with the problem of how to manage all various scenarios of behavior – what we Respectfully submitted, of the information you’re now able to generate, typically call “stimulus generation.” As one Tom Fitzpatrick as outlined in the previous articles. Questa of the authors of the Advanced Verifi cation Verifi cation Technologist Methodology (AVM), I’m very pleased to 6.3 builds on our Unifi ed Coverage Database introduce AVM 3.0, which upgrades the (UCDB) to provide the ability to correlate all of functionality and usability of the AVM, thanks your coverage and results data back to your original verifi cation plan.

2 www.mentor.com Table of Contents

Page 5...Design and Verification of Low Power Designs Verifi cation Horizons is a publication BY MINH CHAU, TEXAS INSTRUMENTS AND STEPHEN BAILEY, MENTOR GRAPHICS of Mentor Graphics Corporation, all rights reserved.

Page 10...Clock Domain Crossing Verification Made Easy Editor: Tom Fitzpatrick BY RINDERT SCHUTTEN, 0-IN VERIFICATION PRODUCT MARKETING MANAGER, MENTOR GRAPHICS CORPORATION Program Manager: Rebecca Granquist Page 13...Mentor Graphics addresses complex clock modeling Wilsonville Worldwide Headquarters issues with new VeloceTM emulation technology. BY VIJAY CHOBISA, TECHNICAL MARKETING MANAGER, MENTOR GRAPHICS CORPORATION 8005 SW Boeckman Rd. Page 16...Advancing the AVM: A Guide to what’s new in AVM 3.0 Wilsonville, OR 97070-7777 BY TOM FITZPATRICK, DAVE RICH, MARK GLASSER, AND ADAM ROSE Phone: 503-685-7000 VERIFICATION TECHNOLOGISTS, MENTOR GRAPHICS CORPORATION To subscribe visit: Page 20...Considerations for Effective Implementation http://www.mentor.com/products/fv/ verifi cation_news.cfm of Processor Driven Testbenches BY JIM KENNEY, PRODUCT MANAGER, MENTOR GRAPHICS CORPORATION Page 23...Solving the Verification IP Re-Use Paradox— How to Re-Use Module Level Testbenches at the System Level BY MARK OLEN, PRODUCT MANAGER; SUDHIR KADKADE, LEAD ENGINEER, MENTOR GRAPHICS CORPORATION Page 26...Verification Project Management— Bringing Visibility to Verification Management BY MARK PERYER, MENTOR CONSULTING DIVISION; DARRON MAY, DVT DIVISION; ANDY WALTON, MENTOR CONSULTING, MENTOR GRAPHICS CORPORATION Page 30...Brief update on OVL BY MIKE TURPIN, ARM LTD, ACCELLERA OVL CHAIR AND KENNETH LARSEN, MENTOR GRAPHICS, ACCELLERA OVL CO-CHAIR Page 31...VSI Alliance Update—Got Verification IP? BY KENNETH LARSEN. MENTOR GRAPHICS DVT DIVISION & VSI ALLIANCE (VSIA) VERIFICATION IP WORKGROUP CHAIRMAN AND MARK BUCHANAN, LSI LOGIC CORP. Page 32...SystemVerilog—Verification for Companies Large and Small BY DR PAUL MARRIOTT, DIRECTOR OF VERIFICATION, XTREMEEDA CORPORATION, ALEX MELIKIAN, LEAD VERIFICATION ENGINEER AETHERA NETWORKS, BEN SAUVÉ, FPGA DESIGN MANAGER AETHERA NETWORKS, AND VINOD EMPRANTHIRI, PRESIDENT/CEO ARCHSILC Page 37...Denali VIP + Mentor AVM: Best-in-Class Functional Verification with SystemVerilog BY SEAN SMITH, DENALI SOFTWARE

www.mentor.com 3 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

“...as you’re wandering through that vast maze that we call DAC. Remember, it’s all about gathering information about what your design is doing and how it behaves under the broadest set of scenarios...” Tom Fitzpatrick Verifi cation Technologist Design Verifi cation and Test and Verifi cation Horizons Editor

4 www.mentor.com Design and Verification of Low Power Designs by Minh Chau, Texas Instruments and Stephen Bailey, Mentor Graphics

ABSTRACT portable form for use with design verifi cation circuit current in the receiving logic gate, and and implementation tools throughout the design reliability issues. Therefore, isolation cells are Dr. David Patterson observed, “… the old fl ow. In this article, we discuss the low power required at the boundary of the power domain paradigm has changed. It used to be that power design techniques used to manage static power to prevent fl oating nodes to propagate when was free, but transistors were expensive. Now consumption and how they are captured and the power domain is powered down. When a power is expensive and transistors are free.”1 expressed in UPF. power domain is down, all of the contents of Although mobile systems have been and its sequential logic are lost. However, for some continue to be key drivers, the need to manage applications, the contents need to be retained. power consumption and heat generation/ REQUIREMENTS FOR LOW Thus, retention sequential elements and dissipation have risen to displace clock POWER DESIGN VERIFICATION memory are introduced in the power domain. frequency (raw speed) in processor design for & IMPLEMENTATION The partition of voltage domains and power laptops, desktops and servers. Thus, power domains in a SoC is usually done by the SoC Currently, active and leakage power reduction management is the number one design driver for architects where many use cases are emulated in SoC are achieved through many well-known virtually all ASIC, SoC and custom IC design. to decide the best partitioning which yields the techniques such as multi-voltage domain, lowest power consumption. Process technology drives power to the Dynamic Voltage Frequency Scaling (DVFS), forefront of all factors constraining electronic and power gating.4 As the techniques are introduced to save design. At process nodes below 100nm, power, many tasks are also introduced in In multi-voltage domain, SoC are partitioned leakage (static) overtakes switching (dynamic) the design and validation methodologies to into separate logic regions (i.e., core logic as the primary source of energy consumption. implement and validate these techniques. Vital region, peripheral region); each can be supplied Management of dynamic power is easily information must be added to enable EDA tools with separate power supply and can run at handled within existing design and verifi cation to understand: different Operating Performance Point (OPP). fl ows through clock domains and clock gating Therefore, level shifters are required for signals • How a SoC is partitioned into voltage techniques. Although, design and verifi cation crossing voltage domains with different voltage domains, power domains and how power methods and tools have evolved to facilitate levels. With multi-voltage domains, DFVS can supplies/switches are connected and design of clock trees and the verifi cation of be applied to different logic region to adapt controlled in these domains. designs with multiple clock domains,2 clock dynamically the frequency and voltage to the • What types of power management gating can be specifi ed and verifi ed using performance required base on the application components (level shifters, isolation cells, existing HDLs and verifi cation tools. to further reduce active leakage power. retention sequential elements) should be Management of static power consumption used appropriately in each domain and how To save leakage power, if a block of logic requires the use of new design techniques to control them. is not used (in stand by mode), its power that fall outside the ability of existing HDLs can be gated using power switches. In this to capture. If HDLs cannot capture the low Information is needed in each step of the power gating technique, a region of logic can power design intent, then verifi cation tools design fl ow so that correct power management be partitioned further into blocks of logic cannot simulate or prove the low power design components can be implemented at RTL level, (power domains); each can have its power intent is correct. Accellera, at the request and inferred correctly during synthesis, and placed independently switched on (active) or switched assistance of users including Texas Instruments and routed effi ciently and accurately in physical off (power down/off). When a power domain and with technical donations and contributions design. Also, information is needed to be able is in off mode, its outputs are fl oating. Floating from multiple EDA vendors including Mentor to validate that the techniques are implemented output signals that interface with an active Graphics, developed the Unifi ed Power Format correctly in early stages of the design (RTL power domain can cause logic failure, short- (UPF)3 to capture low power design intent in a level) as well as fi nal stage of the design

www.mentor.com 5 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

(gate, GDSII levels). Currently, every EDA tool with the original RTL, and that no unintentional the immediate need of the design to use these expects similar input information about power information except power information is added. components. Thus, the power format must management techniques, but in a very specifi c Using the side fi le to add power information allow the ability for the foundry to describe the format to the tool. This non-standard input of requires paying close attention in delivering the new power management components in a way power information causes multiple problems to corresponding side fi le with IP RTL. However, that the EDA tool can understand and support the design community such as: this methodology does not touch the RTL, and as soon as they are invented. there is no need for extra equivalence checks • Diffi culty in cross-checking the validity In order to address the need for a standard between the updated and the original RTL. and consistency of input information and power format, the EDA industry has recently Most important of all, it enables the reusability implementation at later stage (gate, GDSII) introduced the Unifi ed Power Format (UPF). of the IP by allowing the design team to deliver with early stage (RTL) of the design. UPF is the result of an Accellera effort that the same IP RTL to a power managed SoC • Time consuming for designers and brought together leading EDA vendors and (including a variety of different power managed validation engineers as they must again multiple users for the purpose of defi ning SoCs using the same IP block) as well as a non- and again input same power information at a single format to be used throughout the power managed SoC. each design/validation step. RTL-GDSII fl ow. Mentor Graphics, Magma, • Tremendous support from fl ow team in Traditionally, there is no information Synopsys, Atrenta, Arch-Pro, VaST, TI and order to support different formats from about supply network at RTL level. In fact, Sun provided technical contributions based on different EDA tools. information on supply networks come very late their silicon-proven formats and technology. in the design process -- in the netlist format. Several other companies provided technical So, gate level simulation is run with power- contribution including Infi neon, ChipVision, As the demand for low power designs aware library components to emulate the Nordic Semicondutor, ARM, Intel and IBM. grows without sacrifi cing design schedule power-on/off at SoC level. It is quite diffi cult to These donations and contributions were and quality, there is an urgent need to have a debug at gate level simulation as well as have converged into a single format, UPF. single power format accepted by all tools in exhaustive application test cases applied to the fl ow at any given abstraction level to ease gate level simulation. Also, bugs found during the implementation and validation as well as this stage are very costly to fi x. Therefore, the UPF: STANDARD FOR LOW meeting the design schedule. A single power power format must specify the supply network POWER DESIGN & VERIFICATION format must also address reusability, allow to enable validation at RTL level which allows early and thorough validation, and have built-in UPF is designed to address the needs of early validation in design phase. Besides extensibility. capturing the low power design specifi cation the supply network, retention and isolation from RTL through GDSII with consistent elements also must be specifi ed in the power Typically, power information is input in two semantics for both verifi cation and format so that, at RTL validation, the correct ways: implementation of the low power and logic choice and functionality of the types of retention design specifi cation. Figure 1 demonstrates 1. Directly specifi ed in the RTL and isolation elements can be proven. how UPF combined with HDL code form the 2. Indirectly specifi ed via a side fi le. The last but not least important requirement complete design specifi cation at any level of for the power format is extensibility. The power abstraction and how the design specifi cation is There are pros and cons for each method- format must not rely on the built-in knowledge used within the tool fl ow. As shown in fi gure ology. By directly integrating the power inform- about types of power management components 1, the use of UPF makes the low power design a t i o n i n R T L , i t i s g u a r a n t e e d t h a t t h e c o r r e s p o n d - (i.e., retention elements and isolation cells) specifi cation as portable and interoperable as ing power information is packaged together in an EDA tool. As more power management existing HDL code. Figure also indicates that with the IP RTL. However, this methodology techniques are invented, more and different UPF augments or supplements the logic design requires that legacy IP RTL must be updated types of power management components specifi cation captured in HDL. to add power information. Thus, equivalence are frequently created. There is a lag time check is required every time the RTL is touched between updating an EDA tool to understand to prove that the updated RTL is equivalent the new power management components and Figure 1. UPF Specifi es Low Power

6 www.mentor.com power state table. Create_pst defi nes the name supply state (on, off and voltage value). of the table and the table’s columns – the supply The connect_supply_net command nets or ports that are the terms by which a state connects supply nets to one or more ports. is defi ned. Add_pst_state defi nes the row(s) of • Supply states. Each supply port has one the power state table. or more supply states defi ned. The port may drive only one state at any given time. A completely abstract specifi cation of the That state is propagated by the supply net system power states has limited value. A connected to the port. The power state UPF power state table defi nes the power table is defi ned in terms of these states. states in terms of the states of supply nets ensuring integration of system power design If the design is completely PG (power and with the low power design implementation. ground supply) connected, then no additional An abstract defi nition of the supply network work is required. However, the specifi cation of would be cumbersome to defi ne in HDL code. a fully PG connected design is a laborious task. However, UPF provides the ability to specify all UPF automates the connection of the supply information about the supply network to verify network to the logic elements in the design. and implement the power supply distribution and control necessary to realize the needed system power states. SPECIFYING POWER DOMAINS The supply network consists of the following A power domain is a collection of design components and their related UPF commands: (logic) elements that share a primary supply. A primary supply includes the same power and Information throughout the Design Flow • Power switches created with the create_ ground supply nets. This defi nition of a power power_switch command. domain enables the automatic connection of • Supply ports which are defi ned on the primary power and ground nets to all logic SPECIFYING SYSTEM POWER power domains (discussed next) and elements within the domain. STATES & THE SUPPLY NETWORK power switches. The create_supply_port command creates a port on a power When the system architect or chip power Power domains are specifi ed through the domain (they are defi ned for switches in architect begins designing the low power create_power_domain, add_domain_elements the create_power_switch command). aspects of an electronic system, they start by • Supply nets are created with create_ defi ning the system power states. For example, supply_net. Supply nets connect supply Figure 2. System Power States a system power state may be that the modem ports and logic ports propagating the is in a watch-dog mode waiting for an incoming call and the information management system is checking for scheduled appointments but that the rest of the system is in a sleep mode to conserve power. Such a deep sleep state must be defi ned in terms of the functionality in the system.

UPF provides the ability to defi ne a power state table that captures the system power state information. Figure 2 contains an example system power state table.

UPF provides two commands for defi ning a

www.mentor.com 7 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

and set_domain_supply_nets. The fi rst com- ADDING RETENTION, ISOLATION, the use of level shifters. A level shifter mand creates the power domain name and AND LEVEL SHIFTING translates a logic value from an input voltage may completely or partially specify the logic swing to an output voltage swing. As complex When power gating a design, as discussed elements contained in the domain. Additional designs utilize multiple voltage domains (power earlier, it is usually necessary to retain the logic elements can be added to the domain at domains operating at different voltage levels), current value of registers for later restoration on a later time. Reusable IP is supported through it is necessary to insert level shifters to ensure power-up and fast resumption of operation. It the set_domain_supply_nets command which that a logic ‘1’ in one domain is recognized as is also typically necessary to isolate the signals separates the implementation specifi cs of the a logic ‘1’ in a different domain. UPF supports connecting the powered-down domain to other supply network from the specifi cation of the set the specifi cation of level shifter strategies domains which remain on. UPF supports of logic elements that must operate at the same including the voltage tolerance threshold the specifi cation of retention and isolation voltage level or must be on or off at the same (exceeding requires a level shifter), whether “strategies.” A strategy is a general rule on time. the strategy applies to up-shift, down-shift or how to implement these low power design both and which ports the strategy applies to. For verifi cation, UPF specifi es the semantics functions. The set_retention and set_isolation Implementation tools take this information of power-off as the primary power and/or commands specify the respective strategies for and, optimizing based on the power state table primary ground being in the off state. The all registers or logic ports of a power domain or specifi cation, infer level shifters wherever they behavioral semantics of power-down mirror for a defi ned subset of the registers or ports. are required in the design. what happens in actual hardware: To allow IP providers to specify this information which, as IP providers, they need to know from • All registers are corrupted the details of how that IP is incorporated into • All signals driven by powered down logic a low power design, set_retention_control and FEATURES ENABLING PRACTICAL are corrupted set_isolation_control, allow the specifi cation of SIMULATION OF LOW POWER • All behavioral processes within the implementation specifi cs for a corresponding DESIGNS powered down domain are deactivated retention or isolation strategy. Specifi cally, There are additional key concepts and the save and restore signal(s) and their active capabilities of UPF which need to be mentioned, polarity are specifi ed in the set_retention_ even if briefl y. Equally important are the semantics for when control command as the IP integrator is obliged power is restored to a domain. On power-up: to provide and control these signals. Similarly, 1.Anything created in a UPF specifi cation (e.g., switches, supply nets, etc.) are • All combinatorial and latch (level the isolation enable signal is specifi ed in the created within a specifi c scope of the sensitive) processes are evaluated set_isolation_control command. logic design. This helps to provide an • This includes continuous assignment The set_retention and set_isolation easy mapping from the UPF to the logic statements commands specify the retention and isolation design which facilitates writing the UPF • Edge triggered processes (fl ops) are power and ground supply nets respectively. code as well as debugging and analyzing not evaluated until the next active edge These supplies are automatically connected the low power design specifi cation. • All behavioral processes are re-enabled to the retention register’s shadow register and for evaluation isolation cell respectively. The same power 2. To facilitate verifi cation, UPF defi nes down and up semantics apply to the behavioral a support package in SystemVerilog and Power domains enable the automation of processes implied by the retention and isolation VHDL. This package defi nes routines supply network connectivity. UPF recognizes capabilities relative to the on/off state of the which facilitate querying the current state two other types of supplies – retention and retention and isolation supplies as applies to of a supply net or port and setting (driving) isolation – which also have corresponding design logic elements and the primary power the state of a supply port. This allows auto-connection semantics. and ground net states. the testbench to mimic the off-chip power supplies that are connected to the chip’s Although level shifters have no functional supply pads. semantic as they are logically equivalent to a buffer, low power designs frequently require

8 www.mentor.com 3. The ability to defi ne a UPF supply net The 6.3 release of Questa provides low to HDL logic value conversion (and vice power design verifi cation capabilities with versa) is also provided when a supply net power gating and retention. Mentor Graphics is connected to a logic port in the design. supports UPF and that support will be realized This facilitates integrating the supply later this year in our verifi cation solutions network defi ned in UPF to power-aware including Questa and FormalPro. models in the design without requiring re-writing of the model to work with the UPF defi nition and representation of ENDNOTES supply net states. 1. Patterson, David, “The Future of Computer Architecture,” U.C. Berkeley’s EECS Annual CONCLUSION Research Symposium, 23 January 2006.

As power has become more expensive in elec- 2. For example, Mentor Graphic’s CDC and tronic systems, the need to specify low power CDC-fx tools which verify data integrity, design intent has increased in importance. synchronization and reconvergence across The industry responded by defi ning ways to multiple clock domains. augment the logic design with low power design information. For example, Mentor Graphics 3. Unifi ed Power Format Standard version 1.0, defi ned its own low power format, called Accellera, 22 February 2007, www.accellera. the Power Confi guration File (PCF) for use in org. verifi cation of low power designs. Questa and 4. H. Mair, et al., “A 65-nm Mobile Multimedia FormalPro support power-aware simulation and Applications Processor with an Adaptive logic equivalence checking using PCF and this Power Management Scheme to Compensate support is available immediately. for Variations”, to be published in ISSCC’07 However, users quickly discovered that specifying the same information in multiple, tool specifi c formats was ineffi cient and prone to errors in consistency. The user community raised awareness of the need for a standard low power design format. Accellera answered the industry’s call and created the Unifi ed Power Format. Mentor Graphics’s PCF was donated to the UPF technical committee. UPF is the result of converging the best practices and technology from several donations that have been proven through successful silicon. Due to its broad industry support, UPF is delivering the value that standards offer: interoperability and portability of design data.

www.mentor.com 9 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

Clock Domain Crossing Verification Made Easy by Rindert Schutten, 0-In Verifi cation Product Marketing Manager, Mentor Graphics Corporation

Advanced multi-clocking architectures bugs that will very likely slip and sophisticated power modes are the through the verifi cation process means to meet the high-performance, low- and end up in silicon. power demands of today’s high-functionality, Collett (Collett International, consumer-centric devices. The sheer com- 2005 IS/ASIC Design Closure plexity, high-volumes, and emphasis on re- study) reports that in 2005 over liability of these sub-100 nanometer, system- 15 percent of designs used 20 on-chip (SoC) designs have made verifi cation or more clock domains, which quality and productivity key concerns. To literally means thousands of address these concerns, many companies have CDC signals, creating a large begun to adopt new verifi cation technologies verifi cation challenge. Indeed, in the same Figure 2. When the input value (D) changes —such as constrained-random stimulus report, the study reports that clocking issues during the register’s setup or hold time, the generation, assertion-based verifi cation, and are the second most prevalent defect in all register may output a voltage level between 0 and coverage-driven verifi cation—to substantially chips that need a respin. 1. This effect is referred to as metastability. raise their verifi cation quality and productivity.

However, a new class of functional veri- CLOCK DOMAIN CROSSING ISSUES fi cation problems has emerged that even these consider three bits transitioning between two advanced, simulation-based technologies alone When data is passed between two clock clock domains where their values are 111 at one cannot address very well. These issues pertain domains, it can get corrupted when the clock clock cycle, and at the next transition they will to data that has to cross from one clock domain edges of the sending and receiving fl ip-fl ops are be 000. Because metastability causes each of to another; so called clock domain crossing close to each other. For example, if a receiving the receiving fl ip-fl ops to latch an unpredictable (CDC) signals (see Figure 1). If the circuitry hand- fl ip-fl op latches in the data at the same time that value, we may see 101 (or any random value ling the data transfer across clock domains is the sending fl ip-fl op is changing the value, then between 000 and 111) for a cycle before 000 is not carefully designed, it will cause intermittent the value that the receiving fl ip-fl op receives is correctly latched in. neither a 1 nor a 0 but somewhere in between. This value will settle eventually to a 1 or a 0, When these errors occur, they are extremely diffi cult to resolve. The data corruption may Figure 1. Most chips today have many clock but the logic driven by the fl ip-fl op generates occur only after hours or days of operation, domains and many signals transferring data from a random value. This effect is referred to as when the clock edges line up in exactly the one domain to the other that need to be verifi ed. metastability (see Figure 2). wrong way, potentially causing every part to If a bit crosses between fail. These issues cannot be screened with test domains and goes to more vectors on a test system. As well, it is unlikely than one receiving fl ip-fl op, or that a fi rmware fi x will resolve these issues, as if multiple bits cross between they often manifest as data corruption rather domains, then corruption than simple control issues. It can take months is even more likely, as the of engineering time to fi nd, understand, and failure described above is fi x these issues, and the problem may not be combined with another failure detected until a signifi cant number of units mode: it is possible that one have failed in a customer’s hands. Especially receiving fl ip-fl op will see a with today’s complex chips, product recalls and value change before or after design respins caused by these types of bugs another fl ip-fl op. For example, are dangerously expensive. 10 www.mentor.com SYNCHRONIZERS ARE routines assume that values ONLY THE BEGINNING instantly resolve between clock cycles. To avoid metastable signals, designers use synchronizer structures in between clock domains. A correctly designed synchronizer THE FULL CDC virtually eliminates the probability of a VERIFICATION metastable signal. However synchronizers do SOLUTION NOT (and cannot) resolve the unpredictability What is required is an of the delay. To ensure that a signal’s value is automated solution that correctly transferred between clock domains, completely verifi es that data a protocol between sender and receiver of the is transferred correctly and data is required. predictably across clock It is possible that separate sources of data, domains. Such a solution should be applicable early in the design cycle, originating from two (or more) synchronizer Figure 4. The Mentor Graphics 0-In CDC at the RTL, in order to catch CDC errors early structures, are combined in a logical operation Verifi cation solution uses both static and when they are easier and less costly to correct. deep within the receiving clock domain. Since dynamic analysis techniques. the timing of each data source can be shifted Trying to fi nd and resolve CDC errors at the gate one cycle, an incorrect value could be computed. level is simply too late in the process — enabling This failure mode is known as a reconvergence designers to address, at best, structural reconvergence is handled correctly. error (see Figure 3). synchronization errors while leaving functional Since a (digital) simulator does not model verifi cation errors due to CDC protocol and metastability, one must explicitly model Engineers have tried for several years reconvergence errors unaddressed. to address these verifi cation issues using metastability to create the conditions under simulation techniques; however, simulation Hence the fi rst step of a complete CDC which reconvergence errors could occur and alone isn’t well suited to fi nding all CDC bugs. verifi cation solution is a complete and automatic, validate that the circuit properly accounts for Even new advanced testbench methodologies register transfer level, structural analysis of the varying delays (+ or – 1 clock cycle) in the are highly unlikely to catch bugs due to missing design. Such analysis should take into account data that enters a particular clock domain. (intermittent) synchronization. Because the various confi guration and power modes and In the next couple of paragraphs we will simulation environments are designed to catch the support hierarchy. It should also identify all explain how these three verifi cation steps are functional defects, most simulation runs do not CDC signals and synchronizers. provided by the Mentor Graphics® 0 In® CDC account for indeterminate values, as simulation The second step then focuses on CDC verifi cation solution (see Figure 4). protocol verifi cation - ensuring that data is The 0-In CDC verifi cation solution uses transferred reliably between two clock domains. static analysis techniques to perform structural Figure 3. The three failure modes This typically means that one needs to verify analysis. It automatically identifi es the clock related to CDC signals. that signals are held long enough to their logic structure used in the design (i.e., clock value to ensure domains, clock gating, dividers, etc.), while that the data is taking the various confi guration modes of correctly received in the design into account. It further identifi es the receiving clock all CDC signals and determines the required domain. synchronization structure (if any) used on The third and fi nal the signals and whether this synchronization step in the CDC structure is implemented and used correctly. verifi cation process While the process is automated, the user is to verify that all has the ability to guide the tool by providing

www.mentor.com 11 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

additional information on clock groups, preferred errors will be revealed, which can be debugg- synchronization types, exceptions, and many ed using traditional verifi cation techniques. other options. If a problem is identifi ed in the structural synchronization, it can be debugged using an interactive debug environment that CONCLUSION simplifi es working with CDC signals. Without multiple clock domains, today’s Using the information extracted from the performance and power optimized designs cannot design during structural analysis, the 0-In CDC be realized. Only the Mentor Graphics 0-In CDC tool automatically generates protocol monitors solution addresses all possible failure modes for the synchronization structures. These related to clock domain crossing issues at the monitors are expressed as assertions and check RTL, enabling designers to identify and resolve whether the appropriate CDC protocol for the CDC issues early in the design process. With the synchronization structure is followed at all times. verifi cation capabilities to address all three CDC The designer now has two ways to verify that failure modes implemented in an easy-to-use, the CDC protocols are implemented correctly CDC targeted tool, designers have an easy way to — use formal verifi cation techniques to prove gain confi dence that their multi-clock designs will that the protocol assertions are never violated, function correctly the fi rst time. or simulate the design using assertions. The 0- In CDC tool automatically captures the results from both formal verifi cation (assertion proven, assertion violated, or inconclusive) and RTL simulation (assertion violated) in it’s graphical Rindert Schutten has over 20 years of software debug environment, allowing designers to easily development and EDA industry experience. He identify CDC protocol violations and debug a is currently the product marketing manager for design. Mentor’s 0-In verifi cation products. Prior to his current role at Mentor Graphics he was with Finally, the 0-In CDC solution performs Synopsys, in marketing, professional services, exhaustive static reconvergence analysis to and engineering roles. He has worked directly identify all reconvergent CDC paths that can be with leading companies on creating advanced activated in the design. False reconvergence is verifi cation solutions for their most challenging automatically rejected using formal verifi cation system-on-chip verifi cation problems. Prior to techniques. Static reconvergence analysis, Synopsys, Rindert was with Philips’ Research however, relies on manual inspection by the and Development organization, both in Europe engineering team to determine if there is a real and the United States. problem. This is a time consuming and error prone process. To automate this step, the 0-In CDC solution models the metastability effects to create the same variable delay behavior in simulation as would occur in hardware. These metastability injectors are automatically placed on all CDC paths. They model the effects of metastability on CDC signals only at the appropriate times — when metastability could occur in hardware. If the design is not tolerant of these effects, functional

12 www.mentor.com Mentor Graphics addresses complex clock modeling issues with new

VeloceTM emulation technology. By Vijay Chobisa, Technical Marketing Manager, Mentor Graphics Corporation

Not too long ago designs were smaller and algorithm that gives an accurate and high emulator is its ability to build a model that is less complex with simple clock modeling fi delity model even in the presence of multi- insensitive to state setup and hold issues. challenges. Verifi cation was straight forward clock domains. What follows are common asynchronous and clock modeling was not a big concern. But For a multi-clock domain design, Veloce clock handling and synchronization issues today, with the drastic increase in the use of decomposes the design into discrete clock designers face today, and how Veloce’s SoCs, designs have grown in complexity with domains and applies a separate and independent advanced cycle-based emulation technology numerous peripherals/external interfaces, cycle-based computation to each clock domain. addresses those situations. resulting in designs with higher numbers of Veloce is able to accurately model multi-clock asynchronous clocks. domain behavior by executing each clock ASYNCHRONOUS CLOCK Peripherals typically have their own distinct domain independently and aligning only to each HANDLING clock that is asynchronous to other clocks. A respective clock. designer doesn’t have much control over these A clock domain has a timing fi nite state It is interesting to note that the simple peripheral clocks. Because SoCs serve many machine (CtlFSM), which generates clock algorithm of a cycle-based emulator is needed different purposes, a fl exible chip can be used in domain specifi c control signals and is phase- to evaluate the entire design in response to a variety of applications having more interfaces locked to incoming clock signals for the an edge on any clock. As a result, the cycle- than a single-purpose chip. domain. This timing fi nite state machine runs based emulator slowed down substantially if on the emulator’s fastest internal clock. The Asynchronous clocks allow designers there were any distinct and/or independent initiation of processing in a clock domain, to reuse peripheral IP as well as implement clock edges. The new Veloce emulator, (i.e., what causes the fi nite state machine to power save states. However, doing this brings however, offers an independent computation start) is exclusively the clocks from the same additional verifi cation challenges to the design for each clock domain, utilizing independent domain. There is no predictable relationship and verifi cation houses. Designers can rely on computation resources, resulting in zero between the timing of fi nite state machines of best practice techniques and software tools for performance degradation. one clock domain verses another. They operate synchronous designs or designs which at the independently of one another. It is possible for Let’s consider a quick example: Veloce has a most have two asynchronous clocks. two such state machines to start with any phase model for clock domain “X” that gets launched relative to one another (phase is measured in But when the complexity increases beyond as a result of an edge of clock “X.” Similarly, fastest system clock); two can be purely in two clock domains, advanced emulation it has a distinct independent model for clock phase or have a relative phase delay. becomes essential. domain “Y” that gets launched as an edge of

clock “Y.” Veloce has a dedicated set of chips The logic state in a clock domain updates to execute the computation and also dedicated ADVANCED CYCLE-BASED at specifi c times, identifi ed by the domain- interconnect resources for the data transfer for EMULATION IS HERE specifi c CtlFSM. Clock domain execution clock domain “X.” The same applies for each is independent. Veloce is able to model Veloce, Mentor’s new advanced cycle-based independent clock domain. asynchronous phenomenon like race condi- emulator, offers a distinct independent cycle- tions, re-convergence, and glitch phenomenon based computation for different clock domains, The execution of the cycle evaluation for in continuously updating state structures like which is extremely important for maintaining each domain is independent and therefore, preset, clear, and combinatorial cycles. the fi delity to see cross domain effects. Veloce the sampling points of a state in one domain is a sophisticated extension of cycle-based are not synchronized to the data generation of another domain. Another strength of the Veloce

www.mentor.com 13 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

RACE CONDITIONS old state. For example, a three bit AND RE-CONVERGENCE vector that changes from “011” to “100” where each bit is going through Race conditions and re-convergence are an individual synchronizer at the clock used interchangeably in the industry. They both boundary. Due to some clock skews or point to the issue of signals going from one path delays, some of the bits get new clock domain to another, with the expectation values while others remain the same. that sampling of these signals corresponds to Possible resulting vectors are “111” the same transmit time point. Due to variable or “101”, which is a problem. Veloce interconnect path delays, signals may get is able to accurately model this re- sampled at different transmit time points and convergence scenario. we may get new values for some signals and old values of others. Figure 3 shows another example of a similar scenario where signal “X” is As shown in Figure 1, a race condition is a sampled at time point “t” and signal situation where two signals are generated by “Y” is sampled at time point “t+1” in fl ip-fl ops on one clock domain and received the receiving clock domain. This may by fl ip-fl ops on a second domain. If the signals lead to re-convergence errors, Veloce have distinct delays (delta-0 and delta-1) and can model this scenario. the receiving domain clock edge follows by the transmitting edge by a period of time larger As shown in Figure 4, two signals than delta-0 but smaller than delta-1, then the from Clock domain “A” go to clock receiving domain gets a new value of Data[0] domain “B.” One signal goes to data but an old value of Data[1]. Veloce accurately and the other to the enable input of fl ip- models this type of race condition. fl op. This may lead to a race condition even though you have a synchronizer Figure 2 illustrates unpredictable delays on on the data bit. Veloce models this signal paths going from one clock domain to scenario. another clock domain, which can lead to re- convergence issues. It’s certainly possible that Veloce can model cross-domain some of the bits in a vector will be registered race conditions and re-convergence GLITCH DETECTION at their new values and other remains at the because: Within a clock domain, users may want to • There is a delay in going from one clock have zero delay semantics behavior; otherwise, Figure 1: Race Condition: Path delay. domain to another (caused by the any kind of clock gating circuitry will not work. virtual wire transport of the signal) Designers are not relying on emulator to fi nd • The delay on different paths can glitches in the clocking circuitry. be different Veloce models glitch phenomenon in • Clock domains are independent continuously updating state structures like so it is possible for an edge in the preset, clear, and combinatorial cycles. receiving domain to occur at an arbitrary delay (delayed by some Figure 5 illustrates the feedback path on a of the fastest clocks) relative to the clock net creates a transient pulse that causes preceding edge in the transmission the state change of the fl ip-fl op, which Veloce delay can model.

14 www.mentor.com steady state value is “0” - but for a transient time tools. It is essential to run more test vectors/ the clear goes to “1”. scenarios and real-world traffi c to make sure the design is tested for clock synchronization, Figure 7 illustrates a scenario where the fi rst race conditions, and some conditions that may fl ip-fl op is going from “0 to 1” and second fl ip- occur very rarely. For these reasons, Veloce’s fl op is going from “1 to 0.” The output of the AND advanced cycle-based emulation technology is gate can generate a pulse. worthy of consideration.

Fortunately, both glitches depicted in Figures Further, using the capabilities of Veloce 6 & 7 are glitches that Veloce can model. over processor-based emulation has obvious advantages as well: SYNCHRONIZATION ISSUES • Veloce handles true asynchronous clock Veloce maintains the proper edge sequences designs and edge precession to increase the probability • Veloce models race conditions/re- of catching synchronization issues. The convergence scenarios combination of higher throughput of Veloce • Performance does not degrade with added and randomization techniques increases the clock domains: Veloce launches a cycle potential of hitting the scenarios that are likely program for each domain – whenever an to occur when the system is subjected to stress. edge comes for that domain Veloce’s higher performance allows exhaustive Veloce offers solid advantages over typical testing at all inter-domain paths. Veloce reliably event-based emulators, too. Some of these catches the issues of synchronization logic at include: asynchronous clock domain boundaries. • The ability to automatically handle complex clocking styles. Veloce can build a model that is insensitive to state setup – and hold FIFO OVER-RUNS issues in a semantically robust manner FIFOs are used as synchronizer for the signals • A multiplexed communication network that are crossing the clock domain boundary. which means Veloce has better capacity FIFO over-runs or under-runs occur when FIFOs utilization and enhances the possibility to are fi lled using one clock rate and extracted using build higher capacity emulators another clock rate. It is very important to verify • Faster compile times - Emulation-on-Chip that FIFOs are functioning accurately, and are technology is designed to address super- optimized so users do not consume unnecessary fast compilation times die size by over designing the FIFO. Veloce’s higher throughput allows the user to measure Veloce is the new advanced cycle-based the FIFO utilization to design an appropriate size emulator that’s quickly opening eyes and FIFO to serve the required bandwidth. Figure 8 doors to a myriad of new verifi cation/emulation illustrates a FIFO that operates with two clock practices and techniques. I hope Veloce fi nds its domains. way to you in the very near future.

Shown in Figure 6 is a scenario where logic CONCLUSION cones feed out into a clear input of a fl ip-fl op, With the drastic increase of asynchronous and several of logic cones are changing value clock domains in today’s designs, one cannot at the same time. The initial value of clear is “0” fully rely only on best design practices, software simulators, and static software www.mentor.com 15 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

Advancing the AVM: A Guide to what’s new in AVM 3.0 By Tom Fitzpatrick, Dave Rich, Mark Glasser, and Adam Rose Verifi cation Technologists, Mentor Graphics Corporation

One of the major reasons we decided to ENHANCEMENTS is a third argument that can be supplied to the make the Advanced Verifi cation Methodology constructor. Setting this argument to 0 tells it to (AVM) open-source in the fi rst place was to ignore the checking of the parent. This argument TOP-LEVEL COMPONENTS facilitate our ability to share ideas with partners is set to 0 by default in avm_env since it should AND MULTIPLE AVM_ENVS and customers about ways to improve it and always be at the top of the hierarchy to add new features that will keep the AVM at The way components are instantiated in an the leading edge of verifi cation technology. This avm_env has changed for AVM 3.0. Many users AVM_THREADED_COMPONENT plan has worked exceedingly well, and our many requested the ability to instantiate multiple AND AVM_VERIFICATION_COMPONENT users of AVM 2.0 over the past year have given avm_env components in a single testbench, us some valuable feedback. With the release of so the code has been restructured to allow Another user-inspired change is that the Questa 6.3, we’ve now incorporated many of this, adding a name argument to the avm_env name of avm_verifi cation_component has these enhancements into AVM 3.0. constructor to distinguish one from another. been changed to avm_threaded_component. Since the avm_env now has a name (in fact, Since verifi cation activity can occur in avm_ This article will explain to a reader familiar avm_env is now an extension of avm_named_ named_component and avm_env as well as with the AVM 2.0 what the major changes are, component), top-level components instantiated avm_verifi cation_component, some AVM-2.0 how to upgrade your code from AVM 2.0 to AVM in the avm_env should now include “this” as users found the old name confusing. There 3.0, and what the advantages of doing so are. A the parent argument. is no functional difference between the two, more detailed description of these features can although avm_verifi cation_component now be found in the AVM 3.0 Release Notes, and of issues some deprecation messages (which course the entire AVM is explained in great and class my_env extends avm_env; can be suppressed). A global replace of “avm_ easy-to-follow detail in the new 3.0 version of ... threaded_component” for “avm_verifi cation_ The Verifi cation Cookbook. function new(string name = “my_env”); super.new( name ); component” is suffi cient to implement this change For the most part, these enhanced features foo_c = new( “foo”, this ); in the AVM 3.0 class libraries are backward- ...

compatible with the classes defi ned in the AVM REMOVE 2.0 libraries while providing greater usability and In this example, the foo_c component is We have added a remove() method to value. The AVM 2.0 classes are still available, named “my_env.foo”. This also has the added avm_named_component to allow a component but when using the AVM 3.0 class libraries it benefi t that the code to instantiate and construct to remove itself and its children completely will now provide messages (which may be foo is the same, whether it is instantiated in from all the avm datastructures. It is similar suppressed, if desired) that tell you when a new an avm_env or inside another avm_named_ to a destructor in C++, although it does not feature is available. In addition, there are some component. This avoids any problems when actually deallocate the memory, a task left to the genuinely new features available only in AVM pushing code down a level in the hierarchy from automatic garbage collection in SystemVerilog. 3.0. avm_env to avm_named_component for reuse Currently, this method can only be called The AVM 3.0 library requires Questa 6.3 or purposes. BEFORE the connect phase starts – ie during later. Questa 6.3 also includes the AVM 3.0 the construction phase. The AVM 3.0 will produce an informative library in pre-compiled form, so you don’t have message for all named components that do not In the constructor of a sub class of the to compile it explicitly (unless you want to). include the parent argument. When instantiating original environment or parent component, we an avm_named_component in a module, there can now remove a child component, create a

16 www.mentor.com new version of this child component, which may (i) to unify the connection mechanisms include error injection or some other modifi ed for ports and analysis ports function new( string name , functionality, and then allow the connect and - in AVM 2.0, we connect analysis ports avm_named_component parent ); subsequent phases to continue as before. using register but we connect normal super.new( name , parent ); ports using “=” blocking_put_port = new(“p1” , this ); A fully worked example is shown in the new blocking_put_export = new(“e1” , this ); (ii) to enable netlist debugging, both in version of the cookbook at cookbook/07_ endfunction Questa and from user code realtestbenches/03_error_svc. The relevant - ie answer the question “what is this code is shown here: connected to ?” Where we used to do “=” or “register” we In this example, p2s_env has a protected (iii) to issue run time warnings when the now do connect : component called m_driver of type p2s_driver. user has We want to replace this component with a - connected to many or to few things to a port or an export subclass of p2s_driver called p2s_error_driver. function void connect(); We do this using the code below : - made the correct connection in the b1.blocking_put_port.connect wrong connection method ( eg a port ( b2.blocking_put_export ); // used to “=” to a port in export_connections when endfunction

class p2s_error_env extends p2s_env; it should be in import_connections ) function void import_connections(); protected p2s_error_driver m_error_driver; - made the connection the wrong way b1.ap.connect( ap ); // used to be “register” round endfunction function new(...);

super.new( ... ); In all these cases, we can issue a meaningful run time error if these new classes have been m_driver.remove; used. This additional checking includes making m_error_driver = new(“error_driver”); In AVM 2.0, we might declare an export as sure that hierarchical connections of exports m_driver = m_error_driver; and ports are done in the proper connect endfunction shown below : phase (export_connections() and import_ ... endclass connections(), respectively), and that peer-to- peer connections are only done in the connect() tlm_put_if #( trans ) blocking_put_port; method. Any incorrect connections will produce tlm_put_if #( trans ) blocking_put_export; run-time errors and appropriate error messages In the sub class’ constructor, we remove the during the elaboration phase, to allow you to old component, create the new component, and debug connection issues much more easily assign the base class handle to the new sub than tracking the null handle dereference that class instance. The connect() and execute() In AVM 3.0, this becomes : you got in AVM 2.0. methods are simply inherited unchanged from p2s_env. This technique works equally well The AVM 2.0 style connection mechanisms with avm_named_component. avm_put_port #( trans ) blocking_put_port; will still work. This change introduces no avm_put_export #( trans ) blocking_put_export; backwards compatibility issues. 2.0 and 3.0 components can be mixed and matched. PORTS AND EXPORTS However, if the 3.0 classes are used, it is Perhaps the most signifi cant enhancement possible to take advantage of many run time in AVM 3.0 is the introduction of avm_*_port, messages and some useful debugging facilities These objects must be created in the avm_*_export, and replacing tlm_*_imp with inside Questa. constructor, in a similar way to the way we avm_*imp. Also, analysis_port is superceded currently do for analysis ports or tlm_*_imps. by avm_analysis_port. We have done this for a number of reasons:

www.mentor.com 17 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

MANDATORY CHANGES stimulus::generate_stimulus but not new data be of type A, the b_gen.b fi eld does not get fi elds. In the new style, it is possible to do copied. In adding this valuable new functionality both. to the AVM, we strove to maintain backward- Instead, AVM 3.0 defi nes clone() to return compatability as much as possible. For the For example, an avm_transaction, allowing the stimulus most part we were successful, but there are two generator (named avm_random_stimulus in features of such critical importance they were AVM 3.0 to distinguish it from avm_stimulus) class A extends avm_transaction; included even though they require compulsory rand int a; to cast the result to the proper type: changes (what my son’s First-grade teacher endclass called “must-dos”) to user code in moving to $cast( temp , t.clone() ); AVM 3.0. In practice, as we’ll see, the amount class A1 extends A; constraint a_zero_to_ten { 0 <= a && a <= 10; } blocking_put_port.put( temp ); of user code you actually have to touch is endclass relatively small and is more than made up for by class B extends A; the improved functionality. The new clone defi nition relies on a user- rand int b; // new data fi eld not in A between_zero_and_a { 0 <= b && b <= a; } defi ned non-virtual copy() method to do the endclass actual data copying. This allows all fi elds of the CLONE extended transaction, b_gen, to be copied as avm_stimulus #( A ) a_stim = new(“stim”); The transaction cloning mechanism has we defi ne the copy() method. The copy code A1 a1_gen = new; changed in AVM 3.0. Previously, for a given B b_gen = new; would look something like this: transaction type T, clone returned T. As such, it could not be virtual in avm_transaction. The a_stim.generate_stimulus( a1_gen ); // old style A extends avm_transaction; clone() method is now virtual in the avm_ // and new style int a; a_stim.generate_stimulus( b_gen ); // new style only– transaction base class and returns an avm_ // clone is deep function avm_transaction clone(); transaction. We have also introduced a non- A t = new; // so B::b gets copied t.copy( this ); virtual copy() method which is used by clone(), return t; and some optional macros which are used to endfunction handle the defi nition and use of the new clone. Recall that the avm_stimulus generator function void copy( input A t ); // this defi nes the copy a = t.a; There are several reasons why this change was calls clone() to make a copy of the randomized endfunction made. transaction before sending the copy out its endclass put_port. The AVM 2.0 code looks like this: The fi rst was simply a practical concern on B extends A; the part of users that the term “clone” implied int b; trans_type temp; // trans_type is the a “deep” copy in terms of the inheritance function avm_transaction clone(); // parameterized type hiearchy, and should therefore be virtual and B t = new; if( t == null ) t = new(); t.copy( this ); return an avm_transaction. This corresponds ... return t; with common practice in other handle-based temp = t.clone(); endfunction programming languages, such as Java. By blocking_put_port.put( temp ); function void copy( input B t ); super.copy( t ); // this does the A copy redefi ning the clone method, it not only allowed // b = t.b; us to implement such a deep copy, but it also // this copies the The type of t and temp is defi ned by the // additional B stuff provides better support for hierarchical copying endfunction parameter specifi ed when the avm_stimulus of derived transactions as well as managing is instantiated – in this case, they are both of derived transaction with constraints for endclass type A. The problem is that the second call stimulus generation. to generate_stimulus above, which passes in Consider the avm_stimulus generator a transaction of type b_gen, ultimately calls So, we have defi ned B’s copy in terms of A’s base class. In AVM 2.0, it is possible to add b_gen.clone() and assigns the clone back to copy, and then used copy to defi ne clone in constraints in a generator subclass in avm_ temp. Unfortunately, since temp is defi ned to both A and B.

18 www.mentor.com While any backward incompatibility is to has a hierarchical equivalent. Use the non- and severity-specifi c hook to be called. be regretted, we believe that the advantages hierarchical method to make changes in the If the return value of the any hook function is 0 outlined in the above justify the value of these local component only; use the hierarchical then processing of that message is discontinued. changes. The migration path is as follows : method to propagate the changes through the The return value of report_hook is ANDed with named component hierarchy. All of the avm_ - Find all instances of clone in your code the return value the severity-specifi c hook. If set_* methods in AVM 2.0 have been renamed - Change your existing clone method both return 1 then the message is processed. If to set_report_* in AVM 3.0. The hierarchical defi nitions to copy methods either returns a 0 the message is suppressed. equivalent methods are named set_report_*_ - Defi ne clone methods in all transaction This is useful for doing message fi ltering in hier. classes, either by writing the fi ve lines of ways not already provided by the AVM message code as shown above or by using The other major usability enhancement to facility. For example: `AVM_CLONE_METHOD( T ) the reporting mechanism is the addition to - Change a = b.clone() to $cast( a , avm_report_client of fi ve new “hook” methods, b.clone() ) or `AVM_CLONE( a , b ) virtual functions that are called automatically by function bit report_hook(string id, string msg, This last change has already been done for the messaging functions. These provide a place int verbosity); if($time > 10000) avm_stimulus and avm_random_stimulus. to obtain control anytime a message is issued. return 1; You can use these hooks to execute any activity return 0;

you wish. Since these are functions and not endfunction REPORTING tasks you cannot do anything that may cause The other compulsory change in AVM 3.0 is simulation time to advance. The hooks are: that the reporting facility has undergone a major The example fi lters by time, causing messages printed earlier than time 10000 to be internal restructuring to provide many degrees virtual function bit report_hook of freedom in executing actions, writing to fi les, (string id, string msg, int verbosity); fi l t e r e d . and fi ltering messages. The use model visible virtual function bit report_message_hook to the user is largely the same, but there are a (string id, string msg, int verbosity); CONCLUSION few important differences. virtual function bit report_warning_hook (string id, string msg, int verbosity); We plan to continue our efforts to collaborate The user-visible interface to the reporting virtual function bit report_error_hook with our users to incorporate enhancements (string id, string msg, int verbosity); facility is contained in the avm_report_client to the AVM library. There are already some virtual function bit report_fatal_hook base class. Avm_named_component is de- new base classes planned to address user (string id, string msg, int verbosity); rived from avm_report_client so all named requirements in future versions of the AVM, components and threaded components and we actively solicit feedback and additional automatically have access to all the reporting suggestions from existing and future users. Report_hook() is called when any of the facilities, including the new dump_report_ Since the code is open-source, it’s easy to avm_report_* functions is called and the other state() function to help you understand what prototype new things and experiment with new four hooks are associated with a specifi c avm_ fi ltering, verbosity and other options are active functionality. By actively partnering with our report_* function. Report_hook() is called fi rst at that time. We also provide the avm_reporter users, we’ve had the opportunity to “test-drive” and then the severity-specifi c hook is called class, which is derived from avm_report_client, all of these new features, so you can be confi dent next. The default implementation of these to be used in modules or classes not derived that they’ll work out of the box. The actual cost hooks does nothing. The same arguments from avm_report_client. of modifying existing code is relatively small sent to the avm_report_* call are passed to the and we think you’ll fi nd it worth the effort. We In AVM 3.0 the methods for modifying hooks. They are input arguments and can be encourage you to try the new AVM 3.0 features, reporting functionality (fi ltering, actions, and used in anyway you like. and let us know what you think. fi le destinations), have been modifi ed so that the A new action is provided to cause the hooks second argument, which controlled whether or to be called. Specifying CALL_HOOK as an not the effect of the set is local or hierarchical, action will cause both the generic report hook has been removed. Instead, each set method

www.mentor.com 19 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

Considerations for Effective Implementation of Processor Driven Testbenches By Jim Kenney, Product Manager, Mentor Graphics Corporation

In the Q1 2006 Verifi cation Horizons issue, The test simply reads or writes data to specifi ed be implemented in great detail (i.e. Flash and we presented the principals of processor-driven register or memory location. As long as this DDR2) or abstracted to a simple array. At the testbenches. In this article we discuss the tools location remains fi xed in the linear address block level the memory sub-system is typically a models you’ll need to create an effective space of the processor (address map), the test absent. The co-simulation tool permits the environment for processor-driven tests. has no dependency on the actual transport user to declare memory space for program mechanism. Figure 1 depicts this concept. A storage, stack, and memory references. At single test can accommodate to the following the sub-system level detailed memory models WHY USE A PROCESSOR-DRIVEN HW variations without changing a single line of can be introduced without changing the block- TESTBENCH? source: level tests. Code must be added to confi gure Leveraging the embedded core as a tool to the MMU, but once confi gured inject bus cycles which read and write to IP the block tests can be run registers is an attractive adjunct to HDL-based unmodifi ed. Seamless permits testbenches. As an orthogonal approach to the user to easily declare and functional verifi cation, processor-driven tests load an abstract memory array, can expose bus interface and bus timing errors then dynamically direct memory that HDL testbenches may miss. These tests references to that array or the are easy to write, highly portable, work well at memories modeled in the logic all levels of abstraction and can be run on live simulator. silicon. A test written in C or assembly As a supplement to manually developed tests, and compiled to target can be verifi cation teams can adopt signifi cant chunks run at vastly different speeds of code from the fi rmware team. Boot code, depending on how the hardware hardware diagnostics, and the RTOS hardware platform has been implemented. adaptation layer or board support package are Speeds range from real-time on highly relevant to functional verifi cation of the a live target to ~ one clock/ hardware design. second for gate-level signoff simulation. Bus implementation: Bus cycles can be HIGHLY PORTABLE pin-level with detailed timing or high-level PROCESSOR MODELS BRIDGE Embedded code is the one true portable transactions. The processor model dictates the MULTIPLE ABSTRACTION LEVELS testbench. As long as the address map remains level of detail inserted into each bus cycle. consistent throughout the hardware design Much of the portability of processor driven process, a test written in C or assembly and Hardware description: Hardware can tests is owed to processor models of various compiled to run on the processor can be used be modeled at the transaction-level, register abstraction levels and performance. These at the block, subsystem, chip, and system transfer level, gate level or implemented in models are an interface between the test and levels as well as run on the physical prototype. silicon. As long as the hardware description can the target hardware. On the test side, all models No other testbench language or testbench tool deliver a read or write to the correct register in present a consistent view, that being the ability can make this claim. the design, the test cares not about the level of to run C or assembly compiled into executable detail simulated to accomplish the exchange. form. This permits the same test to be run on The magic to the portability of a processor a range of processor models as well as the live driven test is its independence of design detail. Memory: The memory sub-system can target.

20 www.mentor.com It’s the internal detail and the interface poor portability and can’t be used with a live diffi cult due to limited hardware visibility. Owed presented to the hardware that separates target. It’s rare to fi nd bus-functional models to their high degree of portability, a processor these processor models. The breakdown is as of different abstraction with a common driven test that is failing on the live target can be follows: programmatic interface, so tests for BFMs are easily run in simulation where debug visibility usually non-portable. and control are excellent. Errors that remain Transaction-Level: Fast with a bus- unresolved after two weeks of debug effort transaction interface. Speeds range from the in the lab have been diagnosed and corrected single millions to tens of millions instructions per LEAPS LIVE-TARGETS within an hour of being re-run in simulation. second. Cache and pipelines are not modeled. IN A SINGLE BOUND In essence these are instruction-set simulators The ability of processor-driven tests to span with a transaction-level interface to hardware. virtual simulation and physical prototype is a MANY ABSTRACTION LEVELS Strength is speed, downside is the need for a signifi cant capability. Benefi ts include: —ONE DEBUGGER transaction-level hardware description which Since processor-driven tests can be applied is typically not available without investing over a wide range of verifi cation disciplines, additional effort. POWER-UP TESTS ARE FULLY VERIFIED care should be taken to avoid a plethora of Cycle Accurate: Reasonable speed with a execution and debug environments. On the Bringing up fi rst silicon is always a tense pin-level bus interface. Cycle accurate implies hardware side, advanced simulators can span process as there are many unknowns and the cache and pipelines are modeled. Clock for the continuum from transaction-level SystemC everyone seems to be watching. Pre-validating clock, these models should produce bus cycles to gate-level signoff. They present a common the tests to be run on fi rst silicon eliminates a identical to the silicon with pipeline pre-fetch set of windows for debugging these different major unknown. Since processor tests span and cache fi ll burst reads accurately modeled. hardware descriptions. the virtual and physical domains with no Cycles may not occur with exact clock-edge modifi cation, the design bring up processes can To debug the C or assembly code of the timing, but activity between clock edges should be simulated and debugged prior to tapeout. processor-driven test itself, a source-level be accurate. Speeds range from 5K to 500K This eliminates the design and test errors that software debugger is needed. Unlike a logic instructions/second. The strength is the ability typically plague prototype bring-up and raises simulator GUI, source debuggers tend to be to drop into an RTL description with no design the confi dence level that fi rst silicon will boot tightly associated with the processor model modifi cations and cycle accuracy. Downside with relative ease. rather than a specifi c tool. For example, the is performance is several orders of magnitude source-level debugger for a transaction- slower than real-time. level model may be distinct from that of the TEST COVERAGE METRICS Signoff Accurate: Highly accurate but very cycle-accurate model for the same embedded slow. These models are typically derived directly The coverage level of live target tests are core. Since these models are written in C, from the RTL used to synthesize the silicon, so typically a guess at best. However, because they typically incorporate a debugger API to they should be an exact match to the physical the exact tests can be run in simulation and service debugger requests for processor state, core. Strength is accuracy and downside is on silicon, virtual test metrics like code and register info and to accept stop, run, and step simulation speed of ~ one clock/second. assertion coverage can be used to grade the commands from the user. completeness of live target tests. Accurate Live Target: The silicon itself. Accurate by coverage metrics bring a level of confi dence A source-level debugger can also be used defi nition and real-time execution speed. The that the physical prototype had been suffi ciently with a live target via a hardware probe connected main disadvantages are the need for a physical validated. to the JTAG port. Ideally, the same debugger prototype and lack of hardware debug visibility. would be used for processor-driven tests Typically used late in the design cycle. across all levels of abstraction. In practice, this ISOLATE PROTOTYPE FAILURES is a bit diffi cult to achieve. Processor suppliers It’s worth adding a note here about bus- WITH SIMULATION and EDA vendors tend to build the simulation functional models. While they insulate the Physical prototypes deliver blazing speed models while embedded-tools vendors support user from bus complexities, their tests have and great accuracy, but debug of logic errors is live-target debug. As mentioned earlier, the

www.mentor.com 21 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

debugger tends to be model dependant, if the While a single hardware debug environment CONCLUSIONS models come from different sources there’s exists for transaction to gate-level, it’s more a good chance the debuggers will vary. If a diffi cult to fi nd a unifi ed debug solution for the Processor-driven tests apply universally single vendor offers both EDA and embedded processor-driven test itself. An odd occurrence across all phases of functional verifi cation. software development tools, they’re more likely given the source of the test remains constant They are highly portable and execute in both to provide a single software debugger covering yet the debug environment does not. simulation and live-target environments. Mentor both the virtual and physical domains. Graphics offers full-functional processor As processor driven tests become an integral models of various abstractions, which are the In contrast, sign-off models are typically component of functional verifi cation, it’s key to test portability. The work of fi rmware compiled from the core’s golden RTL, and as reasonable to expect the logic simulator GUI will developers can be used to dramatically boost such, lack the internal mechanisms and API be extended to encompass source-level debug. test coverage with minimal effort. to support a source-level software debugger. Figure 2 is one example of such a solution. Resolving test failures at the signoff level The source-view on the left contains the code Questa encourages the use of processor typically involves cross referencing static running on the processor while the view at the driven tests with it’s integrated source-level listings of the source, assembly, and symbol lower right is the HDL source-debug window. debugger and support for multi-abstraction table with the dynamic values displayed in the Both share an identical look and command set, simulation and processor models. As embedded wave window. A tedious task at best and a far making it painless for a hardware verifi cation design complexity advances, processor- cry from the productivity realized with a full engineer to adapt to working with embedded driven tests will become critical to functional featured source-level debugger. Tool vendors code as a testbench. verifi cation coverage. Mentor Graphics are now beginning to address this issue and continued investment in HW/SW simulation signoff model debuggers are available for a technology insures that Questa is ready when limited set of embedded cores. you decide to make the move to processor- driven testbenches.

Figure 2: Questa’s integrated HW & SW debug. The processor- driven test source view on the left shares a common look and feel with the HDL source view at lower right.

22 www.mentor.com Solving the Verification IP Re-Use Paradox— How to Re-Use Module Level Testbenches at the System Level By Mark Olen, Product Manager; Sudhir Kadkade, Lead Engineer, Mentor Graphics Corporation

The process of assembling, combining, and relative timing of its activity with that of other Thus combining traditional subsystem VIP integrating design Intellectual Property (“IP”) subsystems, each of which is dependent on the modules, merely applies the same stimulus to into complex system level designs has been entire history of its own input stream. the subsystem, without consideration of the reasonably well rung out. While certainly not system level complexities. As a result, it is not possible to separate yet turn-key, design and integration processes the verifi cation of one subsystem from that of In a previous article published in the Q1 2007 enable system level engineers to successfully the others, even when the subsystems do not, issue of Verifi cation Horizons, “The Second re-use design IP modules originally developed from a user’s point of view, have any apparent Productivity Revolution – Algorithmic Testbench by external organizations. So why then can’t relation to each other. For example, presenting Synthesis” a radical new technology was Verifi cation Intellectual Property (“VIP”) the same input to one subsystem’s interface at described, that provides a revolutionary increase modules also be easily assembled, combined, different times can result in different responses, in verifi cation productivity. As an alternative to and integrated into an effective system level depending upon what else just happened to be the use of traditional programmatic approaches testbench, to adequately verify an entire system occurring elsewhere in the other subsystems at to verifi cation, the article introduces the use of level design? In fact, system level re-use of VIP that moment. Design bugs may therefore be an automata-based approach. And the benefi ts modules is often promised, but rarely achieved obscured until not only the appropriate stimulus of such an approach extend signifi cantly into – at least not without much pain and suffering. is applied to the pertinent part of a subsystem’s verifi cation of complex system designs. The paradox is that an effective subsystem interface, but also until that stimulus is VIP module must be developed without the Mentor Graphics’ Questa™ Algorithmic coordinated with the complete stimulus history knowledge of the target system design(s) into Testbench Synthesis enables system and applied to the other subsystems’ interfaces which the corresponding design IP module is to subsystem behavior to be concisely described as well. Thus, more intricate and subtle tests be integrated. After all, a VIP module created in declarative rule sets and action routines1. must be created to exercise these situations at with system design dependencies would not These Rules & Actions™ are similar in nature to the system design level. be re-usable at all. However, it is exactly the transitions and states (state diagrams), strings system design level interdependencies between Traditionally, ad hoc and intuitive approaches and terminals (grammars), and/or arcs and subsystem modules that are the most important have been used for system level verifi cation, nodes (automata). From the Rules & Actions, to exercise, confi rming correct system level achieving only limited levels of system level the new Questa technology automatically operation. coverage. In general such approaches constructs a non-deterministic automata tend to focus on areas that “seem to need” (“NDA”) graph, which is compiled into an Complex designs generally comprise a testing, according to preconceived notions, engine. Engines may be combined to form a number of modules, or subsystems, which while leaving other areas entirely uncovered. module, and modules may be combined to form may interact internally, either directly through Complexity is compounded by situations a system level graph. The Questa toolset then active collaboration, or indirectly through the that require interaction between multiple applies algorithms to traverse the Rule graphs successive use of shared resources. These subsystems. System designs can achieve to synthesize a terminal sequence of simulation subsystems may also exhibit behavior through performance advantages by reusing internal stimulus and response by stitching together a several of the system design’s external resources and performing functions in parallel. series of Action routines in sequential order. interfaces simultaneously. Further complexity is Such techniques result in extremely complex added by the interaction of the activity between Questa’s Algorithmic Testbench Synthesis internal interactions, not readily apparent to each of the subsystems and the activity of the breaks the VIP re-use paradox, enabling the user, even when all of the implementation others. In particular, not only is the behavior multiple subsystem VIP modules to be re- details are known. And it is precisely these of a subsystem dependent on the entire history used, combined, and executed in concert to interactions that are unforeseeable when of its input stream, it is also dependent on the synthesize an effi cient set of high-coverage developing subsystem level VIP modules. www.mentor.com 23 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

testbench sequences that verify the system design as a whole, with all of its subsystem interactions and interdependencies. Here are two of the unique attributes that enable this re- use.

First, Questa’s Algorithmic Testbench Synthesis contains the ability to enable each subsystem VIP module to discover the presence of the other subsystem VIP modules, determine what areas of the system are currently being addressed by them, and respond to their activity. A centralized device registry called the Dynamic Resource Scheduler (“DRS”)2 catalogs all of the subsystem VIP modules in a simulation. During simulation different VIP modules can connect to each other, based on their goals and capabilities, thereby creating a system- level testbench structure that is independent of even verifi es that all valid transfers between each interaction between multiple subsystems. specifi c names or fi xed addresses, and instead peripheral function are tested with the expected Questa’s DRS enables multiple subsystem relies on what service is needed to achieve level of concurrency at the rate of transfer VIP modules to generate transactions in coverage goals. expected in the GPS systems that will be built parallel, creating extremely dense interaction For example, if a function VIP module (i.e. with this design. activity during a simulation, yet ensuring that Flash, I2C, IDE, etc.) needs to generate a any resulting failures are due to faulty system Second, Questa’s DRS also registers and transaction, it looks for a bus master VIP module design, rather than faulty testbench design. In grants shared system resources for exclusive (i.e. OCP, etc.) that is connected to the local bus. fi gures 2a and 2b, note the processor design use by the subsystem VIP modules. For No assumption is made about the type of local that contains multiple internal busses and example, if several subsystem VIP modules bus. If later in the same or a subsequent design, external interfaces. The timing diagram depicts are verifying that multiple transfers through the bus type is changed; the same function VIP an actual time slice of signal level activity DMA channels can be concurrently performed module can be used with a different bus master generated by multiple subsystem VIP modules to different peripherals, DRS will verify that VIP module (i.e. AHB, etc.). This enables the each generating transactions in parallel. Note the DUT resources needed to complete each reusability of both the function and the bus that Questa’s DRS is able to overlay multiple transaction are available, and if available will master VIP modules. In fi gures 1a and 1b, note transactions for simultaneous execution, while grant a time slice of use of each resource to the System-on-Chip design intended for use in sharing the exact same resource, yet without each requester. This capability of resource Global Positioning Satellite systems. The ARM confl ict. It would be nearly impossible for a management would normally be performed AMBA AHB bus supports multiple processors verifi cation engineer to intricately interweave by the design’s system software, which in and multiple functions including a NAND Flash the signals as shown. its entirety is impractical to load and execute Interface, IDE Memory Interface, and an I2C during simulation. Traditionally, the burden of The Mentor Graphics Questa™ Dynamic Interface Controller. The Questa Algorithmic design resource management during simulation Resource Scheduler technology enables Testbench Synthesis technology ensures that falls to the system-level verifi cation engineer, verifi cation engineers to re-use subsystem VIP all possible combinations of transfers and who normally resorts to serial execution of modules for system level verifi cation, without arbitration on the AHB bus are covered. It also subsystem VIP module simulations. While this the traditional pain and suffering. By cataloging ensures that all of the peripheral functions are can prevent overwriting of memory locations the available subsystem VIP modules, and by tested in all of their programmable modes. It and DMA controller registers, it does not managing and granting the system design’s result in test sequences that verify the intricate hardware resources during simulation, Questa’s

24 www.mentor.com Algorithmic Testbench Synthesis creates Testbench Synthesis, contact Mark Olen at Mark Olen is the Product Manager at Mentor extremely dense system level verifi cation [email protected]. Graphics for Questa’s Algorithmic Testbench stimulus, providing maximum stress on the Synthesis product line. He has worked at target design, without creating any unwanted Mentor for ten years and has more than 25 illegal conditions. ENDNOTES years of experience in the semiconductor design verifi cation and test industries. Mark Questa fi nds more bugs faster—with less 1. Questa’s Rules & Actions can be written in is a graduate of the Massachusetts Institute engineering time—enabling companies to SystemVerilog, Verilog, SystemC, and/or C/ of Technology and can be reached at mark_ bring their verifi cation productivity up to par C++. [email protected]. with their design productivity as they face 2. DRS Patent Title - “Resource Management ever-growing and increasingly complex system Sudhir Kadkade is the Lead Engineer at During System Verifi cation” - A method and design challenges. Questa reduces design Mentor Graphics for Questa’s Algorithmic apparatus for resource management for non- delays, project costs, hardware respins, Testbench Synthesis product line. He has deterministic automata for dynamic verifi cation fi rmware patches, and fi eld returns. For worked at Mentor for 15 years and, has more of a system of device under test. more information about Questa’s Algorithmic than 25 years of experience in the simulation, synthesis, and test industries. Sudhir is a graduate of the Birla Institute of Technology and Case Western Reserve University.

www.mentor.com 25 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

Verification Project Management—Bringing Visibility to Verification Management By Mark Peryer, Mentor Consulting Division; Darron May, DVT Division; Andy Walton, Mentor Consulting,Mentor Graphics Corporation

INTRODUCTION ready to be released. The usual way to capture implementation can be tracked. the verifi cation plan is to use a spreadsheet or Most project managers would describe In order to measure progress against the a document. managing a functional verifi cation project as a verifi cation plan, there needs to be a way to major challenge, citing visibility as one of the All verifi cation projects have to be completed determine whether a feature has been verifi ed, major short-comings of the process. However, by a certain point in time, but frequently there or covered. This requires a method to collect with recent developments in the Questa are so many features that have to be verifi ed that coverage information and a mechanism for verifi cation platform, verifi cation projects it is impossible to completely verify a design storing this information in a database. The can be managed and brought under control before it is released. In order to manage the risk techniques that are directly supported by provided that the right combination of planning, in the project, the features should be ranked by verifi cation languages, such as SystemVerilog or database, and measurement techniques are their importance so that the verifi cation team PSL, include functional coverage and assertion used. can prioritize their energies on verifying the coverage. Code coverage is supported by functionality in order of project criticality. verifi cation platforms such as Questa. Other Distilled to its essential components, project approaches to collecting functional coverage management is about analysing a major task The next step in the planning process is to information may come from other sources and creating a plan that will allow an identifi ed establish the most effective way of verifying such as verifi cation IP (VIP) – for example a group of people and resources to complete the functionality of each of the features. This bus protocol monitor may provide a functional that task within a given time. Once the project is a question of determining whether the coverage summary of the type and number starts, progress is tracked against that plan feature is best verifi ed using formal verifi cation, of bus transfers it has observed during a and if necessary the plan is revised to allow simulation, emulation, or some form of simulation. Results from all these coverage for changes in circumstances or a revision of prototyping. A set of scenarios is developed, collection methods can be saved in a Questa goals, with sub-tasks, people or resources designed to confi rm that the design is behaving UCDB fi le (see the table below). being added or taken away from the plan as as specifi ed for a particular mode of operation necessary. The project management process or set of circumstances. These scenarios may Once the most suitable way of measuring of juggling resources and tasks is not over until use directed stimulus, constrained random functional coverage for a feature has been the goals of the project have been achieved. stimulus or some combination of the two. determined, the functional verifi cation plan Once identifi ed, these scenarios are added to needs to be updated to refl ect how coverage Verifi cation project management is based the verifi cation plan so that progress in their will be measured for each point. As the design on the same principles, but uses specialised planning techniques and a systematic linkage of tools and methods to gain the visibility and Coverage Mechanism SV Language support Comments insight required to manage the process. Functional Coverage Covergroup, coverpoint, Checks that a condition occurred. cover bins, Works by sampling signal values. crosses Use of cross products yields complex THE VERIFICATION PROJECT information. MANAGEMENT PROCESS: Assertion Coverage Sequence, property, Checks a sequential chain of events assertion or a condition always holds. Can be STAGE ONE – used with formal verifi cation. PREPARING THE VERIFICATION PLAN Functional-Assertion Sequence, covergroup Samples a value or cross product Hybrid sampling on completion of a sequence. The fi rst step in the verifi cation planning process entails taking a functional specifi cation Code Coverage All constructs Confi rms that lines and branches in code have been exercised. for a design and identifying all of the features VIP Coverage Instantiation of models Black box code writing into the that have to be seen to work before the design is coverage data base.

26 www.mentor.com and test bench implementation progresses each coverage construct will come into being and its path within the test bench and design code needs to be linked to corresponding features in the verifi cation plan.

With Questa, the verifi cation plan can be imported from an XML fi le which can be easily generated by most spreadsheets and document editors. This XML representation of the plan can be automatically translated into the UCDB format to include links from the sections of the Verifi cation plan to the coverage objects within the design. Example formats for an Excel and Word document are illustrated which show the sections of the verifi cation plan which defi ne the features of the design to be verifi ed. Each feature is then connected or linked to any number of coverage items. A coverage item to ensure the correct function of the design would sections of Verifi cation Plan are represented that the directed test ran successfully. normally be a SystemVerilog covergroup, as a hierarchical tree within the database. For The UCDB has a mechanism called tagging coverpoint or cross, although any coverage example sections numbered 1.1, 1.2 and 1.3 which allows a relationship to be formed item stored within the database could be used, would become children of the parent section between objects by linking them within the including assertions, code coverage objects number 1. Information on all tests is kept in the database. The process of generating links or coverage from VIP. When the document is test record area of the UCDB so a directed test between the verifi cation plan items and the imported into Questa from the XML fi le, the can have any user attributes added to indicate coverage items in the design and test bench is done when the verifi cation plan UCDB is merged with the coverage UCDBs captured during simulations. By making this merge process a test-associated merge, a single database can be used to show the effectiveness of any test within the database with respect to the verifi cation plan and the design itself. Also, once the links between the design and the plan are added to the database it is very easy to detect coverage points that have not been implemented or coverage points that have not been linked to the plan.

STAGE TWO – TRACKING PROGRESS

Tracking verifi cation progress is a combination of checking how many scenarios have been run and determining how much coverage they have achieved. Given the potential

www.mentor.com 27 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

complexity of this task, automation is required If the verifi cation plan database fi le is merged and to determine how much risk remains in the to capture the results from different tools and with any or all of the result coverage database project. With an automated process for capturing to aid the analysis of the results. At this stage, fi les, then it is possible to determine which functional coverage results and tracking these a primary goal of the verifi cation management of the functional coverage points have been results against a verifi cation plan, it is very easy process should be to give high level visibility of implemented in the design and verifi cation code to make changes to the plan or the verifi cation the verifi cation status to the verifi cation project and also how much functional coverage has environment and quickly regain visibility of the manager to allow any necessary corrective been achieved for each point. This information current status of the project. actions to be identifi ed and taken. can then used to determine progress on the A verifi cation plan might change for a number implementation of the verifi cation environment Each scenario that was identifi ed in the of reasons. One common cause is a change in and also to get an overall picture of how much of verifi cation plan would correspond to a the design specifi cation. In this case, Questa’s the design functionality has been verifi ed. The simulation or a series of constrained random verifi cation tracking system can be used to detail of the functional coverage is important to simulations using different seeds. In order determine which of the test scenarios would be the verifi cation engineers, but the verifi cation to have the most fl exibility in analysis, the affected by the functional change by taking each project manager needs a set of reports that coverage results from each simulation run coverage point affected by the specifi cation enables him to quickly understand how the should be stored in a separate ucdbUCDB fi le. change and determining which test scenarios project is progressing. Ideally this report needs The coverage from the different testsUCDB generate coverage for it. to be in a format such as html that can be read fi les can then be analyzed in any combination easily. An example of such a report generated Another common cause is that during the within a single database that has been merged by Questa is shown below. verifi cation process an “unexpected” functional from these runs using a mechanism called test- bug is discovered. This bug may point to a whole associated merging. This allows cumulative area of functionality that was missed when the coverage data for a series of tests to be analyzed STAGE THREE – ADAPTING TO CHANGE verifi cation plan was originally put together, or without the need to merge all combinations Successful verifi cation management requires it may highlight a shortcoming in the design individually. being able to adapt the verifi cation plan to change specifi cation. Either way, new coverage points should be added to the plan and new scenarios should be created to cover up the hole. Using Questa’s automated techniques enables these changes to be made and tracked effi ciently.

STAGE FOUR – COMPLETING THE PLAN

The fi nal part of the verifi cation process is determining when a design has actually been verifi ed completely. In an ideal world, this would mean that all of the functional elements had been shown to have been verifi ed, but the reality is often that the project reaches a stop date and a quality judgement has to be made by comparing the information collected in the functional coverage database against the verifi cation plan. Those features that have below-target functional coverage should be considered unverifi ed. Going forward with the design at this point means taking a risk that there will be a related functional bug. If prioritization

28 www.mentor.com has been introduced into the plan from the start NOTES of the planning process, then this analysis can be deterministic.

It is not unusual for a design to be released to production with the verifi cation process still in progress. The argument for this is that if the verifi cation is not complete then a bug may be found that can be corrected by a mask change during the fabrication process. Again, verifi cation plan tracking can be very helpful in determining when the appropriate level of confi dence has been reached.

Once the verifi cation project has been completed, the verifi cation plan and the verifi cation reports should be archived along with the design and verifi cation source code. If the design is reused at a later date, then this information will be extremely useful to the new project team as they determine what they need to verify for their project.

CONCLUSION Verifi cation project management builds on conventional project management processes, but the planning and status feedback mechanisms need to be tightly coupled to the verifi cation environment and tools used. The Questa verifi cation platform imports verifi cation plans from spreadsheets and documents and provides a mechanism to track verifi cation coverage results against the plan. Once this connection has been made, the whole verifi cation process becomes transparent and it is far easier for a project manager to gain an objective understanding of a verifi cation project and to bring it under control.

www.mentor.com 29 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

Brief update on OVL By Mike Turpin, ARM LTD, Accellera OVL Chair and Kenneth Larsen, Mentor Graphics, Accellera OVL Co-Chair

Since the standardization of the Open creates an internal testing point Verifi cation Library (OVL) in August 2005, the thereby increasing observability in Accellera technical committee has been working the design. towards its second major release of assertions. OVL v2.0 extends the current library with many One fundamental enhancement new features including: to the library is that all assertions will be available as • Synthesizable ovl_ fully-featured checkers with modules with enable input and fi re output a new naming convention: • 18 new, more advanced assertions, e.g. ‘ovl_’. All new for arbiters and FIFOs assertions will be fully featured • Programmable clock edge, reset polarity, and only available as modules & enable gating named ‘ovl_’. or FPGA prototyping environment. See fi gure 1 • New macros to control global defaults For backwards compatability, the existing 33 (above) for an example. • VHDL Implementation for most popular OVL assertions will be available in both the new OVLs name and the old ‘assert_’ The library also has fi ner control of x-handling, modules (with less features). For new designs allowing users to disable X-checking on a per- See Table 1 below for a complete list of the the new ‘ovl_’ assertions are instance basis (in addition to the global disables v2.0 library checkers. recommended. already in OVL). The user can better control the semantics of the checking made; for example, The OVL is a library of pre-defi ned assertions The fully featured ‘ovl_’ if it should rely on 2 or 4 state semantics. This implemented in several languages —including assertions add two ports to each checker: an is naturally important for several reasons, Verilog, PSL-Verilog, and SystemVerilog. It input port that allows users to dynamically including when using formal verifi cation e.g. an enables assertion-based verifi cation (ABV) enable or disable a specifi c check, and a 3-bit OVL can be exhaustively proven but fail due to throughout the verifi cation fl ow and support for output vector that fi res when a checker fails X-pessimism in simulation. simulation, formal verifi cation, emulation, and (2state or X) or when a coverpoint is activated. FPGA prototyping. OVL assertions are instances The new ports enable several advanced Work is underway to provide a native of modules that guarantee that some condition features, such as chaining the pre-defi ned VHDL implementation of the OVL, in the new holds true. Each assertion is composed of one checkers into a larger checker or a more ‘ovl_’ style, and the most or more properties and one or more coverpoints. complex protocol monitor. The ports also allow popular OVLs are already available in VHDL When instantiated in a design, the assertion the user to stitch up checkers in an emulation for evaluation. Support for an OVL SystemC implementation is one area that the technical committee plans to support in the future. ovl_always, ovl_always_on_edge, ovl_arbiter, ovl_bits, ovl_change, By the time you read this, it is more than ovl_code_distance, ovl_cycle_sequence, ovl_data_used, ovl_decrement, ovl_delta, likely that the committee has already released ovl_even_parity, ovl_fi fo, ovl_fi fo_index, ovl_frame, ovl_handshake, ovl_hold_value, OVL v2.0, and it is made available on the www. ovl_implication, ovl_increment, ovl_memory_async, ovl_memory_sync, accellera.org web site. Should you be interested ovl_multiport_fi fo, ovl_mutex, ovl_never, ovl_never_unknown, in the work of the technical committee and want ovl_never_unknown_async, ovl_next, ovl_next_state, ovl_no_contention, to contribute, please contact the chairs. ovl_no_overfl ow, ovl_no_transition, ovl_no_underfl ow, ovl_odd_parity, ovl_one_cold, ovl_one_hot, ovl_proposition, ovl_quiescent_state, ovl_range, ovl_reg_loaded, ovl_req_ack_unique, ovl_req_requires, ovl_stack, ovl_time, ovl_transition, Table 1 - v2.0 OVL checker library ovl_unchange, ovl_valid_id, ovl_value, ovl_width, ovl_win_change, ovl_win_unchange, ovl_window, ovl_zero_one_hot *bold font = new v2.0 checkers

30 www.mentor.com VSI Alliance Update—Got Verification IP? By Kenneth Larsen. Mentor Graphics DVT division & VSI Alliance (VSIA) Verifi cation IP Workgroup Chairman and Mark Buchanan, LSI Logic Corp.

In your last project, did the verifi cation the attributes evaluated as part of the VIP QIP the VIP, the QIP tool produces a graphic and intellectual property (VIP) you purchased assessment. The tool is implemented as a textual summary and a score. The results can provide the positive return on investment you Microsoft Excel workbook and provides all the be shared with the VIP provider or other users expected? Did it lower risk as much as you had necessary capabilities to provide an objective of the QIP tool for further comparison and hoped? Or was the VIP so buggy that you had vendor and VIP assessment. It also allows the assessments. to use precious development resources to sort user to compare multiple vendors against a The goal of the VSI Alliance workgroup is to out the quality issues and ended up spending standard metric. provide a tool that helps VIP integrators assess more time and money than if you had developed Below are a two example screenshots taken whether third-party VIP is of the expected the VIP yourself? Would you like a method to from the QIP tool. quality and enables VIP developers to better assess the quality of VIP and VIP providers understand what is required to before you purchase VIP for your next project? provide Quality Verifi cation IP. Consumer applications are creating an The VSI Alliance and Mentor insatiable demand for complex system-on- Graphics plan to demonstrate chip (SoC) devices that require specialized the released version of the functionality for products such as iPods, wire- QIP tool at this year’s Design less internet devices, automotive entertain- Automation Conference on ment, and cell phones. As it is no longer cost Tuesday, June 5th. The QIP effective or effi cient to develop these from the tool can be downloaded from ground-up, companies have turned to design the VSI Alliance website at reuse and intellectual property (IP) blocks. To www.vsia.org. objectively assess the quality of third-party

IP, these companies have come to rely on the For further questions please feel free to Figure 1 (above) shows the ‘Verifi cation’ VSIA Quality IP (VSI-QIP) metric to objectively contact Kenneth Larsen at kenneth_larsen@ section, one of the 11 “Vendor assessment” assess the quality of third-party IP. The VSI-QIP mentor.com or the workgroup e-mail refl ector areas, and 60 assessment questions. For ensures the successful integration, verifi cation, at vsi-verifi [email protected]. example, a vendor will receive a lower score if it and reuse of specifi c third-party IP. is not able to provide a detailed and coordinated In September 2006, a number of VIP users, test plan to the user. VIP developers, and EDA vendors formed a Figure 2 (right) shows the workgroup to extend the VSI-QIP metrics to “Portability issues” section, one include a quality assessment tool for standard of the 22 “Digital Verifi cation VIP components. With the announcement of VSI IP” areas, and more than 120 QIP 3.0 in early April 2007, the results of this assessment questions. For effort —by participants from Cadence, Denali, example, if the VIP has been EDA Centrum, Freescale, LSI, Mentor Graphics, proven to be compatible with Synopsys, and UMC— was made available as an industry-wide verifi cation an early release for the general public. methodology, it will receive a Reusability and support of newer verifi cation better score than if not. techniques, such as constrained-randomization, When the user has emulation, and formal verifi cation, are some of assessed the vendor and/or www.mentor.com 31 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

SystemVerilog – Verification for Companies Large and Small By Dr Paul Marriott, Director of Verifi cation, XtremeEDA Corporation, Alex Melikian, Lead Verifi cation Engineer Aethera Networks, Ben Sauvé, FPGA Design Manager Aethera Networks, and Vinod Empranthiri, President/CEO ArchSilc .

EXECUTIVE SUMMARY privately held Montreal company, who had the CONVENTIONAL WISDOM formidable task of verifying two FPGAs coded in An incremental approach to adopting Conventional wisdom dictates that designs VHDL and designed for their Fourth Generation SystemVerilog with an AVM-based environment targeted to FPGAs do not need a complex (4G) AEGIS-VTM. Previously an antiquated is an excellent way for teams to migrate from verifi cation environment and hence only an VHDL based verifi cation environment was being a traditional test approach to a modern state- antiquated VHDL-based environment was used, but it was clear that this approach was of-the-art testbench. Designs targeted to Field available. The team clearly recognized that this no longer adequate. An interim VHDL-based Programmable Gate Arrays (FPGAs) benefi t from approach would just be not adequate for the testbench integrating a commercial off-the- the adoption of a coverage-driven constrained- timelines and quality they required. They realized shelf SONET/SDH -Intelligent Testbench was random approach and the integration of existing a more powerful verifi cation environment was the starting point for the project. specialized third-party verifi cation IP is also needed to successfully validate the designs feasible. In today’s work environment, more and within tight deadlines. In addition, there was more teams need to learn while doing. Teams a need to instantiate with no prior experience using the testbench the VHDL design as features of SystemVerilog, or a framework well as interfacing with such as the AVM, become productive rapidly AiVi (ArchSilc Design with targeted training and consulting services. Automation’s, a third This article is a real-world case study of a successful adoption of SystemVerilog using an AVM methodology.

Original Aethera INTRODUCTION Testbench using VHDL XtremeEDA was approached by the and ArchSilc Intelligent verifi cation team of Aethera NetworksTM, a Testbench (AiVi)

32 www.mentor.com party company, SONET/SDH Intelligent Test- facilitate re-use. Since it is an open standard TOOLS MAKE THE DIFFERENCE bench that automates SONET/SDH protocol the team felt comfortable that they would not Since Aethera were already Modelsim compliancy and fl ow-level verifi cation). be trapped into building a proprietary code base customers, it made perfect sense from both that could be obsolete or unsupported. Telecom a business and a technology perspective to products typically have a very long lifetime so STEPS ON THE ROAD recommend a solution using SystemVerilog protection from obsolescence is important. An TO ENLIGHTENMENT with Mentor’s Questa solution. The benefi ts attractive feature of the AVM is that it is also of SystemVerilog’s high level modeling and Acceptance is the fi rst step on the road to open source, providing Aethera protection random generation were utilized to streamline verifi cation enlightenment. The Aethera team from a proprietary solution and allowing them the verifi cation environment coding and knew they had a problem and this is where they to make any changes that may be required to simulation process. Various components such were when we fi rst met with them. In engaging automate - AiVi confi guration. BFMs, data structures, even the mirroring with a potential client, we always establish of FPGA fi le registers were coded as high their unique requirements before making any One of the team members was already level objects (derived from classes in the recommendations. familiar with other HVLs and so was comfortable making the leap to SystemVerilog. Others AVM library), maximizing code reuse. Built-in They had realized that a more powerful were not familiar at all and so the training and randomization in SystemVerilog made the task verifi cation environment could only be provided knowledge transfer plan had to take a variety of of various but valid data generation trivial. Yet by the move to a modern HVL (high-level backgrounds into account. the code developed was fl exible to support verifi cation language) . The uncertainty was more directed tests when needed. All this lead how to do this and meet their deadlines as well to the development of an effective, constrained as confi gure AiVi to create complex SONET/SDH HIT THE GROUND RUNNING random driven self-checking environment in test scenarios using SystemVerilog constructs. Ask a manager if their team would benefi t relatively little time. This is what was quickly established: from a training course and the answer is, more Questa’s support of mixed language often than not, “no-one has time for training”. • Design IP in VHDL targeted to FPGA environments was an essential feature as it This is probably the most common reason • Need to integrate AiVi SONET/SDH was required to support the SystemVerilog why companies end up with project frustration. Intelligent Testbench testbench as well as the VHDL design. The They know the pain of their current process and • Want to use a modern HVL availability of DPI interfacing in Questa enabled also acknowledge that there is a better way. But • Need to use HVL constructs to confi gure the verifi cation team to directly interface with there’s never any time. In our experience, we AiVi to generate complex test scenarios ArchSilc’s SONET/SDH Intelligent Testbench fi nd that the sooner training is given and applied, • The company and team are both new generators and analyzers with advanced the better for the client, both in the short term to SystemVerilog SystemVerilog verifi cation constructs, and the long term. However, recognizing that • Reuse is important for future projects completing the complex environment. It many teams have tight deadlines, we developed • Need to minimize risk by taking an was also interesting to discover that the DPI our XtremeBoostTM product that provides incremental approach interface gave 10-20% better performance than targeted training and a short term consulting the earlier FLI interface. Furthermore, Questa’s engagement for the application of the newly support of SystemVerilog’s functional coverage instilled knowledge to the problem at hand. This Aethera was already a Modelsim customer was also considered benefi cial as it served to approach maximizes knowledge transfer and and so it made sense to recommend using measure feature completion progress as the allows a client’s engineering resource to add SystemVerilog together with an environment project advanced. based on Mentor’s AVM (Advanced Verifi cation value while training while constantly reinforcing Methodology). SystemVerilog provides all the the learning that is taking place. This is what features of a modern HVL such as constrained- was recommended to and accepted by METHODOLOGY IS KEY Aethera Networks so they would hit the ground random generation, functional coverage Along with SystemVerilog and Questa, the running. together with object oriented features to AVM library was available for use. The lack of experience in SystemVerilog of the verifi cation

www.mentor.com 33 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

team was not a deterrent from using some of PUTTING IT ALL TOGETHER A SONET traffi c analyzer is encapsulated the more basic components and constructs of thus: The interaction between AiVi and the the AVM library. The team determined the best SystemVerilog testbench occurs through the approach was to take incremental steps and class AiviAn_cWrapper extends DPI. The Aethera team discovered that the DPI avm_named_component; initially use only a simple subset of the AVM link gave a 10-20% improvement in performance int C2Elementhandle; libraries such as the built-in error message over the FLI. The AiVi DPI library calls were calls and avm_verifi cation_component struct- function new(); wrapped in classes derived from avm_named_ ural testbench objects. An avm_env class C2Elementhandle = components as the following SONET traffi c AiviGetElementHandle_DPI( “Rx:SONET:C2” ); derivative was used to encapsulate the overall generator object illustrates: endfunction test sequencing. However, this small subset still proved benefi cial and contributed to the easing function void PutSonetFrameBytes( byte data[] ); class AiviGen_cWrapper extends AiviExportData_DPI( data ); of code integration. avm_named_component; endfunction int C2Elementhandle; The key benefi t of a methodology such as the function byte ReportSonetC2value( int channel ) AVM is that it provides the framework to build a function new(); return AiviTrackValue_DPI reusable test environment. The TLM interfaces C2Elementhandle = ( C2Elementhandle, channel) AiviGetElementHandle_DPI( “Tx:SONET:C2” ); allow a plug-and-play approach to building endfunction endfunction endclass verifi cation components and features such as analysis ports and interfaces allow functional function void GetSonetFrameBytes ( ref byte data[] ); coverage objects to be integrated in a very This approach allows the AiVi DPI calls AiviImportData_DPI( data ); straightforward manner. endfunction to be neatly encapsulated as an API that’s implemented in SystemVerilog class methods, This incremental approach allowed the function void Confi gureSonetC2value allowing the greatest fl exibility of integration Aethera team to gain confi dence in the use of ( int channel, byte value ) with the rest of the testbench. SystemVerilog and become productive quickly. AiviSetValue_DPI( C2Elementhandle, channel, value) Yet the code is fl exible to support more directed endfunction This scheme allowed Aethera to meet the tests when needed and interface with AiVi. All endclass goal of pushing all the protocol generation this leads to the development of an effective, and analysis semantics into the AiVi library constrained random driven self-checking environment in relatively little time. As a bonus, the engagement was completed under budget.

FIRST TIME SUCCESS Today, the verifi cation team has developed a fl exible and powerful verifi cation environment and has made successful initial releases of the FPGA designs. The team continues to produce test cases using the same environment and verify features to be included in the following releases in the side graphic.

Aethera Questa + SystemVerilog + AVM + AiVi Environment

34 www.mentor.com while simultaneously utilizing SystemVerilog all of the instantiated testbench objects became class testCoordinator_cBase extends features such as random generation. With trivial. The VHDL DUT itself was instantiated avm_verifi cation_component; the randomization process made at the virtual task Init(); as a Verilog component in the top-level SystemVerilog level, functional coverage endtask SystemVerilog module using the example in can also implemented. The following code the Questa documentation as a template. This virtual task Confi gureDUT (); demonstrates a method by which the traffi c is the most fl exible method of combining endtask generator can be used to assign a random value a SystemVerilog testbench with a VHDL or to a confi gurable element: virtual task Validate (); mixed-language DUT. endtask

int C2Value; virtual task run(); PLANS FOR THE FUTURE AiviGen_cWrapper SonetTx = new(); Init(); Confi gureDUT(); Many of the components coded in the Assert (std::randomize( C2Value )); Validate(); Aethera environment are reusable for future SonetTx.Confi gureSonetC2value( 0, C2Value); endtask endclass projects, further reducing turn-around time and increasing productivity for the next challenge. The incremental approach to adoption allowed the team to meet their deadlines and also have This breakdown established a consistently TEST COORDINATION time to plan to include more of the AVM library organized look and feel for individual test-cases USING THE AVM constructs to further enhance the power of future that were coded throughout the verifi cation Though only partially used, the utilization of verifi cation environments. This evolutionary process. In addition, by applying a hierarchical some AVM components proved quite benefi cial approach was one of the attractive features of node-leaf structure, coordination between in the structural assembly of the testbench. making the transition to SystemVerilog. Many multiple leaf components could be achieved. By Besides the built in messaging functions, basic people think that an all-or-nothing approach is using the stages in the source node coordinator AVM classes such as avm_named_component, required to start using the advanced testbench class, it would ensure that the phases in avm_verifi cation_component and avm_env features of SystemVerilog but this does not underlying leaves would run in a synchronized were utilized. have to be the case. Adopting some of the fashion, i.e. the subsequent phase of a leaf AVM features allowed the team to focus on Avm_named_component, derivatives were would not execute until the current phase of all the important aspects of the test environment used for most objects that implemented the leaves had completed. without fear of being overwhelmed. elementary operations such as BFMs or DUT clock and reset driver models were encapsulating proprietary models. also coded by creating avm_verifi cation_ IT’S ONLY AN FPGA The automatic invocation of a thread of component derivatives. These models added “We’re only doing FPGAs” . The elephant in execution at start of simulation characteristic confi gurable properties controlling period, the room is that today’s FPGA designs are as of avm_verifi cation_component derivatives latency, duty cycle and other such parameters. complex as large ASICs were only a short time was particularly useful for the creation of a Again, the automatic thread spawning feature ago. The cost of bugs is often perceived as lower coordinator verifi cation component and clock/ of these derivatives is ideal as clock and reset than that of ASICs but this may not be the case. reset generators. sequences would be automatically launched no matter where they were instantiated in the test- Our experiences is that all designs benefi t from The coordinator component was used bench. good verifi cation and using SystemVerilog with to implement test phases by extending the the AVM is an excellent way to create a scalable avm_verifi cation_component’s run() method Finally, an avm_env derivative was used and reusable verifi cation environment that has to include specifi c simulation steps (which are to encapsulate the testbench itself. With the the ability to do constrained-random testing extensible) as the following code illustrates: built in do_test( ) method, the process of with the essential feedback that functional launching, executing, and even coordinating coverage provides.

www.mentor.com 35 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

VERIFICATION FOR ALL NOTES Furthermore, the experience we had with Aethera demonstrates that a combination of Questa plus SystemVerilog using the AVM is a great way for even small companies to get into modern verifi cation. Such an approach allows incremental steps to be taken and Questa ensures that an interface with designs in older HDLs, like VHDL, is not a barrier to adopting SystemVerilog for the verifi cation environment. Targeted consulting and training, in the way an XtremeBoostTM is structured, allows even small teams to hit the ground running: it doesn’t have to be expensive and the specially tailored approach taken enables the clients to get up to speed rapidly so they can run with the initial environment and become productive quickly.

XtremeEDA Corporation is a leading professional ASIC services company focused on verifi cation methodology. XtremeEDA’s XtremeBoostTM program was used as the engagement model for this article.

Aethera NetworksTM is a privately held Montreal based company delivering reliable, cost-effective global network solutions and customer service for over 12 years.

ArchSilc Design Automation provides ‘Intelligent Verifi cation Infrastructure’ that automates protocol compliancy and fl ow-level verifi cation of convergent systems and SoCs. AiViTM provides high-performance and highly- scalable testbenches supporting simulation, emulation, and FPGA prototype based design fl o w .

36 www.mentor.com Denali VIP + Mentor AVM: Best-in-Class Functional Verification with SystemVerilog By Sean Smith, Denali Software

Functional verifi cation continues to be easily implemented and extended by the end which are defi ned in “paper” documents that one of the most time consuming phases of users. There is no doubt that SystemVerilog is now regularly exceed one-thousand pages. ASIC and SoC design. Traditional approaches supported by a strong and growing ecosystem So in this sense, VIP can be thought of as are showing their age, and we are now at a of tools and technologies; this widespread the encapsulation of domain knowledge for point where more advanced techniques and availability of tools and technology offers a the protocol, in a package that is utilized technologies are required in order to deal signifi cant incentive to use SystemVerilog as part of an overall functional verifi cation with increasing design complexity. New as the foundation for functional verifi cation strategy, including a test bench, test harness strategies such as assertion based verifi cation, environments going forward or test fi xture to create a virtual simulation of a coverage measurement, objective test plans, hardware system. constrained random generation, and re-use VERIFICATION IP are now becoming a necessity in order to meet COMMERCIAL VERIFICATION IP design schedules. Industry-wide acceptance Verifi cation IP has become an valuable part of SystemVerilog with methodologies like of any functional verifi cation environment, The complexity of modern protocols, such Advanced Verifi cation Methodology (AVM) and perhaps even more-so for SystemVerilog as PCI Express and USB, make it unfeasible for and the availability of commercial verifi cation environments. While terminology has changed all but the largest engineering teams to consider IP (VIP) represent the key technologies that over time, engineers have been utilizing much authoring VIP themselves. A good example of are enabling signifi cant productivity gains in of the functionality of what is now called this is PCI Express protocol, which is described mainstream functional verifi cation. This article “Verifi cation IP” (VIP) for the better part of the in over 2,000 pages of text and diagrams. Just will discuss these technologies, and provide last decade. Bus functional models (BFM’s) comprehending its purpose and behavior alone some examples of how to leverage the synergy “checkers” or “assertions” are terms that are is a gigantic task, independent of the task of to reduce verifi cation time, and improve overall sometimes used in place of verifi cation IP, but actually creating an implementation for design verifi cation quality. in reality, modern commercial VIP is a superset or verifi cation. To provide a real world view into of these key verifi cation elements. VIP could the scope of commercial VIP, consider Denali’s be more formally defi ned as a pre-packaged PureSpec VIP for PCI Express (see Figure 1, SYSTEMVERILOG: component intended to help users perform next page). At time 0 in the simulation, the ENABLING VERIFICATION functional verifi cation on some form of an PureSpec VIP handles over 900 static checks While the above verifi cation techniques electronic circuit. The largest application of VIP to validate the overall architecture and topology above did not originate with SystemVerilog, is in conjunction with a digital logic simulator of the PCI Express device. This is in addition the widespread adoption of SystemVerilog has for the purpose of verifying functionality, 1,500+ dynamic checks in the VIP to ensure enabled these ‘high-end’ techniques to move up compliance, and interoperability for standard correctness of PCI Express transactions from select internal groups, and into mainstream protocol interfaces such as PCI Express, USB, during simulation, and a library of thousands verifi cation fl ows. SystemVerilog offers a SATA, DDR DRAM, etc. In these cases, the of targeted tests cases for compliance and more standardized approach to the problem, VIP encapsulates models, protocol checkers, coverage analysis. Ease of use and customer and provides critical tools such as constraint stimulus generators and other verifi cation support are an obvious, but valuable benefi t of solvers and functional coverage engines; all functions, enabling the verifi cation team to utilizing commercial VIP. To address ease of of which help to enable constrained random verify the design interface protocols, and use use, Denali’s PureSpec VIP provides a GUI that testing and coverage driven verifi cation. The those interfaces to drive verifi cation at the enables users to quickly confi gure advanced SystemVerilog language also provides a rich system level, without investing in the necessary model functionality and timing, other settings syntax for those looking to exploit assertion domain knowledge for the interface protocols. make it easy to implement error injection, based verifi cation. The rich set of Objected The value of VIP in these cases is magnifi ed functional coverage metrics, and advanced Oriented Programming features serve to enable by the increasing complexity of interface stimulus generation. One example of advanced verifi cation methodologies, such as AVM, to be protocols(e.g.: PCI Express, SATA, USB, etc.) VIP functionality is in the use of callback

www.mentor.com 37 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

houses in the world would be diffi cult - hundreds is simply not feasible. VERIFICATION WITH SYSTEMVERILOG A verifi cation environment or testbench in SystemVerilog is similar to a traditional testbench in many ways. The basic structure of both environments is illustrated in the diagram in Figure 3. Here we have the components for creating stimulus and monitoring responses, a scoreboard that collects information about injected traffi c and expected responses, and an evaluator which correlates the injecting traffi c and expected results (this is also often called the reference model). SystemVerilog begins to diverge from traditional approaches in the points. Callbacks enable the user to monitor serious risk into their schedule. And to drive way the verifi cation tasks are accomplished. and act upon the activity of the VIP for generate home another critical point, lets consider for a The SystemVerilog test environment enables functional coverage metrics, scoreboarding, moment that it was feasible to craft a suitable randomization of the confi guration of the or even to modify transactions as they fl ow piece of VIP in house. There is still another major models or DUT, and in the associated through the model for the purposes of error issue to overcome, which is the maturity of the traffi c that gets generated. This constrained injection. An example of callback points in the VIP. In this case, maturity is an expression of random generation enables users to produce Denali PCI Express VIP is shown in Figure 2, VIP quality in terms of exposure to real world stimulus more effi ciently and effectively than where red fl ags mark the callback points. designs to validate its implementation. For in a directed fashion. A key benefi t of the example, Denali’s PCI Express VIP has over Overall, Denali estimates an investment in constrained random approach is that it allows 120 customers spanning every segment of the e x c e s s o f 15 m a n ye a r s i n c r e a t i n g t h i s V I P, w h i c h for easy exploration of unanticipated cases. semiconductors and electronics industries. It is an ongoing effort since the specifi cation is For example, in a PCI Express design, the user has been used to validate all layers of the PCI evolving to address higher speeds and expanded may wish to randomize the address of the Base Express protocol stack, and it has been used functionality. Clearly, this is not a trivial effort, Address Registers or BARs. This can easily to validate all devices in the protocol (e.g.: and most design and verifi cation teams cannot be accomplished in SystemVerilog with the Root Complex, End Point, and Switches). undertake these tasks without introducing following code (below) which will randomize This is clearly important because each users each of the 3 BARs with the constraints that application of IP is unique each BAR must be in increasing order and that and this creates challenges each BAR is at a minimum 512MB. for the verifi cation team and the VIP. Just because a model worked acceptability as x1 // PCI Base Address Register Constraint Example // foreach implication constraint width guard: endpoint does not imply that ascending BAR it will work correctly as a // addresses, BAR ranges at least .5GB x16 root complex. This type constraint c_bar_address { foreach ( bar[ j ] ) of maturity can never be (j < bar.size - 1) -> achieved with home grown bar[j + 1].address.value > VIP. Even getting a couple bar[j].address.value; dozen unique applications foreach ( bar[ j ] ) bar[j].address.value[19:0] == 0; within the largest systems }; 38 www.mentor.com AVM AND VERI- For any given transaction, T, we need to do FICATION REUSE four things:

There are many other • Inherit from avm_transaction changes in the ways to • Implement the virtual function create effective testbenches string convert2string in SystemVerilog. Mentor • Implement a function bit comp Graphics has addressed this ( input T t ); with the Advanced Verifi cation • Implement a function T clone(); Methodology (AVM), which provides classes or objects The PureSpec VIP follows these rules that can be used to simplify and inherits from the proper base class to testbench building and speed provide implementations of the 3 methods their creation. Classes such required. Additionally the PureSpec VIP as the AVM_ENV provide a basis for creating a follows the guidelines of AVM with respect Furthermore, the SystemVerilog environment test environment. The AVM_TRANSACTION and to model architecture, confi gurability and provides a rich set of features for collecting AVM_STIMULUS classes provide a valuable compartmentalization. This means that functional coverage metrics to objectively framework for managing transactions and leveraging PureSpec VIP in an AVM environment measure the progress of how the random stimulus generation. The application of re-use is straightforward and practical. stimulus is progresses. Functional Coverage is methodologies may seem a little intimidating at critical to constrained random methodologies as fi rst but they can quickly be mastered and have REALIZING VALUE WITH it provides an objective measure of verifi cation great benefi ts down the road when it comes MENTOR AND DENALI completeness. In a PCI Express design to application and re-use. Standardizing the The combination of rich new features in environment with Denali VIP, the following code architecture of the models not only provides SystemVerilog with AVM and PureSpec VIP shows that it is relatively simple, yet powerful, great opportunities for re-use, but simplifi es and provides verifi cation engineers with a powerful to create coverage on the replay aspect of accelerate the initial use of a model. Users will framework for verifi cation effi ciency. The the PCI Express protocol. In this example, the understand how to apply and use a model written SystemVerilog language, methodology guides, occurrence and size of reply events are also using a re-use methodology such as AVM since and verifi cation IP are all readily available monitored. many common characteristics of the model will for commercial use now in the industry, and be the same from protocol to protocol. Reuse many leading companies are already reaping covergroup txDlpCovGrp; methodologies like AVM also ensure proper the benefi ts of deploying these verifi cation // Tlp’s @ DataLink Layer partitioning and compartmentalization which environments. Constrained random generation replays : coverpoint 1 iff (covDlp.cbReason ensure we can apply a model at the Transaction == and coverage collection speeds the task PCIE_CB_DL_TX_retry_buffer_exit) Level, RTL Level, or even the gate level. These of creating tests and measuring results, { bins replays = { [0:’h7fffffff] }; } benefi ts far out weigh the small amount of while improving overall quality by exploiting replaySizes : coverpoint covDlp.tlpPkt.length iff learning the user must endure during his initial undiscovered scenarios. Robust VIP speeds (covDlp.cbReason == exposure to the model. PCIE_CB_DL_TX_retry_buffer_exit) the time to fi rst tests, and decreases the overall { bins replaySz[10] = { [0:1023] }; } verifi cation cycle by providing proven sets endgroup of checks, coverage metrics, and re-usable THE AVM LIBRARY stimulus libraries. Utilizing AVM and its OOP AND PURESPEC VIP model allow for components to be quickly Denali and Mentor Graphics have worked and effi ciently reused. The synergy of these Coverage points like this represent a starting together to simplify the usage of AVM technology and methodology improvements is point for a more complex strategy to measure SystemVerilog libraries with PureSpec VIP. ready to be leveraged for dramatic effi ciency important aspects of the overall verifi cation plan. For example, the AVM_TRANSACTION class gains in functional verifi cation today. specifi es the following four rules:

www.mentor.com 39 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

NOTES

40 www.mentor.com www.mentor.com 41 A QUARTERLY PUBLICATION OF MENTOR GRAPHICS

NOTES

42 www.mentor.com www.mentor.com 43 Editor: Tom Fitzpatrick

Program Manager: Rebecca Granquist

Wilsonville Worldwide Headquarters

8005 SW Boeckman Road

Wilsonville, OR 97070-7777

Phone: 503-685-7000

Subscribe: http://www.mentor.com/ products/fv/verifi cation_news.cfm

www.mentor.com 40