INCISIVE VERIFICATION NEWSLETTER

DECEMBER 2004

Incisive platform news and events................... 19

IN THIS ISSUE: 01 02 03 04 05 TO OUR READERS | PAGE 1 ADVANCED VERIFICATION FLOW | PAGE 2 PROCESSOR-BASED EMULATION | PAGE 10 THE INCISIVE ASSERTION LIBRARY | PAGE 14 INCISIVE DEBUG AND ANALYSIS TIPS | PAGE 17

01
TO OUR READERS
Hello and welcome to the December 2004 issue of the Cadence Incisive Newsletter, the quarterly technical verification newsletter for design and verification engineers. The Incisive Newsletter contains articles and information to help you increase the speed and efficiency of your verification efforts for todays complex system-on-chip (SoC) projects. In this issue, you will find a smaller number of articles to accommodate the more detailed technical information each article contains. This months newsletter features the Advanced Verification Flow, an implementation of the Unified Verification Methodology that Cadence introduced last year along with the Incisive platform. Flows are a popular topic as more tools and techniques become available to solve verification challenges. New tools are great, but where should they be used? When should they be used? And how should these tools and techniques be assembled into an optimal verification flow that will let you unleash the full potential of an integrated platform like the Incisive platform? In this article, we introduce the Advanced Verification Flow (AVF), describe its major stages along with their challenges and benefits, and detail a sample reference design that is available to help you understand and implement the AVF. Cadence recently raised the bar on speed and capacity with the introduction of our new Palladium II acceleration/emulation system. The Palladium family is a processor-based solution that provides a number of benefits over earlier FPGA-based systems. In our second article, we will examine the differences between FPGA and processor-based emulation and describe the advantages and disadvantages of each type of system. Assertion-based verification is catching on like wildfire as a way to embed expected design behavior checks, add to your coverage metrics, and help create more selfdocumenting designs. To help users get even more power out of assertions, Cadence is releasing a library of assertion modules that implement checks for common design structures. In our third article, we review this new library and show how it can be used in your designs. Our fourth article continues our popular series on SimVision debugging tips and techniques. Well show you new ways to use time ranges how to save them and synchronize them among multiple waveform windows to greatly expand your debug power. And finally, we once again give you a round up of news and events in Q4 that may be of interest to you. Want to see an article on a specific topic? Feel free to send in your requests to incisive_info@cadence.com. I hope you all have a happy holiday season and enjoy any vacation plans you might have. Well see you in 2005 with our next edition of the Incisive Newsletter.

John Willoughby, Incisive Marketing Director

02

ADVANCED VERIFICATION FLOW

BY KARL WHITING, CADENCE DESIGN SYSTEMS

Todays larger chips and shorter design cycles have driven many companies to invest in verification teams and tools. Yet these verification teams struggle to do more with fewer resources and outdated tools. Yesterdays verification techniques are falling short, and functional verification has become a moving target for many designers who feel they are going to battle unprepared and understaffed. Companies are now realizing that they cant just throw engineers at the verification problem-they have to take advantage of new technologies. Cadence realized this long ago and stepped up to provide technologies that eliminate the verification bottleneck. The Cadence Incisive functional verification platform provides many key verification technologies, but these technologies by themselves are not a solution without a proper methodology. Effective verification must be methodology based, not tool based. The Cadence Methodology Engineering (CME) team has developed the Advanced Verification Flow to bring the most comprehensive verification strategy to design teams around the world. The CME team comprises former customers and verification consultants who are knowledgeable about effective verification methodology. They have created a reference design to demonstrate world-class, industryleading methodologies. This paper introduces the reader to the Cadence Advanced Verification Flow and illustrates the reference design environment that the CME team created for customers to use as they adopt Incisive platform technologies.

AVF OVERVIEW
The Advanced Verification Flow (AVF) is an implementation of the Unified Verification Methodology (UVM)1,2. It outlines the development of both transaction-level and implementation-level functional virtual prototypes (FVPs), which are the environments used to functionally verify large systemon-chip (SoC) designs of one million gates and above (although techniques used in this flow are universal). The design complexity of chips at this size is such that a wide variety of techniques and technologies must be used to successfully complete the project. This paper walks the reader through all the AVF steps, from verification planing through full system verification. It also highlights the flows efficiency and how it utilizes the appropriate methods and tools at the appropriate time to maximize verification throughput. By understanding this flow, the reader will learn industry best practices for functional verification. Verification teams are not expected to implement and perform every major phase or all the steps in a phase. The AVF is designed to be incrementally adoptable. Teams can decide based on their requirements, group experience, and individual expertise which technology and, therefore, which flow steps should be adopted for their project. GOALS OF THE ADVANCED VERIFICATION FLOW Provide a roadmap for verification, from project conception to system verification, which you can adopt incrementally Begin verification of the design earlier, increasing design checkpoints and isolating bugs Create a verification methodology that promotes reuse across testbenches and projects Maximize the verification effectiveness of your environment for each cycle run Provide the necessary information, in the form of documentation and examples, to help teams successfully develop and utilize advanced verification methodologies and associated techniques

2 | Incisive Newsletter December 2004

 Explain the benefits and tradeoffs of using these techniques Show detailed examples of each step on a real design Direct users where to go for additional information BENEFITS OF USING THE ADVANCED VERIFICATION FLOW Users can understand how various advanced techniques integrate together into a complete verification flow Users can begin adopting new verification technologies Users can select parts of the flow and adopt them incrementally Users can walk through the individual steps in the flow using the reference design Users can utilize the code, scripts, and infrastructure of the reference design to jump start their work The AVF follows the basic guidelines of the UVM. Figure 1 below illustrates the phases in the flow starting with the verification plan. The phases of the AVF are:

