Upload
usrdresd
View
765
Download
1
Embed Size (px)
Citation preview
POLITECNICO DI MILANO
Design Flow for SoPCDesign Flow for SoPC
PPartial artial DDynamic ynamic RReconfiguration econfiguration WWorkshoporkshop
DRESD Team
2
MotivationsMotivations
Especially interesting is the scenario of dynamically reconfigurable system, in which hardware reconfiguration is carried out without necessarily having to cease execution of those parts of the system that are not involved.The successful deployment of such complex and reconfigurable embedded systems to the market requires the identification, formalization, and implementation of concepts, methods, and tools that are able to ease the development of the software components and the implementation of the system architecture. This scenario is the one in which the Dynamic Reconfigurability in Embedded Systems Design (DRESD) research project takes place.
Aim of these presentations is to propose, after the overview of related work, the DRESD methodology. Up to now the proposed solution, extending and improving the Xilinx design flow, accomplishes the design and development of a particular kind of embedded systems that exploit the advantages of dynamic reconfiguration.
3
OutlineOutline
FPGA
Xilinx design flows
Design Flow: challenges and rationale
DRESD contribution
4
What’s nextWhat’s next
FPGATechnologyCLB, Slice, LUTFrameConfiguration bitstream
Xilinx design flowsDesign Flow: challenges and rationaleDRESD contribution
5
Xilinx FPGA technologyXilinx FPGA technology
5
6
CLBCLB
Switch BoxSLICE
TBUF
Y
X6766
75
74
SLICE_X66Y74
77
The configuration bitstreamThe configuration bitstream
Occupation must be determined only on the basis of
Number of configuration wordsInitial Frame Address Register (FAR) value
8
Frame and Configuration Frame and Configuration MemoryMemory
Virtex-II Pro Configuration memory is arranged in vertical frames that are one bit wide and stretch from the top edge of the device to the bottomFrames are the smallest addressable segments of the VIIP configuration memory space
all operations must act on whole configuration frames.
Virtex-4 Configuration memory is arranged in frames that are tiled about the deviceFrames are the smallest addressable segments of the V4 configuration memory space
all operations must therefore act upon whole configuration frames
9
Xilinx FPGA and configuration Xilinx FPGA and configuration memorymemory
9
10
What’s nextWhat’s next
FPGA
Xilinx design flowsDifference based (smallbit)Module basedEAPR
Design Flow: challenges and rationale
DRESD contribution
1111
IntroductionIntroduction
Design flow for partially reconfigurable architectures
Set of subsequent phases to implement the architecture“Partially reconfigurable” requirementsNeed to partition the development phases into several steps
Xilinx official design flows:Difference based (Smallbit)Module basedEAPR
12
Difference based (Smallbit)Difference based (Smallbit)
The basic brick to Xilinx partial reconfiguration
This method of partial reconfiguration is accomplished by making a small change to a design, and then by generating a bitstream based on only the differences in the two designs.
Switching the configuration of a module from one implementation to another is very quick, as the bitstream differences can be extremely smaller than the entire device bitstream.
13
Pre – Partial ReconfigurationPre – Partial Reconfiguration
Xilinx Virtex II Pro FPGA
14
Post – Partial ReconfigurationPost – Partial Reconfiguration
Xilinx Virtex II Pro FPGA
15
Module based Module based 1/31/3
“Traditional” design flow for partially reconfigurable architectures
Based on a modular design approach (iterative)Design entry and synthesisDesign implementationDesign verification
Several design constraintsModule definitionModule height and widthInter-module communication
15
16
Module based Module based 2/32/3
The design flow has a relevant limitationReconfigurable modules (regions) have strict shape requirementsBus-macro replication
17
Module based Module based 3/33/3
The Module-based design flow at a glance
1
2
HDL description and synthesis
Initial Budgeting Phase (define design constraint)
3Active Module Phase (implementation of each component)
4Final Assembly Phase (asseble individual modules togheter)
18
Pre – Partial ReconfigurationPre – Partial Reconfiguration
Xilinx S3 FPGA
Static Side RFU1 RFU2
19
Post – Partial ReconfigurationPost – Partial Reconfiguration
Xilinx S3 FPGA
Complete System
20
EAPR EAPR 1/31/3
Early Access Patial Reconfiguration (EAPR) flowOvercome the limitations imposed by module-based flowThe requirements of column-wise reconfiguration are removed2-dimensional shaped modules can be definedSupport for Virtex-4 is now available
20
FPGA
ROWs
CLBs
A
Communication Infrastructure
B C
Static Side
Fixed Logic
(b) Logical View
Static Side
Reconfigurable Area
Static Net Routing
HW Macro
Smallest Feasible Reconfigurable Area
(a) Physical View
ROW 0
ROW 1
ROW 2
ROW 3
Reconfigurable Core A
Reconfigurable Core B
Static Side
Reconfigurable Core C
FPGA
21
EAPR EAPR 2/32/3
The EAPR design flow at a glance
21
1
2
HDL description and synthesis
Define design constraint (text editor, Floorplanner...)
3 Implement base design (static)
4 Implement PRM design
5 Merge phase: PRM + base
22
EAPR EAPR 3/33/3
The top component must be used to instantiateBase designPR modulesB us-macrosClock primitives (BUFG and DCM)
The base design should not containAny clocking or reset logic
All PRMs should guaranteeNo clocking logicPin and port name consistency
22
23
Pre – Partial ReconfigurationPre – Partial Reconfiguration
Xilinx Virtex 4 FPGA
Static Side RFU1 RFU2
24
Post – Partial ReconfigurationPost – Partial Reconfiguration
Xilinx Virtex 4 FPGA
Complete System
25
What’s nextWhat’s next
FPGAXilinx design flows
Design Flow: challenges and rationale
DRESD contribution
26
Design Flow: Challenges and Design Flow: Challenges and RationaleRationale
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
No EDA support:to define which IP-Core has to become a reconfigurable coreto perform the actual swap of reconfigurable cores and the FPGA reconfigurationto define interconnections among reconfigurable coresto identify from an high-level or RT-Level specification how to define reconfigurable cores
27
What’s nextWhat’s next
FPGAXilinx design flowsDesign Flow: challenges and rationale
DRESD contributionINCACaronte
Hardware side managementSoftware side management
28
INCAINCA
INCA Based on EAPR design flowAn automated tool for bitstream generation
To generate complete bitstreams for the entire architectureTo generate partial bitstreams for the partially reconfigurable regions
28
29
Low-Level design flow: Low-Level design flow: CaronteCaronte
29
HW: HardwareRHW: Reconfigurable HWSW: Software
30
Hardware Side – design flowHardware Side – design flow
30
31
Low-Level Design: Low-Level Design: ContributionsContributions
The design of a complete framework, able to support different devices, reconfiguration techniques and kinds of reconfigurationIP-Core generation
System architecture generationGeneration (context creation) of combinations of static and dynamic partsCommunication infrastructure creation
31
Automatic IP-Core generation starting from a given Core
Generation time almost constant Interface impact tends to 0 for the biggest Cores
32
System DescriptionSystem Description
33
Area ConstraintsArea Constraints
Xilinx VIIP
Xilinx S3
Xilinx V4
34
Reconfigurable Region Reconfigurable Region DefinitionDefinition
34
The flows require constraints to be satisfied when defining RRs in the UCF (User Constraints File) file
AREA_GROUP "RR1" RANGE = SLICE_X28Y64:SLICE_X41Y127;
AREA_GROUP "RR1" RANGE = RAMB16_X2Y9:RAMB16_X2Y15;
35
Design Synthesis and Placement Design Synthesis and Placement Constraints AssignmentConstraints Assignment
36
System GenerationSystem Generation
Context Creation: EAPR-basedContext Creation: EAPR-based
37
YaRA: Yet another Reconfigurable Architecture
The basic reconfigurable architecture defineda Static area: a basic Harvard architecturea Reconfigurable area: a device area composed of several reconfigurable regions
YaRA v1: 1D, Whishbone BUS-basedYaRA v2: 2D,CoreConnect-based
The DRESD reconfigurable The DRESD reconfigurable architecturearchitecture
38
Software Side – Standalone Software Side – Standalone SolutionSolution
39
Software side of the Caronte flowSoftware side of the Caronte flow
Standalone solutionSpecific reconfiguration librariesIntegration in the final bitstreamNo multitasking
Linux supportHigh-level reconfiguration librariesSupport for multitasking and other OS servicesOnly a bootloader is integrated in the bitstreamDevice driver development for specific hardware
39
elf
SW-Side Design
GCC Frontend
Configuration Set Identification
GCC Backend
Software Integration
.c
Application
elf
Reconfiguration Libraries
Linux OS
SW
40
Reconfiguration SupportReconfiguration Support
Linux kernels do not natively support dynamic reconfiguration
No interaction with the reconfiguration controllerDynamic addition of hardware modules is supported…… But area management or module caching are not!
The kernel must be extended in order to perform a set of basic operations
Module configuration upon requestModule release/removal
General assumption: the partial bitstream is provided as part of the module request
40
41
IP-Core devices accessIP-Core devices access
Interaction with configured IP-Cores implemented by means of the standard Linux device access
Open, Close, Read, write, ioctl operations
41
/dev/device_1
/dev/device_2a
/dev/device_2b
SoftwareApplication 1
SoftwareApplication 2
device_1.o
device_2.o
/dev
DeviceDrivers
Userspace
Devices
IP-Core_1
IP-Core_2a
IP-Core_2b
FPGA
Multiple instances of the same
hardware module
42
Reconfigurable Process Control Reconfigurable Process Control BlockBlock
Reconfigurable process: an RFU object code in execution
Each reconfigurable process is represented in the system by a Reconfigurable Process Control Block (RPCB).
A RPCB contains all the information associated with a specific reconfigurable process
State: the state in which the reconfigurable process control is at the current timePosition: the placement position on the deviceObject Code Accounting Information:
Object CodeConfiguration PriorityResourcesPosition
Configured
Addressing Space Assignment
Ready
Positioning
Configuring
Configuring
Cached
ComputingRemoved
Waiting
Executing
Preempted
42
43
The Centralized ManagerThe Centralized Manager
Userspace applications are not allowed to explicitly request a bitstream
They request high-level functionalities
Userspace requests are collected and served by a centralized manager (Linux Reconfiguration Manager)
The OS chooses the configuration codeA new reconfigurable process is created
Only the LRM can ask for a bitstream to be configured on the FPGA
Centralized knowledge of the device statusArea management and module caching
43
44
Software Side – Linux SolutionSoftware Side – Linux Solution
45
Concluding Remarks:Concluding Remarks:Top Ten Reasons to work in Caronte and Top Ten Reasons to work in Caronte and
OSyRiSOSyRiS1. Definition of a complete methodology to implement self
reconfigurable embedded systems2. Description of adaptable solutions able to meet the user
needs3. Definition of an integrated HW/SW solution to support the
reconfiguration4. A design flow able to support different devices and basic
design flows5. Design support and available interaction at each level for
expert users6. Reconfiguration hiding for new users7. OS solution Vs Standalone solution8. Runtime decision on the RPCB gender9. From now on, Transformers are the past!10. Do we really need a ten? :)
46
Treasure HuntTreasure Hunt
Thursday 30, October Search the Research: an adventure in the world of Reconfigurable Will you be brave enough to live a 100% pure DRESD night to discover the reconfigurable systems secrets? If so, do not miss the next adventure in the world of Reconfigurable Systems:
http://www.dresd.org/treasurehunthttp://www.dresd.org/th08_it
47
QuestionsQuestions