I s todays I s todays I s today s I s today s design m ethodology - - PowerPoint PPT Presentation

I s today’s I s today’s I s today s I s today s design m ethodology design m ethodology a recipe for a a recipe for a a recipe for a a recipe for a Tacom a Narrow s incident? Tacom a Narrow s incident?

Carl Seger Carl Seger Strategic CAD Labs Strategic CAD Labs I ntel Corporation I ntel Corporation l 8 2 0 0 9 2 0 0 9 July July 8 , , 2 0 0 9 2 0 0 9

Outline Outline Outline Outline

 Validation brick w all Validation brick w all Validation brick w all Validation brick w all  Tw o types of validation Tw o types of validation W hat is know n W hat is know n  W hat is know n W hat is know n

–More developm ent needed More developm ent needed

W h t i k W h t i k  W hat is unknow n W hat is unknow n

–More research neede More research neede

 Danger of “business as usual” Danger of “business as usual”

2

Electronic Circuits Electronic Circuits Electronic Circuits Electronic Circuits

 Moore’s law drives industry Moore’s law drives industry

b f i il bl b f i il bl – Num ber of transistors available Num ber of transistors available doubles every tw o years doubles every tw o years

– Over Over 2 2 billion in billion in 2 0 0 9 2 0 0 9

– No sign of show No sign of show -stoppers for stoppers for – No sign of show No sign of show -stoppers for stoppers for next next 1 0 1 0 -

• 1 5

1 5 years. years.

 Extrem ely com plex system s Extrem ely com plex system s can be designed on a single can be designed on a single can be designed on a single can be designed on a single die die

– Single chip m ulti Single chip m ulti-

• core

core processors processors p – System On a Chip System On a Chip

 Society increasingly depends Society increasingly depends

• n correctly functioning
• n correctly functioning

3

y g y g products and devices products and devices

Design Challenges Design Challenges Design Challenges Design Challenges

 Com plexity of design Com plexity of design

More transistors More transistors →

In-order, pipelined Out-of-order, threading, mcode-fusion, power mgmt, …

– More transistors More transistors → More functionality More functionality → More design effort More design effort

 Num ber & size of m odels Num ber & size of m odels

P f ERTL GRTL P f ERTL GRTL

2 000 000 2,500,000

L

– Perform ance, ERTL, GRTL, Perform ance, ERTL, GRTL, Schem atics, … Schem atics, … – Multi Multi-

• m illion line RTL

m illion line RTL

 Multi Multi-objective convergence

• bjective convergence

4000000

8000

500,000 1,000,000 1,500,000 2,000,000

Lines of RTL

Multi Multi objective convergence

• bjective convergence

– Tim ing, pow er, area, etc. Tim ing, pow er, area, etc. feedback w ay too late in feedback w ay too late in design schedules design schedules

 Validation of design Validation of design

1500000 2000000 2500000 3000000 3500000

3000 4000 5000 6000 7000 Files Checked In #Total Lines Lines Ch d

# Pre-silicon bugs

P4 P5 P6 WMT NWD PSC

 Validation of design Validation of design

– Bug rate rising ~ Bug rate rising ~ 4 4 x per lead x per lead – Trillions of sim ulation cycles Trillions of sim ulation cycles

• n a rapidly changing m odel
• n a rapidly changing m odel

500000 1000000 1500000

1000 2000 3000 Changed

Increasing rate (~4x per lead) 486 P5 P6 NHM WMT

4

Plan Design Analyze weeks/months

Verification Verification Brick W all Brick W all

Without major breakthroughs, verification will be a non-scalable, show-stopping barrier to further

Brick W all Brick W all

Verification killing schedules

, pp g progress in the semiconductor industry

THE INTERNATIONAL TECHNOLOGY ROADMAP FOR SEMICONDUCTORS: 2005/6

Too many pre-Si bugs!

• n success
• n success
• N. America Re-spin Statistics

39% 44% 48%

6 0 0 0 8 0 0 0 1 0 0 0 0

1st

st silico

silico 71% of SoC re-spins due to logic bugs

Source:* 2002 Collett International Research and Synopsys

1999 2002 2004

2 0 0 0 4 0 0 0

Pre-Si validation headcount growing fast

Validation HC

Bugs found too late

Incoming bugs (5 wks AVG)

5

‘02 ‘03 ‘04 ‘05

Tw o Classes of Bugs: Tw o Classes of Bugs: Tw o Classes of Bugs: Tw o Classes of Bugs:

 Specification Specification bugs bugs

– “W hat” is captured “W hat” is captured incorrectly incorrectly

– Unintended interactions Unintended interactions – Com m unication failures Com m unication failures – Deadlock Deadlock – Livelock Livelock

 I m plem entation I m plem entation bugs bugs

