A Practical Solution to Fixing Netlist X-Pessimism

Similar documents
Reset and Initialization, the Good, the Bad and the Ugly

Leveraging Formal Verification Throughout the Entire Design Cycle

Accelerating CDC Verification Closure on Gate-Level Designs

Advanced FPGA Design Methodologies with Xilinx Vivado

Recommended Design Techniques for ECE241 Project Franjo Plavec Department of Electrical and Computer Engineering University of Toronto

Bulletproofing FSM Verification Automated Approach to Detect Corner Case Issues in an FSM Design

101-1 Under-Graduate Project Digital IC Design Flow

Constraint Verification

Mapping Multi-Million Gate SoCs on FPGAs: Industrial Methodology and Experience

Addressing Verification Bottlenecks of Fully Synthesized Processor Cores using Equivalence Checkers

Choosing an Intellectual Property Core

Accelerating RTL Simulation Techniques by Lior Grinzaig, Verification Engineer, Marvell Semiconductor Ltd.

FishTail: The Formal Generation, Verification and Management of Golden Timing Constraints

Synthesizable Verilog

Verification of Clock Domain Crossing Jitter and Metastability Tolerance using Emulation

ACCELERATING DO-254 VERIFICATION

Hardware Design Environments. Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University

EE 5327 VLSI Design Laboratory Lab 8 (1 week) Formal Verification

Challenges in Verification of Clock Domain Crossings

FT-UNSHADES credits. UNiversity of Sevilla HArdware DEbugging System.

Optimizing Blocks in an SoC Using

Design Creation & Synthesis Division Avoid FPGA Project Delays by Adopting Advanced Design Methodologies

TOPIC : Verilog Synthesis examples. Module 4.3 : Verilog synthesis

Best Practices for Incremental Compilation Partitions and Floorplan Assignments

8. Best Practices for Incremental Compilation Partitions and Floorplan Assignments

VHDL. VHDL History. Why VHDL? Introduction to Structured VLSI Design. Very High Speed Integrated Circuit (VHSIC) Hardware Description Language

SP3Q.3. What makes it a good idea to put CRC computation and error-correcting code computation into custom hardware?

Chapter 5: ASICs Vs. PLDs

Ten Reasons to Optimize a Processor

CS232 VHDL Lecture. Types

ADVANCED DIGITAL IC DESIGN. Digital Verification Basic Concepts

A Brief Introduction to Verilog Hardware Definition Language (HDL)

Two HDLs used today VHDL. Why VHDL? Introduction to Structured VLSI Design

VHDL for Synthesis. Course Description. Course Duration. Goals

Comprehensive CDC Verification with Advanced Hierarchical Data Models

The Verilog Language COMS W Prof. Stephen A. Edwards Fall 2002 Columbia University Department of Computer Science

Custom Design Formal Equivalence Checking Based on Symbolic Simulation. Overview. Verification Scope. Create Verilog model. Behavioral Verilog

Next-generation Power Aware CDC Verification What have we learned?

Overview of Digital Design with Verilog HDL 1

Beyond Soft IP Quality to Predictable Soft IP Reuse TSMC 2013 Open Innovation Platform Presented at Ecosystem Forum, 2013

Definitions. Key Objectives

DESIGN STRATEGIES & TOOLS UTILIZED

Reuse MATLAB Functions and Simulink Models in UVM Environments with Automatic SystemVerilog DPI Component Generation

Formal Verification: Not Just for Control Paths

Chapter 9. Design for Testability

On-Chip Design Verification with Xilinx FPGAs

Functional Programming in Hardware Design

Sunburst Design - Verilog-2001 Design & Best Coding Practices by Recognized Verilog & SystemVerilog Guru, Cliff Cummings of Sunburst Design, Inc.

Lecture 9. VHDL, part IV. Hierarchical and parameterized design. Section 1 HIERARCHICAL DESIGN

Introduction to VHDL. Module #5 Digilent Inc. Course

Universal Asynchronous Receiver/Transmitter Core

Boost FPGA Prototype Productivity by 10x

System Verification of Hardware Optimization Based on Edge Detection

