Processor performance trend

1
Processor performance trend

• Software performance is increased almost entirely
  through higher core frequency
• Power consumption follows closely behind and is
  becoming the new limiting factor
• Improvement through parallelism is limited by
  available ILP and preserving program order

2
Transistor scaling challenge

• What can we do with gt106 transistors?
• 1GB L2 cache not efficient or even useful
• Many parallel cores parallel-processing software
  is already prohibitively difficult
• Entire PC on a chippossibly, but not just by
  direct integration

Cache
µP
0.05µm die?
3
21st century computing

• Previous reconfigurable research was more focused
  on hardware accelerators generated or allocated
  by a software host
• Can we gain significant power and energy
  efficiency by using entirely direct-mapped
  hardware (no sequential instructions) on-the-fly?
• Can we create a natural programming model which
  preserves the algorithms parallelism, but is as
  intuitive to write as C/C/Java?
• Goal Use massively parallel field-programmable
  hardware (BEE) as a general-purpose computer

4
Solidifying software

• Dataflow Operations
• Typically the CPU-intensive part of a program
  (searching, audio/video encoding, graphical
  rendering)
• Often contains explicit parallelism
• Well-known and well-investigated in
  reconfigurable research
• Design flow already exists

• Control Operations
• The high-level, decision-based parts of a program
• Traditional software roles (GUIs)
• Event-driven in human time
• Less research in hardware domain and automation
• Design flow already exists

BEE / SysGen
BEE / SF2VHD
5
Approach 1 (bottom-up)Revisit ILP techniques

• Tremendous amount of research on ILP in
  architecture community (trace scheduling,
  register renaming, branch/jump prediction)
• Always fell short due to branch penalties, finite
  register files, and preserving program order
• Direct-mapped hardware provides free (purely
  parallel) speculative execution and nearly
  infinite register resources
• Precise interrupts and program order take on a
  whole new meaning, and remain an open issue
• Benefit binary compatibility with existing
  programming methods and legacy applications

6
Approach 2 (top-down)Reapply programming model

• Software has the perception of faster design time
  and a shorter learning curve
• Graphical hardware design entry (Simulink /
  Stateflow) can be tedious and confusing
• Textual hardware description with synthesis is
  very hard to master, and leaves much uncertainty
  about the resulting hardware
• A programming model must be built with a direct
  path to hardware, but simplicity and
  predictability for the user

7
Current stepHardware command shell

• BEE StrongARM/Linux host acts as a network
  character device
• Character buffer queues the command and detects
  token boundaries (spaces)
• A comparator matches the command to a known list
  and references a string table ROM for sending
  back responses
• In the near future, the open command will trigger
  a system call to access the file system

8
Next stepDefining function calls

• In user space, a function call is just
  instantiating a hardware library macro
• Initially, each function call can be replicated
• Eventually, it may be better to share and
  time-multiplex complex, non-stream based
  functions (printf, scanf, GUI events)
• In kernel space, the equivalent is a system call,
  which must trap to the OS to access a shared
  resource
• Kernel system call protocol is being designed
  with Hayden So

9
Future work

• Help define and implement the kernel system call
  interface and file system
• Evaluate each software solidification approach
  and choose the best method
• Re-implement some existing BEE functions to use
  the hardware command shell
• Investigate possibilities for function reuse,
  context switching, and memory management