Advanced Techniques for RTL Debugging YuChin Hsu, Bassam Tabbara, YirngAn Chen, Furshing Tsai

1
Advanced Techniques for RTL DebuggingYu-Chin
Hsu, Bassam Tabbara, Yirng-An Chen, Furshing Tsai

• VLSI CAD Seminar
• Presented By
• Guy Afriyat

2
Background

• Why do we need RTL Debugging ?
• Designers have to build a mental image of how
  data is propagated and used over the simulation
  run.
• As designs get more and more complex, there is a
  need to facilitate this reasoning process, and
  automate the debugging.

3
Introduction

• Debugging is generally a major endeavor for the
  designer with large and complex designs since
  these are typically
• Heterogeneous
• Mixed
• Diverse

4
Introduction (cont.)

• Heterogeneous
• Composed of varied components, possibly
  intellectual property blocks, from several
  providers.
• Mixed
• Made up of portions described at different
  abstraction levels behavioral as well as
  structural.
• Diverse
• Composed of multiple interaction such as sensors,
  D/A or A/D converters, ext.

5
Introduction (cont.)

• The data used to exercise and observe design
  behavior is a large and varied data set.
• Manipulating, studying and analyzing this data
  and its correlation with expected behavior is a
  horrendous undertaking.

6
Debugging

• The process of debugging involves
• Locating the logic that is associated with an
  error.
• Isolating the pertinent cause and effect
  relationship.
• Understanding exactly how the design is supposed
  to behave and why it is not behaving that way.

7
Debugging

• Rely entirely on the engineers ability to deduce
  the designs behavior from its structure.
• Struggle to grasp how the design is supposed to
  work or why it doesnt.
• Leads to long debug cycles.
• Main goal is to improve debug productivity by
  automating the process.

8
Behavior-Based RTL Debug

• Behavior analysis automatically infers the
  designs temporal behavior using the information
  in
• The HDL source
• The simulation results.
• Given an analysis scope, we extract the temporal
  behavior of the design from the designs logical
  model and the simulation data.

9
Behavior-Based RTL Debug (cont.)

• The analysis procedure is divided into
• Logic extraction.
• Timing activity analysis.

10
Logic Model

• An inference step converts an HDL description
  into a logic behavioral model using a
  rules-based approach.
• Each statement is represented as a component
  block.
• No optimization is performed on the logic model.
• The input are classified into data-path and
  control inputs using a pre-defined set of rules.

11
Primary rules

• The primary rules are as follows
• Latch Inference
• Register Inference
• Incomplete Sensitivity List
• 2-D memory array
• MUX/priority-encoder Inference
• The non-inferable RTL

12
Primary rules (cont.)

• Latch Inference
• When a conditional statement is incompletely
  specified. The missing signal becomes the latch
  enable.
• Register Inference
• Happens when an always block is edge sensitive
  (e.g. FLIP-FLOP).

13
Primary rules (cont.)

• Incomplete Sensitivity List
• To prevent possible mismatch, we interpret the
  missing signal to be an unintended latch output.
• 2-D memory array
• A memory is inferred.

14
Primary rules (cont.)

• Mux/priority-encoder Inference
• In case of if statements, either latches or
  priority encoders are inferred depending on the
  context.
• For case statements, latches or muxex are
  inferred depending on the context.
• The non-inferable RTL
• Such as algorithmic computation blocks will be
  treated as a black box.

15
Timing Model and Activity Analysis

• Simulation result is used to extract the temporal
  behavior for an identified (problem) signal,
  starting with the problem signal.
• Fan-in logic is traversed until FLIP-FLOPs or
  inputs are hit.
• The active clock transition time is determined.
• Fan-in cone logic is evaluated to determine which
  signal are (in) active.
• Activity analysis serves as the basis for
  enabling automation of debug in the time domain.

16
Behavior-Based Debug Infrastructure

• Starting from an error source, debug traces back
  towards the cause of this error.
• It does so by marrying the logical model and the
  timing activity models.
• Builds a behavior trace of the signal in
  question.
• This expansion can be performed interactively
  again and again moving backwards in time.

17
Tracing and Clocking
18
Trace a Suspicious Value

• Automatically trace value back across multiple
  cycles

19
Value Tracing

• Can be specialized to search for the first
  unknown (X) that propagates to the output.
• Can determine when the content of a 2-D array
  element has been written and with what value.
• This debug infrastructure is used to build
  advanced debug approaches
• Behavior exploration.
• Behavior query.

20
Behavior Exploration Layer

• Enables users to explore possible behaviors of
  their designs in the debugging environment.
• Has 2 techniques
• What if analysis.
• How can analysis.

21
What if analysis

• Provides the ability to quickly evaluate a
  potential bug fix by changing the current values
  in the design with new values.
• First performs fan-out marking.
• Backward timing expansion start from the target
  signals or time to the starting signals.
• Performance depends on the size of the expanded
  model.

22
What if analysis - Example
23
How can analysis

• Provides the inverse capability to what if.
• Give a way to find all possible combinations of a
  set of signals that achieve a specific value for
  a target signal at a specific time.
• Performance depends on
• Size of the expanded model as in what if
  analysis.
• Numbers of set symbolic values.

24
Behavior Query Layer

• Aimed at assisting the user in asking about the
  presence or absence of desired or undesired
  design scenarios.
• Debug flow
• Enter a query using an assertion language.
• Validate the query on the simulation run data.
• Debug the query starting from the failure
  instance.

25
Behavior Query Layer

• Enter a query using an assertion language.
• Assertion languages are becoming popular as a
  means to describe a design specification.
• Formal and declarative languages, aimed at
  precise behavior description of design specs.

26
Behavior Query Layer

• Validate the query on the simulation run data.
• A tool that checks the behavior query against the
  simulation data.
• The results flag the failure or success.
• Results can consist of simple success/fail or
  more detailed assertion evolution tags (keeps the
  tags of the window in a sequence).

27
Behavior Query Layer

• Debug the query starting from the failure
  instance.
• Debug infrastructure is driven by the assertion
  result.
• automatically build an assertion driven design
  trace to help locate the error injection region.

28
Trace Slice and Dice

• A simple assertion
• a followed by b one cycle later, followed by c
  one cycle later.
• An assertion fail, means that the c expression
  was not satisfied.
• Cs expression is the starting error signal
  source.
• Build a trace backwards from starting point and
  set of signals to the trigger time of the
  assertion.

29
Slicing and Dicing - Example
30
Trace Slice and Dice (cont.)

• Trace slice is the backward trace from c to the
  trigger time of the assertion.
• We know that not all drivers of signal c caused
  the failure because only a limited number of
  paths in the previous cycle are valid.
• Trace dice is where additional info is used to
  limit the paths to be traced.

31
Bug in AluBuf Register
32
Trace slicing of AluBuf Assertion
33
Trace dicing of AluBuf Assertion
34
Experimental Results
35
Experimental Results
36
Conclusions

• Behavior analysis and debug technique can be used
  for
• Quickly locate and diagnose errors with behavior
  query.
• Evaluate potential corrections with behavior
  exploration.
• Quickly trace back to the root causes.

37
(No Transcript)