“H ” i t d “H ” i t d – “How ” is captured “How ” is captured incorrectly incorrectly

– Refinem ent failed Refinem ent failed

N t N t  Note: Note:

– The m ore abstract the The m ore abstract the specification is, the m ore specification is, the m ore im plem entation bugs im plem entation bugs

mentation bugs cation bugs

6

p g p g ( and vice versa) . ( and vice versa) .

Abstraction Level Implem Specific

How to Address How to Address I m plem entation Bugs I m plem entation Bugs I m plem entation Bugs I m plem entation Bugs

 Form al equivalence* checking Form al equivalence* checking Form al equivalence checking Form al equivalence checking

– Poster child of form al m ethods Poster child of form al m ethods – Sequential checking and local property Sequential checking and local property verification are still difficult and can verification are still difficult and can benefit from algorithm ic breakthroughs benefit from algorithm ic breakthroughs

 How ever FEV is very lim ited in How ever FEV is very lim ited in  How ever, FEV is very lim ited in How ever, FEV is very lim ited in abstraction gap that can be bridged abstraction gap that can be bridged  I ntegrated design and verification can I ntegrated design and verification can I ntegrated design and verification can I ntegrated design and verification can solve this problem solve this problem

7

* Should really be called Formal Refinement Checking

I ntegrating Design and I ntegrating Design and Verification Verification Verification Verification

 Start w ith a very high Start w ith a very high-

• level

level m odel description of the m odel description of the

Validatio

m odel description of the m odel description of the design design

– Validation target Validation target

 Through sequential design Through sequential design steps: steps:

C t d t il & C t d t il &

n

HLM

Verified steps

– Create m ore detail & Create m ore detail & explore/ add/ rem ove explore/ add/ rem ove – W hile proving that each W hile proving that each step m aintains correctness step m aintains correctness

 Additionally, start from Additionally, start from d t il d d i d d t il d d i d

M1 M2

detailed design and detailed design and abstract up abstract up

– Abstract details by Abstract details by transform ations transform ations – W hile proving that each W hile proving that each t i t i t t i t i t

M3

GRTL

M3’

p g p g step m aintains correctness step m aintains correctness

 System : System :

– ensures correctness ensures correctness – autom atically replays steps autom atically replays steps

gRTL SCH

8

Exam ple Designs Done Using a Exam ple Designs Done Using a P otot pe I DV S stem P otot pe I DV S stem Prototype I DV System Prototype I DV System

Bottom line: During 13 months of design effort, no RTL changes were needed because of implementation considerations.

Early Design: RTL to Early Design: RTL to netlist netlist Top Top-

• level RTL Entry

level RTL Entry

12,000 lines

• f RTL

1 2 3 4 5 6 8 9 10 7

Final FPU pipeline diagram Final FPU pipeline diagram

S SC CL L

• C. Seger - Intel Confidential

Logic And Physical View Logic And Physical View S SC CL L

• C. Seger - Intel Confidential

Final Design Sent to Router Final Design Sent to Router

S S L L S S L L

130,000 trans. (2 RF + 1 CAM) Converged to 270ps

Graphics execution unit (~120,000 gates) HLM -> Placed cells

9

S SC CL L

• C. Seger - Intel Confidential

S SC CL L

• C. Seger - Intel Confidential

W hat to do for Spec W hat to do for Spec bugs? bugs? W hat to do for Spec W hat to do for Spec-bugs? bugs?

 Create few er bugs Create few er bugs

W it i ifi tl b t t W it i ifi tl b t t – W rite significantly m ore abstract specs. W rite significantly m ore abstract specs.

– Style? Methodology? Language? … Style? Methodology? Language? …

– Change specification infrequently Change specification infrequently

– How to accom plish this? How to accom plish this? Maybe m ake it easier to absorb spec changes? Maybe m ake it easier to absorb spec changes? – Maybe m ake it easier to absorb spec. changes? Maybe m ake it easier to absorb spec. changes?

 Make design easier to check Make design easier to check

– Focus on “w hat” not “how ” Focus on “w hat” not “how ”

 Make bugs easier to find Make bugs easier to find

– Reduce specification size by at least Reduce specification size by at least 1 1 -

• 2

2 orders of

• rders of

m agnitude m agnitude

 Capture bugs sooner Capture bugs sooner  Re Re-

• use verification

use verification

10

Danger of Danger of “Business “Business-as as-Usual” Usual” Business Business as as Usual Usual

The Original Tacom a The Original Tacom a Narrow s Bridge Narrow s Bridge Narrow s Bridge Narrow s Bridge

 The first Tacom a Narrow s Bridge The first Tacom a Narrow s Bridge w as evolutionary in its design w as evolutionary in its design w as evolutionary in its design. w as evolutionary in its design.