EE595. Part VIII Overall Concept on VHDL. EE 595 EDA / ASIC Design Lab

Early Models in Silicon with SystemC synthesis

Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions

Mixed Signal Verification Transistor to SoC

Programmable Logic Devices HDL-Based Design Flows CMPE 415

An Evaluation of the Advantages of Moving from a VHDL to a UVM Testbench by Shaela Rahman, Baker Hughes

Visual Design Flows for Faster Debug and Time to Market FlowTracer White Paper

Nikhil Gupta. FPGA Challenge Takneek 2012

Assignment. Last time. Last time. ECE 4514 Digital Design II. Back to the big picture. Back to the big picture

Digital Systems Testing

Finding Reset Nondeterminism in RTL Designs Scalable X-Analysis Methodology and Case Study

ECE 4514 Digital Design II. Spring Lecture 20: Timing Analysis and Timed Simulation

HECTOR: Formal System-Level to RTL Equivalence Checking

18. Synopsys Formality Support

High-Level Information Interface

Formal Verification of ASIC Design

Digital Design LU. Lab Exercise 1

Applications Note. HDL Simulation FPGA Design Methodology. October 15, Revision 1.0

Cover TBD. intel Quartus prime Design software

Is Power State Table Golden?

Automated Formal Verification of X Propagation with Respect to Testability Issues

Design Guidelines for Optimal Results in High-Density FPGAs

Formal Technology in the Post Silicon lab

RTL Coding General Concepts

Sunburst Design - Comprehensive SystemVerilog Design & Synthesis by Recognized Verilog & SystemVerilog Guru, Cliff Cummings of Sunburst Design, Inc.

Shortest path to the lab. Real-world verification. Probes provide observability

Digital Design Methodology (Revisited) Design Methodology: Big Picture

Introduction to Partial Reconfiguration Methodology

Certitude Functional Qualification with Formal Verification. Jean-Marc Forey November 2012

Optimizing Emulator Utilization by Russ Klein, Program Director, Mentor Graphics

Overview. CSE372 Digital Systems Organization and Design Lab. Hardware CAD. Two Types of Chips

High Quality, Low Cost Test

VERIFICATION OF RISC-V PROCESSOR USING UVM TESTBENCH

ECE 587 Hardware/Software Co-Design Lecture 11 Verification I

Administrivia. ECE/CS 5780/6780: Embedded System Design. Acknowledgements. What is verification?

TSEA44 - Design for FPGAs

EECS150 - Digital Design Lecture 5 - Verilog Logic Synthesis

LSN 1 Digital Design Flow for PLDs

EECS150 - Digital Design Lecture 6 - Logic Simulation. Encoder Example

Lecture 32: SystemVerilog

ECE U530 Digital Hardware Synthesis. Course Accounts and Tools

Eliminating Routing Congestion Issues with Logic Synthesis

CHAPTER 1 INTRODUCTION

RTL Power Estimation and Optimization

קורס VHDL for High Performance. VHDL

INTRODUCTION TO VHDL. Lecture 5 & 6 Dr. Tayab Din Memon Assistant Professor Department of Electronic Engineering, MUET

You will work in groups of four for the project (same groups as Project 1).

Transcription:

A Practical Solution to Fixing Netlist X-Pessimism Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis, since gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X s) that were not seen in RTL due to X-optimism, and additional X s in the gate-level simulations due to X-pessimism. This paper focuses on the issues of X-pessimism at the netlist level. X-pessimism is described, current solutions are discussed, and an Ascent XV- Netlist solution is presented. X-pessimism and X-optimism Defined The presence of X s can cause both X-optimism in RTL simulations and X-pessimism in netlist simulations. X-optimism can result in the failure to detect functional bugs at RTL. X-pessimism typically makes it hard to get netlist simulations up and running quickly. X-pessimism occurs in gate-level designs when an X signal at the input of some digital logic causes the simulation output to be an X value, even though in real hardware the value will be deterministic, e.g. a 1 or 0. Figure 1 shows a very simple example. When the value of in1 and in2 are both 0, the simulation value at the output is 0, as it would in hardware. But when the input value is an X, and the values of in1 and in2 are both 1, the simulation value at the output is X in simulation but is 1 in real hardware. This behavior is called X-pessimism because the known value simulates as an unknown. More specifically, we say it is 1-pessimistic because the output should have been a value of 1. Input=X D=input*in1 + ~input*in2 D X CLK Figure 1. X-pessimism example showing an X results when the values of signals in1 and in2 are both 1. X-optimism is the opposite, when an unknown value is simulated as though it is a known value in hardware. Consider the example shown in figure 2 below. If the input signal is an X value,