Block-level verification Verifies individual blocks being developed in the SoC. Tests and components used during this phase can be reused at the system level. Integrating a block into the FVP The FVP environment represents the system environment. Integrating a design block into the FVP allows that block to be verified using system tests and software earlier in the design cycle. Full-chip or system verification Consists of the steps required to integrate the full chip and verify it. Transaction-based acceleration can be used in this phase most effectively. In-circuit verification Some systems require that you create a prototype or an in-circuit environment to verify more of the hardware and software together before tapeout. The AVF recognizes this need, but does not describe the in-circuit flow. (A description of the in-circuit flow, however, is available in another Cadence document.) It is a major goal of the AVF that verification IP developed for one phase or step carries forward and is reused in other phases, thus reducing the overall work load. In addition, it is important for design teams to be able to reuse old tests and verification IP from previous projects. However, the AVF does not advocate that a verification team throw out their existing testbench methodologies. The flow is intended to complement and enhance an existing verification methodology in an evolutionary manner. VERIFICATION PLANNING The success of any project depends, first, on a welldeveloped plan, followed by efficient execution of the plan. The AVF starts with a planning phase that provides a roadmap for verifying an SoC design. It documents the goals for verification, the methods and technologies that will be used to achieve those goals, and the tests that need to be developed. The plan is used throughout the flow to track progress and ensure that the goals are being achieved. It chooses which of the flow phases will be followed and describes the details of each step in each phase. Finally, the plan defines the functional verification completion requirements and tapeout criteria. The steps associated with the creation of a verification plan3 are as follows: Set verification goals Describes measurable functional verification goals. Develop the feature list Describes the system features to be verified. Define the verification environment Defines the environment to be used to verify the system features.

Verification plan

TL FVP Block-level verification

Integrate block into FVP Full-chip/system verification In-circuit system verification

Major flow step

Dependency direction

Figure 1: Advanced Verification Flow

Verification planning Specifies requirements, lists functionality to test, and lists the tests that must be created. The flow is developed to ensure that the testbench created is robust enough to handle all the verification challenges that the team will encounter. Creating the transaction-level functional virtual prototype (TL FVP) The FVP is an executable specification of the system that can be utilized during all phases of the flow and by the software group to start software development.

Incisive Newsletter December 2004 | 3

 Define assertions at all levels Defines the assertions that will assist the designer by finding structural bugs earlier in the design cycle. Assertions are also useful for debugging by associating a problem to a specific area of RTL code. Create the list of tests Defines tests to be used to verify the system features. Develop the coverage and completion requirements Describes coverage metrics, goals, and functional verification completion requirements needed before tapeout. Determine resource requirements Defines resources needed to accomplish all the goals. Resources include engineers, machines, software, and tools-and their quantities-needed for verification. CREATING THE TRANSACTION-LEVEL FVP After the planning process, the next stage of the flow is to develop an FVP. The FVP is an executable specification of the design. It can be used to evaluate the system architecture, make performance tradeoffs, and develop low-level software, and it ultimately defines the final SoC functionality and partitioning. The FVP contains transaction-level models (TLMs), system-level tests, application checkers, and performance monitors. It is typically written in C, C++, or SystemC. The SystemC library was created to make system modeling easier. In creating the FVP, the verification team begins creating the testbench and system-level tests early in the design cycle. Both software and hardware teams use the FVP during development. The software team can begin writing and executing code against the FVP, maturing the software side of the system earlier in the design cycle. The steps associated with the creation of an FVP are as follows: Create digital and analog TLMs TLMs are the design blocks in abstracted form. TLMs run faster and enable system testing earlier in the design cycle. Create system tests Develops system directed and constrained random tests. Create application checker The application checker verifies the high-level functionality of the system. Develop and integrate software Boot code, diagnostics, and hardware drivers can be developed and tested using the FVP. Create test harness The test harness connects everything and enables you to run a simulation with the correct configuration. Compile and link Defines the compile and link process where testing control is defined. Run tests and softwareDefines the run process and how to control the tests to run and their setup, scenarios, and configurations from the command line.

Debug the FVPDefines the process for verifying your FVP environment. Synchronize with the verification plan Monitors progress against the verification plan by promoting test, coverage, bug, and schedule reviews. BLOCK-LEVEL VERIFICATION Either after or concurrent with the creation of the FVP, one or more design blocks must be verified. Because designs are complex, SoC design practices require that functionality be split up into blocks with well-defined interfaces. A design block can be any logical or functional partition in the design. SoC design blocks are typically between 30-100K gates in size and are partitioned with well-defined or standard interfaces on the exterior. The steps associated with block-level verification are as follows: Perform static analysis on the block Describes the process for checking the RTL with a lint checker and assertion density evaluator before simulation is run. Accumulate testbench Describes the components needed to verify the block design, including transactors, interface monitors, response checkers, stimulus generators, and scoreboards. Some of these components need to be pre-planned in order to maximize acceleration performance later. Create or re-use tests Defines the directed and constrained random testing process. Add functional and interface assertions Defines the process of adding PSL structural checks, pre-existing protocol monitors, and checkers that check common design elements. All provide coverage information as well. Create test harness Defines the test harness, which connects everything and enables you to run a simulation with the correct configuration. Compile and link Defines the compile and link process where testing control is defined. Run tests and software Defines the run process and how to control the tests to run and their setup, scenarios, and configurations from the command line. Debug the block Defines the process for verifying your block-level design. Check code and functional coverage of the block Describes the process for performing code and functional coverage analysis. Accelerate block to smooth the path for system verification This outlines the process for getting the block ready for hardware acceleration. It confirms that the RTL can be synthesized into the hardware accelerator and will behave correctly when accelerated.

4 | Incisive Newsletter December 2004

 Synchronize with the verification plan Monitors progress against the verification plan by promoting test, coverage, bug, and schedule reviews. INTEGRATING A BLOCK INTO THE FVP Once a block has been verified in its own environment, it is ready to be placed in the system environment and tested against the FVP. Integrating a design block into the FVP is the next step in the flow. The steps associated with the integration of a block into the FVP are as follows: Modify test harness Adds the RTL block to the FVP Compile and link Defines the compile and link process where testing control must be defined Run the FVP tests and software Defines the run process and how to control the tests to run and their setup, scenarios, and configurations from the command line Debug the block in the FVP environment Defines the process for verifying your block-level design in the FVP environment Synchronize with the verification plan Monitors progress against the verification plan by promoting test, coverage, bug, and schedule reviews FULL-CHIP OR SYSTEM VERIFICATION The verification of a full chip or a system is an iterative process that focuses on the interconnection of blocks in the system. For example, you can start the process by connecting the processor to a couple of key blocks that transfer data. By doing this, these key blocks can be configured and basic data flow across these blocks can be tested. Next, attach another block and test its processor connection and the connection to one of the blocks in the testbench. This process continues until all blocks are integrated. The testbench evolves through this process. Throughout the debug process you are modifying and adding components, assertions, and tests to the testbench to further verify the full chip or system. The steps listed below outline the flow for a single iteration through the verification of the full chip or system. As you incrementally integrate blocks in the system, steps (such as accumulate testbench, create more tests, add more assertions, and add more coverage checks) are revisited to increase the functional coverage of the testbench. Accumulate testbench Describes the components needed to verify the block design, including transactors, interface monitors, response checkers, stimulus generators, and scoreboards. Some of these components need to be pre-planned to enable hardware acceleration at a later stage.

