Leveraging SemiFormal and Sequential Equivalence Techniques for Multimedia SOC Performance Validatio

1
Leveraging SemiFormal and Sequential
Equivalence Techniques for Multimedia SOC
Performance Validation

• Lovleen Bhatia, Jayesh Gaur,Praveen Tiwari,
  Raj S. Mitra, Sunil H. Matange Texas
  Instruments Bangalore, India DAC
  2007, Paper 5.2

2
Memory Bandwidth Validation Problem

• Multimedia SOCs
• Real Time data transfers to/from memory
• High throughput, data intensive applications
• Multiple masters accessing the memory subsystem
• Memory Bandwidth analysis is pivotal for
  overallsystem performance
• Bandwidth Validation Task
• Ensure that none of the masters are starved
• Flush out bottlenecks in implementation
• Bandwidth requirements are different for
  different use cases
• Complexity
• Need accuracy analyze on actual RTL
• Need corner case analysis simulations /
  emulations are not sufficient

3
Memory Bandwidth Validation Problem
1011101101011100
10111011011100
1011101101011100
10111100
1011101101011100
Can The System Support The Application ?
4
Discussion on Prior Art

• Traditional Verification Strategies
• Simulating the RTL
• Risk of missing corner cases
• Running Pseudo Application on FPGA
• Limited controllability
• Usually too late to make any design changes
• Running application software on actual Silicon
• Too late to make any design changes
• Architectural evaluation using models
• Models not accurate enough, and actual RTL not
  yet available
• Statically adding up worst cases of models does
  not yield overall worst case analysis
• Verification Techniques
• Simulation risk of missing corner cases
• Formal analysis cannot handle large
  RTL,abstract models can be inaccurate
• Semi-Formal bug-hunting

5
Summary of Our Methodology

• Application on actual RTL implementation
• Accuracy of analysis
• Early usage in the design cycle
• Allows RTL fixes to be done
• Usage of semi-formal techniques rather than
  simulation
• Greater coverage on corner cases
• Usage of formal analysis and sequential
  equivalence techniques in case of abstractions
• Models of masters (in RTL and PSL) are validated
• Case Studies
• Proof of concept developed Re-discovered known
  bugs
• Application on a live design Caught several
  bugs before the RTL freeze

6
Problem Definition

• Aspects of SOC Performance Validation
• Rate, e.g. "Requests are produced every n time
  units"    t(Requesti1) - t(Requesti) n
• Latency, e.g. "Response is generated no more than
  k time units after Request"    t(Responsei)
  - t(Requesti) lt k
• Throughput, e.g. "at least W Request events
  will be produced in any period of T time
  units"    t(RequestiW) - t(Requesti) lt T
  
• Influential Factors
• Structural (Design) Components
• Interconnect, Memory interface controllers, FIFO,
  Data transfer initiators (masters)
• Functional (Application) Scenarios Broken down
  to phase level
• Scheduling
• Interactions (overlapping, non-overlapping)

7
Methodology Definition

• Use actual RTL in as many places as possible
  without any abstractions
• Partition at boundaries where protocol is well
  defined and the bandwidth requirements at the
  interface are well-understood
• Create models for very complex masters (which
  involve high complexity in data-path) using
  abstraction techniques
• The abstraction should preserve the Request
  generation and supporting logic. The data-path
  units such as FIFO and memories should be removed
  while preserving their control logic
• Verify the above models using Sequential
  Equivalence Checking
• Use-Case Traffic Rates used as constraints for
  the masters.
• Semi-Formal tool will automatically create the
  traffic patterns, based on constraints and master
  models.

8
Example Application
9
Functional Decomposition

• Divide the complete application run into
  different Phases Pi depending on expected
  Software Scheduling (if possible)
• Analysis needs to be carried out on each
  application phase Pi for each possible master.

10
Modeling

• Real Time Masters Application specific masters
  like video input and display output
• Non Real Time MastersSoftware triggered DMA
  transfers.Bandwidth requirements are analyzed
  over aggregated time (multiple frames, phases of
  data transfer).

B Bytes/burst R Rate (MB/s) Y MHz data
transfer cycles variable delay
11
Case Study 1

• Design Characteristics
• Low-power, highly integrated signal-processing
  platform
• Design uses 16 bit external SDRAM interfaced to
  Memory Traffic Controller (MTC)
• All imaging functions and software execution run
  from the SDRAM
• SDRAM latency is bottleneck for system
  performance
• Eleven peripheral masters can access MTC
  simultaneously
• Verification Objective
• Performance issues related to ISP and HSSP in
  first silicon
• Software workarounds to fix these issues impacted
  project schedule
• Objective was to replicate the silicon issues by
  this methodology

12
Case Study - 1

• Data
• RTL 8k Flops
• Assertions 21
• Constraints 15
• Effort 4 weeks
• Results

13
Case Study - 2

• Design Characteristics
• High Performance multimedia System On Chip (SOC)
• Supports various imaging applications Video
  Capture, Video Playback, Video Call, Still
  Capture etc.
• Design uses a 32 bit DDR for improved memory
  bandwidth
• Three levels of arbitration are implemented
• Peripherals have different amount of buffering
  based on bandwidth requirements
• System supports dynamic priority escalation

14
Case Study - 2

• Verification Objective
• To uncover any potential bottlenecks very early
  in the designcycle thereby mitigating the risk
  of potential performance issuesgetting into
  silicon
• To enable design changes for performance at RTL
  stage with least impact on schedule
• Verification Complexity
• The system performance is dependent upon the DDR
  accesses, arbitration delays, the amount of
  buffering, bridge latencies, dynamic priorities
  as well as the burst patterns of the masters
• Each application has different performance
  requirements, different sets of masters, burst
  patterns, etc, and the design has to ensure that
  the performance requirements for every master are
  satisfied for each and every application
• The overall verification subsystem was nearly 44K
  flops
• Priorities can be dynamically escalated

15
Case Study - 2

• Data
• RTL 44k Flops
• Assertions 45
• Constraints 32
• Results

16
Discussion and Conclusion

• Advantages
• Can catch performance bugs in the Hardware very
  early in thedesign cycle
• This will help avoid late software workarounds
  frequently done to meet the overall performance
• This can also be a very significant step to
  validate architecture much ahead of RTL closure
• May help S/W teams in creating the most efficient
  code for a given H/W
• The models and assertions developed can be used
  as VIPs for analysis on future designs
• Challenges
• The tool and methodologies are still evolving so
  the tools are not yet mature
• Semi-formal techniques cannot prove properties.
  Only falsifications can be found
• Since the technology used is a formal technique
  so application can be restricted by design sizes

17
(No Transcript)