Design methodology for partial dynamic reconfiguration: a new degree of freedom in HWSW codesign Dyn

1
Design methodology for partial dynamic
reconfiguration a new degree of freedom in HW/SW
codesignDynamic Reconfigurability in Embedded
System Design
Donatella Sciuto sciuto_at_elet.polimi.it Marco
Santambrogio marco.santambrogio_at_dresd.org
2
Outline

• Reconfiguration
• Motivations
• Definition
• A birds eye view
• An overall design flow
• Reconfiguration Management
• Commercial Design flows
• DRESD
• Goals
• Innovative contributions
• The proposed approach
• High Level Reconfiguration
• Simulation
• Low Level Reconfiguration
• Case study
• Runtime Reconfiguration Management
• New frontiers
• Whats next...

2
3
Reconfigurable Computing

• Reconfigurable computing is intended to fill the
  gap between hardware and software, achieving
  potentially much higher performance than
  software, while maintaining a higher level of
  flexibility than hardware
• (K. Compton and S. Hauck, Reconfigurable
  Computing a Survey of Systems and Software, 2002)

3
4
Motivations

• Increasing need for behavioral flexibility in
  embedded systems design
• Support of new standards, e.g. in media
  processing
• Addition of new features
• Applications too large to fit on the device all
  at once
• Speedup the overall computation of the final
  system
• However, we need a way to process a specification
  to make it suitable for reconfigurable
  implementation

4
5
Motivations something more...
5
6
Motivations something more...
6
7
Reconfiguration

• The process of physically altering the location
  or functionality of network or system elements.
  Automatic configuration describes the way
  sophisticated networks can readjust themselves in
  the event of a link or device failing, enabling
  the network to continue operation.
• Gerald Estrin, 1960

8
Reconfigurability characterization
Partial
Total
Embedded

• SoC (System on Chip)
• Embedded Vs External
• Complete Vs Partial
• Dynamic VS Static
• SoMC (System on Multiple-Chip)
• Embedded Vs External
• Complete Vs Partial
• Dynamic VS Static

s t a t i c
9
Dynamic reconfigurability - state of the art -

• Dynamic reconfigurability available at device
  level on Xilinx FPGAs (2D for Virtex 4 and 5) but
  
• No EDA support
• to define which IP-Core has to become a
  reconfigurable core
• to perform the actual swap of reconfigurable
  cores and the FPGA reconfiguration
• to define interconnections among reconfigurable
  cores
• to identify from an high-level or RT-Level
  specification how to define reconfigurable cores
• TIME FOR PHYSICAL RECONFIGURATION STILL HIGH

10
Whats next

• Reconfiguration
• Motivations
• Definition
• A birds eye view
• An overall design flow
• Reconfiguration Management
• Commercial Design flows
• DRESD
• Goals
• Innovative contributions
• The proposed approach
• High Level Reconfiguration
• Simulation
• Low Level Reconfiguration
• Case study
• Runtime Reconfiguration Management
• New frontiers
• Whats next...

10
11
Challenges

• Design of high-performance adaptive embedded
  systems
• An adaptive system is a system that is able to
  adapt its behavior according to changes in its
  environment or in parts of the system itself by
  reconfiguring the existing design to counteract
  faults or a changed operational environment
• Needs
• Define reconfigurable hardware and software
  design methodologies that exploit existing
  devices multicores and FPGAs
• Design specification techniques and validation
  methodologies
• Design automation flows and tools to generate
  hardware and software components and runtime
  support
• Dynamically reconfigurable hardware and software
  architectures

12
Design Flow Challenges

• Dynamic reconfigurable embedded systems are
  gathering, an increasing interest from both the
  scientific and the industrial world
• The need of a comprehensive framework which can
  guide designers through the whole implementation
  process is becoming stronger
• There are several techniques to exploit partial
  reconfiguration, but..
• Few approaches for frameworks and tools to
  design dynamically reconfigurable system
• They dont take into consideration both the HW
  and the SW side of the final architecture
• They are not able to support different devices
• They cannot be used to design systems with
  different architectural solutions

12
13
Ideal design flow
13
14
Design flow challenges

• Reconfiguration times impact heavily on the final
  solutions latency
• Hiding reconfiguration time is not sufficient
• Possible solution maximize the reuse of
  configured modules
• How?
• Identify in the application specification
  clusters or recurrent structures to be used as
  configurable modules that can be reused
• Additional requirements for
• Partitioning algorithm (hw/sw/reconfigurable)
• Scheduling and allocation to take into account
  reconfiguration times and modules reuse

14
15
Research Aspects design flow

• Partitioning
• Hw/sw and reconfigurable partitioning
• Time partitioning
• Spatial partitioning
• Regularity driven partitioning
• Scheduling
• Configuration time and execution time
• Configuration prefetching
• Resource reuse
• Placement
• 1D and 2D model
• Communication
• Resources allocation