Create more tests Describes the process of testing functionality, interconnection of blocks, and corner cases using constrained random techniques. Create more assertions Defines the process of adding PSL structural checks and utilizing pre-made checkers that check functions and interfaces. Add more coverage checks Describes the process of adding functional coverage checkers (in some cases automatically obtained with assertion checkers). Integrate software HW/SW co-simulation is an important part of verifying the full chip or system. There is increasing competitive pressure to develop and integrate software (such as boot code, diagnostics, and hardware drivers) earlier in the cycle. Implement transaction-based acceleration Simulation acceleration combines a software simulator running on a workstation with a hardware accelerator. During simulation acceleration, the design under verification (DUV) is synthesized and realized in the accelerator while any non-synthesizable objects (testbenches, verification components, tests) are run on the software simulator. Create test harness Defines the test harness, which connects everything and enables you to run a simulation with the correct configuration. Compile and link Defines the compile and link process for both simulation and acceleration and defines testing control. Run full regression suite and software Defines the run process for both simulation and acceleration, and shows how to control the tests to run and their setup, scenarios, and configurations from the command line. Debug the chip or system Defines the process for verifying your full-chip design. Check coverage Describes the process for performing code and functional coverage analysis. Synchronize with the verification plan Monitors progress against the verification plan by promoting test, coverage, bug, and schedule reviews. Perform completion analysis Describes the process for reviewing the project and determining if the design is ready for tapeout. IN-CIRCUIT VERIFICATION The next logical step for systems that must be attached to hardware is in-circuit emulation. The AVF does not go into any more detail on the in-circuit verification step, because this step is a flow within itself.

Incisive Newsletter December 2004 | 5

REFERENCE DESIGN ENVIRONMENTS

To illustrate the AVF and highlight the advanced verification methodologies it promotes, we took an existing design and created top-down and bottom-up verification environments. The design project will be referred to as Eagle. The Eagle design is a networked video processing chip that can be used in a networked picture frame, for example. It is an SoC design that consists of multiple processors, hardware IP blocks, and firmware. HIGHLIGHTS Multiple processor implementation 2GB (total) external addressing for data, code, and video memory External SRAM and DRAM interface 56-bit encrypt/decrypt engine (DES) JPEG decompression engine Standard buses FEATURES Two 32-bit LEON RISC processors Controller DSP Decryption engine VGA controller AMBA AHB/APB-compliant internal bus 2-channel DMA controller with dual 10/100 Ethernet MACs Firmware for system control and JPEG decompression EXTERNAL INTERFACES Dual 10/100 Ethernet port VGA/LCD port Standard serial interface The internal block structure of the Eagle design is shown in Figure 2.

Encrypted and compressed video streams are passed to the chip over two Ethernet channels to corresponding Media Access Control (MAC) blocks. Inside each MAC block, the Ethernet frame is decomposed and the payload (video stream) is placed in a FIFO. The control processor runs firmware, hardware drivers, and applications. Software running on the processor controls the processing of video frames. The DMA block is programmed and transfers the video frame to the DES blocks FIFO. The DES block decrypts 64 bits of video using a 56-bit key. The DSP then decompresses the video image and renders it for VGA display. Following this transformation, the video image is streamed out the VGA port in rows to the monitor for display. CREATION OF THE TRANSACTION-LEVEL FVP For the Eagle design, the transaction-level FVP was created using the same block-level view as the planned RTL. Each block was either represented as a transaction-level model (TLM) in SystemC, or as an instruction set simulator (ISS) for the processing units. We created the TLMs to be functionally and register accurate. Because they are abstracted versions of the real design, they simulate very fast. We were able to develop software using this environment as well. There are two software routines that execute within Eagle. The first is the master controller firmware, which performs the main functions of controlling data transfers and housekeeping functions. The second program performs JPEG decompression. These programs are written in C, compiled for the appropriate machine architecture, and transformed into memory load files. The development of the transaction-level FVP allowed early development of the firmware. In addition, the TLMs were created with the expectation that they would be utilized as reference models in the RTL testbenches. Lastly, the verification components in this environment were reused later for the full-chip testbench. The FVP environment allowed us to create and debug parts of our testbench environment far earlier than we would have normally been able to. The testbench created for the transaction-level FVP is shown in Figure 3. Software and video images are loaded into the simulation. The DES, DSP, AHB, DMA, VGA, and memory are all TLMs.

Controller processor (VHDL)

DSP (VHDL)

DES (Verilog)

Memory

2 FIFOs

AMBA AHB DMA (Verilog) FIFO memory (8KB) MAC 1 (Verilog) FIFO memory (8KB) MAC 2 (Verilog)

Video RAM

AHB/Wishbone VGA (VHDL)

Figure 2: Eagle block-level structure

6 | Incisive Newsletter December 2004

Memory load ISS Code image DES DSP DES RTL

AHB

Code image VGA Memory Memory load AHB assertion monitor AHB DES TLM

Ethernet DMA MII Segmentor System test System test System test

VGA Video image Exp. video image

AHB master transactor

Response checker

JPEG image Scenario file Pass? Compare JPEG image Compare Pass? Test 1 Test 2 Random test JPEG image Segmentor

TLMs Transaction channel

VIP Verification IP

File

RTL Signal

TLMs Transaction channel

VIP Verification IP

File

Figure 3: Eagle transaction-level FVP

