Wolfgang Roesner - PowerPoint PPT Presentation

1 / 46
About This Presentation
Title:

Wolfgang Roesner

Description:

Wolfgang Roesner. Verification Tools Development. IBM Corp. Austin, TX. Logic Simulation : ... Modeling Levels - A Taxonomy of HDL Constructs. General Purpose ... – PowerPoint PPT presentation

Number of Views:88
Avg rating:3.0/5.0
Slides: 47
Provided by: bruce48
Learn more at: https://www.cse.psu.edu
Category:

less

Transcript and Presenter's Notes

Title: Wolfgang Roesner


1
Logic Simulation Languages, Algorithms,
Simulators
  • Wolfgang Roesner
  • Verification Tools Development
  • IBM Corp
  • Austin, TX

2
  • Outline
  • Hardware Design Languages
  • Modeling Levels - A Taxonomy of HDL Constructs
  • General Purpose HDL Simulators - Event-Driven
    Sim
  • Improving Simulator Performance
  • Synchronous Design Methodology and Cycle-Based
    Sim
  • Let's Design a Cycle-Based Simulator

3
  • Simulation of Hardware Design Languages
  • Logic or "functional" simulation today is done
    mostly with HDLs (Hardware Design Languages)
  • Most popular languages today (both are IEEE
    standards)
  • Verilog
  • VHDL
  • Verilog
  • logic modeling and simulation language
  • started in EDA industry (start-up) in the 80's
  • was acquired by Cadence
  • donated to IEEE as a general industry standard
  • approx. 60 market share in U.S. EDA market
  • VHDL
  • committee-designed language contracted by U.S.
    (DoD) (ADA-derived)
  • functional/logic modeling and simulation language
  • approx. 40 market share in U.S. EDA market

4
  • Modeling Levels - Highest Level Interface
  • Let's look at the common constructs we use to
    specify the functionality of a piece of
    hardware

input behavior over time
output behavior over time
t
5
  • Modeling Levels - Major Dimensions (I)
  • Temporal Dimension
  • continous (analog)
  • gate delay (psec?)
  • clock cycle
  • instruction cycle
  • events
  • Data Abstraction
  • continuous (analog)
  • bit multiple values
  • bit binary
  • abstract value
  • composite value ("struct")

6
  • Modeling Levels - Major Dimensions (II)
  • Functional Dimension
  • continuous functions (e.g. differential
    equations)
  • Switch-level (transistors as switches)
  • Boolean Logic
  • Algorithmic (eg. sort procedure)
  • Abstract mathematical formula (e.g. matrix
    multiplication)
  • Structural Dimension
  • Single black box
  • Functional blocks
  • Detailed hierarchy with primitive library
    elements
  • A good VHDL-centric taxonomy can be found at
    http//rassp.scra.org

7
  • Modeling Levels - Major Dimensions (III)

Temporal
Data
Functional
Structural
8
  • Coverage of Modeling Levels - Verilog

Temporal
Data
Functional
Structural
9
  • Coverage of Modeling Levels - VHDL

Temporal
Data

Functional
Structural
extremely inefficient compared to Verilog
10
  • In HDL Terms
  • VHDL, Verilog were both defined as simulation
    languages
  • Big emphasis on the structural refinement
  • VHDL entity/architecture/component/port/signal
  • Verilog module/instance/port/signal/reg
  • Specification of function
  • General programming language constructs
  • VHDL user-defined data type, package,
    procedure, function, sequential code
  • Verilog function, task, sequential code
  • Parallelism
  • VHDL process, signal update, wait
  • Verilog "always" block, fork/join, wait, event
    construct
  • Special purpose H/W constructs
  • VHDL concurrent assignment, delayed assignment,
    signal, Boolean logic
  • Verilog continuous assignment, 4-value Boolean
    logic, switch-level support

11
  • General HDL Simulators
  • Before we can look at architectures of simulators
    we need to understand the execution model that
    the HDLs imply
  • VHDL's execution model is defined in detail in
    the IEEE LRM (Language Reference Manual)
  • Verilog's execution model is defined by Cadence's
    Verilog-XL simulator ("reference implementation")

12
  • An event-driven VHDL example

Block 1
Block 2
13
  • A more hardware-oriented example

sum_out(1)
s(1)
s(0)
a
c(0)
sum_out(0)
b
carry_out
14
  • A more hardware-oriented example

sum_out(1)
s(1)
0
s(0)
1
a
c(0)
sum_out(0)
1
b
carry_out
1
15
  • A more hardware-oriented example

sum_out(1)
0
1
s(1)
s(0)
1
a
c(0)
sum_out(0)
1
b
carry_out
1
16
  • A more hardware-oriented example

sum_out(1)
0
1
1
s(1)
s(0)
1
a
c(0)
sum_out(0)
1
b
carry_out
1
17
  • A more hardware-oriented example

