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