The SDR dichotomy

1
The SDR dichotomy

• Software-defined radios combine very powerful,
  low-level signal processing with very
  complex,high-level control
• Communications devices always require power,
  energy, and spatial efficiency

2
The critical tradeoffEase of design vs.
performance

• Industry consistently chooses software design for
  the short turnaround time and learning curve
• Software-based architectures are severely less
  efficient than direct hardware mapping and work
  poorly in real-time applications

3
The inefficiencies of software

• CPU power consumption scales with performance
• Limited ILP prevents parallel speedup
• Sequential architecture poorly utilizes area
• Caches will dominate die area around tiny core

4
The difficulties of hardware

• Mainstream hardware design involves synthesis of
  HDL and routing of components
• Synthesis can result in performance uncertainty
  and requires a high level of skill
• Place and route is an extremely long process
• HDL-based design must be at a farily low level of
  abstraction to remain efficient
• Algorithm designers often must pass designs on to
  a hardware team for manual translation

5
The BEE 1.0 approach

• Designs entered graphically in Simulink and
  Stateflow
• Large, tiled structures can be tedious to deal
  with
• Place and route is inherently slow
• But mapping to hardware is clear
• Debugging is done within Simulink or with
  ChipScope
• Two debug phases, before and after hardware
  implementation
• Simulink is far too slow
• ChipScope requires a priori setup

6
Missing components of BEE

• A straightforward yet powerful programming model
  with an efficient mapping to hardware
• Rapid in-the-loop verification and debugging
  directly on BEE
• A quick and seamless model for accessing on-chip
  resources from client workstations

7
Programming model

• Hybrid text/graphical description
• Exploit the objective nature of hardware
• Preserve a direct mapping to library blocks
• Expose performance tradeoffs and/or block
  placement to the designer
• Allow designer to choose text or graphical
  formats at any level of the hierarchy
• Several language options
• Build on top of Matlab (simpler to integrate with
  existing BEE/Xilinx back-end flow)
• Start with an OOP purists language like CLOS or
  Smalltalk (risky, but more potential to radically
  change the model)
• Develop a completely new language (i.e.
  Basis/Metavolt by Adam Megacz)

block MAC(in, out, sattrue) sig Ni new
fastvar(8, 2, 1)sig result m0 new mult(in,
Ni, sat)acc new add(m0.out, result.d,
sat)result acc.outout result.d
8
Debugging and monitoring

• Possibly the most attractive benefit of software
• Performed on same platform and at same speed as
  final product
• Need hardware equivalents of printf and gdb
• One for coarse testing and one for intense
  cycle-by-cycle operation
• Should help cope with the complexity of parallel
  system state
• Must play nice with existing implementation time
  (long PR)
• Minimize the need to rerun PR, until partial
  reconfiguration and hardware-acceleration become
  common

Design
Performance estimates?(future)
Compile(map, PR, etc.)
Verify andDebug
Maximize iterationswithin this stage
9
Hardware user interfaces

• A fundamental part of increasing the usability of
  pure hardware systems is fast and simple access
  to on-chip resources
• Custom-designed hardware block communicates
  between the running FPGA and the embedded Linux
  for network access
• Custom-made Matlab GUI provides direct data and
  control features to on-chip designs before,
  during, and after runtime