that means that input could be either a 0 or a 1 value in real hardware because real hardware does not have an X value. So in real hardware, signal D might also be a 0 or a 1 value. However, in simulation, the output D would always show as a 1 value. It is called optimism because the unknown was resolved as a known value. This can cause functional bugs to be missed in RTL simulations, though in netlist the X would always be properly propagated. Input=X if (input) D=1; else D=0; CLK D 1 Figure 2 X-optimism example showing an input value of X produces a 1 result. The above are very simplistic examples. In real designs the logic cone of the cloud is often very complex, with the selected output being driven by a logic expression and the input also being a logic expression. In this case, sometimes the output X value is a result of pessimism and sometimes it is simply the propagation of an X that was optimistic in RTL. One can be artificially corrected without harm, but the other could be a bug lurking to be discovered. Refer to X- Propagation Woes A Condensed Primer 1 for more details. Commonly Used Quick Fixes There are three approaches that we hear being used for addressing X-pessimism, all with downsides. The approaches are 1) eliminating all X s in the design, 2) artificial random initialization of uninitialized flops, and 3) manual drudgery. The first common approach for eliminating all X s is to add a reset to all memory elements. This eliminates the most common source of Xs uninitialized flops. However, synchronous resets can sometimes cause pessimism issues to be introduced during the synthesis process. Also, other sources of X s do exist in a design, such as explicit X-assigns for flagging illegal states, bus contention, and out of range references, among others. A more significant issue is that extra resets eat into power, size, and routing budgets. Resettable flops are larger, more power hungry, and require additional routing resources. Resetting all flops is practical only for smaller designs, and does not address all sources of X. The second common approach is to artificially randomize the initialization of uninitialized memory elements at time 0. The issue with this approach is that while it will help simulations, it will not necessarily match real hardware. It also does not address all sources of X in a design. X-optimism bugs that were masked in RTL will likely be artificially masked again in netlist simulations. This risk of missing a bug that was masked by optimism in RTL and artificially

removed at netlist, may result in a critical bug being missed. These days, with the high costs of manufacturing and heaven forbid, recalls, the downside for a failure can be very expensive. The third approach is to manually analyze the root cause of all X-differences between the outputs of RTL and gate-level simulation, and then determine the correct value and time to force and release pessimistic nodes. This can be very difficult to do because a gate-level design is a transformation of an RTL design into something that is more complex, has a different structure, and has unfamiliar signal names. It can be very time consuming to chase down those pessimistic X s in the netlist simulation. The issue is exacerbated when there is a mixture of X differences from both optimism and pessimism, with pressure to get it fixed as soon as possible and not accidently miss a real bug. For large designs, this effort can take months. Existing approaches fall short in that they do not address pessimism caused by X s from all sources, they can mask issues in the gate-level simulations due to X-optimism in RTL simulations, and they are insufficient to handle the largest SoC designs. Introducing Ascent XV Netlist If a node is determined to be 1(or 0) pessimistic, that means its real circuit value is 1(or 0), but simulation produces an X. A pessimistic simulation value can be corrected by forcing a 1(or 0) on the node until the conditions for pessimism no longer hold, at which time, it is released. This does not mean that all X s can be arbitrarily forced to a known value. Only X s that result from pessimism should be forced, and they must be forced to represent the deterministic value that real hardware would see and released immediately when the pessimism stops. Ascent XV-netlist makes your simulation hardware accurate by appropriately correcting pessimism. Ascent XV statically identifies the potentially pessimistic nodes and then uses that information to create SimPortal files that augment gate-level simulation to correct X-pessimism on the fly. By doing the analysis statically before the simulation starts, the number of nodes that must be analyzed during simulation is significantly reduced. Also, the X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X- value. The SimPortal files monitor the potentially pessimistic nodes in the design on the fly, independent of the testbench. A bottoms-up hierarchical static analysis can also be done at the block level. When all the blocks are integrated for full chip simulations, a very scalable solution is achieved. The SimPortal is designed for performance, and also minimizes compile time and memory overhead. You can control the verbosity at simulation time, and can choose to drop back to simple monitoring or even turn off both the correction and monitoring at any point in time. The flow and methodology is shown below in Figure 3.

