Baseband Multicore challenge

1
Baseband Multicore challenge

• A view from the Baseband Research Team

2
Baseband requirements HW

• Hard latency demands hard realtime
• Should be reconfigurable every millisecond.
• Embedded All resources always very scarce
• Partly Embarrassingly parallel, partly not.
• Scalability

3
Baseband requirements HW

• Heterogeous (example Cell)
• Special purpose accelerators
• Low power gt low clock frequency

4
Challenges

• Deployment
• Reconfiguration in runtime

5
The dynamic challange
6
Challenges

• Deployment
• Reconfiguration in runtime
• Programming model
• Engineering efficiency
• Debugging
• Verification
• Heterogeous HW/SW? (Several types of functions,
  HW, and languages in system (assembler, C,
  Erlang, xtUML))

For how long can we continue to build on
ASICsclassical DSPs? How to be prepared for the
new times to come?
7
(No Transcript)
8
Cambrian Explosion
?
9
Important multicore questions

• How to split a problem (e.g. de-interleaving) in
  unnaturally small pieces in the most efficient
  way (mainly regarding latency)? Different
  difficulties depending on target architecture
• Which of the architectures on the market is the
  best for our purpose?
• How could it be even better?
• Which of the architectures on the market will be
  commercially successful?
• How is the relation between HW SW development
  in these typically HW centered companies?
  Holistic? Cooperative? Ignorant?

10
Multicore hardware to keep an eye on

• ASIC hard as a rock
• FPGA soft as a chewing-gum.
• Single- and few-core DSP CPU
• Application Specific SOCs.
• Single- and few-core DSP CPU with off-load
  engine
• Hard off-load engines
• Software-configurable off-load engines
• SIMD
• MIMD
• Multi-core DSP CPU

TI DSP Proton
11
MPR view of the future

• For a project manager, the easy way out is to
  ignore the new extreme architectures in favor of
  conventional solutions. In the old days, nobody
  ever got fired for buying IBM. Today, the safe
  bets are probably DSPs or ASSPs from major
  vendors like Analog Devices, Broadcom, or TI. But
  taking the safe route may overlook a
  more-flexible, higher-performance, lower-cost,
  lower-power architecturealbeit one that requires
  more time to understand. A competitor that spends
  that additional time might design a better
  product. Such are the hazards of architectural
  abundance. (Tom R. Halfhill)

12
(No Transcript)