A TLM Design-for-Verification Methodology

1
A TLM Design-for-Verification Methodology
University of Verona Dep. Computer Science Italy

• Nicola Bombieri

Research activity partially supported by the
FP6-2005-IST-5-033709 VERTIGO European Project
2
Agenda

• Motivations
• Transaction Level Modeling (TLM)
• TLM levels
• TLM-based design and verification flows
• TLM advantages
• Todays challenges in TLM
• Design challenges
• Verification challenges
• Conclusions

3
Agenda

• Motivations
• Transaction Level Modeling (TLM)
• TLM levels
• TLM-based design and verification flows
• TLM advantages
• Todays challenges in TLM
• Design challenges
• Verification challenges
• Conclusions

4
Motivations
up to 500,000,000 transistors (2006)
Design complexity
Manufacturing costs
Time to Market
up to 80 due to verification
5
Motivations
Does it really work?
Standard functionalities
Corner cases
Timing constraints
Environment constraints
Manufacturing bugs
6
Motivations
Classical design flow
Functional specif.
Architect. specif.
SW develop.
Sys integration
Sys validation
Design
Fab.
Breadboard
Functional specifications failures?
Performance expectations missing?
Main reason lacking of a concretely usable view
of the complete system before the tape-out phase!
Re-spins!
7
Agenda

• Motivations
• Transaction Level Modeling (TLM)
• TLM levels
• TLM-based design and verification flows
• TLM advantages
• Todays challenges in TLM
• Design challenges
• Verification challenges
• Conclusions

8
Transaction Level Modeling (TLM)

• Transaction-level is the new level of design and
  verification above RTL.

TLM
Abstraction
TLM


RTL
Synthesis
9
Transaction Level Modeling (TLM)

• Enabling Software development to start very early
  in the design flow

Classical design flow
Functional specif.
Architect. specif.
SW develop.
Sys integration
Sys validation
Design
Fab.
Breadboard
GAIN!
SW develop.
Sys integration
Sys validation
10
TLM Levels
Level Use Features Abstraction
PV (Programmers View) Executable specification Proof of concepts Event-driven Untimed Data types Time Resource sharing
PVT (Programmers View Time) HW/SW partitioning Performance estimation Event-driven with time estimation Clocks Protocols
CA (Cycle Accurate) Detailed modeling Cycle accurate tesbenches Cycle accurate Wires Registers
RTL Signal level modeling for synthesis Pin accurate Gates Delays
11
TLM Modeling Comparison

• More emphasis on the data transfer functionality
• less on their implementation details at the early
  design stage

write (data, addr)
12
TLM-based Design Flow
PV system
M1
Untimed functional verification
Specifications (UML, Matlab, C/C)
M5
M2
M3
M4
HW/SW partitioning and refinement
PVT system
M1
Timed functional verification Performance
analysis
M5
SW component
M2
M3
M4
HW component
Refinement
Cycle accurate verification Performance analysis
CA system
M1
M5
M2
M3
M4
13
TLM-based design flow (II)
Cross-comp.
DRAM
CPU
SRAM
CA system
M1
M5
BUS
M2
M3
M4
FPGA
ASIC
System-on- Chip (SoC)
Synthesis
14
TLM-based design IP re-use (III)
DRAM
CPU
SRAM
M1
system
M5
M2
BUS
M3
M4
FPGA
ASIC
NB Reuse ? Modularity
e.g., Digital Signal Processor (DSP) MPEG, Coder,
Decoder, Filters, etc.
15
Mixed-level verification the transactor
write(addr,data) read(addr, res)
clk
clk
(write_status)
Control inputs
RTLsignals
Data inputs
(read_status)
Control outputs
RTLsignals
Data outputs
RTL Design
TLM Design
Transactor
16
Transactor example
clk
A
D
B
Transactor
C
TLM
RTL
write (addr, data)
17
Testbench and assertion reuse
Transactor-based Verification (TBV)
TLM
M2
TLMTestbenches Assertions
M1
M3
New testbenches and assertionoptimization
Testbench assertionreuse
Refinement
TLMTestbenches Assertions

RTL
M2
TLM
M1
T
RTLTestbenches Assertions
M3
Transactor
T
18
HW/SW cosimulation
Instruction Set Simulator (ISS) (CPU)
SystemC

• TLM (i.e., OSCI 2.0 becoming standard IEEE)
• SystemC 2.1 (IEEE 1666)
• C

SRAM
BUS
FPGA
ASIC
19
HW/SW/Network simulation
Instruction Set Simulator (ISS) (CPU)
SystemC

• TLM (i.e., OSCI 2.0 becoming standard IEEE)
• Systemc 2.1 (IEEE 1666)
• C

SRAM
BUS
FPGA
Ethernet device
20
System/Network Design Space Exploration
Network alternatives
System configuration TLM refinement
TLM/Network design space exploration
21
TLM Advantages

• Implementation details are abstracted while
  preserving the behavioral aspects of the system
• this allows a faster simulation (up to 1,000x)
  than at RTL
• An early platform for SW development can be
  quickly developed
• System level design exploration and verification
  are simplified
• IP components and buses can be modified in an
  easier way than at RTL
• IP reuse and mixed level verification
• TLM testbenches and assertions reused at RTL

22
Agenda

• Motivations
• Transaction Level Modeling (TLM)
• TLM levels
• TLM-based design and verification flows
• TLM advantages
• Todays challenges in TLM
• Design challenges
• Verification challenges
• Conclusions

23
Design challenges

• TLM-based design flows what can be automatic and
  what manual?