Netlist Static Pessimism Analysis SimPortal Generation Ascent XV SimPortal SimPorta Files Simulation (VCS/Questa/IES) Simulation Logfile Pessimism Log Figure 3 Ascent XV X-Pessimism Flow and Methodology Ascent XV X-pessimism Flow and Methodology: 1. Run static analysis to determine which data input values can cause monitored nodes to exhibit pessimism. Generate design-specific SimPortal data files. 2. Run SimPortal simulation to find out which nodes experienced the input combinations that cause pessimism. The Ascent XV solution is characterized as follows: Performance o Gate-level simulation overhead is as low as 2x-2.5x o Memory overhead is 0.5x o Negligible overhead to compilation time o Simulation time configuration of verbosity from totally quiet to full details o Can choose to turn off correction at any point in time (such as after reset) Capacity o Unique approach easily handles next generation full chip netlists (billion gate SOCs) Accuracy o Only does forces when pessimism is occurring.

o The value forced is the value that will be seen in real hardware. Ease of Use o No setup required o Testbench independent static analysis o No need to touch the existing design or testbench, only the simulation script In RTL, X s can hide functional bugs due to X-optimism. These bugs will be brought to light in netlist gate simulations. Unfortunately, X s also cause X-pessimism in netlist simulations, making it difficult to determine whether a functional mismatch is due to X-optimism, X- pessimism, or something else entirely. Ascent XV Netlist will remove X s caused by X- pessimism, removing the major source of simulation RTL and netlist simulation differences. Related Considerations Reliable correcting of pessimism at the netlist has become very feasible, thanks to Ascent XV. But there is additional analysis that can be done early in the RTL development process to prevent potential X-issues. This will benefit the post-rtl handoff, whether it is gate-level simulations or FPGA modeling of your design, so you are not debugging X-optimism issues in hard to debug environments. Ascent XV- Reset Optimization minimizes significant X s in the design that result from incomplete initialization. Ascent XV Reset Optimization will do a hardware accurate reset analysis that will report where additional resets are needed; as well suggest where resets can be removed. It ensures complete initialization, taking into account the propagation of known values to avoid adding extraneous resets. The goal is to minimize X-issues during the design of the RTL. In the case of simulations, fewer occurrences of pessimism will speed your simulation. Ascent XV-RTL Optimism analyzes where the X-sources of a design are, as well as where they can cause X-optimism. This ensures hardware accurate simulations at RTL either by eliminating the X-source, or through coding for X-accuracy. Hardware accurate RTL simulations will make the RTL-netlist simulation outputs easier to compare, but more significantly, it will make FPGAbased modeling easier to get up and running. Summary Once a design is synthesized, the immediate goal is to get gate-level simulations up and running fast. Unfortunately, X s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X s generally exist in all designs it can be difficult to prevent this for practical reasons. Simulation results may be different because of X s that are hidden in the RTL simulation by X-optimism, or additional X s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.

Ascent XV- Netlist Pessimism corrects X-pessimism on the fly so the simulation is hardware accurate. Use of Ascent XV saves in the time required to get gate-level simulations started by an order of magnitude. It is proven to be superior to alternative approaches in the marketplace in terms of performance, memory, and accuracy. Its ease of use and capacity, make it the only practical solution for large SOCs. Author Lisa Piper is Senior Manager of Technical Marketing at Real Intent. References 1. X-Propagation Woes A Condensed Primer. Lisa Piper, Real Intent. 2. X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist. Lisa Piper, Vishnu Vimjam. DVCon 2012.

2024 © technodocbox.com Privacy Policy | Terms of Service | Feedback