sum_out(1)
0
1
1
1
s(1)
s(0)
1
a
c(0)
sum_out(0)
1
b
carry_out
1
18
  • A more hardware-oriented example

sum_out(1)
0
1
1
1
s(1)
s(0)
1
1
a
c(0)
sum_out(0)
1
1
1
b
carry_out
1
1
19
  • A more hardware-oriented example

sum_out(1)
0
1
0
1
s(1)
s(0)
1
1
a
c(0)
sum_out(0)
1
1
1
1
b
carry_out
1
1
20
  • A more hardware-oriented example

sum_out(1)
0
1
0
0
s(1)
s(0)
1
1
a
c(0)
sum_out(0)
1
1
1
1
b
1
carry_out
1
1
21
  • A more hardware-oriented example

sum_out(1)
0
1
0
0
s(1)
s(0)
1
1
a
c(0)
sum_out(0)
1
1
1
1
b
1
carry_out
1
1
1
22
  • A more hardware-oriented example

23
  • A more hardware-oriented example

carry_out
0
1
0
0
c(1)
s(0)
1
1
a
c(0)
sum_out(0)
1
1
1
1
b
carry_out
1
1
1
1
1
24
  • Event-Driven Simulation
  • The simulator maintains
  • a list of all atomic executable blocks
  • a data structure that represents the
    interconnect of the blocks via signals
  • a value table that holds all current signal
    values
  • At start time the simulator schedules all
    executable blocks of the models

25
  • Core-Architecture of an Event-Driven Simulator

26
  • Improving Simulation Speed
  • The most obvious bottle-neck for functional
    verification is simulation throughput
  • There are two basic ways to improve throughput
  • Simulator performance
  • Running many simulations in parallel
  • Parallelization
  • Hard parallel simulation algorithms
  • much parallel event-driven simulation research
  • has not yielded a breakthrough
  • hard to compete against "trivial parallelization"
  • Simple run independent testcases on separate
    machines
  • Workstation "SimFarms"
  • 100s - 1000s of engineer's workstations run
    simulation in the background
  • ideal parallelization factor

27
  • Improving Simulator Performance (I)
  • Full-HDL support
  • If full cover of VHDL/Verilog is important
  • Optimizing compiler techniques
  • treat sequential code constructs like general
    programming language
  • all optimizations for language compilers apply
  • data/control-flow analysis
  • global optimizations
  • local optimizations (loop unrolling, constant
    propagation)
  • register allocation
  • pipeline optimizations
  • etc. etc.
  • Global optimizations are limited because of
    model-build turn-around time requirements
  • Example modern microprocessor is designed w/
    1Million lines of HDL
  • Imagine the compile time for a C-program w/ 1M
    lines!

28
  • Improving Simulator Performance (II)
  • Full-HDL support
  • Better scheduling algorithms
  • scheduling is clearly the bottle-neck in all
    event-simulators
  • Use hybrid techniques
  • some of the simplifications discussed in the
    following can be applied to localized "islands"
    of HDL.
  • requires an HDL compile process that
    automatically analyzes the structure of the model
    and uses "speed-up" modes for sub-partitions
  • Problem
  • assume 50 of the model has such islands
  • even if we could speed up simulation of those
    parts to take 0 time, we would only gain a
    speedup factor of 2x

29
  • Improving Simulator Performance (III)
  • Simplifications
  • Use higher-level HDL specification

30
  • Improving Simulator Performance (IV)
  • Principles of using higher-level HDL
    specification
  • Common theme cut down of number of scheduled
    events
  • create larger sections of un-interrupted
    sequential code
  • use less fine-grain granularity for model
    structure
  • -gt smaller number of schedulable blocks
  • use higher-level operators
  • use zero-delay wherever possible
  • methodology implications timing verification is
    not done together with functional simulation
  • Data abstractions
  • use binary over multi-value bit values
  • multi-value use only for bus contention
    situations to resolve several drivers with
    different strengths (strong, resistive,
    high-impedance)
  • use word-level operations over bit-level
    operations
  • NEXT Most Powerful - methodology-based subset
    of HDLs

31
  • Synchronous Design Methodology
  • Clock the design only so fast the longest
    possible combinational delay path settles before
    cycle is over
  • Cycle time depends on the longest topological
    path
  • Hazards/Races do not disturb function
  • Longest topological path can be analytically
    calculated w/o using simulation -gt stronger
    result w/o sim patterns

32
  • Logic Design Groundrules
  • Synchronous design
  • LSSD design for testability
  • Critical delay path defines the clock frequency
  • Behavioral Function and Timing Correctnesscan be
    verified independently
  • Design can be verified independently of its
    implementation
  • -gt Logic Synthesis
  • -gt Custom Design
  • -gt Synthesizable, high-level HDL as main vehicle
    for functional verification
  • IF Boolean Equivalence Checking proofs closure
    between functional an implementation view
  • Functional Verification can use zero-delay
    functional simulation
  • --gt Cycle-Based Simulation, FSM-based Formal
    Verification