• Refinement steps.
• Abstraction steps.
• Transactors they represent the key objects to
  allow mixed level simulation, testbenches and
  assertion reuse.
• IP exchange and reuse API standard? (i.e., OSCI
  TLM 2.0, SPIRIT consortium, OCP-IP).
• Simulation speed RTL IP reuse decreases the
  simulation speed of the system.

24
TLM Refinement and Abstraction
TLM
M2
M1

• Mixing Top-down and Bottom-up design flows
• Top-down IP refinement steps from TLM towards
  RTL (i.e., Hardware components).
• Almost all manual!
• Behavioral compilers? (e.g., Forte Cynthesizer)
• Bottom-up IP abstraction steps from RTL to TLM
  (i.e., existent RTL IPs reused into TLM system)

M3
Refinement
Abstraction
RTL
M1
M2
TLM
M3
T
T
25
Automatic transactor generation (I)
RTL standard communication protocol (e.g., AMBA
bus) IEEE HLDVT06 - we can rely on a formal
model of the communication protocol - formal
centric transactor generation (FCTG)
REQ_m1 true
SYNCH_ MASTER_ 1
SYNCH_ SLAVE_ 1_1
READY
GRANT_M1true
Bus
Transactor

GRANT_M1 true
READY
got_request
EXEC
SYNCH_ BUS
WRITEm1 ADDRm1 WDATAm1
REQ_m1 true
26
Automatic transactor generation (II)
RTL testbench
RTL IP
1
RTL non standard comm. Protocol (e.g., IP-core)
DVCon06 - no formal model of the IP-core
- testbench centric transactor generation (TCTG)
IP driverEFSM
TLM APIs standard
3
2
DRIVER
TRANSACTOR
transactor
RTL IP
TLM testbench
27
Automatic abstraction of RTL IPs

• Abstraction Methodology
• ACM/IEEE MEMOCODE06
• - Automatic process
• - Clock abstraction.
• - State collapsing.
• Methodology correctness formally proved
• ACM/IEEE MEMOCODE07
• - Definition of event-based
• equivalence.
• - TLM design correct by
• construction.

Abstraction
28
Verification challenges (I)

• System-level verification (communication of IPs,
  bus sharing, system throughput, real time
  constraints, etc.)
• Dynamic Verification Transaction-based
  Verification (TBV)
• Hybrid Verification Assertion-based Verification
  (ABV)
• Component-level verification (component
  functionality, communication protocol, etc.)
• Dynamic Verification TBV
• Hybrid Verification ABV
• Static Verification
• Model Checking (MC)
• Equivalence Checking (EC)

29
Verification challenges (II)

• Verification in TLM-based design flows
• Verify functionality at the right abstraction
  level with the right technique
• Higher abstraction levels
• fast simulation
• formal tools inapplicable
• Lower abstraction levels
• accuracy slows down simulation speed
• formal tools (MC, EC)
• At each refinement step
• Verify the added architectural details
• Check the previously verified functionality
• Redundant verification?
• Can the effort spent for verification of previous
  steps be reused?

30
Hybrid Verification Assertion-based Verification
write(addr,data) read(addr, res)
(write_status)
TLM Design Under Verification (DUV)
POs
PIs
(read_status)
TLM testbench
Properties (assertions) (CTL,PSL,etc.)
Assertion Coverage
IBM FoCs
Checkers
31
Hybrid Verification Assertion-based Verification
write(addr,data) read(addr, res)
clk
clk
Control inputs
(write_status)
RTLsignals
Data inputs
RTL DUV
Transactor
POs
PIs
(read_status)
Control outputs
RTLsignals
TLM testbench
Data outputs
Properties (assertions) (CTL,PSL,etc.)
Assertion Coverage
IBM FoCs
Checkers
32
Incremental Assertion-based Verification
TLM Assertions
0 TLM Assertion Coverage
100

• TLM testbench and assertion reuse ACM/IEEE
  DATE06
• - efficiency theoretically proved in terms of
  detected faults and verified assertions.
• Incremental ABV verification IEEE DesignTest of
  Comp07
• To combine the reuse of
• - TLM assertions
• - RTL bus assertions
• - TLM code as satellites
• to increase the RTL assertion
• coverage.

RTL assertions for communic. protocol (AHB,
OCP-IP, etc.)
TLMimplementation
Definition ofnew assertions
Assertionreuse
TLM-to-RTLrefinement
Assertionreuse
RTLimplementation
Transactor
Standardfunction assertions
TLM assertions
Bus assertions
0 RTL Assertion Coverage
100
33
TLM vs. RTL Equivalence Checking

• Main problems
• No temporal similarities (e.g., untimed PV level
  vs. clocked RTL)
• No structural similarities (i.e., no common
  registers, no FSM templates)
• Traditional techniques (combinational, sequential
  EC) are inapplicable.

TLM IP
Refinement
Abstraction
Equivalence Checking
RTL IP
What does equivalent mean?
34
Agenda

• Motivations
• Transaction Level Modeling (TLM)
• TLM levels
• TLM-based design and verification flows
• TLM advantages
• Todays challenges in TLM
• Design challenges
• Verification challenges
• Conclusions

35
Conclusions

• Transaction Level Modeling is an emerging design
  practice for overcoming the increasing design
  complexity.
• TLM introduction arouses new challenges since no
  methodologies are mature to automate any
  refinement step of the TLM-based design flow,
  thus manual interventions are mandatory.
• Todays research activities aim at
• automating as much as possible the steps of the
  design flow.
• combining static and dynamic techniques for
  improving the verification quality

36
Questions?