reconfigurable computing partial reconfiguration design ... · pdf filefloorplanning and...

Reconfigurable Computing

Partial reconfiguration design

Chapter 8

Prof. Dr.-Ing. Jürgen Teich

Lehrstuhl für Hardware-Software-Co-Design


Dynamic Partial Reconfiguration Design - Introduction

Advantages of Reconfigurable Hardware Designs

Speedup in comparison to GPP

Higher flexibility in comparison to ASIC

Advantages of Partial Dynamic Reconfiguration

Area (cost) savings

Power savings


2

Reconfigurable Platform

CPU

HW Module 1

HW Module 2

HW Module 3

Motion

Texture

Color

Shape

Edge

Color

Shape

Edge

Motion

The Altera video surveillance

camera reference designSource: www.terasic.com.tw

Partial Reconfiguration Design - Introduction

A partially reconfigurable design consists of: A set of full reconfigurable designs

A set of partial designs which can be separately downloaded

The full designs as well as the partial modules are available as full (partial) bitstream used to configure the device

The partially reconfigurable modules are use to move the system from one configuration to the next one


3

Partial reconfiguration design - Introduction

The purpose of this section is to learn how to design a

partially reconfigurable system using the current CAD

tools and devices

The Xilinx FPGAs (Virtex and Spartan) are some of the

few devices on the market allowing partial reconfiguration

This section will focus three Xilinx FPGA-based

methodologies for designing a partially reconfigurable

system:

The Xilinx partial design flow

The ReCoBus-Builder flow

The Xilinx PlanAhead flow


4

Things to know

A frame is the smallest unit of configuration.

Spans the height of the FPGA (Virtex-II family) or the

height of one or more clock regions (newer Virtex families)

Configuration is glitchless. If you reconfigure a frame with

the same data, no glitches appear on the signal lines.

Reconfiguration “reinitializes” SRL16s and LutRAM, not

BlockRam


5

Xilinx Partial Flow


Partial reconfiguration design - Approach

Traditional design flow

Full circuit

Constraints define:

Placement Constraints

Relative Location Constraints

Timing Constraints

Only one full circuit is

generated


7

VHDLBasic Constraints

(pins, timing, …)+

Netlist

Full

Bitstream

Technology Mapping

Place and route

All constraints

provided earlier


Partial reconfiguration flow:

Placement constraints

must be provided

Modules are compiled

separately

The result is a set of full and

partial implementations (EDIF

and bitstream).

The partial reconfigurable

bitstreams are used to move

the device from one

configuration to another.


8

Netlist 3

VHDL

Basic Constraints

(pins, timing, …)+


(block positions and area)

Technology Mapping

Place and route

Netlist 2Netlist 1 Netlist 3Netlist 2Netlist 1

Full Partial

Full

Bitstream 3

Full

Bitstream 2

Full

Bitstream 1

partial

Bitstream 3

partial

Bitstream 2

partial

Bitstream 1


Delaying placement constraints increases degree of freedom


9

Basic

constraints

Basic

constraints

Basic

constraints

VHDL SystemC HandelC

Netlist 3

Technology Mapping

Place and route

Netlist 2Netlist 1 Netlist 3Netlist 2Netlist 1

Full Partial

Full

Bitstream

3

Full

Bitstream

2

Full

Bitstream

1

partial

Bitstream

3

partial

Bitstream

2

partial

Bitstream

1


(block positions and

area)

+

Placement

constraints

Run-time

Relocation

Area constraints

provided after a

first evaluation

Partial reconfiguration on Xilinx Virtex FPGAs

Create a bitstream database for full and

partial modules to be used at run-time

for device reconfiguration


10

Source: Images generated with Xilinx ISE design tool

The partial design flow

Modular implementation of a large project

The team manager defines the structure of the overall project (top-level)

Each designer or team of designers imple-ment and test each module separately

The implemented modules are inte-grated in the final design

A top-level consists of A set of independent modules

Interfaces between the modules

Interfaces with the pins

