Sei sulla pagina 1di 44

Reconfigurable Computing

CS G553

Dr. A. Amalin Prince


BITS - Pilani K K Birla Goa Campus
Department of Electrical and Electronics Engineering

‹#›
Lecture – 25,26
Programming Reconfigurable Systems: In System
Integration, Implementation Approaches

CS G553 2
In System Integration
3 different ways (usage)
3 different methods (Reconfiguration)
2 approaches (Implementation)

CS G553 3
Rapid Prototyping

● Reconfigurable devices (RD) are


usually used in three different ways:

1. Rapid Prototyping: The RD is used as


emulator for a circuit to be produced
later as ASIC. The emulation process
allows for testing the correctness of the
circuit, sometimes under real operating APTIX System Explorer
conditions before production.
Examples:
The APTIX-System Explorer and the
ITALTEL Flexbench systems are two
examples of emulation platforms.

ITALTEL FLEXBENCH

CS G553 4
Non Frequent reconfiguration

2. Non-frequently reconfigurable
systems: The RD is used as
application specific device similar to
ASIC. However the possibility of
upgrading the system by means of
reconfiguration is given.
The Nallatech BenADIC

Such systems are used as


prototyping platform, but can be
used as running environment as
well.

Examples:
The RABBIT System, the celoxica
RC100, RC200, RC300, the The Celoxica RC200
Nallatech BenADIC.

CS G553 5
Frequent reconfiguration

3. Frequently reconfigurable systems:


Usually coupled with a processor, the
RD is used as an accelerator for time-
critical parts of applications.
The processor accesses the RD using The Celoxica RC1000
function calls.
The reconfigurable part is usually a PCI-
board attached to the PCI-bus.
The communication is useful for
configuration and data exchange.
The Raptor 2000

Examples:
the Raptor 2000, the celoxica RC1000
and RC2000, the Nallatech Ballynuey.

More and more stand-alone frequently


The Nallatech Ballynuey
reconfigurable systems are appearing.
CS G553 6
Static and Dynamic Reconfiguration

ENG6530CSRCS
G553 7 7
Reconfigurability
 Reconfiguration is either static (execution is interrupted), semi-static (also
called time-shared) or dynamic (in parallel with execution):
1. Static configuration involves hardware changes at the slow rate of days/weeks,
typically used by hardware engineers to:
I. Evaluate prototype chip implementations,
II. Implement an architecture on an entire FPGA fabric or multiple FPGAs.

2. Semi-Static If an application can be pipelined, it might be possible to implement


each phase in sequence on the reconfigurable hardware.
• The switch between the phases is on command: a single FPGA performs a
series of tasks in rapid succession, reconfiguring itself between each one.
Such designs operate the chip in a time-sharing mode and swap between
successive configurations rapidly. Each configuration corresponds to an
application.

3. The dynamic reconfiguration: most powerful form of reconfigurable computing.


• The hardware reconfigures itself on the fly as it executes a task. While some
modules are executing others might be swapped in/out.

CS G553 8
Static and dynamic Reconfiguration
● The three ways of using a reconfigurable systems can be classified in
two big categories:

1. Compiled time reconfigurable systems.


The computation and reconfiguration is defined once at compile
time.
This category encounters the rapid prototyping systems, the non-
frequently reconfigurable systems as well as some frequently
reconfigurable systems.

2. Run-time reconfigurable systems.


The computation and reconfiguration sequences are not known at compile-
time.
The system reacts dynamically at run-time to computation and therefore, to
reconfiguration requests. Some non-frequently reconfigurable systems as
well as most frequently reconfigurable systems belong to this category.

CS G553 9
Static Implementation and CTR

 Static and Compile Time Reconfiguration (CTR)


o Static implementation strategy
o Single system wide configuration
o Configuration doesn‟t change during computation
o Similar to using ASIC for application acceleration

CONFIGURE EXECUTE

CS G553 10
Static Implementation and CTR

 Compile time configuration is an important feature in SRAM-


based FPGAs that allows changes in functionality according to need.
o Enables benefits such as flexibility, hardware reuse, and reduced power
consumption
 Drawbacks of compile-time reconfiguration