15
16
Research aspects Reconfiguration Management

• The flexibility of a reconfigurable system comes
  from the possibility of downloading different
  hardware configurations onto the chip at
  different times
• Reconfiguration time overhead
• Memory to store the bitstreams
• Bitstream relocation
• Software reconfiguration management
• Stand-alone application
• Integration into the operating system

16
17
Runtime Reconfiguration Management

• Stand-alone applications
• Operating system support

17
18
Available design flow Module based

• Traditional design flow for partially
  reconfigurable architectures
• Based on a modular design approach (iterative)
• Design entry and synthesis
• Design implementation
• Design verification
• Several design constraints
• Module definition
• Module height and width
• Inter-module communication
• Main limitations
• Reconfigurable modules (regions) have strict
  shape requirements
• Bus-macro replication

18
19
Module based

• The design flow has a relevant limitation
• Reconfigurable modules (regions) have strict
  shape requirements
• Bus-macro replication

20
Module based design flow
HDL description and synthesis
1
2
Initial Budgeting Phase (define design
constraints)
Active Module Phase (implementation of each
component)
3
Final Assembly Phase (assemble individual modules
together)
4
20
21
Available design flow EAPR

• Early Access Partial Reconfiguration (EAPR) flow
• Overcome the limitations imposed by module-based
  flow
• The requirements of column-wise reconfiguration
  are removed
• 2-dimensional shaped modules can be defined
• Support for Virtex-4 is now available

21
22
EAPR design flow
HDL description and synthesis
1
Define design constraints (text editor,
Floorplanner, Planahead...)
2
Implement base design (static)
3
Implement PRM design
4
Merge phase PRM base
5
22
23
EAPR

• The top component must be used to instantiate
• Base design
• PR modules
• Bus-macros
• Clock primitives (BUFG and DCM)
• The base design should not contain
• Any clocking or reset logic
• All PRMs should guarantee
• No clocking logic
• Pin and port name consistency

23
24
Whats next

• Reconfiguration
• Motivations
• Definition
• Basic principles
• A birds eye view
• An overall design flow
• Reconfiguration Management
• Commercial Design flows
• DRESD
• Goals
• Innovative contributions
• The proposed approach
• High Level Reconfiguration
• Simulation
• Low Level Reconfiguration
• Case study
• Runtime Reconfiguration Management
• New frontiers

24
25
How to exploit dynamic reconfigurability

• Ongoing research at Politecnico di Milano (DRESD
  lab). Definition of a methodology for the design
  of dynamically reconfigurable FPGA applications
• to define a design flow that exploits, wherever
  possible, the commercial tools available
• to provide guidelines on the identification and
  definition of reconfigurable cores
• to define the modules schedule trying to reduce
  the reconfiguration time
• to reduce the number of bitstreams to store in
  memory for reconfiguration
• using the runtime bistreams relocation technique
• to perform the runtime swap of reconfigurable
  cores

26
DRESD the proposed approach

• DRESD aims at providing the designer with a
  complete design flow to cover the different
  aspects necessary to design a reconfigurable
  application
• Tools are designed and developed whenever not
  available commercially (from Xilinx or FPGA
  synthesis tool vendors)
• It is possible to identify three main phases
• High-level design from specification to VHDL
• Low-level design flow from VHDL to bitstream
• Reconfiguration management from bitstream to
  solution

26
27
in details

• High-level design
• Identify functionalities from the input
  specification
• Identify reconfigurable cores
• Scheduling of cores
• Low-level design flow
• Generation of the IP-Cores from these cores to be
  mapped onto the FPGAs
• Generation of the communication infrastructure
• Generation of reconfigurable bitstreams
• Reconfiguration management
• Generation of the runtime reconfiguration manager
  for internal reconfiguration, if a processor is
  available
• These tasks apply to a specific reference
  architecture constituted by a static part,
  reconfigurable slots, communication
  infrastructure model

27
28
The reconfigurable architecture
28
29
HLR Contributions

• Given a specification (C, Impulse C) transform
  it into Task Graphs
• Analysis of the graphs to identify a first
  partitioning of cores by extracting isomorphic
  cores to cover the entire input specification
• Scheduling of the cores through heuristic
  algorithms
• VHDL generation of each core

29
30
Simulation Contribution

• Define a novel model to describe reconfigurable
  systems
• Based on a known HDL (SystemC)
• To be used in the early first stage of the
  project to consider the reconfiguration at the
  system level
• Propose a complete framework for the simulation
  and the design of reconfigurable systems
• Providing system specification that can be
  simulated
• Allowing fast parameters setting, e.g. number of
  reconfigurable blocks, reconfiguration time
• Taking into account the software side of the
  final system

30
31
Low-Level design flow

