Download presentation
1
Sungho Kang Yonsei University
Verification Sungho Kang Yonsei University
2
Outline Hardware Acceleration Emulation Co-Verification
Formal Verification
3
Why Simulation Engine Speed up difficulty in software simulation
Acceleration Speed up difficulty in software simulation Parallel Processing Multi-processing Pipelining Array Processing Hardware Implementation Simulation Engine / Hardware Accelerator Compiled Event Driven Multi-Processor Array
4
Simulation Engine Performance
Acceleration
5
TEGAS Accelerator Acceleration
6
TEGAS Accelerator Acceleration Functional Level Block Diagram
7
TEGAS Accelerator Acceleration Accelerator Update Processor
8
TEGAS Accelerator Acceleration Accelerator Evaluation Processor
9
TEGAS Accelerator Acceleration Accelerator Time Queue Processor
10
Yorktown Simulation Engine
Acceleration Compiled
11
Yorktown Simulation Engine
Acceleration Partitioning of 256 PUs Each PU simulates a subcircuit consisting of up to 4k gates Specialized PU for RAMs and ROMs All PUs are synchronized by a common clocks PU can evaluate a gate during every clock cycle Partitioning Minimize the waiting time Control processor : host to YSE
12
Yorktown Simulation Engine
Acceleration Logic Processor PC provide the index to the next gate to be evaluated (compiled) Signal values(0,1,X,Z) are stored in data memory Up to 4 inputs for each gate Generalized DeMorgan Code(GDM) 16 functions of 4 valued variables Evaluation is done in zoom table
13
AAP-1 Acceleration
14
AAP-1 Acceleration Processing Element
15
What is Emulation? Turnkey rapid prototyping systems
Read users design and automatically partition & map to array of FPGAs Enable user to run at system level and verify with application software Full internal visibility to debug - thousands of probes Modify design in minutes
16
Bugs Found with Emulation:
Functional ASIC bugs Board/system-level bugs Software, firmware bugs Synthesis bugs Bugs that require rich, real-world stimulus or high throughput to find Bugs caused by spec. misinterpretation
17
Comparison with Co-simulation
Emulation Performance potential of simulation accelerator is not achievable with current testbench strategies Speed of testbench (workstation) Channel latency & bandwidth Frequency of communication Design under test execution speed
18
Comparison with FPGA FPGA High chip capacity Slow compilation
Emulation FPGA High chip capacity Slow compilation Low I/O to gate ratio Emulation Fast compile speed Productive debugging High I/O to gate ratio On-board logic analyzer Generic FPGAs used for emulation Unpredictable capacity and highly variable routing delays with poor debuggability
19
Anatomy of an Emulator Emulation
20
Emulator Architecture
Emulation Hierarchical Multiplexed Architecture Simplifies Design Mapping Process
21
Definition A logic emulator is a system of
Emulation A logic emulator is a system of Programmable hardware with capacity much greater than one FPGA Software which automatically programs the hardware according to a gate level design representation Software and hardware to support operation and analysis of the emulated design as a component in real hardware
22
System Overview : SW Components
Emulation Design compiler Netlist reader and parser : Reads and parses gate-level design netlists Technology mapper : Maps design components into optimal emulator equivalents System-level Partitioner and Placer : Partitions mapped design into boxes, boards, ultimately into FPGA netlists. System-level Interconnect router : Determines the programming of interconnect hardware to complete nets cut by the partitioner FPGA compiler : Reads each FPGA netlist, maps, partitions, places and routes FPGA. Timing Analysis(optional) : Analyzes compiled design on emulation hardware for speed, hold violations. Runtime download and analysis controller. Graphical User Interface Hardware diagnostics
23
System Overview : HW Components
Emulation Logic emulation boards : FPGAs and interconnect chips Memory emulation boards : RAMs, FPGAs and interconnect. System interconnect board : chips which interconnect emulation boards. I/O Connectors and Pods : connects to in-circuit interfaces, external components. Instrumentation : stimulus generator, logic analyzer, vector interface. Controller : downloads configurations, operates instruments. Interface : to host computer.
24
Advantages of Emulation
Emulation performance is not a function of design size Deep Sub-micron Zone Emulation Point of Emulation Simulator Accelerator Cycle-based Simulator Time to Verify Design
25
Disadvantage of Logic Emulation
Hardware emulation system is required Speed is 5-10 X slower than real design speed System emulation speeds of 1 to 4 MHz are common today Target system must be slowed down for emulation Delays do not match those of real design Timing-induced errors are possible, that is, hold-time violation Delay independent functionality may not operate correctly
26
Logic Emulation FPGA-based Hardware Emulation
Contain a large pool of general purpose logic block Design preparation time and compilation time are costly Processor-based Hardware Emulation An array of basic CPUs or simple Boolean processors that perform basic logic operation on a time sharing basis Design under verification is converted into a simulation data structure, similar to that of a software simulator Slower than FPGA-based
27
Mixed Implementation Co-verification P
28
Co-Design Co-verification Integrated design of systems implemented using both hardware and software components Why Advances in enabling technologies System level specification / simulation High level synthesis and CAD frameworks Advanced design methods required due to the increased diversity and complexity Cost and performance of HW/SW systems should be optimized for market competitiveness Produce-to-market time is vital Exploiting concurrency among design threads and tools will result in significant gains Difficulties Target moves (e.g. in size and complexity) Tolerance level for error decreases
29
Co-Design Integration of HW and SW design techniques Advantages
Co-verification Integration of HW and SW design techniques The HW and SW components are interdependent HW and SW are typically described and design using different methodologies, languages and tools Advantages Acceleration of the design process Lengthy system integration and test phase can be avoided Dynamic HW/SW trade-offs in the design process Co-design methodologies differ widely Widely differing assumptions Interface/communication techniques Design goals Example types A microprocessor and its associated glue logic A microprocessor and special-purpose computing engine
30
Co-Simulation Co-verification Simulation of heterogeneous systems whose HW and SW components are interfacing Roles of co-simulation Verification of system specification before system synthesis Verification of mixed system after system synthesis and integration System performance estimation for system partitioning Issues of HW-SW co-simulation Timing accuracy Processor model Performance Interface transparency Transition to co-synthesis Integrated user interface and internal representation
31
Reason for Co-simulation
Co-verification Processor transition to embedded core No existing hardware Increased software content Software controls more functions Development and debug times increased More complex hardware interfaces Processor interactions with DSP Processor interactions with increasingly complex hardware
32
Reason for Co-Simulation
Co-verification Design problem found Something wrong due to logic error Problem is visible, but not apparent in hardware Found while running software Brings SW and HW together
33
Co-Design Problems Instruction set processors ASIP
Co-verification Instruction set processors Codesign to design well-balanced long-lasting processors Instruction set selection Cache design Pipeline control HW mechanism : flush the pipelines SW solution : reorder instructions or insert no operation ASIP SW : retargetable code generation for ASIP data path HW : library binding High performance Desirable programmability Low unit cost than ASIC Embedded systems and controllers Real time systems with peripheral devices (sensors, actuators)
34
Co-Design Methodologies
Co-verification Automation of conventional codesign clear early binding easy design decisions
35
Co-Design Methodologies
Co-verification Model-based codesign late partitioning/binding after refining easy to handle design changes component reuse modular hierarchical models
36
HW-SW Partitioning Performance requirements
Co-verification Performance requirements Some functions may need to be implemented in HW The overhead of synchronization and data transfer should be considered Implementation costs HW can be shared Modifiability SW can be easily changed Nature of computation Some function may have an affinity for either HW or SW Degree of data parallelism
37
HW-SW Partitioning Software-preferred Task which calls OS often
Co-verification Software-preferred Task which calls OS often Hardware-preferred Arithmetic operation High degree of data parallelism Multiple threads of control Customized memory architecture
38
Performance Estimation
Co-verification At a low abstraction level Easy and accurate Long iteration time At a higher level of abstraction Necessary to reduce the exploring time Currently quick and dirty Goal : quick and accurate Performance and cost estimation is important for HW-SW partitioning and for HW/SW synthesis/optimization
39
Complexity Trends Rapidly Growing Design Size
Formal Rapidly Growing Design Size Doubling of million-gate designs 50% reduction in designs under 500K gates 3X reduction in designs under 100K gates Shrinking Process Geometries Nearly 10X reduction in .5 micron designs Most designs going to .35 micron or below Architectural Complexity Before: simple instruction pipelines, single functional units, simple stalls/holds, simple caches/TLBs, protocols at the pins Now: deep instruction pipelines, super-scalar design, multiple (pipelined) functional units, instruction re-circulate, speculative execution, complex stalls/holds, complex protocols on chip and at the pins, integration of external IP
40
Informal Verification
Simulation Compare against an executable version of the specification, also know as THE GOLDEN MODEL Simulate in software Simulate in hardware Test cases Hard-written by the designers Randomly generated test vectors
41
Trends : Verification Problem
Formal Number of test vectors proportional to design complex Simulation cannot guarantee correctness Confidence based on proportion of design space explored Hardware, software systems are becoming increasingly complex Number of basic components growing exponentially Designs are increasingly aggressive
42
Why Formally Specify? Formal Showing that a property holds globally of the entire system Want to characterize the correctness conditional can promise the user of my system Want to show this property is really a system invariant Error handling Want to specify what happens if an error occurs Want to specify the right thing happens if an error occurs Want to make sure this error never occurs Completeness Want to make sure that I’ve covered all the cases, including error cases, for this protocol Like to know that this language I’ve designed is computationally complete
43
What to Specify? Correctness conditions Invariants
Formal Correctness conditions Invariants Observable behaviors Properties of state entities
44
Formal Specification Formal A concise description of the behavior and properties of a system written in a mathematically-based language Specifies what a system is supposed to do as abstract as possible Eliminating distracting detail and providing a general description resistant to future system modification
45
Formal Verification Mathematically proves correctness
Shows specification satisfies requirement properties Shows implementation satisfies the properties required by specification Higher performance Use symmetry and decomposition Collapse sets of similar behaviors into a single cases
46
Definitions Formal Verification:
Use of mathematics to automate logic verification Formal, mathematical proof that circuit = specification Specification: A trusted description of any portion of a circuit’s behavior Equivalence Checking: Formal tool that proves whether a circuit description is functionally equal to a reference circuit description Model Checking: Formal tool that proves whether a particular functional design detail operates as specified
47
Definition of Formal Verification
Formal verification is proving that the functions in the specification are the same as the functions in the implementation The proof is done mathematically not experimentally Functional Correctness Any piece of hardware is functionally correct if we can somehow prove that its implementation realizes the specification
48
Correctness Preserving Transformation
Formal Useful when intergrating verification and automated synthesis in a cooperative approach to correct design Takes a correct implementation of a specification and derives another correct implementation Generates design alternatives to improve the quality of some original solution Proves the equivalence of two hardware descriptions
49
Disadvantages of Formal Verification
Often difficult to apply Tend to take too long Verify what is specified Gap between abstraction and real implementation One can only verify what is specified Discrepancies between the ideal and real worlds Assumption about the environment
50
Verification Paradigms
Formal Equivalence Checking Consider implementation and specification The specification and implementation are equivalent in a suitable sense Requires complete specification Property Verification (Model Checking) The specification consists of a set of properties that are to be proved about the implementation model Assumes that the implementation is functionally correct for the typical cases and that the goal is to discover the infrequently occurring corner cases that result in deadlocks, access conflicts, etc.
51
Temporal Logic A special type of Modal Logic, a branch of philosophy
Formal A special type of Modal Logic, a branch of philosophy Provides a formal system for qualitatively describing and reasoning about how the truth values of assertions change over time A useful formalism for specifying and verifying correctness of computer programs
52
Temporal Logic Consider time and temporal evolution
Formal Consider time and temporal evolution Introduces the concept of possibility and necessity in the future Can capture time and dynamic behaviors and avoid the introduction of explicit time function Races and hazards can be represented Includes all usual connectives and adds some typical operators Henceforth Eventually Next Until
53
Theorem Proving Formal A theorem prover is based on a logic - a formal language for stating mathematical propositions A logic is equipped with a proof system - a set of axioms and inference rules that make it possible to reason in a step-by-step manner from premises to conclusions Depending on how powerful the logic is, the proof system may or may not be complete Most theorem provers are interactive, requiring guidance from the user in order to generate proofs
54
Combining Formal and Informal
Goals Should fit into existing verification methodology Robust graceful degradation with increased design complexity Better coverage than simulation/FV Highly automated Hybrid Use formal techniques and exhaustive simulation Try to balance proof power and computational efficiency Enumeration on a restricted set of variables
