47
POLITECNICO DI MILANO Design Flow for SoPC Design Flow for SoPC P P artial artial D D ynamic ynamic R R econfiguration econfiguration W W orkshop orkshop DRESD Team [email protected]

RCW@DEI - Design Flow 4 SoPc

Embed Size (px)

Citation preview

Page 1: RCW@DEI - Design Flow 4 SoPc

POLITECNICO DI MILANO

Design Flow for SoPCDesign Flow for SoPC

PPartial artial DDynamic ynamic RReconfiguration econfiguration WWorkshoporkshop

DRESD Team

[email protected]

Page 2: RCW@DEI - Design Flow 4 SoPc

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.

Page 3: RCW@DEI - Design Flow 4 SoPc

3

OutlineOutline

FPGA

Xilinx design flows

Design Flow: challenges and rationale

DRESD contribution

Page 4: RCW@DEI - Design Flow 4 SoPc

4

What’s nextWhat’s next

FPGATechnologyCLB, Slice, LUTFrameConfiguration bitstream

Xilinx design flowsDesign Flow: challenges and rationaleDRESD contribution

Page 5: RCW@DEI - Design Flow 4 SoPc

5

Xilinx FPGA technologyXilinx FPGA technology

5

Page 6: RCW@DEI - Design Flow 4 SoPc

6

CLBCLB

Switch BoxSLICE

TBUF

Y

X6766

75

74

SLICE_X66Y74

Page 7: RCW@DEI - Design Flow 4 SoPc

77

The configuration bitstreamThe configuration bitstream

Occupation must be determined only on the basis of

Number of configuration wordsInitial Frame Address Register (FAR) value

Page 8: RCW@DEI - Design Flow 4 SoPc

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

Page 9: RCW@DEI - Design Flow 4 SoPc

9

Xilinx FPGA and configuration Xilinx FPGA and configuration memorymemory

9

Page 10: RCW@DEI - Design Flow 4 SoPc

10

What’s nextWhat’s next

FPGA

Xilinx design flowsDifference based (smallbit)Module basedEAPR

Design Flow: challenges and rationale

DRESD contribution

Page 11: RCW@DEI - Design Flow 4 SoPc

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

Page 12: RCW@DEI - Design Flow 4 SoPc

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.

Page 13: RCW@DEI - Design Flow 4 SoPc

13

Pre – Partial ReconfigurationPre – Partial Reconfiguration

Xilinx Virtex II Pro FPGA

Page 14: RCW@DEI - Design Flow 4 SoPc

14

Post – Partial ReconfigurationPost – Partial Reconfiguration

Xilinx Virtex II Pro FPGA

Page 15: RCW@DEI - Design Flow 4 SoPc

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

Page 16: RCW@DEI - Design Flow 4 SoPc

16

Module based Module based 2/32/3

The design flow has a relevant limitationReconfigurable modules (regions) have strict shape requirementsBus-macro replication

Page 17: RCW@DEI - Design Flow 4 SoPc

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)

Page 18: RCW@DEI - Design Flow 4 SoPc

18

Pre – Partial ReconfigurationPre – Partial Reconfiguration

Xilinx S3 FPGA

Static Side RFU1 RFU2

Page 19: RCW@DEI - Design Flow 4 SoPc

19

Post – Partial ReconfigurationPost – Partial Reconfiguration

Xilinx S3 FPGA

Complete System

Page 20: RCW@DEI - Design Flow 4 SoPc

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

Page 21: RCW@DEI - Design Flow 4 SoPc

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

Page 22: RCW@DEI - Design Flow 4 SoPc

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

Page 23: RCW@DEI - Design Flow 4 SoPc

23

Pre – Partial ReconfigurationPre – Partial Reconfiguration

Xilinx Virtex 4 FPGA

Static Side RFU1 RFU2

Page 24: RCW@DEI - Design Flow 4 SoPc

24

Post – Partial ReconfigurationPost – Partial Reconfiguration

Xilinx Virtex 4 FPGA

Complete System

Page 25: RCW@DEI - Design Flow 4 SoPc

25

What’s nextWhat’s next

FPGAXilinx design flows

Design Flow: challenges and rationale

DRESD contribution

Page 26: RCW@DEI - Design Flow 4 SoPc

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

Page 27: RCW@DEI - Design Flow 4 SoPc

27

What’s nextWhat’s next

FPGAXilinx design flowsDesign Flow: challenges and rationale

DRESD contributionINCACaronte

Hardware side managementSoftware side management

Page 28: RCW@DEI - Design Flow 4 SoPc

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

Page 29: RCW@DEI - Design Flow 4 SoPc

29

Low-Level design flow: Low-Level design flow: CaronteCaronte

29

HW: HardwareRHW: Reconfigurable HWSW: Software

Page 30: RCW@DEI - Design Flow 4 SoPc

30

Hardware Side – design flowHardware Side – design flow

30

Page 31: RCW@DEI - Design Flow 4 SoPc

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

Page 32: RCW@DEI - Design Flow 4 SoPc

32

System DescriptionSystem Description

Page 33: RCW@DEI - Design Flow 4 SoPc

33

Area ConstraintsArea Constraints

Xilinx VIIP

Xilinx S3

Xilinx V4

Page 34: RCW@DEI - Design Flow 4 SoPc

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;

Page 35: RCW@DEI - Design Flow 4 SoPc

35

Design Synthesis and Placement Design Synthesis and Placement Constraints AssignmentConstraints Assignment

Page 36: RCW@DEI - Design Flow 4 SoPc

36

System GenerationSystem Generation

Context Creation: EAPR-basedContext Creation: EAPR-based

Page 37: RCW@DEI - Design Flow 4 SoPc

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

Page 38: RCW@DEI - Design Flow 4 SoPc

38

Software Side – Standalone Software Side – Standalone SolutionSolution

Page 39: RCW@DEI - Design Flow 4 SoPc

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

Page 40: RCW@DEI - Design Flow 4 SoPc

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

Page 41: RCW@DEI - Design Flow 4 SoPc

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

Page 42: RCW@DEI - Design Flow 4 SoPc

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

Page 43: RCW@DEI - Design Flow 4 SoPc

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

Page 44: RCW@DEI - Design Flow 4 SoPc

44

Software Side – Linux SolutionSoftware Side – Linux Solution

Page 45: RCW@DEI - Design Flow 4 SoPc

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? :)

Page 46: RCW@DEI - Design Flow 4 SoPc

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

Page 47: RCW@DEI - Design Flow 4 SoPc

47

QuestionsQuestions