Applying Agile To Hardware Development

(…We’re Not That Different After All!)

Neil Johnson
XtremeEDA
[email protected]
http://www.AgileSoC.com

1
© 2011 XtremeEDA USA Corporation - Version 080721.10
About Me

•  Neil Johnson
–  12 years of hardware design and verification
–  Altera, Neterion, Flextronics, Nextwave Wireless
•  Principal Consultant XtremeEDA
–  Consulting services
•  Verification experts
–  Clients are any size and many applications
•  Telecom, networking, wireless, computer hardware, etc.
–  We work remotely or onsite as part a client’s team

2
© 2011 XtremeEDA USA Corporation - Version 080721.10
About Me

•  Neil Johnson
–  12 years of hardware design and verification
–  Altera, Neterion, Flextronics, Nextwave Wireless
•  Principal Consultant XtremeEDA
–  Consulting services
•  Verification experts
–  Clients are any size and many applications
•  Telecom, networking, wireless, computer hardware, etc.
–  We work remotely or onsite as part a client’s team

3
© 2011 XtremeEDA USA Corporation - Version 080721.10
Why Are You Here?

No Yes

Learn something from an agile expert

Become experts in Agile embedded development

4
© 2011 XtremeEDA USA Corporation - Version 080721.10
Why Are You Here?

No Yes

Learn something from an agile expert

Become experts in Agile embedded development

An overview of hardware process and the challenges

we face (Part I)

See how the principles of the agile manifesto apply to

hardware development (Part II)

How hardware teams can get started with agile and

how you can help (Part III)

5
© 2011 XtremeEDA USA Corporation - Version 080721.10
 Part I

What Are The Strange Hardware People

Doing?

6
© 2011 XtremeEDA USA Corporation - Version 080721.10
What Do I Mean By Hardware

•  ASIC
–  Application Specific Integrated Circuit
–  Static structure
–  Digital or mixed signal
–  High NRE/Low cost
•  FPGA
–  Field Programmable Gate Array
–  Reprogrammable structure
–  Primarily digital
–  No NRE/High cost
•  SoC
–  Either of the above + embedded processor(s) + software
7
© 2011 XtremeEDA USA Corporation - Version 080721.10
SoC Development Basics

•  Typical SoC design flow

–  Specification Documentation
–  Design
Pre-silicon Code
–  Verification
–  Physical design “Stuff”

8
© 2011 XtremeEDA USA Corporation - Version 080721.10
SoC Development Basics

•  Typical SoC design flow

–  Specification Documentation
–  Design
Pre-silicon Code
–  Verification
–  Physical design “Stuff”

–  Fabrication Chip
–  Validation Production Board
–  Integration System

9
© 2011 XtremeEDA USA Corporation - Version 080721.10
SoC Development Basics

•  Typical SoC design flow

–  Specification Documentation
–  Design
Pre-silicon Code
–  Verification
–  Physical design “Stuff”

–  Fabrication Chip
–  Validation Production Board
–  Integration System
OS
You Guys Drivers
Application

10
© 2011 XtremeEDA USA Corporation - Version 080721.10
Common Industry Challenges

•  Tape-out… aka: the big bang

–  NRE >$1million
•  Cost of first silicon > $10Million
•  We like to be careful!
•  Tape-out stress is very high

11
© 2011 XtremeEDA USA Corporation - Version 080721.10
Common Technical Challenges

•  Optimization Code Code

–  Size, speed, power

consumption, target Synthesis Compile

Hardware
Software
technology and time-to- Floor Planning Link
market Initial P&R

•  We depend on tools very, Timing Closure EXE

very heavily Equivalence Checking

–  Physical design is pretty Design Rule Checking

complicated relative to a Layout vs. Schematic
software build DFM Checking
GDSII Generation

To FAB

12
© 2011 XtremeEDA USA Corporation - Version 080721.10
Common Organizational Challenges

•  Organized primarily by function

–  Functional teams act independently
•  Design and verification don’t normally share goals
•  Common for software to be “out of the loop”
–  Physical and/or software teams are involved late
•  “deal with it” instead of working together

Design SW

Physical Verif

13
© 2011 XtremeEDA USA Corporation - Version 080721.10
Common Organi-technical(?) Challenges

•  The composition of an SoC is changing

–  Software is becoming dominant
–  Tools are being developed to integrate hw/sw
–  Encouragement of real teamwork lags

IP/Custom
Hardware
Embedded
Processor

14
© 2011 XtremeEDA USA Corporation - Version 080721.10
Big Bang Hardware Development

•  We do EVERYTHING in parallel with no objective way to

measure progress along the way
–  Strict product definition
–  Compartmentalization and vertical team organization
–  Teams quickly diverge; minimal communication
–  Long development times with few checkpoints
–  Subjective development status

Spec
Kaboom!!

15
© 2011 XtremeEDA USA Corporation - Version 080721.10
Big Bang Hardware Development

•  We do EVERYTHING at once with no objective way to