• HW Hardware
• RHW Reconfigurable HW
• SW Software

31
32
Tasks Allocation Management

• Definition of Area Constraints and an Allocation
  manager
• Desired features
• Low fragmentation and management overhead
• High routing efficiency
• Different shaping policies
• Fitting strategies
• General (First Fit, Best Fit, Worst Fit)
• Focused (Fragmentation Aware, Routing Aware )

32
33
Case Study Digital Image Processing

• The canny edge detector is used to detect the
  edges in a given input image i Kb
• 4 functionalities
• Image smoothing ? remove the noise
• Gradient operator ? highlight regions with high
  spatial derivative
• Non-maximum suppression ? reveal the edges
• Hysteresis ? remove false edges
• Each functionality has to be executed using an
  input of j Kb
• j i and x i/j
• Time analysis to identify a first partition in HW
  cores and SW cores
• Non-maximum suppression implemented as a SW core
• Image smoothing, Gradient operator and Hysteresis
  implemented as HW cores

33
34
Case Study Digital Image Processing

• Static side and IP-Cores resources requirement
  analysis
• Time analysis, resources requirement and
  reconfigurability evaluation
• Hysteresis implemented as a SW core
• Image smoothing and Gradient operator implemented
  as reconfigurable cores
• Reconfiguration time (fa into fb) 368ms

34
35
Runtime Reconfiguration Management Contributions

• Reconfigurable architecture
• Static Side used to control the reconfiguration
  process
• Reconfigurable side used to swap at runtime
  different cores
• Runtime reconfiguration managed via SW
• Standalone, Operating System
• Bitstreams relocation technique to
• speedup the overall system execution
• reduce the amount of memory used to store partial
  bitstreams
• achieve a core preemptive execution
• assign at runtime the bitstreams placement

35
36
OS-based management of dynamic reconfiguration

• Provide software support for dynamic partial
  reconfiguration on Systems-on-Chip running an
  operating system (i.e., LINUX).

• OS customization for specific architectures
• Partial reconfiguration process management from
  the OS
• Addition and removal of reconfigurable components
• Automatic loading and unloading of specific
  drivers for the IP-Cores upon components
  configuration and/or deconfiguration
• Easier programming interface for specific drivers

• )

36
37
Linux-based reconfiguration management

• Daemon startup
• 500 milliseconds (exec once)
• Device drivers setup
• 650 milliseconds
• (executed once for each driver)
• Module loading
• 3450 microseconds (if module is not cached)
• 2500 microseconds (if module is cached)
• Reading and writing from an to a configured
  module takes around 3.6 microseconds to read 4
  bytes and 2.7 to write

38
Relocation The Problem
39
Relocation Scenario
40
Relocation Motivation
41
Relocation
42
Relocation management

• Create an integrated HW/SW system to manage
  relocation (1D and 2D) in reconfigurable
  architectures
• Maintain information on FPGA status
• Decide how to efficiently allocate tasks
• Provide support for effective task allocation
• Perform bitstream relocation

42
42
42
43
Relocation time experimental results
44
Reconfigurability for reliability

• Designing reliable systems implemented on FPGAs,
  able to cope with the effects of faults caused by
  radiations
• Applying already known and well studied detection
  and recovery techniques to novel scenarios
• Exploiting dynamic partial reconfiguration to
  trigger the reconfiguration of the affected
  portion of the architecture
• while the rest of the system is still working
• without need to entirely reprogram the system

45
Whats next

• Reconfiguration
• Motivations
• Definition
• Basic principles
• A birds eye view
• An overall design flow
• Reconfiguration Management
• Commercial Design flows
• DRESD
• Goals
• Innovative contributions
• The proposed approach
• High Level Reconfiguration
• Simulation
• Low Level Reconfiguration
• Case study
• Runtime Reconfiguration Management
• New frontiers
• Whats next...

45
46
Design of adaptive multicore-based applications

• Definition of languages and representation models
  to support the explicit definition of
  reconfigurable applications to take into account
  possible evolutions
• Extraction of task-level parallelism from
  existing sequential specifications
• Identification of dynamically reconfigurable
  tasks to be associated with portions of FPGAs
• System-level simulation of reconfigurable systems
• Adaptive partitioning and mapping of tasks onto
  the heterogenous platform hardware, software,
  reconfigurable, evolvable
• Tasks scheduling on reconfigurable hardware and
  software (static or dynamic)

47
Whats next...

• Architectures
• Quantum computing
• Reconfigurable computing is not equal to FPGAs
• Nanotechnologies
• Models and paradigms
• Is the turing machine enough?
• RDL Reconfiguration Description language
• Applications
• Start from real worls needs
• Benchmarking...
• Knowledge about all these disciplines has helped
  transform hardware/software codesign from an art
  to a science, now we need to help the
  recoonfigurable computing

48
Questions