The Future of EDA: The Future of EDA: The Future of EDA: The - - PowerPoint PPT Presentation

The Future of EDA: The Future of EDA: The Future of EDA: Methodology, Tools d S l ti The Future of EDA: Methodology, Tools d S l ti and Solutions and Solutions

Sharad Malik Princeton University Sharad Malik Princeton University ceto U e s ty

NSF Future of EDA Workshop

ceto U e s ty

NSF Future of EDA Workshop July 8-9, 2009 July 8-9, 2009

Essence of EDA

• Tools follow methodology
• ASIC Design Methodology

Standard Cells – Standard Cells – Synchronous Timing Defined sub-problems based on what needed to

Source: vlsitechnology.org

be solved, and what could be reasonably solved

• Tools support methodology

gy

– Provide

• Design productivity
• Design quality

es g qua ty

Source: chipdesignhome.com

Design in the Late- and Post- Design in the Late and Post Silicon Era

Our Charter

– Enable Moore’s Law

• Reduce cost/unit-function
• Functionality includes all aspects of design quality

– power, performance, reliability, usability

• Significant threats to all aspects of reducing cost and

increasing functionality

– Design verification and test – Staying within power budgets – Reliable designs on unreliable fabrics – Usability through efficient programmability

Moore’s Law and Design Verification Moore s Law and Design Verification

Moore’s Law: Growth rate of transistors/IC is exponential

– Corollary 1: Growth rate of state bits/IC is exponential – Corollary 2: Growth rate of state space (proxy for complexity) is Corollary 2: Growth rate of state space (proxy for complexity) is doubly exponential

But…

C G f – Corollary 3: Growth rate of compute power is exponential

Thus…

– Growth rate of complexity is still doubly exponential relative to Growth rate of complexity is still doubly exponential relative to

• ur ability to deal with it

Design methodology must adapt to deal with this.

Possible Solution Direction: Possible Solution Direction: Runtime Validation

• Increasingly need to reconcile ourselves to the

fact that hardware like software will be shipped ith b with bugs

• Runtime validation (through error detection and

recovery) offers a potentially scalable solution recovery) offers a potentially scalable solution

– Provide robustness in the face of inevitable bug escapes escapes

• Significantly reduce verification costs

– Verify chips “to life” rather than “to death” y p

Solution Direction: Runtime Validation

Transient Faults due to Transient Faults due to Cosmic Rays & Alpha Particles Cosmic Rays & Alpha Particles

(Increase exponentially with (Increase exponentially with n mber of de ices on chip) n mber of de ices on chip)

Parametric Variability Parametric Variability

(Uncertainty in device and environment) (Uncertainty in device and environment)

Intra die variations in ILD thickness

number of devices on chip) number of devices on chip)

Intra-die variations in ILD thickness

Figure Source: T. Austin

• Dynamic errors which occur at runtime
• Will need runtime solutions
• Will need runtime solutions
• Combine with runtime solutions for functional errors

(design bugs)

Example: Checking Memory Consistency

• A directed graph that models memory ordering constraints

– Vertices: dynamic memory instruction instances

[H. W. Cain et al., PACT’03] [D. Shasha et al., TOPLAS’88]

– Vertices: dynamic memory instruction instances – Edges:

• Consistency edges A cycle in the graph indicates a

A cycle in the graph indicates a memory ordering violation memory ordering violation

• Dependence edges

ST A P1 P2 ST A P1 P2 ST A P1 P2 ST A P1 P2 ST A P1 P2 ST A P1 P2

y g y g

ST A ST B LD B LD A ST A ST A ST B LD D LD A ST A ST A ST B MB LD A ST A ST A ST B LD D LD A ST B ST A ST B LD D LD A ST B ST A ST B MB LD A ST B LD B LD C ST A ST A ST C LD A LD D LD C ST A S ST C LD A LD C ST A ST C LD A LD D LD C ST A ST B ST C LD D LD C ST A S ST C LD C ST A ST C

Sequential Consistency Total Store Ordering Weak Ordering

LD A LD A LD A

Extensions for Transactional Memory

• Extended constraint graph for transaction semantics

– Non-transactional code assumes Sequential Consistency

LD A P1 P2 LD A

TransOpOp: [Op1; Op2] => Op1 ≤ Op2

ST B TStart LD A TStart

TransMembar: Op1; [Op2] => Op1 ≤ Op2 [O 1] O 2 O 1 O 2

LD C LD D ST C ST D

TransAtomicity: [Op1]; Op2 => Op1 ≤ Op2

TEnd ST A TEnd LD B

TransAtomicity: [Op1; Op2] ¬ [Op1; Op; Op2] =>

LD E ST F

(Op ≤ Op1)  (Op2 ≤ Op)

On-the-fly Graph Checking

DFS h b d l DFS h b d l

Processor Core

Processor Core

Processor Core

Processor Core

Processor Core

Processor Core

L l L l

Central DFS search based cycle checker for sparse graphs Central DFS search based cycle checker for sparse graphs

Processor Core

Processor Core

L l L l

L1 Cache

Cache Controller

L1 Cache

Cache Controller

L1 Cache

Cache Controller

L1 Cache

Cache Controller

L1 Cache

Cache Controller

L1 Cache

Cache Controller

Local Observer

Local Observer

Local Observer

Local Observer

Graph Checker Graph Checker

L1 Cache

Cache Controller

L1 Cache

Cache Controller

Local Observer

Local Observer

Local Observer

Local Observer

L2 C h

Interconnection Network

L2 Cache Interconnection Network L2 C h

Interconnection Network

L2 Cache Interconnection Network L2 Cache L2 Cache L2 Cache L2 Cache

• Local observer:
• Local instruction ordering
• Central checker:
• Build the global constraint graph
• Local access history
• Locally observed inter-processor edges

Build the global constraint graph

• Check for the acyclic property

P ti l D i Ch ll Practical Design Challenges

A naively built constraint graph that includes all executed memory instructions

• Billions of vertices
• Billions of vertices
• Unbounded graph size

Key Enabling Techniques

Graph Reduction Graph Slicing

Enables checking of graphs of a few Enables checking of graphs of a few hundred vertices every 10K cycles hundred vertices every 10K cycles hundred vertices every 10K cycles hundred vertices every 10K cycles

Runtime Validation: Runtime Validation: Key Advantages

• Common framework for a range of defects
• Manage pre-silicon verification costs

– Have predictable verification schedules p – Support bug escapes through runtime validation

• Complexity, Performance Tradeoffs

– Common mode Common mode

• High performance, high complexity

– (Infrequent) Recovery mode

• Low complexity, low performance
• Leverage check-pointing support

– Backward error recovery through rollback – Relevant for high-performance to support speculation g p pp p

Pre-Silicon vs. Runtime Validation

• Complementary Strengths

– Large state space

• Pre-silicon: Incomplete formal verification, simulation
• Runtime: Easy - observe only actual state

– State observability State observability

• Runtime: Challenging to observe

– Distributed state, large number of variables

• Pre Silicon: Easy

just variables in software models for

• Pre-Silicon: Easy – just variables in software models for

simulation or formal verification

Future Challenges

• Keep costs low, with increasing complexity and failure

modes

• A discipline for runtime validation?
• A discipline for runtime validation?

– Mature from one-off solutions to a general methodology – General checking and recovery mechanisms

• Checking

– Design assertions

• Recovery

– Generalized check-pointing and rollback

– Analysis and synthesis tool support for the above