o Entire fabric is reconfigured even for slight design changes
 System execution stalls completely
o Time to load a design onto the fabric from external memory (reconfiguration
time) increases with bitstream size

Flexibility
Design A Designs loaded
Power Savings
Configuration when required
Design A, B, & Design B Design A
B
C
controller
C stored in
Hardware Reuse
external Design C Current required
memory
B Required
Design A
C design replaces
External memory FPGA Fabric old one on the
same fabric
CS G553 11
Static Reconfiguration

No complexity
associated with
generating bit-streams
nor mapping onto
FPGA

CS G553 12
Reconfiguring FPGA
 Different Configuration interfaces
o JTAG
o SelectMAP
o Slave/Master Serial
o ICAP (a special case of SelectMAP) (Internal Configuration Access
Port)
o PCAP (Processor Configuration Access Port)

 Different Configuration phases


o Clearing the configuration memory
o Initialization
o Bitstream Loading
o Device Startup

CS G553 13
How to manage large Designs?

1. Use the largest FPGA available.


2. Use multiple FPGAs to accommodate the entire design.
3. Optimize your design and the synthesis and place &
route.
4. Customize your architecture to fit in the available
FPGA:
 use serial implementations or
 semi-parallel implementations.

CS G553 14
Implementation Approaches (RTR)

 Run Time Reconfiguration (RTR)


o Dynamic implementation strategy
o Multiple time-exclusive configurations
o Dynamic hardware allocation (run-time)

CONFIGURE EXECUTE

CS G553 15
Static and dynamic Reconfiguration

Generally compile time and each configuration is one complete application

Generally run-time and each application has multiple pieces of configurations


For compile time if dynamic is required, the configuration sequence is known already.
CS G553 16
Virtual Memory

 What does virtual memory accomplish?


 Optimizing use of random access memory (RAM)
 With virtual memory (VM), portion of hard disk is allocated to function as RAM

Step 1. The
operating system
transfers the least
recently used data
and program
instructions to Step 2. The
disk because operating system
memory is needed transfers data and
for other program
functions. instructions from
disk to memory
when they are
needed.
CS G553 17
Virtual Hardware

The concept of Run Time Reconfiguration on


FPGAs is similar to the concept of Virtual Memory
on Computer Systems.
Configuration data
stored in memory device

Function A Unused resources

Active tasks
Inactive tasks
Function A
Function B

Function B

Function C

Overwrite function B
with new function C

CS G553 18
Virtual Hardware

 Provides programmer with an abstraction of unlimited


hardware, similar to Virtual Memory
 Useful abstraction which, like virtual memory, provides
portability between devices
 OS is responsible for directing the chip to context-switch
user “hardware” (may include multiple processes)
 Requires fast context-switching capability and software to
effectively partition user hardware

CS G553 19
Run Time Reconfiguration

 Main Task: Dividing algorithm into time-exclusive segments


or spatial segments
 Run time reconfiguration require partial reconfiguration
capability (PR)
o PR allows the ability to reconfigure a portion of an RD (FPGA)
 Types:
o Static Partial Reconfiguration (Global RTR)
o Dynamic Partial Reconfiguration (Local RTR)

CS G553 20
Run Time Reconfiguration

 Partial Reconfiguration:
 Static Partial Reconfiguration (Global RTR): Reconfiguring a
portion of the device (changing the functionality) when the
device is inactive without affecting other areas of the device

 Dynamic Partial Reconfiguration (Local RTR): Reconfiguring a


portion of the device while the remaining design is still active
and operating without affecting the remaining portion of the
device.

CS G553 21
Global RTR Implementation

Application

#1
Reconfiguration
Reconfiguration
#2

#3
Execution
Execution
Reconfiguration
#4

Reconfiguration
#2 Contexts
#1
#4

Dynamically Reconfigurable Device


CS G553 22
Local RTR

 Local RTR (Dynamic)


o Locally reconfigure subsets of logic at run-time
o Partial reconfiguration, flexibility
o Functional division of labor

Local RTR

