Rajesh K' Gupta

1
ASP-DAC 1998 TUTORIAL Part IV Validation and
Test Techniques DRAFT

• Rajesh K. Gupta
• University of California, Irvine.

2
Agenda

• Validation strategies
• Simulation basics
• Co-Simulation
• Emulation
• Test Challenges
• Summary

3
Validation Strategies

• Validation concerns
• functional verification
• that the IC/system has been designed correctly
• parametric (performance) verification
• that the part has been fabricated and
  manufactured to meet timing specs
• field testing
• that the part is operating correctly
• production test
• that the part has been manufactured correctly.

4
Simulation As A Modeling Activity

• A model consists of two components
• representation of structure -- abstraction
• description of structure -- resemblance
• Simulation based modeling is prevalent due to
  availability of powerful computing resources
• Mostly rule-driven

5
Types of Simulation Programs

• Time Based
• Notion of a tick
• Assume arrival of events in a tick is not
  important
• Underlying synchronous model
• The algorithm
• initialize
• repeat
• T Tt
• Generate events
• Process events independently
• until T gt Tmax
• Example
• operation of a CPU IF, ID, OF, EX, WB stages

6
Types of Simulation Programs contd.
Event Based

• Main control loop represent a single event
• Efficient since no actions until events are
  generated
• The algorithm
• initialize
• repeat
• determine next event
• T T_nextevent
• case nextEvent
• Event 1
• generate next event
• ...
• update statistics
• until no more events
• Example simulation of a floppy drive

7
Mixed Domain Simulations

• Time-based and event-based simulations
• simultaneous event processing versus
  one-event-at-a-time
• ordering of events
• Parts of system modeled using either mechanisms
• Example
• CPU versus peripherals (floppy)
• Integration of diverse parts into a single system
  leads to model heterogeneity
• use more general models, or
• use coordination languages such as Granular
  Lucid, Linda, Statemate.

8
Co-Simulation

• Simulation of systems with mix of
• hardware, software components
• analog elements, digital elements
• Co-simulation is an important co-design tool
• Co-simulation can be done at either the modeling
  level or at the system implementation level
• modeling level using heterogenous models such as
  imperative programs, finite state machines,
  process networks, discrete event components,
  data-flow blocks.
• implementation level consists of machine code,
  asic hardware, gate-level blocks, analog models.

9
Co-Simulation Difficulties

• Different system components run at different
  levels of abstraction (use different levels of
  data), run at different speeds and are triggered
  by different sets of events
• analog components operate over voltages and
  currents and time, digital logic operates over
  binary values, and microprocessors operate over
  instructions.
• a microprocessor may take one or more cycle to
  execute an instruction, during which time analog
  or digital devices may go through several changes
  of state

10
Modeling Detail vs. Simulation Time

• Basic objective of simulation is two monitor
  behavior and performance of a system
• There is a tradeoff between the degree of detail
  used in modeling the system and the time required
  to carry out the simulation.
• hardware modules can be modeled either as SPICE
  circuits, switch-level or behavioral blocks
• software modules can be modeled at the level of
  stacks, queues or at the operating system level
  or more abstractly as protocol layers.

11
Model Development
There are two important dimensions of time

• Simulation time and model development time
• Model development is labor intensive.
• Model reusability is important
• several companies are in the business of just
  providing simulation models, e.g., LogicModeling,
  VHDL models for DSP cores etc.
• Simulation time depends upon strategy chosen for
  mixed domain simulations
• PTOLEMY
• Program-driven simulations

12
Scheduler Coordination Across Domains
Ptolemy

• Unified simulation framework
• Particular model of computation referred to as a
  design style
• Domain as objects consisting of
• blocks (as a design style)
• operational semantics for blocks
• targets
• a scheduling discipline
• programming in C
• Example domains SDF, DE, Thor.

13
Scheduler Coordination (contd.)

• Domain types timed (DE), untimed (DF)
• untimed domains do not have an absolute time
  scale associated with the events generated
• Basic mechanism
• events and event horizon
• domain encapsulation and hierarchy
• simulation and conservative restrictions

A domain
B domain
scheduler
scheduler
event horizon
14
Scheduler Coordination
Four cases of event propagation

• 1. Untimed to untimed
• 2. Timed to untimed
• 3. Timed to timed
• 4. Untimed to timed
• Untimed domains react in zero time.
• Outer untimed domains maintain timing attribute
  that is used to set the stop time of the inner
  domains.
• Use stopping heuristics to ensure that inner
  domains do not temporally get ahead of the outer
  domains.
• An event from untimed domain initiates a time
  scale on which future events of a timed domain
  are carried out until the inner domain has no
  more events left.

15
Co-Simulation With A Processor CoreThe Logic
Modeling Approach
Memory Image File
Netlist
Confg.
Simulator
structural config. format
16
Available Co-Simulation Environments

• Ptolemy (UC Berkeley)
• SPW (Alta/Cadence)
• Bones
• Polis
• Mentor Graphics DSP workstation
• Seamless
• COSSAP
• Synopsys
• plus other university offerings.