– Third longest suspension bridge Third longest suspension bridge ever constructed ever constructed – The lightest suspension bridge The lightest suspension bridge ( considering its length) ever ( considering its length) ever ( considering its length) ever ( considering its length) ever constructed constructed – ( Arguably) the m ost beautiful and ( Arguably) the m ost beautiful and elegant suspension bridge ever elegant suspension bridge ever constructed. constructed.

 The original bridge w as built The original bridge w as built

– using the best available scientific using the best available scientific know ledge know ledge

– including self resonance and vortex including self resonance and vortex induced vibrations induced vibrations

– w as m anufactured correctly using w as m anufactured correctly using high high-

• quality products

quality products

12

But… But…

 The bridge collapsed four The bridge collapsed four m onths after its opening m onths after its opening m onths after its opening. m onths after its opening.

– The shape of the bridge w as The shape of the bridge w as sim ilar to an airplane w ing sim ilar to an airplane w ing and created significant lift and created significant lift even in m odest w inds even in m odest w inds Due to self Due to self excitation excitation – Due to self Due to self-excitation excitation ( negative dam ping) a “cork ( negative dam ping) a “cork screw ” screw ” 0 0 . .2 2 Hz oscillation grew Hz oscillation grew until the bridge deck broke until the bridge deck broke and the bridge collapsed and the bridge collapsed This w as an entirely new This w as an entirely new – This w as an entirely new This w as an entirely new phenom ena and required a phenom ena and required a new validation approach new validation approach

 Let us not m ake the sam e Let us not m ake the sam e m istake in continuing today’s m istake in continuing today’s m istake in continuing today s m istake in continuing today s validation approaches blindly validation approaches blindly into the “new brave w orld” of into the “new brave w orld” of m ulti m ulti-

• billion transistor

billion transistor system system -

• on
• n-a

a-

• chip designs.

chip designs.

13

Backup Backup

I deal Specification I deal Specification

 A specification of * w hat* you w ant A specification of * w hat* you w ant  A specification of * w hat* you w ant A specification of * w hat* you w ant  I deally, im m utable and has im m unity I deally, im m utable and has im m unity from how you use it from how you use it  But: But:

– Has to change due to “above” changes Has to change due to “above” changes ( bugs, architectural feature change, ( bugs, architectural feature change, i l h ) i l h ) ( g , g , ( g , g , environm ental changes, etc.) environm ental changes, etc.) – May have to change if not w hat you really May have to change if not w hat you really w ant ( e.g. “below ” discovery that the idea w ant ( e.g. “below ” discovery that the idea w as bad to begin w ith) w as bad to begin w ith) w as bad to begin w ith) w as bad to begin w ith) – Have to change if it cannot be built ( e.g., Have to change if it cannot be built ( e.g., “below ” discovery that spec. is not “below ” discovery that spec. is not im plem entable) im plem entable)

15

im plem entable) im plem entable)

Create few er bugs Create few er bugs Create few er bugs Create few er bugs

 Use a KI SS approach ( keep it sim ple and stupid) Use a KI SS approach ( keep it sim ple and stupid) R d th b f li f d R d th b f li f d  Reduce the num ber of lines of code Reduce the num ber of lines of code

– Higher Higher-

• level m odeling ( pow erful abstractions)

level m odeling ( pow erful abstractions) – Focus on “w hat” not “how ” Focus on “w hat” not “how ”

 Re Re-

• use already correct code

use already correct code y  Use experienced coders w ith good SW skills Use experienced coders w ith good SW skills  Use a structured SW developm ent m ethod Use a structured SW developm ent m ethod

– E.g., extrem e program m ing E.g., extrem e program m ing

