my first 100 days in formal land - t&vs first 100 days in formal land alex orr ... powerpoint...

1 Broadcom Proprietary and Confidential. © 2015 Broadcom Corporation. All rights reserved.

MY FIRST 100 DAYS IN FORMAL LAND

Alex Orr Principal Engineer – IC Design


DAVE in various Bristol/Bath startups for ~20 years

Purely verification at Broadcom

“Just Show Me the Waves”

Career-long simulation abuser

First simulation using Verilog (TLM) in the mid 1990s

First experience of CSR approach in 2001 - Specman/e

Just starting to migrate over to UVM

QUICK BIOGRAPHY


State-space explosions! Hands-on experience only last year (2014) using Jasper

Assertion-based verification Ludicrously constructed examples … when you have a hammer

Tend towards monitors

Industry is expanding away from full formal proofs. Focus on smaller problems and tasks

Automation of some routine verification (Apps)

Tools to help debug problems (waves)

FORMAL VERIFICATION EXPERIENCE


Living the Life Formal

ADVENTURES IN FORMAL LAND


Pipeline Performance Verification Data transfer should occur when:

Previous stage has valid data,

Current stage is moving or empty (moe).

If not, performance is lost.

FIRST TASK – PIPELINE PERFORMANCE VERIFICATION

PL1 PL2

clk

rstn



assert property

(@(posedge clk) disable iff (!rstn)

rstn |=> PL2.valid == $past (PL2.moe && PL1.valid)) else

$error (“ERROR : PL2 failed to load data”);

Pre-formal approach Use a monitor: Emit an error when performance lost.

Use an assertion: Fire when performance is lost.

Passive approach Proving a negative – “I’ve never seen … ”

No completeness metric – always need caveat “… yet!”

Retains human factor – for human, read “possibly wrong”



Formal approach Proves assertion correct (proven) or incorrect (CEX)

Active - “proven” means your job is done.

Execution is usually far quicker than the simulation can even rebuild.

Debug CEXs using waves.

Assertions live on in simulation – just in case somebody …

Lessons learned Reconsider your proof boundary if using too many assumptions.

Do not assume what you can also prove.

Can you include the drivers of those signals in the proof?

Assumptions become assertions in simulation …

… proving a -ve again.


SECOND TASK – ARBITER VERIFICATION

FF1 RAM1 RAM2 IP

OP 1

2

3

4

Priority

BP


Some problems suit formal approaches better. Priority scheme requires few assertions to fully prove.

Use one assertion per priority level, based around bus integrity.

Proving bus priority using dynamic simulation:

Wastes billions of cycles,

Is hard work in directing traffic into corners.

Use dynamic simulation to prove arbiter’s “fit-for-purpose” in the system context. Overlapping methodologies are key to efficient verification.

Lessons learned No need to use deposits or assumptions to identify buses.

Use $past and formal tool will do differentiation.

SECOND TASK – ARBITER VERIFICATION


THIRD TASK – ANTI-HOGGING

Block

A

Block B

Anti-

Hogging

Counter

Counter

OP


Mistakes made Specification

“Make sure block A doesn’t hold off block B for too long.”

Struggled with how to phrase rule in a single property Used intermediate RTL signals to achieve it.

Bug found in dynamic simulation “But I thought it was formally proven?”

Lessons learned Keep abstraction as high as possible.

Prove logic intent not implementation.

Use behavioral helper logic if needed.

THIRD TASK – ANTI-HOGGING


ACTIVE SIGN-OFF - EXCEPTIONS

I, the undersigned, being a verification

engineer of 23 years, do stake my reputation

and career on the fact that this silicon

integrated circuit will be perfect in every way

despite only achieving 99.3% functional and 97.12%

code coverage.

I have sacrificed 1 goat(s) and 1.5 chicken(s) to

appease the silicon gods.

_____________________________

(your blood only please*)

*this will be verified


Design and verification is mostly science/engineering. … Except when dealing with less than 100%.

Retain an element of art/expert judgment/reputation-leverage.

Traditional sign-off methods Coverage refinements

Executable waivers TCL/Perl scripts

Reviews with text waivers

All rely on interpretation of code/context by humans. For human, read “possibly wrong”.

Backed up with monitors/assertions … proving a negative!

ACTIVE SIGN-OFF - EXCEPTIONS


Unreachable coverage Logically impossible or not trying hard enough?

Traditional method Review with peers (and waves).

Better methods Use assertions, monitors, and/or illegal_bins statements.

Best method Prove unreachability using assertions and formal tools.

Assertions live with RTL – just in case somebody …

ACTIVE SIGN-OFF – UNREACHABLE COVERPOINTS


Constraints False and multicycle paths

Capture the design intent – a primary input … but with less robust checking mechanisms!

Traditional method STA Timing issues/SDF sims

Better methods Assertions, monitors, STA scripts

Best method Prove the constraint using assertions and formal tools.

ACTIVE SIGN-OFF – STA CONSTRAINTS


If you can script it – automate it.

Run sign-off as part of continuous integration (Jenkins). Write a script to dump a junit file of results.

Use <fail> tags for everything that isn’t “proven”.

This is more nuanced than relying on non-zero exit status.

Create a Jenkins job. Make it sensitive to a subset of SCM changes, check every other hour.

Enable the notorious “e-mail those who broke the build” option.

Bonus Keep assertions/assumptions bound in sanity builds for

pre-commit heads-up.

ACTIVE SIGN-OFF - AUTOMATION


Life Post Formal

RECAP AND CONCLUSIONS


Some verification problems are more suited to a formal approach, some a dynamic, but do not use either alone. Use appropriately as part of an overlapping verification flow.

Start with assertions. Formal almost comes for free.

Active sign-off Prove your assertions, constraints, exceptions, and excuses.

Use formal as a sign-off tool and automate its execution.

Very easy to get started App-based approach is making it easier to adopt and get results quickly.

I’d never used a formal approach 12 months ago … … now I find it hard to imagine a robust flow without a formal element.

CONCLUSIONS


“To err is human!” Quoted by

Janick Bergeron


“To err is human!” Quoted by

Janick Bergeron

“So why trust humans?” me, Broadcom

my first 100 days in formal land - t&vs first 100 days in formal land alex orr ... powerpoint...

Documents