17
Emulation and Prototyping

• Discrete event modeling for system simulations is
  attractive because
• one can model system at almost all
  levels(behavior, RTL, gate, transistor)
• incorporate heterogeneous simulation domains
• However, it is slow
• due to event interpretation and management
• separate contexts leads to enormous overheads
• simulation time increases rapidly with the design
  detail and data set
• Some application domains operate on large data
  sets
• e.g., video processing over multiple frames.
• Hardware emulation offers a way to improve
  simulation performance.

18
Emulation

• refers to the process of imitation of a system by
  another system.
• can be stand-alone or in-circuit (that is the
  imitated object is a part of another system)
• Uses programmable hardware
• Software maps a design into hardware
• Can be used at all levels of design
• in-circuit emulation (ICE) and software
  development
• logic level simulation
• architectural exploration
• Issues
• how much performance is gained versus simulation?
• what is the emulation system cost?
• how much extra design effort is involved?

19
Simulation Performance

• Algorithmic level
• programming language descriptions using ISA
  models run need about 10-100 instructions per
  cycle or run at 1M-100M cycles/sec on 100 MIPS
• Architecture level
• HDL models using functional blocks need 1K-10K
  instructions per cycle or run at 10-100K
  cycles/sec
• RTL level
• HDL models using RTL primitives run need about
  1M-10M instrs. per cycle, or run at 10-100
  cycle/sec
• Logic level
• HDL/Netlist models using logic gates need about
  10M-100M instructions/cycle, or run at 1-10
  cycles/sec.

Realistic application simulation requires 1M
cycles/sec.
20
Emulation Using FPGA Hardware

• Logic blocks mapped to pre-design FPGA blocks on
  PC board(s)
• 10K-325K gates/FPGA
• FPGA interconnect direct or through FPICs(
  Aptix)
• interfaces to integrate other system components
• bus exerciser, sockets, daughter boarder, memory,
  emulation frameworks etc.
• Field programmability (as opposed to MPGA) costs
• x10 density
• x5 performance
• Vendors Xilinx, Altera, Actel, ATT, ...

21
Emulation System Software
Used for

• HDL compilation tasks
• high-level partitioning
• Technology mapping to bind netlist gates to FPGA
  primitive cells
• Design optimization and analysis
• logic synthesis, timing analysis
• Support system simulation
• input stimulus
• monitor response (for a logic analyzer, etc.)

22
Emulation System Examples

• Quickturn Enterprise System
• uses a partial cross-bar interconnect topology
  between FPGAs
• Aptix
• uses programmable interconnects between FPGAs
• Virtual Wires
• uses software to multiple pins

Compare this to simulation speeds table in
Part II of the tutorial!
Courtesy P. Subrahmanyam
23
Emulation Benefits and Costs

• (Five) order of magnitude speed up over SW
• run OS, applications
• debug hardware, application development platform
• Costs
• Quickturn 2/gate gt M
• Virtual Wires 0.5/gate (slower)
• Significant design effort
• Needs
• better compilation for hw/sw, incremental
  compilation
• low cost emulation alternatives.

24
Test Strategy for Firm/Hard Cores

• System-level test strategy
• build test sets for cores
• generate functional vectors
• fault grade for interconnects
• prepare cores for test application from primary
  inputs through access/isolation, Scan/DFT
• if BIST, schedule BIST application and signature
  analysis.
• System-level DFT
• goal is to reduce testing cost
• increase accessability of the internal nodes
• controllability ability to establish a specific
  signal value at each node from primary inputs
  (PIs)
• observability determine signal value by
  controlling Pis and observing primary outputs
• tradeoffs area, I/O pins, performance, yield, TTM

25
DFT Techniques

• Commonly used approach is to modify a sequential
  circuit into a combinational one during test.
• Automatic test generation is much easier for
  combinational circuits
• Current monitoring techniques.
• For sequential circuits, scan techniques are
  often used
• link memory elements into a shift register
• serially load and read out
• boundary scan is commonly used to test
  board-level devices
• Built-In Self Test
• minimal external support, high fault coverage,
  easy access requirements, protect IP

26
Test Access for Cores

• Peripheral access techniques
• parallel access, serial access or functional
  access
• Parallel access
• add MUXs to connect core IOs, high routing
  overhead, pin limitations may prevent parallel
  access
• Serial access
• most common is ring approach, during test core
  I/Os are connected via a scan chain, low
  overhead, delay penalty, easy to test
  user-defined logic, long test application time
• Functional access
• sensitize path through cores, low hardware cost,
  parallel test pattern translation possible.
• Also need isolation mechanisms for cores.

27
Summary of Part IV

• Simulation models are flexible and detailed.
• Co-simulation based on
• domain encapsulation
• (conservative) coordination rules.
• Emulation using programmable hardware speeds up
  validation speeds to allow development of
  applications in limited cases
• costs, additional design efforts.