Behavioral Synthesis of RunTime Reconfigurable Networking Devices

1
Behavioral Synthesis of Run-Time
ReconfigurableNetworking Devices
5th International Symposium on Communication
Systems, Networks and Digital Signal Processing
CSNDSP 06

• George Economakos and Sotirios Xydis
• NTUA - GREECE

National Technical University of Athens
2
Outline

• Key ideas
• Motivation
• Other approaches
• Introductory material
• Proposed methodology
• Experimental results
• Implementation issues
• Conclusion

3
Key ideas

• Hardware
• Optimized area
• High speed
• Low flexibility

• Software
• Large area
• Moderate speed
• Very high flexibility

Reconfigurable Hardware Optimized area, High
speed, High flexibility
4
Key ideas

• Field Programmable Gate Arrays (FPGAs)
• Contain an array of computational elements whose
  functionality is determined through multiple
  programmable configuration bits
• These elements are connected using a set of
  routing resources that are also programmable

5
Key ideas
The most common configuration technique is to use
Look-Up Tables (LUTs) implemented with RAM
6
Key ideas

• Frequently the areas of a program that can be
  accelerated through the use of reconfigurable
  hardware are too numerous or complex to be loaded
  simultaneously onto the available hardware. For
  these cases it is beneficial to be able to swap
  different configurations in and out of the
  reconfigurable hardware as they are needed.

7
Key Ideas
Run-Time Reconfiguration (RTR) supports the
concept of Virtual Hardware
8
Key ideas

• FPGAs require less manufacturing and testing time
• Modern FPGAs are very powerful
• Modern design techniques seek to minimize design
  time as well
• As a consequence, FPGA based consumer electronics
  hit the market earlier without performance cost
• High-Level Synthesis (HLS) transforms algorithms
  into structures and provide fast design space
  exploration
• In communication and networking applications,
  with complicated control paths, HLS supports
  speculative execution to achieve better throughput

9
Key ideas
10
Motivation

• The architecture HLS generates has relative small
  arithmetic blocks that can be reconfigured very
  fast
• When an arithmetic block is idle it can be
  reconfigured in some other needed type
• In Xilinx FPGAs, a LUT based multiplier takes 3-4
  times the memory of an adder (of the same bit
  width)
• In modern architectures reconfiguration time can
  be as little as 10ns (and this is going to be
  even lower in the near future)
• This paper proposes a scheduling heuristic that
  utilizes reconfigurable components used as either
  1 multiplier or 3 adders and produces shorter
  schedules that outperform speed degradation due
  to reconfiguration time

11
Other approaces

• In modern devices each LUT may have multiple
  configurations (i.e. 8). A hardware context
  switch performs RTR.
• Conventional devices can be used with the same
  idea if we have LUTs to spare.
• RTR can be effective if reconfigurations are kept
  to a minimum during the whole life time of the
  application.
• Reconfigurable arithmetic components (using MUXs)
  have been proposed as a way to share hardware
  resources in non-programmable devices.

12
Introductory material

• 2 , 2 X
• 2 , 1 X, 1 RTR

13
Introductory material

• 1 , 2 X

14
Introductory material

• 1 , 1 X, 1 RTR

15
Proposed methodology

• Resource constrained list scheduling heuristic

16
Proposed methodology

• Modify resource constrained list scheduling
  heuristic to
• Combine priority lists of operations that can be
  executed in a reconfigurable component
• When reconfigurable and on-reconfigurable
  components are available, the latter take
  precedence
• Decrease the number of available reconfigurable
  components in a control step only when they are
  fully covered

17
Proposed methodology

• For complicated control flows (like network
  protocols)
• Isolate code blocks with exact one entry and one
  exit point (basic blocks).
• Find the shortest schedule for each basic block
  and for all possible reconfigurations.
• Combine the schedules of each block adding
  reconfiguration control step when required.

18
Experimental Results
19
Implementation issues

• Use an embedded processor for RTR
• A slice of the FPGA is written in memory, small
  modifications are applied (to make 1 multiplier 3
  adders) and put back in configuration memory

20
Conclusion

• RTR can fit large algorithms into small chips.
• HLS can be combined with RTR and provide faster
  implementations (even 50).
• As reconfiguration time is continuously
  decreasing, this technique may be proven very
  effective.