A Design Flow for SingleChip Radios

1
A Design Flow for Single-Chip Radios

• Rhett Davis
• Qualifying Examination
• January 18th, 2000
• Department of Electrical Engineering and Computer
  Science
• University of California, Berkeley

2
CMOS density now allows complete
System-on-a-chip Solutions
Could also add

• FPGA
• Reconfigurable Interconnect

How do we design these heterogeneous systems?
3
The Industry Standard ASIC Design Flow
Architecture Micro-Architecture

• Difficulties
• Logic Verification
• Timing Closure
• Routing Congestion

Front-End
Problem Indeterminate Design Time
Back-End

• Design Decisions made at Every Step
• Unsolvable Problems Arise

4
Research Proposal
Problem How do we design complex integrated
circuit radios in a deterministic and minimal
time frame without sacrificing performance
(power/area/throughput)? Solution Develop a
design flow which begins with an encapsulation of
decisions made at the architecture, front-end and
back-end stages of the design process.
5
Approach

• Develop a Design Flow
• Fully Automated
• Restrict all decisions to beginning
• Demonstrate on at least two chips
• Direct-Mapped Radio Micro-Architecture
• Compare to other chips and flows

Key Challenge Demonstrate Functionality without
Sacrificing Performance
6
Outline

• Establish the initial description at different
  levels
• Approach to Common Chip Design Problems

7
Terminology
An Automated Design Flow is a directed, acyclic
graph

• Each node is a step. A step has associated with
  it a file or list of files
• A step with one or more outgoing edges is a
  dependency
• A step with one or more incoming edges is a
  target. Each target has associated with it a
  command to update the file(s) from the
  dependencies

This terminology focuses us on automation
8
Levels of Specification
Design decisions broken up in the following
categories

• Function Level - basic input-output behavior
• Signal Level - physical signals and types
• Circuit Level - transistors
• Floorplan Level - physical positions

How do we choose a initial description which
captures all of these decisions?
9
Simulink is a good Starting Point
Simulink Improves Interaction among Disciplines
Does a Simulink Model Qualify as a Specification?
10
Simulink Qualifies as a Function-Level
Specification
Simulink systems have been built which model

• Concurrent Hardware / Parallelism
• Datapath Control Logic (with Stateflow)
• Programmable Processors (with S-Functions)
• Fully Synchronous
• Mixed Signal (Analog Digital)

What about the other three levels?
11
Signal-Level SpecificationSimulink Fixed-Point
Types

• Apply Naming Restrictions to all ports and
  Subsystems
• Base all signal definitions on Simulink Subsystem
  ports
• Check the Simulink Fixed-Point type which drives
  the port
• Create an EDIF file which captures this
  information

Netlisting is the process of creating the EDIF
file from a Simulink model
12
Logical and Physical Hierarchies
Netlisting does more than specify signals, it
specifies a Physical Hierarchy

• Physical hierarchy affects clock skew, routing
  congestion
• Tools usually allow modifications of physical
  hierarchy

Recent studies have shown (Williams 1999) that
performance can be improved when logical and
physical hierarchies match
13
Signal-Level Specification Wires
Some Simulink Subsystems (called Wires)
correspond to special instructions to the
netlister

• Constant Shift - fixed wiring
• Constant Value - power and ground nets
• Compare-to-Zero - sign bit
• Ripper - arbitrary bit

This allows more detailed Signal-Level
Specification from Simulink
14
Gated Clocks

• Clock gating is modeled with Enable signals which
  can freeze the state of a register
• Enable Generators become gated clock buffers in
  the physical design

This allows more detailed Signal-Level
Specification from Simulink
15
Circuit-Level Specification Macros

• Upon encountering a Macro stops translating the
  hierarchy
• Embed certain subsystem mask parameters in the
  EDIF cell definitions as properties
• Read the EDIF file and create a schematic
  hierarchy based on Macro type

Elaboration captures transistor-level
specifications as Cadence Design Framework II
schematics
16
Fixed Mapping to Abstracts

• Elaboration does more than specify transistors,
  it specifies mask-layout, or more specifically,
  abstracts
• Each Macro type will have a fixed mapping to
  abstracts
• Block/Module Macros - single abstract
• VHDL/Stateflow Macros - netlist of standard cell
  abstracts
• Microprocessor Macros - single abstract for
  processor and memory, netlist of standard cells
  for interface