Figure 4: DES block-level testbench

The testbench works in conjunction with the software. Testbench components were created such that they could be reused in the RTL simulation. The segmentor component loads a JPEG image from a file. It then segments it into specific sized chunks and sends it to the system test. The system test packs it into an Ethernet frame and sends the Ethernet transaction to the Ethernet/DMA TLM. Software then controls the processing of video frames. There are two points of reference for the testbench to check that the system is working correctly. The first opportunity is after decryption occurs and the JPEG image is sent back out the Ethernet channels. This video image is compared against the expected JPEG image for correctness. The second opportunity is when the image is sent out of the VGA interface in RGB format. This RGB data is stored and compared against an expected image for correctness. The simulation will fail if either of these checks fails. BLOCK-LEVEL VERIFICATION In the Eagle design, the DES block was newly created and therefore required a block-level verification environment. Figure 4 illustrates the block-level testbench for the DES block. Encrypted images (with an encryption key) are fed into the DES block, decrypted, and then sent back to memory. The testbench consists of directed and constrained random tests; an AHB master transactor and assertion monitor; a response checker that utilizes the TLM from the FVP; and a segmentor that reads JPEG images into the testbench and segments them into payloads, which are bundled into Ethernet packets by the tests. The DES block has embedded assertions that check the design as it simulates and accumulate functional coverage statistics. This powerful testbench easily verified the DES block while reusing parts of the FVP and creating components and tests that can themselves be reused in the full-chip testbench.

INTEGRATING THE BLOCK INTO THE TRANSACTIONLEVEL FVP Once the FVP is created, RTL blocks that have been verified in a standalone testbench can be integrated with the system and run against the software. This is huge advantage to this methodology. If you are developing multiple blocks, you no longer have to wait for them all to be developed before you integrate them with the system environment. Each block can be integrated on it own and run with system tests and software. Figure 5 illustrates this phase.
Memory load ISS Code image DES RTL AHB master DSP

AHB

Code image VGA Memory Memory load

Ethernet DMA MII Segmentor System test System test System test

VGA Video image Exp. video image

JPEG image

Pass?

Compare

JPEG image

Compare

Pass?

TLMs Transaction channel

VIP Verification IP

File

Figure 5: Integration of the DES block into the transactionlevel FVP

Incisive Newsletter December 2004 | 7

In the Eagle design, we integrated the DES RTL into a transaction-level wrapper. This required the use of the AHB master transactor to translate the transactions being sent by the AHB TLM into the signal-level protocol on the DES block. The normal FVP systemlevel tests and software were then executed without modification to further test the DES block. VERIFICATION OF THE FULL CHIP By the time we approached the verification of the fullchip Eagle design, we had already created much of the verification environment. The transaction-level FVP, segmentor, system tests, and response checker from the other testbench environments were reused (unchanged) in the full-chip testbench. The full-chip testbench is illustrated in Figure 6.

Memory load Code image

Processor

DES

DSP

Memory load

AHB Code image MII master MII MII master MII System test System test System test VGA Ethernet DMA VGA

The same segmentor and system tests are reused from the FVP environment. These have already been debugged and work without modification in this environment. The system tests pass JPEG-packed Ethernet frames to the MII master transactor. The MII and VGA transactors had to be developed for this environment. The transactor passes the Ethernet frames to the MAC blocks via the signal protocol. Just like in the transaction-level FVP environment, the same two points of reference exist for the testbench to check that the system is working correctly. We used a response checker in both cases to compare actual results against expected results. We created a generic response checker that could be used to check different transactions. In this picture, there are two response checkers. One is being used to compare Ethernet frames from the design against expected Ethernet frames from the transaction-level FVP. The other is checking RGB data from the design against expected RGB also arriving from the FVP. Both response checkers are the same piece of code. We utilized the template construct in C++ to create one component that can be instantiated and used to compare different transactions arriving from different parts of the design. Our simulations at the full-chip level include the software. We were able to integrate the ISS into this environment by adding a master transactor at the interface to capture the reads and writes from the ISS and translate these into AHB reads and writes on the signals.

MII monitor

MII monitor

VGA monitor

Segmentor

MII response checker FVP

VGA response checker

JPEG image

Pass?

SUMMARY
RTL Signal TLMs Transaction channel VIP Verification IP File

Figure 6: Full-chip testbench

The practical application of the Advanced Verification Flow varies depending on the system being developed and the team doing the implementation. The AVF was developed in a modular way such that design and verification teams can adopt the methodology incrementally. If you have been struggling with response checking and do not create TLMs today, this might be one starting point for incorporating the AVF. But equally, there are two dozen other ways to start using the AVF incrementally in your own environment. Todays larger chips and shorter design cycles have been the impetus for Cadence to step up and provide technologies that remove the verification bottleneck. The Incisive platform provides key verification technologies such as the IUS simulator kernel, HAL, SystemC, SystemVerilog, PSL, the Incisive Assertion Library, the verification IP library, functional coverage, code coverage, and the SimVision debug environment. This powerful platform in conjunction with the Advanced Verification Flow makes the Cadence methodology-based solution very effective in solving a companys toughest verification challenges.

8 | Incisive Newsletter December 2004

The Cadence Methodology Engineering team has created a reference design to demonstrate the AVF and industry-wide leading-edge methodologies. This reference environment was created using a wide variety of techniques and technologies and is being used by customers as they adopt new techniques or technologies from the Incisive platform. Cadence offers the AVF on a CD that contains the following: AVF tutorial Documentation AVF description AVF user guide AVF detailed reference manual Reference design and examples Verilog/VHDL RTL source code with assertions SystemC testbench source code Verification IP AHB master, slave and monitor, MII master and monitor, and VGA monitor transactors DES and VGA response checkers Constrained random and directed tests Instruction set simulator SoC development project directory structure Scripts and Makefiles The Advanced Verification Flow provides a roadmap for verification, from project conception to system verification, and it can be adopted incrementally. It enables teams to start verification of their designs much earlier and enhances design checkpoints to isolate bugs quicker. This methodology promotes design reuse across the verification environments, thus requiring less code. The AVF maximizes verification effectiveness of your environment for each cycle run, providing more bang for your buck. It helps teams successfully develop and utilize advanced verification methodologies and associated techniques by example and with documentation. You can utilize the code, scripts, and infrastructure of the reference design to jump start your verification work.