Each module is assigned a given position and area on the device by means of area constraints


11

Top1

mod

1

mod

2

mod

3

Interfaces

The partial design flow

For partial reconfiguration, the goal is to generate

A set of full designs

A set of partial designs

The partial designs are used to move from one full design to another

The input is structured as follows: Top_level

Module_1

Module_2

…

Module_N

The input language can be any HDL


12

Top3

mod

1

mod

2

mod

3

Top2

mod

1

mod

2

mod

3

Top1

mod

1

mod

2

mod

3

The partial design flow – Example

Modular design Static module is

fixed for all times

Only partial module can be reconfigured

Insertion of communication macros at fixed positions


13

Partial

Module

Static

Module

Partial

Module

Static

Module

t1 t2

t3t4

yx

The partial design flow – Use of Slice Macros

The routing of two designs creates unpredictable paths

Signals connecting two reconfigurable modules in two different designs can be routed in different ways

This can produce malfunction of the design after reconfiguration

This can be avoided by providing fixed communication channels (slice macros) among reconfigurable modules

Bus macros are tri-state lines running over 4 CLBs in FPGA Must be placed only at the top level!


14

Bus macros

The partial design flow – Four Steps

1) Build the top level context Slice Macros at fixed positions are used to communicate

between static design logic and reconfigurable logic.

Note that there is NO logic except IOs and clocks in the top

level design. All logic is contained in one or more 'modules'

(e.g., AREA_GROUP).

Required files : top.ngc and top.ucf (for constraints)

Output file: top.ngo.

2) Build the static modules These are the modules (E.G. logic and routing) that will NOT

be dynamically reconfigured.

Required files: .ngc for each static 'module'.

Output files: top_routed.ncd (without reconfigurable logic)


15


3) Build the dynamic modules Build each flavor of each dynanically reconfigurable module.

Required files: .ngc for each dynamic 'module'.

Output files: Routed .ncd file for each flavor of a dynamically

reconfigurable module WITHOUT logic and routing from

static modules.


16


4) Assemble full design with each flavor of each

dynamically reconfigurable module. Generate the

required bitstreams. Required files: .ncd for static modules and for each flavor of

each reconfigurable

Output files:

a bitstream for full design with each flavor of each

reconfigurable module

a partial bitstream for each flavor of each reconfigurable

module

report file


17

The partial design flow – Example

Two modules

One VGA controller

One colour generator

The two modules can be partially reconfigured


18

VGA controller Color generator Overall design

Source: Images generated with Xilinx ISE design tool

ReCoBus-Builder Flow


ReCoBus Tool Flow - Introduction


20

The Simple Formula for Building Bus-based

Reconfigurable Systems

Source: A Quick Introduction into the ReCoBus Technology. Available on www12.cs.fau.de/research/recobus/technology.php

• Example system:

• Fine slot grid for reducing internal fragmentation

• Alignment-multiplexer allows free module placement

• Interface grows together with the module complexity (size)

• Very low logic overhead (no extra connection logic within the slots)

• Allows high speed / high throughput

• Hot-swap module exchange


21

CPU en dout

en dout

en dout

en dout

en dout

S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8

Module 0

en dout

Module 1

static system runtime reconfigurable system

ReCoBus Communication www.Re Bus.de


I/O-Bars for Point-to-Point Links

static system

static system

video

ReCoBus

out

audioout

Slot 0 Slot 1 Slot 5Slot 4Slot 3Slot 2

videoin

audioin


22


The ReCoBus-Builder

• Easy usable

builder for

reconfigurable

systems

• Available on

www12.cs.fau.de/

research/recobus

System Specification

(Communication Architecture & Floorplan)

generate

static

system

generate

module

repository

bitlink module.bit -pos X,Y static.bit -outfile initial.bit

Re Bus


Source: Koch, D. Partial Reconfiguration on FPGAs: Architecture, Tools and Applications, Springer, 2013.

23

ReCoBus-Builder – Design flow

module1