33
  • Functional View of Synchronous Designs
  • Logic mapped to a non-cyclic network of Boolean
    functions
  • Network also constains state-holding primitives
    latch/reg/array
  • HDL does not contain any timing information
  • Function can be evaluated by zero-delay signal
    evaluation
  • --gt Speed of Simulation Simplicity of Tools

34
  • Cycle Simulation Algorithm

Logic is ordered into levels so that order of
evaluation is correct. E.g., A and B are computed
before C.
A
C
B
35
  • Why Is This Faster?

As an example, let's assume we compile our
circuit into a stream of pseudo instructions....
36
  • Methodology Flow

37
  • Network of Boolean Equations/Operators

38
  • Storage Elements
  • Latch Inference for sequential HDL
  • if there is a possible set of signal evaluations
    that leave the value of a signal undefined -gt
    that signal is assumed to be a storage element
  • Verification Logic Synthesis must interpret HDL
    the same way (check with Boolean Equivalence
    Checking)

39
  • Implementation Options For Cycle Sim
  • HDL Compilation
  • Evaluation Sequence
  • Function Evaluation

40
  • HDL Compilation Options For Cycle Sim
  • Preserve the HDL structures
  • Compile HDL like a programming language
  • Preserve design hierarchy, processes, modules,
    functions, procedures
  • Implementation process very similar to
    programming language compilers
  • Incremental processing is trivial
  • Model optimization is hard (cross-functional
    boundary) and limited
  • Map HDL to library of primitive functions (e.g.
    IBM "Texsim")
  • Crush design hierarchy to increase optimization
    potential
  • Synthesis-like process, but simpler because of
    missing physical constraints
  • Incremental model build is very hard
  • Designer view of hierarchy must be preserved for
    model debug process

41
  • Evaluation Sequence Options For Cycle Sim
  • Oblivious Evaluation
  • For every cycle, evaluate all Boolean logic
  • Minimal amount of book-keeping and runtime
    control data structures
  • Large amount of redundant evaluation for large
    models with low change activity
  • Event-Driven Evaluation
  • Evaluate changes only
  • Minimize redundant work for low-activity models
  • Book-keeping overhead (But use synchronicity
    constraint)
  • Hybrid Techniques (example Texsim)
  • Use design partitions as base granularity for
    event-driven evaluation
  • Use key controling signals as guards for
    event-driven evaluation

42
  • Function Evaluation Options For Cycle Sim
  • Interpreted
  • Map design network into an efficient data
    structure which a simulator walks at run-time
  • Model is data, highly portable
  • Few successfull examples where interpretation ofn
    a datastructure didnt add significant
    performance loss due to indirection
  • Compiled (example Texsim)
  • Map design network into a sequence of
    instructions
  • Generating C-source is not an
    industrial-strength option
  • Model consists of machine-instructions,
    platform dependent
  • Many programming language compiler optimizations
    apply, but the problem is simpler (more
    constrained)

43
  • IBM's Texsim simulator
  • Flattening of the hierarchy
  • Network optimizations - using levelized network
  • Constant propagation
  • DeMorgans law and other Boolean optimizations
  • Equivalent function removal
  • Merging of functions with only one fanout
  • Final levelization
  • Structural analysis and logic partitioning (e.g.
    latch-partitioning, below
  • Create model symbol table and allocate value
    table
  • Compile logic by partition and level
  • Generate reference history for use by register
    allocation
  • Generate machine independent code perform
    peephole optimization
  • Perform instruction scheduling
  • Generate target machine object code

44
  • Orders of Magnitude in Speed
  • These numbers are supposed to give you intuitive
    feel
  • The actual numbers depend on many other factors
  • Model activity rate
  • Test bench activity implementation language
  • Multiple clock domains

Event Simulator
1
Cycle Simulator
20
Event driven cycle Simulator
50
Acceleration
1000
Emulation
100000
45
  • We could write a simulator now...
  • But we have not talked about many areas
  • Model-Build software principles (how to make
    gigantic model in minutes)
  • Simulator user interface (how to talk to user and
    to programs)
  • How a cycle simulator deals with multi-value
    signals
  • do we need those ? Yes, mainly for bus logic and
    power-on-reset sim
  • How do we take the cycle-sim algorithm and
    implement in special purpose hardware
    simulation acceleration, emulation
  • Where is there still a need for pure
    event-simulation?
  • Good research only few papers in the field
    during the last 10 years
  • Good place to start is Peter Maurer at Florida
    State. Extremely interesting for folks who want
    to explore different algorithms

46
  • And...
  • This field is just one segment of verification
    tools development which is just one segment of
    Electronic Design Automation
Write a Comment
User Comments (0)
About PowerShow.com