REFERENCES
[1] Its About Time: Requirements for the Functional Verification of Nanometer-scale ICs; Lavi Lev, Rahul Razdan, and Christopher Tice; Cadence Design Systems white paper. [2] Professional Verification: A Guide to Advanced Functional Verification; Paul Wilcox, Boston: Kluwer Academic Publishers (KAP), 2004; ISBN: 1-4020-7875-7. [3] Principles of Functional Verification; Andreas S. Meyer; Elesevier Science, 2004; ISBN: 0-7506-7617-5.

RESOURCES
System-on-Chip Verification Methodology and Techniques; Prakash Rashinkar, Peter Paterson, and LeenaSingh; Kluwer Academic Publishers (KAP), 2001; ISBN 0-7923-7279-4. Advanced Verification Techniques; Leena Singh, Leonard Drucker, and Neyaz Khan; Kluwer Academic Publishers (KAP), 2004; ISBN 1-4020-7672-X. Writing Testbenches, Second Edition; Janick Bergeron; Kluwer Academic Publishers (KAP), 2003; ISBN 1-40207401-8.

Incisive Newsletter December 2004 | 9

03
PROCESSOR-BASED EMULATION
BY RAY TURNER, CADENCE DESIGN SYSTEMS
FPGA-based emulation is widely understood by engineers because they are accustomed to designing with FPGAs. Much less familiar are processor-based emulators and ample amounts of misinformation abound. This article will attempt to remove the mystery surrounding processor-based emulation and to explain how design constructs are mapped into it. each chain to an ALU, thus parallelizing the process and reducing the time required, perhaps to one half. A processor-based emulator has from tens of thousands to hundreds of thousands of ALUs, which are efficiently scheduled to perform all the Boolean equations in the design in the correct sequence. The following series of drawings illustrate this process. Step 1: Reduce logic to four input Boolean functions

PROCESSOR-BASED EMULATOR ARCHITECTURE

In the early 1990s, IBM pioneered a different emulation technology that was an offshoot of earlier work they had done in hardware-based simulation engines. To understand how a processor-based emulator works, it is useful to briefly review how a logic simulator works. Recall that a computers arithmetic-logic unit (ALU) can perform basic Boolean operations on variables (e.g., AND, OR, NOT) and that a language construct such as always @ (posedge Clock) Q = D forms the basis of a flip-flop. In the case of gates (and transparent latches), simulation order is important. Signals race through a gate chain schematically left to right so to speak, or top to bottom in RTL source code. Flip-flops (registers) break up the gate chain for ordering purposes.

Original circuit
A

F/F
Clock
CLK

C B E F

G H J S

M K L

F/F
Clock
CLK

F/F
Clock
CLK

C B E F

G H J S

M N K L

F/F
Clock
CLK

The set of Boolean equations after reducing the logic to four input functions is:
IF (Clock is rising) C = A S = C & B & E & F M = NOT (G + H + J + S) P = NOT (N + NOT (M & K & L) ) IF (Clock is rising) R = P

Additionally, the following sequencing constraint set applies:

A=B+CDE
Load E Invert AND D AND C OR B STORE A

6 CPU clock cycle

The flip-flops must be evaluated first S must be calculated before M M must be calculated before P Primary inputs B, E, and F must be sampled before S is calculated Primary inputs G, H, and J must be sampled before M is calculated Primary inputs K, L, and N must be sampled before P is calculated Note: primary input A can be sampled at any time after the flip-flops

Figure 1: Logic simulation CPU does Boolean math on signals and registers

One type of simulator, a levelized compiled logic simulator, performs the Boolean equations one at a time in the correct order. (Time delays are not relevant for functional logic simulation.) If two ALUs were available, you can imagine breaking the design up into two independent logic chains and assigning

10 | Incisive Newsletter December 2004

Step 2: Schedule logic operations among processors and time steps:

Time step Processor 1 Calculate C Processor 2 Sample B Sample E Sample F Processor 3 Sample G Sample H Sample J Sample K Calculate S Calculate M Receive M Sample L Processor 4 Processor 5 Calculate R Sample N

SPECIFIC TECHNOLOGY IN THE PALLADIUM SYSTEM

Each custom ASIC in a Palladium system implements a number of Boolean processors (see Table 1 below). These ASICs are assembled with additional memory dies onto a ceramic multi-chip module (MCM). Each Palladium emulation board contains a number of interconnected MCMs. A Palladium II system can have up to 16 emulation boards for a total of 884,736 processors. The memory on each MCM can be flexibly shared between modeling design memory and logic analyzer trace memory.

1 2 3 4 5 6 7 8 9 10

Palladium
Sample A Calculate P

Palladium II 768 2 55,296 884,736 16 million 256 million 8 74 9 5.3ns 600KHz1.5MHz 61,440 .07 1.4 billion

Processors per ASIC ASICs per MCM

256 1 16,640 266,240 8 million 128 million 3 68 8 7.5ns 300750KHz 4,224 .12 100 million

One possible scheduling is shown above. (This is done for illustrative purposes and does not necessarily reflect the most efficient scheduling.) Step 3: Result of scheduling logic:

Processors per board Processors per system (16 boards) Maximum gates per board Maximum gates per system Memory chips per MCM

F/F
Clock
CLK

C B E F

G H J S

M N K L

GBytes per system

F/F
R
CLK

Clock