bitfilemodule

1

bitfile partial module

1

bitfile

bitstream linking [bitscan]

functional simulation [Modelsim]

bus & bar

RTL model

static

systemmodule

1module1module

1

OK?n

static

netlist

module1

templates

place & route static [PAR] build partial module1

initial system

bitfile

build partial module1

ReCoBus & connection bar protocol specification

[ReCoBus-Builder]

repository for the run-time system

ReCoBus

I/O barsb

itstr

ea

m a

sse

mb

lyd

esig

n e

ntr

y,

sta

tic /

dyn

am

ic

pa

rtitio

nin

g,

an

d v

erifica

tio

np

hysic

al im

ple

me

nta

tio

n

static

constraintsmodule

1

netlist

build static bitstream [bitgen] build module1 bitstream [bitgen]

place&route module1 [PAR]

module1

bitfilemodule

1

bitfile full module

1

bitfile

static system

bitfile

[ ] novel tool third party or vendor tool[ ]

budgeting

[Xilinx XST]

budgeting

[Xilinx XST]

module1

constraints

floorplanning and communication

synthesis [ReCoBus-Builder]

partial bitstream extraction

[bitscan]

Design Entry, Static/Dynamic

Partitioning, and Verification


bus & bar

RTL model

static

systemmodule

1module1module

1

OK?n


[ReCoBus-Builder]



24

Physical Implementation

OK?

static

netlist

module1

templates

place & route static [PAR] build partial module1build partial module

1

ReCoBus

I/O bars

static

constraintsmodule

1

netlist


budgeting

[Xilinx XST]

budgeting

[Xilinx XST]

module1

constraints

floorplanning and

communication synthesis

[ReCoBus-Builder]



module1

bitfilemodule

1


1

bitfile



bus & bar

RTL model

static

systemmodule

1module1module

1

OK?n

static

netlist

module1

templates


initial system

bitfile



[ReCoBus-Builder]


ReCoBus

I/O barsbitstr

eam

assem

bly

desig

n e

ntr

y,

sta

tic /

dynam

ic

part

itio

nin

g, and v

erification

physic

al im

ple

menta

tion

static

constraintsmodule

1

netlist



module1

bitfilemodule

1

bitfile full module

1

bitfile

static system

bitfile


budgeting

[Xilinx XST]

budgeting

[Xilinx XST]

module1

constraints




[bitscan]


25

module1

bitfilemodule

1


1

bitfile



bus & bar

RTL model

static

systemmodule

1module1module

1

OK?n

static

netlist

module1

templates


initial system

bitfile



[ReCoBus-Builder]


ReCoBus

I/O barsbitstr

eam

assem

bly

desig

n e

ntr

y,

sta

tic /

dynam

ic

part

itio

nin

g, and v

erification

physic

al im

ple

menta

tion

static

constraintsmodule

1

netlist



module1

bitfilemodule

1

bitfile full module

1

bitfile

static system

bitfile


budgeting

[Xilinx XST]

budgeting

[Xilinx XST]

module1

constraints




[bitscan]

Bitstream Assembly

module1

bitfilemodule

1


1

bitfile


initial system

bitfile


module1

bitfilemodule

1

bitfile full module

1

bitfile

static system

bitfile


[bitscan]




26

module1

bitfilemodule

1


1

bitfile


static

netlist

module1

templates


initial system

bitfile



ReCoBus

I/O bars

static

constraintsmodule

1

netlist



module1

bitfilemodule

1

bitfile full module

1

bitfile

static system

bitfile

budgeting

[Xilinx XST]

budgeting

[Xilinx XST]

module1

constraints

floorplanning and

communication synthesis

[ReCoBus-Builder]


[bitscan]

bitlink module.bit X Y \

static.bit initial.bit

Tested Design




27

Creation of Partial Modules

User modules need to be restricted in its place

2 Aspects of Restriction: Mapping of the functions

Routing

Mapping restrictions: Use prohibit statements in the ucf-file of the Xilinx flow

