Design Methodology for PicoRadio

1
Design Methodology for PicoRadio

• Fernando De Bernardinis
• Marco Sgroi
• Julio Silva

2
The Goal

• Design Methodology for Wireless Systems
• PicoRadio starting from the functional and
  performance requirements of the entire system
• Design the network protocols (routing, MAC)
• Design each network node
• Communication Refinement
• From System Specification to Implementation
• Identify levels of abstraction
• Transformations correct by construction
• Propagate constraints. Top-down vs. Bottom-up

3
Levels of Abstraction
4
Bubblesrequirements, architecture, constraints.
Functional Performance Requirements
Architecture capabilities
Performance analysis (constraints)
5
Bubblesrequirements, architecture, constraints.
Network level
OPNET, NS
Constraints
Node level
VCC, POLIS
6
Intercom
Slide from Fred

• Centralized (single-cell) network lt 32 active
  users
• MAC layer TDMA (20 slots)
• Voice

7
From the Intercom board
Program-mable logic
Software running on processor
Protocol
Proxim Radio
ADC
Digital Baseband processing
Analog RF
DAC
Slide from Josie
8
to the Two-Chip Intercom
Program-mable logic
Software running on processor
Custom analog circuitry
Mixed analog/ digital
Fixed logic
Protocol
ADC
Digital Baseband processing
Analog RF
DAC
Chip 2
Chip 1
Slide from Josie
9
Why TCI?

• Intercom possibly one application of PicoRadio
• Integration of 1) Protocol Stack, 2) Baseband,
  3) ADCs and 4) Analog RF
• Experiment the use of several tools Polis, VCC,
  Stateflow/Simulink
• Evaluate architectures including reconfigurable
  processors (Tensilica), bus (Sonics)

10
Four components
11
Protocol Design

• Specification
• formally describing what the protocol is supposed
  to do
• Verification
• is the protocol logically consistent?
• Performance Estimation
• is the protocol efficient?
• Implementation
• building a system that implements the
  specification

12
Protocol DesignPast Design Flow

• Informal mapping between different models
• No guarantee of functional correctness
• No system level design exploration
• Little performance optimizations
• Hw synthesis
• No direct path from SDL to HDLs
• Sw synthesis
• Automatically generated using SDT

Textual Spec
Informal
SDL
Informal
Formal/Informal
Hw (VHDL)
Sw (C)
13
User Interface
DPCM
Control
ARM MAC
Xilinx MAC
Synchr.

• Control vs. Datapath
• Software vs. Hardware

S/P
P/S
Proxim Radio
14
User Interface
DPCM
Control
ARM (SDL)
ARM MAC
Xilinx MAC
Synchr.
FPGA (VHDL)
CRC
S/P
P/S
Proxim Radio
15
User Interface
DPCM
Control
ARM MAC
Datapath
Xilinx MAC
Control
Synchr.
CRC
S/P
P/S
Proxim Radio
16
Protocol Designmethodology under test
System Spec
Input language (ECL,SDL)
Co-simulation Formal Verification
Model of Computation ECFSMs
Refinement
Implementation Hw (VHDL) / Sw (C)

• Based on a formal Model of Computation (ECFSMs)
• Unbiased towards SW or HW
• Modeling mixed Control/Dataflow specs
• Supporting Communication Refinement
• Allows to cleanly define layers and interfaces
• Performance simulation Architecture exploration
• Architectural modeling
• Hw and SW estimation
• Direct path to implementation
• Reuse

17
User Interface
DPCM
Transport
S/P
P/S
18
VCC Design Flow
(from the VCC manual)
19
Behavior Models of Computations

• Main model CFSMs
• State Transition Diagrams
• for simple-moderate cases provide a clear visual
  representation
• may be more complex to debug
• White C (subset of C)
• textual, can handle complexity better
• ECL (future release)
• Some blocks are implemented in C/C
• can have more general behaviors
• can import/reuse code/IPs
• useful for testbench generation
• Simulator Semantics Discrete Event
• functional simulations
• performance simulations

20
Costs vs. Benefits

• What the VCC methodology
• assumes (functional simulation)
• Asynchronous semantics (no 2 events at the same
  instant)
• Concurrent model of execution without time
• costs
• Explicit synchronization/sequentialization
• allows
• Unbiased design exploration (no assumptions on
  the executing model)
• Behavior specification independent of
  architecture related details
• Communication Refinement
• Performance simulations

21
Architecture and Mapping

• Architectural components
• CPUs
• ASICs
• Scheduler/OS
• Bus
• Architectures can be parameterized, partially
  specified, hierarchical
• Mapping
• associates a behavioral block with an
  architectural resource
• associates a given communication with a bus

22
Performance Simulation

• Timed semantics
• each block introduces a delay
• there may be different events at the same time
• communication may part of the performance
  estimation
• Allows incremental refinement of
  behavior/architecture
• not everything needs to be specified at once
• e.g., bus models may be introduced and refined
  later along with the architecture (bus
  width,frequency, etc.)
• Automatic estimation for White C, STDs, SDL--
• however, errors may range from 20-100
• Delay Scripting Language for BlackBoxes and ASICs
• the user has to provide some input

23
What is it useful for?

• VCC allows (or imposes?) a clear separation among
  behavior, architecture, communication and time
• Architecture/Behavior can be incrementally tuned
  after exploration
• The final output of VCC is a (refined) behavior
  and an architecture suitable for automatic
  synthesis/compilation
• However, the backend tools is not ready yet, so
  there is no automatic way of getting an
  implementation out of VCC now