measure progress along the way
–  Strict product definition
…if a project managed
–  Compartmentalization by team
and vertical a defined process fails,
organization
people
–  Teams then diverge;
quickly assumeminimal
that the project failed because the
communication
defined
–  Long approach
development timeswas notcheckpoints
with few adhered to rigorously
enough. They conclude that all they need…is
–  Subjective development status
increased control and project definition.

Ken Schwaber, Agile Project Management with Scrum

Spec
Kaboom!!

16
© 2011 XtremeEDA USA Corporation - Version 080721.10
 Part II

Taking the Manifesto Where It Wasn’t

Meant To Go

17
© 2011 XtremeEDA USA Corporation - Version 080721.10
www.agilemanifesto.org

© 2011 XtremeEDA USA Corporation - Version 080721.10

Customer Collaboration

•  Customers can’t tell you exactly what they want

–  Feature creep is actually good!
–  Question what you’re building and why
–  Find the middle ground between acceptance and rejection
•  Prioritize requirements

© 2011 XtremeEDA USA Corporation - Version 080721.10

Individuals and Interactions

•  Building a cross-functional development team

Individual Ownership Of Shared Goals and

Individual Tasks Cooperative Problem Solving

Functional sub-teams Functional experts

Isolation Pairing
Documentation Conversation
Cubicles Co-located teams
Code that’s written Code that works
Reporting progress Demonstrating progress

© 2011 XtremeEDA USA Corporation - Version 080721.10

Individuals and Interactions

•  Visibility and Effective Communication

–  We prefer technical solutions over “people” solutions
•  bug data bases
•  project management sw/spreadsheets

“I…found that…Purely people factors predict project trajectories

quite well, overriding choice of process or technology.”
Alistair Cockburn, Agile Software Development: The Cooperative Game

© 2011 XtremeEDA USA Corporation - Version 080721.10

Working Software (Hardware)

•  Waterfall Model
–  A sequential process
–  One big bang, production
ready release at the end of
the project
–  Lessons learned for the
next project
–  Task driven development

© 2011 XtremeEDA USA Corporation - Version 080721.10

Working Software (Hardware)

•  Waterfall Model •  Agile model

–  A sequential process –  An iterative process
–  One big bang, production –  Many production ready “re-
ready release at the end of spins” during the project
the project –  Many opportunities for
–  Lessons learned for the feedback
next project –  Deliverables driven
–  Task driven development development with every
iteration

© 2011 XtremeEDA USA Corporation - Version 080721.10

Working Software (Hardware)

•  Waterfall Model •  Agile model

Physical Design Physical Design

50% Done
Software Software

Verification Verification

Design Design

Specification Specification

50% Done

© 2011 XtremeEDA USA Corporation - Version 080721.10

Working Software (Hardware)

•  Incremental coverage closure

–  Coverage model grows incrementally with the DUT

Software

Tests
Physical Design
Coverage Model

Environment Verification

50% Done
Design

Specification

50% Done

© 2011 XtremeEDA USA Corporation - Version 080721.10

Responding to Change

•  Regular regression testing

–  Add new features without breaking existing features
–  Start on day 1 to avoid introducing defects
•  Continuous integration
–  Small batch integration == quick & easy
–  large batch integration == slow & difficult

© 2011 XtremeEDA USA Corporation - Version 080721.10

The Solution: Agile Development

•  Instead of building everything at once, build a product

incrementally
–  Everything you would normally do, just do it a little
differently a little piece at a time

Kaboom!!

27
© 2011 XtremeEDA USA Corporation - Version 080721.10
 Part III

If it looks like a Duck…

And it quacks like a Duck…

You’re better off saying it’s a Rabbit.

28
© 2011 XtremeEDA USA Corporation - Version 080721.10
Where’s The Potential?

•  Agile model

Physical Design

Software

Verification SoC
Hardware Teams
Teams
Design

Specification

© 2011 XtremeEDA USA Corporation - Version 080721.10

Where’s The Potential?

Right Here
No Way!!

Maybe... but... I love agile

30
© 2011 XtremeEDA USA Corporation - Version 080721.10
Where’s The Potential?

•  Deviations from •  Agile articles and ideas

traditional hardware – “Agile software
development developers have a lot
– “Here is a different way of good ideas. We
to look at the things should use some of
you already do” them”

Maybe... but... I love agile

31
© 2011 XtremeEDA USA Corporation - Version 080721.10
Getting Comfortable:
www.agilemanifesto.org

Defined Approach Agile Approach

(Very Rigid) (Highly Adaptive)

Contract negotiation Customer collaboration

Processes and tools Individuals and interactions
Comprehensive documentation Working software (or hardware)
Following a plan Responding to change

© 2011 XtremeEDA USA Corporation - Version 080721.10

Where’s The Potential?

•  Working hardware over

comprehensive documentation Physical Design
–  We complete tasks, not features
•  Client experience #1: The Feature-of- Software
the-week
Verification
–  We develop everything at once... we
can’t help it!
Design
•  Client Experience: Just try and deliver
something (anything)
Specification
•  Exercise: Operation Basic Sanity
50% Done

