Upload
usrdresd
View
427
Download
1
Embed Size (px)
Citation preview
POLITECNICO DI MILANO
Analysis and Analysis and management of management of
bitstream generators for bitstream generators for Xilinx FPGAsXilinx FPGAs
Davide Candiloro: [email protected]
Marco D. Santambrogio: [email protected]
PPartialartial DDynamic ynamic RReconfiguration econfiguration WWorkshoporkshop
RationaleRationale
Xilinx software is mainly tailored to static designsAbsence of validation or support for partial dynamic reconfiguration techniques
-therefore-Development of a novel flow for the debugging and validation of partial dynamic reconfigurable architectures on Xilinx FPGAs
Methodology to spot and address possible design flaws
Design of a framework to automate and ease the designer’s task independently from vendor software
2
Detailed ContributionDetailed Contribution
Automated constraint checking on Reconfigurable RegionsGuided error resolution and visual constraint editingHW functionality area conflict monitoringExploration of the relocation possibilities for partial bitstreams
Analysis of the end result files of a PDR flowWorking on an architectural model and representation outside of Xilinx SW
3
4
OutlineOutline
Partial dynamic reconfiguration and related issues
The proposed frameworkCase study descriptionCase study application
ContributionsFuture works
5
What’s nextWhat’s next
Partial dynamic reconfiguration and related issues
The proposed frameworkCase study descriptionCase study application
ContributionsFuture works
PDR flows and related issuesPDR flows and related issues
The flows require the manual definition of RRs, conforming to specific guidelines
The designer must refer correctly to the underlying architecture of the FPGA => error prone
Vendor software has been designed for static designs
There is no guarantee that the constraints for the RRs are respected by the Place and Route phaseThis can inject further errors into the design: area conflicts and RR overflowing
Designer efforts are taken away from the actual application development
6
PDR issue 1: RR definitionPDR issue 1: RR definition
7
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;
PDR issue 2: Xilinx PAR PDR issue 2: Xilinx PAR programsprograms
Place and Route built for static designs
Even if RR defined correctly, HW might overflow it
This situation is NOT reported to the designer
Can inject silent errors in the design due to configuration overwriting and area conflicts
8
State of the artState of the artPlanahead® - 2008
Used to constrain the logic inside particular regionsLast version adds PDR supportAn error situation is simply reported but
- not where - not how to overcome it
Floorplanner® - 2008Editor for the constraints of regions on the chipArchitecture-awareNOT reconfiguration aware => guidelines not enforced
Chipscope® - 2008Used in debugging designs on Xilinx FPGAsOnly AFTER the design has been downloaded on board
Jbits (discontinued) - 2004/5Provided low level access to configuration in bitstreams
9
10
What’s nextWhat’s next
Partial dynamic reconfiguration and related issues
The proposed frameworkCase study descriptionCase study application
ContributionsFuture works
Integration with the Earendil Integration with the Earendil flowflow
11
•Existing flow for defining FPGA reconfigurable apps
•Proposed flow at the end of Earendil chain
•Based upon reconfigurablearchitecture product files
•May thus be inserted at the end of generic flows
Rebit: the proposed frameworkRebit: the proposed framework
12
C++
wxWidgets
Conflict GraphConflict Graph
13
Conflict graph
conflict=edge
Incidence Matrix
conflict=red
which functionalities can be used at the same time?
14
Demo descriptionDemo description
ApplicationEdge detection on black and white digital images
Input: color digital imagesOutput: edge detected on the input images
Architecture2 IP-Cores
Filter (gray scale converter)Edge Detector (E.D.)
Static areaGPP: PPC405SW: standalone
Reconfigurable area1 reconfigurable regions
14
15
Data flowData flow
sddd
15
Input image
Gray scale (Filter)
Edge Detection (E.D.)
16
Performance analysis (1)Performance analysis (1)
17
Reconfiguration performanceReconfiguration performanceArea (Xilinx VIIP7)
SystemStatic area
– Slices: 2100Reconfigurable area
– Constrained slices : 896
RFUsFilter (Gray scale)
– # Frames: 126– Bitstream size: 110 KB
Edge Detector (E.D.)– # Frames: 158– Bitstream size: 110 KB
Reconfiguration performance
Execution time: 0.31sRec. troughput :1,02 MB/secRec. time: 0,1 secmin data size: 32353 byte
min image size: 180x180
18
Performance analysisPerformance analysis
Enhancement explorationEnhancement exploration
Is there any way in which we can enhance the application performance/flexibility?
Yes!
Exploring new design solutions using REBIT(we will now see how)
19
20
Performance analysisPerformance analysis
Case study: architectureCase study: architecture
21
• 2 image filters
• 2 partial bitstrams
• 1 RR
•Synthesis finished, we now aim at:
•Finding flaws in the design, if any
•Correcting them
Case study: constraint Case study: constraint validationvalidation
22
Case study: UCF editingCase study: UCF editing
23
Case study: relocationCase study: relocation
24
•We have resolved the issues of the design…
•Now we would like to explore new solutions
Case study: area conflictsCase study: area conflicts
25
26
What’s nextWhat’s next
Partial dynamic reconfiguration and related issues
The proposed frameworkCase study descriptionCase study application
ContributionsFuture works
27
Contributions of the workContributions of the work
Novel flow for the DRC of PDR architecturesAutomation of the flow for the validation and debug of PDR architectures: no more manual stepsVisual editing and guided issue resolution
Configuration memory maps for the analyzed FPGAsRelation of Xilinx bitstream format to the specific architectureDevelopment of a framework independent of Xilinx software that integrates knowledge of the architectural details
Future worksFuture works
Adding support for new/other FPGAs to the system
Turn the reasoner module into an expert system, to develop further automation in the definition and validation of the system
Taking BUS Macros into account, i.e.: communication between different RFUs
Extend the data model with board data, not only chip
Develop methodologies to generate constraints based on IOB connections to the external board components
28
Questions