A A D
B EX EX
E. C E.

CS G553 23
Local RTR Implementation

 Partial Run Time Reconfiguration (Multiple context)


Aplicacition

#1
Reconfiguration
#2

#3

#4

#1 Reconfiguration
Contexts
#4
#3
#3#2

Dynamically Reconfigurable Device


CS G553 24
Dynamic Reconfiguration

CS G553 25
Partial Reconfiguration (PR)
 PR allows the ability to reconfigure a
portion of an FPGA dynamically by dividing
the FPGA into two types of regions ICAP Module A

Controlling Agent
o Static region - contains static portion of the Module B

Mem controller
design (Static Modules)

Central
o Partially reconfigurable region (PRR) - Module C
loaded with a partial reconfiguration
module (PRM) Module D
 PR benefits in addition to full
reconfiguration benefits Static modules Reconfigurable Modules (PRMs)

o Only reconfigured PRR is stalled while static Module:


A&B
region and other PPRs continue operating PRR 1

Static region
o Smaller bitstreams sizes
• Reduced power consumption Static Modules:
PRR 2 C&D
• Reduced memory requirements modules

• Reduced time to reconfigure


Example with 2 PRRs
FPGA Fabric
CS G553 26
Local RTR Implementation issue

 Ensure all configurations interface correctly


 Ensure inter-configuration communicate properly
 Ensure physical footprint of a configuration is compatible
with other configuration
 Ensure that fragmentation is minimal to accommodate
several designs efficiently
 Advantage of local RTR:
o more efficient usage of FPGA resources

CS G553 27
Prior Obstacles to RTR

 Lack of hardware devices that support RTR in an


appropriate fashion
o Provide fast reconfiguration without sacrificing performance
 Lack of software to support RTR
o Generate and modify bitstream configurations during runtime
 Requires some OS support for efficiently swapping in/out
tasks.

CS G553 28
Design Flow

Initial full bitstream


generate
Interface Interface partial
bitstream
Static Dynamic Static Dynamic
Core Core Dynamic
Core 1 Core 1
Core 2

Full bitstream
JBitsCopy
merge

JBitsCopy
extract
Dynamic Dynamic
Core 2 Core 2

CS G553 29
Computation flow
● The computation in a reconfigurable system
is usually done according to the figure
aside. The processor controls the complete
system.

1) It first downloads data to be computed by the


RD to the RD memory.

2) Then the RD is configured to perform a given


function over a period of time.

3) The start signal is given to the RD to start


computation. At this time, the processor also
computes its data segment in parallel to the
RD.

CS G553 30
Computation flow
4) Upon completion, the RD acknowledges
the processor.

5) The processor collects the computed


data from the RD memory.

o If many reconfigurations have to be


done, then some of the steps from 1) to
5) should be reiterated according to the
application's need.

o A barrier synchronisation mechanism is


usually used between the processor and
the RD.

o Blocking access should also be used for


the memory access between the two
devices.
CS G553 31
Computation flow
o Devices like the Xilinx Virtex II/II-
Pro/Zynq 7000 and the Altera
Excalibur feature one or more soft or
hard-macro processors.
• the complete system can be
integrated in only one device.

o The reconfiguration process can be:

• Full: The complete device have to be


reconfigured.

• Partial: Only part of the device is


configured while the rest keeps
running.

CS G553 32
Computation flow

CS G553 33
Hardware/software partitioning
 The implementation of a reconfigurable
system is a Hardware/software co- design
process which determines:

o The software part, that is the code-


segment to be executed on the processor.
The development is done in a software
language with common tools.
• We will not pay much attention to this part.

o The hardware part, that is the part to be


executed on the RD.
• This is the target of this section.

o The interface between software and Interface


This part is not in the
hardware.
Software Hardware
scope of this course. C, C++, Java VHDL, Verilog
etc ... HandelC, etc..

CS G553 34
Computation flow

o Full reconfiguration devices task 2

• function to be downloaded at run-time are task 1 task N


developed and store in a database.
• No geometrical constraints restriction are
required for the function. Services Task Request