Routing restrictions: Block all not allowed routing resources by dummy

signals


28

Design Flow: Blocking



29

Start window of the ReCoBus-Builder


30


Blocking with the ReCoBus-Builder


31


Building an I/O bar


32


Building a ReCoBus


33


Small demo system


34

In the lab, you will build a small

demo system:

Xilinx PlanAhead Flow


Xilinx PlanAhead

New advanced GUI for the complete FPGA Design-Flow

Project management

Floor planning

Critical path analysis

Implementation viewer

Integration of the Partial Flow


36

Source: Xilinx, Inc.

Xilinx PlanAhead – Design flow

1. Step: Synthesis of all partial and static modules in individual netlists (Static netlist has black boxes)

2. Step: Creation of a new

PlanAhead project

3. Step: Creation of

Reconfigurable Partitions A reconfigurable partition

(RP) might consist of several

reconfigurable modules (RM)

Assign a partial netlist to

each RM

A RM can also be a black

box (empty module)


37



4. Step: Floor planning reconfigurable partitions Create Area Groups

PlanAhead automatically creates the communication ports of the reconfigurable

partition

Port proxy logic:

LUT1 (old flow:

Bus macro)

PlanAhead

automatically

creates the con-

straints file (UCF)


38



5. Step: Run design rule check (DRC) to verify the design

6. Step: Create the first reconfigurable configuration Consisting of the static module and for each RP a RM

Implement this configuration

Promote this configuration


39



7. Step: Create further configurations Import the static design

Implement the partial module

8. Step: Create the static and partial bitfiles


40


Xilinx PlanAhead – Under the Hood

The old partial flow is improved and integrated into PlanAhead

The differences are:

New proxy logic: Only one LUT is needed instead of two

Possibility to analyze the timing over the borders of partial modules


41

Flow Comparison


Flow Comparison: Tiling the Reconfigurable Area

Different ways of tiling the system

43

a) island style b) slot style c) grid style

m1

m2

m1

m2 m

3

m1

m2

m3

static part of the system unused reconfigurable area different modules

m4

m1m

2

m3m

4

m1m

2

m3m

4

m1m

2

m3 m

4 m1

m2

m3

m4

Xilinx Partial Flow

Xilinx PlanAhead

ReCoBus-Builder

Flow Future research


Flow Comparison

Feature Xilinx Partial Flow Xilinx PlanAhead ReCoBus-Builder

Device support V2, V2P, V4 V4, V5, V6Old: V2, V2P, S3

New: V4, V5, V6, S6

Floor planning manually Script and GUI-based Script and GUI-based

Routing constraint

technique for PR

region signal crossing

Explicit with dedicated

hard macros

Implicit based on an

incremental design

flow and proxy logic

Explicit by binding

signals directly to

wires (blocking)

Routing constraint

planning

Manual macro

instantiation and

placement

Automatic placement

of the proxy logic

Semiautomatic signal

to wire binding

Module RelocationNo, but possible with

handcrafting

No - a module is

bound to one fixed

position

Yes

Multi Module

Instantiation (place

same module multiple

times on the FPGA)

No, but possible with

handcrafting

No – one bitfile for

each module/position

permutation

Yes

Module Migration

among different

systems

No NoPossible within a

device family


44

Flow Comparison

Feature Xilinx Partial Flow Xilinx PlanAhead ReCoBus-Builder

Module encapsulationNo, but possible with

handcrafting

No – changes in the

static design require

rerouting of all partial

modules

Yes – the static

system and all

modules are

implemented fully

independent

Overhead 2 LUTs/signal wire 1 LUT/signal wire No logic overhead

Island style Yes Yes Yes

1D slot style

possible with

handcrafting

(only coarse-grained)

NoYes (fine and coarse-

grained)

2D grid style

possible with

handcrafting (only

coarse-grained)

NoYes, by cascading

multiple 1D rows


45

reconfigurable computing partial reconfiguration design ... · pdf filefloorplanning and...

Documents