Use a very sm all team ( < Use a very sm all team ( < 1 0 1 0 )  Use a very sm all team ( < Use a very sm all team ( < 1 0 1 0 )

– Each coder ow ns/ understands m ore of the interactions Each coder ow ns/ understands m ore of the interactions

 Use a concise and efficient language to express Use a concise and efficient language to express design in design in

– Rich strongly typed language Rich strongly typed language – A language w ith pow erful abstraction m echanism s A language w ith pow erful abstraction m echanism s

 Do thorough and form alized code review Do thorough and form alized code review

16

Make Design Easier to Check Make Design Easier to Check Make Design Easier to Check Make Design Easier to Check

 Make features orthogonal Make features orthogonal

– I n the high I n the high-

• level m odel, do not use sharing even

level m odel, do not use sharing even though the im plem entation w ill! though the im plem entation w ill!

 Avoid duplication of sam e/ sim ilar state Avoid duplication of sam e/ sim ilar state  Make m odules functional Make m odules functional  Make m odules functional Make m odules functional

– Avoid state Avoid state – Localize state to input and/ or output delays Localize state to input and/ or output delays

 “Overdesign” Overdesign”  Overdesign Overdesign

– Don’t take advantage of every don’t care Don’t take advantage of every don’t care

 Use standard w ell Use standard w ell-

• defined protocols

defined protocols betw een com ponents betw een com ponents betw een com ponents betw een com ponents

– Efficiency can be added during refinem ent Efficiency can be added during refinem ent

 Make don’t cares explicit Make don’t cares explicit

– Both tem poral and data Both tem poral and data

17

p

 Make environm ental assum ptions explicit Make environm ental assum ptions explicit

Make Bugs Easier to Find Make Bugs Easier to Find Make Bugs Easier to Find Make Bugs Easier to Find

 Make m odules self Make m odules self-

• contained

contained

– Localize im pact of bugs Localize im pact of bugs

 Make environm ental assum ptions Make environm ental assum ptions explicit explicit explicit explicit  Add invariants and properties to code Add invariants and properties to code  W rite com plex behaviors as a W rite com plex behaviors as a  W rite com plex behaviors as a W rite com plex behaviors as a com position of sim ple ones com position of sim ple ones

– Test/ verify each sim ple m odule Test/ verify each sim ple m odule

 Use an environm ent in w hich Use an environm ent in w hich com position is correct by construction com position is correct by construction

– E g very strong type checking ( including E g very strong type checking ( including

18

– E.g., very strong type checking ( including E.g., very strong type checking ( including properties and behaviors) properties and behaviors)

Capture Bugs Sooner Capture Bugs Sooner Capture Bugs Sooner Capture Bugs Sooner

 Static checks Static checks

– Strong typing Strong typing – Thorough Lint type program enforcing nam ing and Thorough Lint type program enforcing nam ing and coding style coding style – Form al verification of properties Form al verification of properties Form al verification of properties Form al verification of properties

– User w ritten properties User w ritten properties – Self consistency properties ( e.g., new feature did not Self consistency properties ( e.g., new feature did not break old functionality) break old functionality)

– Form al verification of equals Form al verification of equals-for for-equals equals Form al verification of equals Form al verification of equals-for for-equals equals

 Sym bolic Sim ulation Sym bolic Sim ulation  Dynam ic checks Dynam ic checks

– Faster sim ulation Faster sim ulation Faster sim ulation Faster sim ulation – HW em ulation HW em ulation – Extensive coverage m onitors Extensive coverage m onitors

 Add rigorous regression checks for checking Add rigorous regression checks for checking

19

Add rigorous regression checks for checking Add rigorous regression checks for checking in code into repository in code into repository

Logical Design Logical Design Transform ations Transform ations Transform ations Transform ations

 Add correct Add correct-

• by

by-

• construction

construction construction construction im plem entation im plem entation details details

– Exam ples: Exam ples:

waddr

Write Read

M din raddr dout

Read

M din raddr dout waddr

1

=

– Bypass Bypass – Re Re-

• tim ing

tim ing – Duplication/ m erging of Duplication/ m erging of logic logic – Changing state Changing state

Latch 1 Latch 2

~12

Latch 3

~4

Latch 1 Latch 2

~12 ~12

Latch 3

~4

Changing state Changing state encoding encoding – Don’t care usage Don’t care usage – I ntroducing clock I ntroducing clock gating gating – …

Latch 3 Latch 1 Latch 2

~9 ~7

Latch 3 Latch 1 Latch 2

~9 ~7

…

 Allow arbitrary Allow arbitrary design changes design changes w hen coupled w ith w hen coupled w ith m achine m achine checked checked

Latch 2 Latch 2

f

a b

f

a b

20

m achine m achine-checked checked justification justification

valid clk valid clk

Physical Design Physical Design Transform ations Transform ations Transform ations Transform ations

 Add physical details Add physical details

word-level bit-level – Exam ples: Exam ples:

– Change Hierarchy Change Hierarchy – Re Re-

• synthesize

synthesize – Change relative Change relative



Change relative Change relative placem ent placem ent – Change overlapping Change overlapping region constraints region constraints – Replace abstract w ires Replace abstract w ires

Spec

Block A: at most 40% utilized

p w ith sized/ repeated w ith sized/ repeated w ires w ires

 Again, allow Again, allow arbitrary design arbitrary design

Imp

Block B: at most 40% utilized

arbitrary design arbitrary design changes w hen changes w hen coupled w ith coupled w ith m achine m achine-checked checked

Imp

Block A: at most 60% utilized but in smaller area

21

m achine m achine checked checked justification justification

Block B: at most 80% utilized but in smaller area