o Partial reconfiguration capabilities


Module Scheduler
• modules represented as rectangular Database
M1 M4
boxes, are pre-computed and stored in a
data base. M2 M3
Placer
• With relocation, the modules are assigned
O.S.
to a position on the device at run-time
T2
 In the two cases, modules to be downloaded
at run-time are digital circuit modules
T
o development is done according to digital circuit T1 N

design rules Reconfigurable Device

CS G553 35
RTR Challenges

 Management of Reconfigurable Device: task 2

• Usually as a part of the OS running on a processor task 1 task N

o Scheduler
• Decides when a task must be executed
Services Task Request
• Tasks in a database
• Characterized by (bbox, run time)
Module Scheduler
o Placer Database
M1 M4
• Temporal placement: management of tasks at run
time M2 M3
Placer
• Allocates a set of resources for the task.
O.S.
• If cannot find a site, task is rejected

 Challenges: T2

o Fragmentation
T
o Communication between new/old tasks T1 N

Reconfigurable Device

CS G553 36
Operating Systems for RCS

 With the development of the reconfigurable computing


systems, designers are looking towards multitasking
reconfigurable computers
 Multitasking an FPGA will require an OS to manage the
loading, swapping and allocation of the tasks to the FPGA
surface
 As the status of the FPGA changes in time, the designs will
have to be completed at run-time, and not statically
compiled.
 The partitioning, placement and routing need be handled
by the OS.

CS G553 37
Tasks of OS for RCS

General Tasks
o Loader
o Scheduler
o Memory management
o I/O Handler
o Inter-process communication

Special Tasks
o Allocation
o Partitioning
o Placement
o Routing multiple circuits on one or more FPGA

CS G553 38
Conclusion

 Reconfigurable systems benefits:


o More flexibility: in run-time or over lifetime
o More computation power: approach or surpass ASICs
o More various architectures allowed (coupling types)

 New challenges introduced:


o More complex compilers and CAD tools.
o Optimized scheduling
o Reconfigurable time is to improve in RPUs
o Embedded Operating Systems to manage the system
efficiently.

CS G553 39
Reputed Conference/Journals

 Journals
o ACM transactions on reconfigurable technology and systems
o International Journal of Reconfigurable Computing
o Elsevier Microprocessor and Microsystem
 Conferences
o Reconfigurable Architectures Workshop (RAW) 27th is announced
o Reconfigurable Communication-centric Systems-on-Chip (ReCoSoC), 2019
o International Symposium on Applied Reconfigurable Computing (ARC) 2020
announced
o International Conference on Reconfigurable Computing and FPGAs
(ReConFig) 2019 in Dec, Mexico
o FPGA 2020-28th ACM/SIGDA International Symposium on Field-
Programmable Gate Arrays
o 30th Field Programmable Logic and Applications (FPL) , 2019
o Filed Programmable Technology (FPT), 2019

CS G553 40
Our Work
 Prince A.A. and Mishra S. (2015) „Multi-Mode Electronic Stethoscope Implementation and
Evaluation Using Dynamic Reconfigurable Design‟, 5th IEEE International Advanced Computing
Conference (IACC 2015), p.p. 228-232, June 12th - 13th 2015, Bangalore, India, IEEE.

MODES Lower Upper


S.No Frequency(Hz) Frequency(Hz)
1. Bell mode 30 500
2. Diaphragm mode 80 500
3. Bass enhanced bell mode 60 500
4. Lung sound mode 100 1000
5. Wide band mode 20 2000
CS G553 41
Our Work
 Prince A.A. and Vineeth K. (2015) „A Framework for Remote and Adaptive Partial
Reconfiguration of SoC Based Data Acquisition Systems under Linux‟, Proc. Of 10th IEEE
International Symposium on Reconfigurable Communication-centric Systems-on-Chip
(ReCoSoC 2015), p.p. 1-5, June 29th – July 1st 2015, Bremen, Germany, IEEE.

CS G553 42
Latest Development:: Xilinx

CS G553 43
The End

 Questions ?

 Thank you for your attention

CS G553 44

Potrebbero piacerti anche