1

Design Best Practices for Bug Avoidance

Bryan Dickman

ARM Ltd.

Verification Futures (Europe) 2015

2

Verification is well established as the biggest challenge for the delivery of high quality IP

products, but can verification ever find all bugs, and what can designers do to reduce the

number of bugs in RTL code by applying design-for-verification practices, and not

submitting to design-by-verification?

1. Complexity is increasing beyond the capabilities of verification practices and cannot catch all bugs.

2. How can designers avoid bugs?

3. How to deploy best practices in a diverse engineering team?

Abstract

3

Joined ARM in 1996 – 140 person company

Previous experience as hardware designer for ICL Series 39 mainframes

2nd Verification Hire

“do this validation role for a couple of years Bryan and then we’ll let you do design again”

Ha, Ha……18 years later……..

So what has changed in 18 years?

HVLs and Constrained-random+FCOV (Vera/Specman -> SystemVerilog/UVM)

Compute resources scale-out (10 simulations ->10,000 simulations)

Hardware Acceleration scale-out (emulators, FPGAs, post silicon)

Formal Verification maturing capability (LEC-> Property checking, SEQ, Assertion generation, proof

convergence techniques)

Automation scale-out...Data Management...Results Analysis...Test Planning

The role of verification…

4

Thank goodness – else we are all unemployed….

Complexity is our friend….

and enemy….

“Verification is a non-tractable (NP-complete) problem”

solutions are checkable, but the problem is not solvable in polynomial time

i.e. we can show that certain behaviours perform correctly, but we cannot prove that the DUT will

never behave erroneously for all possible behaviours (absence of bugs).

Thus, verification is mainly an imperfect bug-hunting strategy

And it is unreasonable to expect to find all bugs

But we still have bugs

5

Who is accountable for delivering bug free designs?

What does bug-free mean?

How do bugs get into the design?

Why does clean RTL deteriorate into buggy RTL?

Can verification find all bugs?

What sort of bugs is verification missing and why?

Why is complexity increasing?

Is all complexity necessary?

Is Design an Art-form or Craftsmanship?

We’ve been doing our damnedest with Verification for last 18 years – what else can be

done?

Designers – we need your help now please!

Make designs that work!

Verification – it’s not all your fault Guys!

6

An AHAA! Moment

A H A A

Bug Avoidance

Design Practices

Complexity Analysis

Interfaces

Assertions

Specification

RTL coding

Bug Hunting

Verification Practices

Constrained-Random Testbenches

RIS

Coverage

Assertions

Emulation/FPGA

Post-Silicon

Software compatibility

Formal

Bug Absence

Formal proofs

Prove critical properties to

get 100% assurance

May require considerable

user expertise and effort

Bug Analysis

Debug Practices

Data Analysis

Root Cause Analysis

7

Extracting the learning points from critical bugs

Using an 8D process to identify the root causes of the bugs

Leading to identification of improvement measures

Verification Root Causes:

How was the bug discovered?

Why was it missed until now?

How can we improve the verification

Design Root Causes:

How did the bug end up in the design?

Why was the behaviour not understood?

How could designers avoid such bugs in future designs?

Root Cause Analysis

8. Communication and Knowledge sharing

7. Identify Preventative Measures

6. Implement Corrective Actions

5. Identify Corrective Actions

4. Root Causes Analysis

3. Containment

2. Describe the Problem

1. Identify the Team

8

Root Causes (from 8Ds)

Specification weaknesses

Interface specification issues

Reviewing failed to pick up the error

Code was complex (and hard to review)

Copy-paste errors

Clocking/synchronisation corner cases

Unknown dependencies

Appropriate Designer Assertions might have prevented the bug

Time pressure/limited resources

Missing Designer Concerns

Insufficient stimulus

Insufficient cycles

BFM weaknesses

Fully random can miss the

problem

Coverage did not help

Missing checkers

Insufficient clock ratios

tested

9

Best Practices

Verification Practices

Test Planning

Verification Sign-off

Bug Tracking

Formal Verification Practices