Domains per board (# users/bd.) Processor cycle time

Processor 1 Step 1

Processor 2 Step 5

Processor 3 Step 6

Processor 5 Step 10

Processor 5 Step 1

Typical emulation speed Maximum I/O pins per system

In addition to having the Boolean equations represent the design logic, the emulator must also efficiently implement memories and support physical IP bonded-out cores. For simulation acceleration, it must also have a fast, low-latency channel to connect the emulator to a simulator on the workstation, since behavioral code cannot be synthesized into gates in the emulator. For in-circuit operation, the emulator needs to support connections to a target system and test equipment. Finally, to provide visibility into the design for debugging, the emulator contains a logic analyzer (which will be described in a future article).
High-speed RTL compiler Verilog and VHDL Behavioral C/C++ Incisive sim SystemC HDL

ASIC geometry (Leff) Transistors per MCM

Table 1: Comparison of the original Palladium system to Palladium II

The custom silicon for Palladium II systems is designed in-house and fabricated using IBMs 70-nanometer (Leff), 8-layer copper process (see Figure 3).

Palladium Workstation
Custom processor array High-speed co-simulation data pump Embedded logic analyzer High-speed in-circuit emulation interface

IP core hosting
Programmable memory array

FullVision Runtime control and debug environment

Figure 3: Palladium II processor module

Figure 2: Processor-based emulator architecture

Incisive Newsletter December 2004 | 11

During each time step, each processor is capable of performing any four input logic functions using as inputs the results of any prior calculation of any of the processors and any design inputs or memory contents. Processors are physically implemented in clusters with rapid communication within those clusters. The compiler optimizes processor scheduling to maximize speed and capacity.

inserted into the design to hold the state of the bus when no drivers are enabled. If multiple enables are on, then for pull-up and retain-state logic 0 will win, and for pull-down logic 1 will win. (Note: this is a good place to use assertions.) ASYNCHRONOUS LOOP BREAKING Since the Palladium system does not model gate-level timing (delays are 0), asynchronous loops are broken automatically by a delay flip-flop during compilation. The Palladium compiler will automatically break asynchronous loops without user intervention. However, by allowing the user to specify where loop breaks should occur, Palladium performance may be enhanced, since the performance of the Palladium system is related to the length of long combinatorial paths. By inserting delay elements to break false paths or multiclock-cycle paths, performance can be improved if these paths are the critical paths of the design. The breakNet and breakPin commands provide a way of breaking loops or paths without editing design sources. LONG COMBINATORIAL PATHS Palladium processors operate from an instruction stack of 160 words (Palladium II) or 256 words (Palladium). These are the time steps into which the design calculations are sequenced. Occasionally a design may include a very long combinatorial path that cannot be scheduled into 160/256 sequential steps. This does not necessarily mean that the path has more than 160/256 gates, as scheduling must take many time sequence constraints into consideration. In such a case, the scheduler will complete the path by scheduling the remaining Boolean operations in a second pass using the unused processor time steps. A design with a long combinatorial path can also be the result of trying to squeeze too many gates into an emulator, but, as a benefit, it provides a tradeoff between emulation speed and capacity.

DESIGN COMPILATION
Compilation of an RTL design is completely automated through the following sequence: 1. Map RTL code into primitive cells: gates, registers, etc. 2. Synthesize memories 3. Flatten the hierarchy of the design 4. Reduce Boolean logic (gates) into four input functions 5. Break asynchronous loops in the design by inserting a register at an optimal place 6. Assign external connections for the target system and any hard IP 7. Set up any instrumentation logic required (e.g., logic analyzer visioning) 8. Assign all design input and output to processors in a uniform way 9. Assign each cell in the design to a processor priority is given to assigning cells with common inputs and/or outputs to the same processor or cluster, and to assigning an equal number of cells to each processor 10. Schedule each processors activity into sequential time steps the goal is to minimize the total number of time steps The compiler also has to take into account simulation acceleration connections, tri-state bus modeling, memory modeling, non-uniform processor connectivity, logic analyzer probing and triggering, and other factors. But the Palladium compiler doesnt have to cope with the highly variable FPGA internal timing in FPGA emulators. For this reason processorbased emulation compiles much faster and with fewer resources. The compiler maintains all originally designated RT-level net names for use in debugging, in spite of the Boolean optimization it performs. This allows users to debug with the signal names with which they are familiar. (Clock handling in Palladium technology was presented in the last newsletter.) TRI-STATE BUS MODELING Tri-state buses are modeled with combinatorial logic. When none of the enables are on, the Palladium system gives the user a choice of pull-up, pulldown, or retain-state. In the latter case, a latch is

SUMMARY
Processor-based emulation has proven itself superior to FPGA-based emulation for every design goal or challenge: emulation speed, compilation speed, debug productivity, number of users, maximum capacity, and amount of memory (see Table 2). Compile speed is ten times faster on one-tenth the number of workstations minutes vs. hours. Emulation speed is faster on nearly all designs an average of 44% faster overall. The variety of debug vision choices provide much faster signal trace data display times six times faster on large designs. While FPGA-based emulators have been getting slower in emulation speed from generation to generation, processor-based emulators have been getting faster with each new generation.

12 | Incisive Newsletter December 2004

FPGA-based emulators Compile speed Emulation speed Predictable, reliable compiles Maximum capacity Ability to handle async. designs Takes many hours on many CPUs 150-600KHz Fair 30-120 million gates Good

Processor-based emulators 10-30 million gates/ hour on one CPU 600KHz-1.5MHz Excellent 256 million gates Good Found early in process Avoided completely

Partitioning problems Not found until individual FPGA compiles fail Timing issues in emulation model Potential for setup and hold issues and sublet, hard to find timing problems

Ability to make small Must dowload changes quickly entire FPGA

Can download incremental changes to processor

Table 2: Comparison of FPGA-based and processor-based emulators

Processor-based emulators have demonstrated that they are equally capable of handling a large number of asynchronous clocks in a design without suffering a performance impact. The ability of processor-based emulators to instantly probe new signals and change trigger conditions without requiring a slow FPGA compile greatly improves the interactivity of debugging. Processor-based emulators offer very precise control over input/output timing, which may be crucial for target environment interfacing. The Palladium systems unique ability to support JTAG ports for software debuggers, while using FullVision for the hardware, delivers the highest speed for software verification. The design experiments facility of processor-based emulators increases debugging productivity. Since users spend most of their design time debugging, processor-based emulators can deliver more design turns per day than FPGA-based emulators. These design benefits translate into shorter time to market for new products and higher product revenue.

Incisive Newsletter December 2004 | 13

04
THE INCISIVE ASSERTION LIBRARY
BY RAY SALEMI AND DAVE ALLEN, CADENCE DESIGN SYSTEMS
Assertion-based verification (ABV) is growing rapidly as engineers experience its many benefits. The value of ABV is immediately apparent to designers who easily find bugs that would have taken days to solve, and to verification engineers who can clearly see whether they have covered their test plans. ABV functions on the premise that defects are easier to fix when they are identified as soon after they happen as possible. For example, you are better off catching a FIFO overflow just as it happens, rather than trying to debug it once the wrong data has propagated to other blocks. Using assertions, designers can capture the intention of their designs (e.g., FIFOs should not overflow) and receive error messages if the design violates these intentions. While many engineers recognize the value of assertions, they often run into the chicken-or-theegg problem of schedules. They cannot afford the time to learn assertion languages like PSL, so they dont reap the time-saving benefits that would occur later. Cadence has developed the Incisive Assertion Library to help solve this problem. The Incisive Assertion Library (IAL) is a library of 50 Verilog/PSL modules that implement checks for common design structures. For example, there is an IAL element that will catch the FIFO overflow mentioned above. The IAL helps engineers in two ways: 1. Engineers can use the IAL modules as is and instantiate them into their designs. These engineers will immediately reap the benefits of assertions without needing to spend time learning PSL. 2. The IAL is delivered as Verilog source. Engineers can use these modules as templates to create new functions that were not shipped with the IAL. This article will explain how to instantiate Incisive Assertion Library modules into your design so you can quickly take advantage of assertion-based verification.

USING THE INCISIVE ASSERTION LIBRARY

The Incisive Assertion Library ships with the Incisive Unified Simulator, beginning with version 5.4. You can find it in your Cadence installation under the tools/ial subdirectory. To use the IAL in your designs, youll need to do the following: 1. Instantiate the IAL modules you want to use into your design. 2. Run simulation with the appropriate commandline switches to enable specific IAL features.

INSTANTIATING IAL MODULES

IAL modules are simply Verilog modules, and you can instantiate them in one of two ways: 1. You can instantiate the IAL modules inside of the module you want to test. With this approach, the IAL assertions will travel with the component youre testing, which may be useful if the block is re-used in other designs. 2. You can instantiate the IAL modules outside of the object you want to test. This allows you to use IAL modules without modifying the original RTL. Figure 1 is an example of the second instantiation method.

fifo #(DATA_WIDTH, ADDR_WIDTH, FIFO_DEPTH) .reset_n(resetn), .clk(clk), .wr_en(enque) .rd_en(deque) .wr_data(in_data) .rd_data(out_data) ); ial_fifo #(FIFO_DEPTH, DATA_WIDTH) .reset_n(resetn) .clk(clk) .rd_fifo(deque), .wr_fifo(enque), .data_in(in_data), .data_out(out_data) );

duv_fifo (

ial_c1 (

Figure 1: Instantiating an IAL element to test a FIFO

Instantiating this FIFO IAL module automatically gives you two of the significant benefits of assertion-based verification. You get assertions that catch errors and you get functional coverage. Well look at these more closely in the following sections.

14 | Incisive Newsletter December 2004

SIMULATING WITH IAL MODULES

Simulating with IAL modules is just like performing any other Verilog simulation. You simply compile the IAL modules along with the rest of your design, with the appropriate command-line switches. If you invoke your simulation using the single-step ncverilog command, youll need to add the following to your command line:
-v <path to IAL library>/ial.v +assert

ASSERTIONS IN INCISIVE ASSERTION LIBRARY ELEMENTS

The FIFO IAL elements contain the assertions shown in Figure 2.

The -v option specifies that the ial.v library file should be compiled with the rest of your design. The +assert option enables the PSL assertions in the Incisive Assertion Library. So, your simulation command would look like this:
ncverilog -v <path to IAL library>/ial.v +assert <rest of the sim. command line>

If you use the three-step ncvlog-ncelab-ncsim command, youll need to add the following to your ncvlog command line:
<path to IAL library>/ial.v -assert

Your ncvlog command line would look like this:

ncvlog <path to IAL library>/ial.v -assert <rest of the ncvlog command line>

Figure 2: Assertions in the FIFO IAL elements

The IAL modules have additional capabilities that can be enabled at compile time. In the first version, some modules have additional coverage information and can use a global reset signal. Table 1 shows the additional capabilities and the command-line switches needed to enable these capabilities:
Description Enable coverage assertions Define a global reset signal ncverilog switch +define+IAL _COVERAGE_ON +define+IAL_GLOBAL _RESET=<reset signal> ncvlog switch -define IAL _COVERAGE_ON -define IAL_GLOBAL _RESET=<reset signal>

Lets look at the ial_fifo_overflow assertion as an example. This assertion catches an error when the FIFO receives a write even though it has set its full signal to true. The code for this assertion is as follows:
psl property ial_fifo_overflow = never ( ((fifo_level == FIFO_DEPTH && (`IAL_RESET_SIGNAL)) && (({rd_fifo, wr_fifo}) == 2b01) ); psl assert ial_fifo_overflow;

Table 1: Additional IAL module capabilities

For the global reset signal, <reset_signal> is the full hierarchical name of the signal you want to use.

This assertion states you should never see that the FIFO has reached its depth and receives a write signal. If you see this situation, then someone else is misusing the FIFO. In this case, the Incisive Unified Simulator will print the following error message:
Ncsim: *E, ASRTST (time 4850 ns) Assertion top.duv.ial_c1.ial_fifo_overflow has failed

This is a good example of the firewall techniques many designers use in their blocks. Designers place assertions at the input pins to their block to ensure that they are getting correct input. This can help reduce debug time designers can quickly determine if a defect is actually in their block or caused by incorrect input.

Incisive Newsletter December 2004 | 15

FUNCTIONAL COVERAGE
The Incisive Assertion Library also automatically creates a test plan for the module being checked by creating functional coverage points. The functional coverage points for the FIFO example are represented in Figure 3.

INCISIVE ASSERTION LIBRARY ELEMENT LIST

The IAL contains 50 elements that introduce assertions to many common design elements. Figure 4 shows the list of elements scheduled for release in January 2005:
BASIC TYPES ial_tristate ial_one_hot ial_one_cold ial_zero_one_hot ial_active_bits ial_valid_bis ial_constant ial_next ial_always ial_never ial_range ial_bitcnt ial_gray_code ial_hamming_dist ial_mutex ial_timeout INTERFACE TYPES ial_follower ial_leader ial_seq ial_width ial_window ial_stall ial_together ial_handshake DATAPATH TYPES ial_arith_overflow ial_crc ial_decoder ial_encoder ial_decr ial_incr ial_max ial_min ial_delta ial_serial2parallel ial_parallel2serial ial_even_parity ial_odd_parity CONTROL TYPES ial_mem_access ial_mport_mem_access ial_stack ial_eq_seq

INTERFACE+CONTROL TYPES ial_outstanding_id ial_fifo ial_mclk_mport_fifo ial_multiplexer ial_arbiter ial_case_check ial_req_gnt_ack ial_var_time_seq ial_eq_frame

Figure 4: Comprehensive assertion library

Figure 3: FIFO functional coverage points

SUMMARY
As you can see, you can now tell whether you have tested the FIFO at its corner cases. The IAL element automatically tracks how many times youve performed certain tasks, like read from it, written to it, and filled it you automatically have a complete functional test plan for the FIFO. The Incisive Assertion Library functional coverage points are supported by the Incisive platform and can be read and analyzed using Incisive functional verification tools. The Incisive Assertion Library is the fastest way to take advantage of the benefits of assertion-based verification. When you instantiate IAL elements, you immediately begin reaping the benefits of ABV without needing to learn PSL. When the time comes for you to create your own PSL-based checkers, IAL components will serve as a template to get you started.

16 | Incisive Newsletter December 2004

05
INCISIVE DEBUG AND ANALYSIS TIPS
BY RICK MEITZLER, CADENCE DESIGN SYSTEMS
Did you know that SimVision enables you to synchronize time ranges between multiple waveform windows? That you can save time ranges and use them in any waveform window? Or that you can customize the zoom toolbar to display larger zoom buttons? All of these features are available in SimVision release IUS5.3 by simply using the zoom toolbar in the waveform window, represented in Figure 1.

Figure 1: Waveform zoom toolbar

WAVEFORM TIME RANGE LINKING

Employing the linking feature on the waveform window allows you to open multiple waveform windows that display different signals, but all at the same time range. When you change the time range on one waveform window (either by zooming or moving to a different time range), the corresponding time will display on all other linked waveform windows. Just to the left of the time range entry in the toolbar is an icon with a broken link. Clicking this icon drops down a menu that lists all currently open waveform windows. By clicking on the window names in the menu, you can link the time ranges in the current window to the other windows (see Figure 2).

Figure 2: Linking waveform time ranges

SAVING TIME RANGES

Another useful feature of the zoom toolbar is the ability to save time ranges and use them in all of the waveform windows. When you drop down the time range menu, you have the option to keep the current time range (see Figure 3).

Figure 3: Time range menu

Incisive Newsletter December 2004 | 17

A dialog box will appear, allowing you to name your time range and, if desired, change the start and end times (see Figure 4). After you save a time range, that time range will be available in all waveform windows in the dropdown menu.

CHANGING ZOOM BUTTONS

When the zoom toolbar is updated to include the above functionality, the zoom controls automatically change to a new format that conserves space and displays smaller zoom buttons. If you prefer the larger zoom buttons, however, they are still available to you through toolbar customization. First, select View>Toolbars>Customize to bring up the toolbar customization dialog, shown in Figure 6.

Figure 4: Time range dialog

The time range menu also gives you the option to edit time ranges. When you select this option, a properties window will appear and allow you to modify the time ranges (see Figure 5). The in-place editing option on the properties page enables you to rename time ranges and change the start and end times.

Figure 6: Toolbar customization dialog

Once this dialog box is open, check the Zoom box in the left pane. The right pane will list all the items on the toolbar that can be modified (see Figure 7). If you want to hide the new compressed zoom buttons, simply clear the checkbox labeled zoom_controls and then check the box next to the zoom buttons you want to show. As you check or uncheck boxes, the window will preview how the new toolbar will look.

Figure 5: Editing a time range in the properties window

Figure 7: Modified zoom toolbar

As you can see, the zoom toolbar on the waveform window has a number of handy options in a small space. For more information about the various features of SimVision release IUS5.3, please refer to our online SimVision documentation.

18 | Incisive Newsletter December 2004

INCISIVE PLATFORM NEWS AND EVENTS

PRESS RELEASES New Palladium II Extends Cadence Acceleration/Emulation Leadership
October 25, 2004 Cadence Delivers Unparalleled Speed and Capacity to Tackle the Most Complex SoC Verification

NEW COLLATERAL White paper: Accelerated Hardware/Software Co-verification Speeds First Silicon and First Software
http://www.cadence.com/whitepapers/Coverification_wp.pdf

Demonstration: Cadence Palladium II Accelerator/Emulator

http://www.demosondemand.com/clients/cadence/014/dod_ page/previews.asp#4

Cadence Announces Comprehensive Assertionbased Verification Solution

October 18, 2004 Expanded Support of PSL and SystemVerilog Assertions Enables More Efficient Verification

WORKSHOPS This quarter, Cadence is offering the following Incisive platform workshops:
Developing a SystemC Testbench

Cadence Incisive Conformal Technology Becomes Standardized Solution for Fujitsu Worldwide
September 7, 2004 Deployment Helps Fujitsu Speed Time to Market and Maximize First Silicon Success of Highly Complex Chips for Multimedia, Consumer and Communications Applications

Developing Self-checking Designs Using Assertions

WEBINAR Using Assertions to Check Your Designs

This webinar focuses on ways to increase the efficiency of verifying your complex HDL code. http://www.cadence.com/webinars/webinars.aspx?xml=abv

Incisive Newsletter December 2004 | 19

Cadence Design Systems, Inc. Corporate Headquarters 2655 Seely Avenue San Jose, CA 95134 800.746.6223 408.943.1234 www.cadence.com

2004 Cadence Design Systems, Inc. All rights reserved. Cadence, the Cadence logo, Conformal, NC-Verilog, Palladium, and Verilog are registered trademarks and Incisive is a trademark of Cadence Design Systems, Inc. All others are properties of their respective holders.

5693 12/04