This allows us to add as much heterogeneity as we
like
17
Block Module Macros

• Block
• Simple Layout and Schematic
• Module
• Parameterized
• Tiled Layout
• Generated Schematic

Block Module Macros map to a Single Abstract
18
VHDL Stateflow Macros

• VHDL
• Synthesized Code
• Stateflow
• Extended Finite State Machine
• Subset of Syntax
• Converted to VHDL
• Synthesized

VHDL Stateflow Macros map to a netlist of
Standard Cell Abstracts
19
Microprocessor Macros

• Includes
• Processor
• Memory
• Bus
• Interface
• Hard Soft Cores
• Automatic Code Generation

Microprocessor Macros map to a more general
combination of abstracts
20
Floorplan-Level Specification
Problem Up to now, we have had a convenient way
to encapsulate information inside the Simulink
description, but there is no way to conveniently
add physical position information from within
Simulink Solution Add another input
description, another dependency to the design
flow. It makes sense for this description to be
a design hierarchy from a standard Floorplanning
tool (Cadence Design Planner / Pillar). Challenge
Floorplans are dependent on physical
hierarchies. How do we break this dependency?
21
Floorplan Merge

• Placement info merged from the floorplan into
  autoLayout based on instance names
• autoLayout hierarchies are user editable
• floorplan hierarchies created by saving
  autoLayout state
• Small changes in the Simulink should require
  small changes to the floorplan
• Simulink designer is responsible for creating the
  floorplan

This approach requires seamless automation to be
effective
22
Minimized Floorplanning

• The Simulink Designer is responsible for creating
  the floorplan in DesignPlanner with the following
  functions
• Draw Standard Cell Rows
• Align
• Distribute/Compact
• Boundary Compaction
• The floorplan contains placement information only
• Using these functions, the Simulink designer for
  our test chip (Paul Husted) was able to learn the
  tool and floorplan 58 of a 600,000 transistor
  chip in only 6 hours

23
Example Floorplan
24
Outline

• Establish the initial description at different
  levels
• Approach to Common Chip Design Problems

25
Approach to Logic Verification

• Fundamental Library of Macros correct by
  construction
• EPIC simulation to verify

This approach gives us scalability
26
Approach to Routing Congestion
Problems to be solved in Input Description or
with more complex design flow

• User-Settable Compaction Margins
• Block Placement Routines
• Changes to physical hierarchy

Make no decisions late in the design flow
27
Approach to Timing Closure

• Delay Characterization of Modules
• Buffer Macros
• Better Wire-Load Models
• Two-Phase, Non-Overlapping Clocks
• EPIC Pathmill to Verify

Concise Timing Methodology is still being
developed
28
Status

• icmake program working but not yet generalized
• Design Flow complete through to the floorplan
  merge step
• All macros functional except Stateflow
• Debugging the Fundamental Library available
  Add, Sub, Add_Sub, Reg, Reg_R, Mult, Neg, Comp,
  MUX, Rst_gen, En_gen available in fixed size
  Var_2shift, Var_3shift
• SCR1 Chip expected by March 1st, 2000
• 625,000 transistors, 516 module instances, 6
  Stateflow, 3 Lookup, 108 Subsystems, hierarchy
  depth of 5
• 2-phase, non-overlapping clocking scheme,
  full-scan
• Flow executes in 30 minutes

29
Future Work

• Complete the current flow (Spring 2000)
• Implement a concise timing methodology
  (Spring/Summer 2000)
• Implement a Micro-processor Macro(Summer/Fall
  2000)
• Generalize the icmake program (Spring 2001)

30
Supported Research Efforts

• BEE (Greg Wright, Hayden So)
• Minimal Energy Clocking (Prof. Borivoje Nikolic,
  Dejan Markovic)
• Algorithm Architecture Co-Design (Ning Zhang)
• Pico Radio(Prof. Jan Rabaey et al)

31
Summary of Contributions

• Exploration of a new design methodology on at
  least 2 chips
• CDMA Timing Recovery Chip
• Microprocessor-Based Chip
• Means of extending the methodology to further
  chip projects

32
Proposed Thesis Outline

• Chapter 1 The Standard ASIC Design Flow
• Chapter 2 Input Description
• Chapter 3 Design Flow Automation
• Chapter 4 Direct-Mapped Architecture Chip
• Chapter 5 Microprocessor/Direct-Mapped
  Architecture Chip