Clocking, Reset, Power Verification

Deployed into workflow reviews

Design Practices

Specifications

Assertions

Bug Avoidance

Bug Mitigation

Clocking, Reset, Power Design

Deploying into workflow reviews

10

Design Specifications

Specification purposes

Design conception, development, refinement

Enable Verification planning

Enable reviewing, approval and sign-off

Knowledge sharing

Document for design maintenance and reuse

Enabler for product documentation

Usually start with product-level

requirements

Which are refined and decomposed into an

implementation

Often developed alongside design

investigations and modeling

What can Designers do?

Collaborate with the DV team

Deliver completed specs sufficient to enable

verification planning

Highlight verification considerations and

enablers

Capture appropriate level of detail (so that

the specs are accurate and maintainable).

Maintain and update specs as the design

evolves

◦ But not a replacement for high level of

dialogue with the DV team

11

Avoiding Denial of Service Bugs

Complexity can lead to emergent behaviours Unknown corner-cases (missed in the test

planning, and unreached by random)

Often resulting in deadlocks, livelocks or starvation scenarios.

Arising from Dependencies/shared resources – common issue

for coherency/MP

Arbitration mechanisms

Loop-backs and retry mechanisms

Possibly introduced through Architecture misunderstandings

Un-readable/badly constructed code

Code optimisations

Bug fixes

What can Designers do?

Identification (documentation) of shared

resources and dependencies in the code

◦ Capture assumptions as designer assertions

◦ Consider using formal bring-up

Analysis and modeling of potential conflicts

Deploy clean interfaces

Simplify where possible within design goals

and constraints

If complexity is necessary – warn the DV

guys!

Build in bug mitigation mechanisms that will

workaround unforeseen/emergent behaviours

◦ De-feature bits, hang detectors/recovery

mechanisms

12

Coding rules and implementation styles

RTL should obey the standard coding rules

RTL code has to be understandable By reviewers and other designers

By the designer himself

Styles can range from equation-based to behavioural

FSMs may be explicit or implied

RTL has to be Maintainable

Re-usable maybe

Optimisations for PPA may be non-intuitive Duplication of logic for reduced switching

Watch out for copy-paste errors

Watch out for out of date/misleading comments

What can Designers do?

Use automated checking of the coding rules

(Linting)

Write well-structured self-evident behavioural

code wherever possible

Document any complex optimisations

Exercise caution when copy-pasting

Review the design function with peers – and

walk-though behaviour scenarios and corner

cases.

Partner with the DV team to ensure focused

effort is applied to areas of risk

Avoid “Design-by-Verification”!

13

Designer Assertions

Bryan’s assertion… “Assertions captured while coding RTL help

to eliminate bugs”

Capture the designers intent and any assumptions in an executable form

Encourage a more rigorous thought process about the intended behaviour

Ensure that a future change to the code does not break the expected behaviour

Enable Formal Verification

Can police the behaviours of interfaces between blocks (designers)

Detect X-propagation issues

Increase design observability

Reduce debug time

Slow down simulations

What can Designers do?

Learn to apply high value assertions (quality

not quantity)

Ensure that interfaces are always protected

with appropriate assertions

Consider Formal bring up to check-as-you-go

14

Design For Verification

Enabling Verification Techniques

Assertions – already mentioned that

Documentation – already mentioned that

too

Avoid DoS bugs – that too

Design Mutation – parameterization to

accelerate corner case reachability

Error injectors – e.g. random invalidates,

cache evicts

But…be careful that you are still verifying

the actual design

Be careful not to impact PPA

What can Designers do?

Review DFV considerations with the DV team

early on, and establish DFV requirements

Make DFV features accessible through build

configuration or software programmable

Consider including DFV features for test

silicon to enable post-silicon verification

15

Design Reviewing Practices

Design Optimisation Practices

Clocking, Reset and Power Practices

DFT

Design for Debug

Design Entry Abstraction Practices

Design Modeling Practices

Coaching and Training Practices

Requirements Management Practices

Design Source code management practices

Further considerations…

16

End