System-on-a-chip
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

Design methods to facilitate rapid growth of SoCs Arvind PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

System-on-a-chip. Design methods to facilitate rapid growth of SoCs Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology. The biggest SoC drivers. Explosive growth in markets for cell phones game boxes sensors and actuators.

Download Presentation

Design methods to facilitate rapid growth of SoCs Arvind

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Design methods to facilitate rapid growth of socs arvind

System-on-a-chip

Design methods to facilitate rapid growth of SoCs

Arvind

Computer Science & Artificial Intelligence Lab

Massachusetts Institute of Technology

http://csg.csail.mit.edu/arvind


The biggest soc drivers

The biggest SoC drivers

  • Explosive growth in markets for

    • cell phones

    • game boxes

    • sensors and actuators

Functionality and applications are constrained primarily by:

- cost

- power/energy constrains

http://csg.csail.mit.edu/arvind/


Current cellphone architecture

WLAN RF

WCDMA/GSM RF

WLAN RF

WLAN RF

Comms. Processing

Application Processing

Current Cellphone Architecture

Today’s chip becomes a block in tomorrow’s chip

IP reuse is essential

Hardware/software migration

IP = Intellectual Property

Complex, High Performance

but must not dissipate more than 3 watts

http://csg.csail.mit.edu/arvind/


An under appreciated fact

An under appreciated fact

  • If a functionality (e.g. H.264) is moved from a programmable device to a specialized hardware block, the power/energy savings are 100 to 1000 fold

Power savings  more specialized hardware

but our mind set

  • Software is forgiving

  • Hardware design is difficult, inflexible, brittle, error prone, ...

http://csg.csail.mit.edu/arvind/


Soc trajectory multicores heterogeneous regular

IBM Cell Processor

On-chip memory banks

Application-specific processing units

General-purpose processors

Structured on-chip networks

SoC Trajectory:multicores, heterogeneous, regular, ...

Can we rapidly produce high-quality chips and surrounding systems and software?

http://csg.csail.mit.edu/arvind/


Things to remember

Things to remember

  • Design costs (hardware & software) dominate

  • Within these costs verification and validation costs dominate

  • IP reuse is essential to prevent design-team sizes from exploding

design cost = number of engineers x time to design

http://csg.csail.mit.edu/arvind/


Common quotes

Almost complete reliance on post-design verification for quality

Mind set

Common quotes

  • “Design is not a problem; design is easy”

  • “Verification is a problem”

  • “Timing closure is a problem”

  • “Physical design is a problem”

http://csg.csail.mit.edu/arvind/


Through the early 1980s

Make

Inspect

Rework

Defect

Defect

Defect

Through the early 1980s:

The U.S. auto industry

  • Sought quality solely through post-build inspection

  • Planned for defects and rework

    and U.S. quality was…

http://csg.csail.mit.edu/arvind/


Less than world class

… less than world class

  • Adding quality inspectors (“verification engineers”) and giving them better tools, was not the solution

  • The Japanese auto industry showed the way

    • “Zero defect” manufacturing

http://csg.csail.mit.edu/arvind/


New mind set design affects everything

New mind set:Design affects everything!

  • A good design methodology

    • Can keep up with changing specs

    • Permits architectural exploration

    • Facilitates verification and debugging

    • Eases changes for timing closure

    • Eases changes for physical design

    • Promotes reuse

 It is essential to

Design for Correctness

http://csg.csail.mit.edu/arvind/


New ways of expressing behavior to reduce design complexity

New ways of expressing behavior to reduce design complexity

  • Decentralize complexity:Rule-based specifications (Guarded Atomic Actions)

    • Lets you think one rule at a time

  • Formalize composition: Modules with guarded interfaces

    • Automatically manage and ensure the correctness of connectivity, i.e., correct-by-construction methodology

Strong flavor of Unity

Bluespec

  • Smaller, simpler, clearer, more correct code for both simulation AND synthesis

http://csg.csail.mit.edu/arvind/


Reusing ip blocks

data_inpush_req_npop_req_nclkrstn

data_outfullempty

Reusing IP Blocks

Example: Commercially available FIFO IP block

No machine verification of such informal constraints is feasible

These constraints are spread over many pages of the documentation...

http://csg.csail.mit.edu/arvind/


Bluespec promotes composition through guarded interfaces

theFifo.enq(value1);

Enqueue arbitration control

theFifo.deq();

value2 = theFifo.first();

enab

not full

rdy

enab

not empty

rdy

not empty

theFifo.enq(value3);

rdy

Dequeue arbitration control

theFifo.deq();

value4 = theFifo.first();

Bluespec promotes compositionthrough guarded interfaces

Self-documenting interfaces;

Automatic generation of logic to eliminate conflicts in use.

theModuleA

theFifo

n

enq

theModuleB

deq

FIFO

n

first

http://csg.csail.mit.edu/arvind/


Bluespec state and rules organized into modules

module

interface

Bluespec: State and Rules organized into modules

All state (e.g., Registers, FIFOs, RAMs, ...) is explicit.

Behavior is expressed in terms of atomic actions on the state:

Rule: guard  action

Rules can manipulate state in other modules only via their interfaces.

http://csg.csail.mit.edu/arvind/


The plan

The Plan

  • BS2- Simple Example: GCD

  • BS3- Combinational Circuits: IFFT

  • BS4- Architectural Exploration: 802.11a

  • BS5- The IP Lookup problem; subtle concurrency issues

  • BS6- Bluespec Semantics and Scheduling Primitives

Bluespec is available in two versions:

BSV – Bluespec in System Verilog

ESEPro – Bluespec in SystemC

These lectures will use BSV syntax

http://csg.csail.mit.edu/arvind/


  • Login