3rd 3DDRESD: Rebit

POLITECNICO DI MILANO

Analysis and Analysis and management of management of

bitstream generators for bitstream generators for Xilinx FPGAsXilinx FPGAs

Davide Candiloro: davide.candiloro@dresd.org

Marco D. Santambrogio: marco.santambrogio@polimi.it

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