33
© 2011 XtremeEDA USA Corporation - Version 080721.10
The Perfect Place To Start

•  Feature-of-the-week
–  “Tell your customer you’re going to give them something
that works in a week”
•  Jonathan Rassmuson, Agile in a Nutshell, APLN April 2009
–  The Agilesoc Blog: Remote Development And The Feature-
of-the-week

The feature-of-the-week is not Agile, it’s frequent

delivery... which is hard to argue against.

34
© 2011 XtremeEDA USA Corporation - Version 080721.10
Feature Of The Week

•  Client experience
–  Goal
•  Convince myself that incremental development is possible
–  Situation
•  Functional testing of a sub-system
•  Design was done, test harness was partially complete
–  Planning
•  4 increments, 1 for each major feature
•  Detailed plan included 1-2 week sub-milestones
•  2 increments planned in detail

35
© 2011 XtremeEDA USA Corporation - Version 080721.10
Feature Of The Week

•  Client experience - Highlights

–  Planning
•  The planning was different but no convincing was required
–  Increment 1
•  Uh oh… I’ve committed to delivering something in a week
•  First up: remove everything I don’t need

36
© 2011 XtremeEDA USA Corporation - Version 080721.10
Feature Of The Week

•  Client experience – Highlights (con’t)

–  Increment 2
•  I was focused and delivering on time
•  Functional milestones allowed me to react to new priorities
–  Increment 3
•  Functioning code was great for gaining confidence and/or
being corrected
•  I wasn’t so concerned with building infrastructure
–  Summary
•  Convince myself agile can work

37
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Situation
–  Deliver an internal IP block
–  Project well behind schedule
–  Just coding the design and test environment would take us
beyond our scheduled delivery date
•  Good time to introduce agile as an alternative to tradition
–  dealing with agile skeptics
–  I wanted to make sure that different still familiar so I didn’t
scare anyone away

38
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things

39
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
The “Old Way”
•  All the planning
•  Code the environment
•  Integrate the design
•  Sandbox debug
•  Write/debug sanity test

40
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
The “Old Way” Architecture
•  All the planning
•  Code the environment
•  Integrate the design
•  Sandbox debug
•  Write/debug sanity test
Implementation

41
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
The “Old Way” Architecture
•  All the planning •  Draft architecture plan
•  Code the environment
•  Integrate the design
•  Sandbox debug •  Revise architecture plan
•  Write/debug sanity test
Implementation

42
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
The “Old Way” Architecture
•  All the planning •  Draft architecture plan
•  Code the environment •  Skeleton test environment
•  Integrate the design
•  Sandbox debug •  Revise architecture plan
•  Write/debug sanity test
Implementation

43
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
The “Old Way” Architecture
•  All the planning •  Draft architecture plan
•  Code the environment •  Skeleton test environment
•  Integrate the design •  Integrate design
•  Sandbox debug •  Revise architecture plan
•  Write/debug sanity test
Implementation

44
© 2011 XtremeEDA USA Corporation - Version 080721.10
Client Experience: Just Try And Deliver

•  Recommendations
–  Prioritize a bypass solution to be used in case of emergency
–  Incrementally deliver the rest as a series of threads
–  Change the order in which we do things
Architecture
•  Draft architecture plan
•  Skeleton test environment
•  Integrate design
•  Revise architecture plan
Operation Basic Sanity:
Implementation
A Faster Way To Sane •  Draft implementation plan
Hardware •  Write the sanity test
•  Code the required sanity design/test
environment
•  Debug the sanity test
•  Revise the implementation plan

45
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

46
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

–  Start with a finished product

47
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

–  Start with a finished product
–  Identify the sanity path

48
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

–  Start with a finished product
–  Identify the sanity path
–  Remove everything you don’t need

49
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

–  Start with a finished product
–  Identify the sanity path
–  Remove everything you don’t need
–  Plan how to build what’s left

50
© 2011 XtremeEDA USA Corporation - Version 080721.10
Exercise: Operation Basic Sanity

•  Help teams plan a first product increment

–  Start with a finished product
–  Identify the sanity path
–  Remove everything you don’t need
–  Plan how to build what’s left

CPU

51
© 2011 XtremeEDA USA Corporation - Version 080721.10
Summary

•  What Are The Strange Hardware People Doing?

–  We’re doing big bang development... and it’s not working
•  Taking the Manifesto Where It Wasn’t Meant To Go
–  The manifesto absolutely applies to hardware development
•  If it looks like a Duck… And it quacks like a Duck…
–  Present agile in a way that makes sense to hardware developers
•  Resources
–  www.AgileSoC.com
•  blog/articles/video
–  open-ended rambling
•  [email protected] - @nosnhojn
•  [email protected] - @bryanmorrispeng

52
© 2011 XtremeEDA USA Corporation - Version 080721.10