INSTITUT D’ÉLECTRONIQUE ET DE … · Institut d’Electronique et de Télécommunications de...

1UMR6164

INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES

Techniques de conception et applications sur FPGAs

partiellement reconfigurables

Jean-Philippe Delahaye

Doctorant à Supélec

SUPELEC - Campus de Rennes - FRANCESCEE team – Signal, Communication and Embedded Systems

IETR – UMR 6164Institut d’Electronique et de Télécommunications de Rennes

Séminaire SCEE, - Nov. 2005 - Rennes2


Techniques de conception et Application sur FPGA partiellement reconfigurable

• Introduction

• Flot de conception Modular Design

• La reconfiguration partielle de FPGA

• L’ application P-HAL

• Conclusion



Introduction

• Clock Ressources:– Global Clock Trees (GCLKBUF)

– DLLs/DCMs

• Logic Ressources: – CLB array

• 2 Flops/Luts par Slices• 2 Slices par CLB • 2 TBUF par CLB

– BlockRAMs, BlockMult– IOBs

• Xilinx FPGA: architecture overview



Xilinx Modular Design Xilinx Modular Design [1][1]

FPGA Design Methodology

• Module Based Design flow• Available with ISE Fundation Tools• Compatible with the following device families:

• Virtex-II Pro• Virtex /-II /-E• Spartan –II /-IIE /-3

• Design Entry and Synthesis

[1] : Development System Reference Guide (->Chapter 4)



Xilinx Modular DesignXilinx Modular Design

FPGA Design Methodology

• 3 Phases flow– Design / Modules Synthesis

3. Initial Budgeting (floorplanning)

4. Active Phase (Implementation of each Module)

5. Final Phase (Implementation of the complete top design )



• To write HDL with ‘‘good’’ rules …• Full Synchron. Design• I/O ports Declaration (IOB) at the

Top- level . • To Limit I/O Number.• Use registered I/O.

Modular Design: General design rules

◆ Modules are writen as independent component.

◆ Multiple component instantiation are not supported.

◆ One Netlist for each module in the design



Directories Structure Proposal

Modular Design: Directories structure

•Hdl Dir : for all sources storage.•Synthesis Dir : for each Top/Module ISE project•Implementation Dir :

•for each Module active implementation•For each Top final assembly implementation •Pims is automattically created

•Bitstream Dir : to store all configuration of the FPGA (optional).

Advantage: Best project visibility



Modular Design:Synthesis Step

• At the top-Level:– Declaration of all IOBs in I/O Buffers – Module Instanciation as ‘black boxes’

• At the Module Level:➨ Unselect Add I/O Buffers option

Create a ISE Fundation Project for each top configuration and for each module:

➨One Netlist for each module➨Using the same name for a module and his HDL file.

➨Netlist (.ngc files) is generated for each modules/top (with XST Synthesis tools)

ISE Project navigator menu: process->properties



Modular Design: Initial Budgeting Phase

• Initialise/Entering in the Modular Design Flow

• Assign contraint on top design and each Modules :– Timing Contraints using constraints_editor tools– Area Contraints Using Floorplanner tools

> Constraints_editor design_name.ngd (To Apply timing contraints)> floorplanner design_name.ngd (To Apply area contraints)

> ngdbuild -modular initial design_name (top netlist file .ngc or edif)

Create mydesign.ucf contraints file

file->write constraints…



> ngdbuild -uc module_name.ucf -modular module -active module_name (launch Active phase for module implementation) top_dir_path/design_name.ngo

> map design_name.ngd (netlist mappping for the module)> par -w design_name.ncd design_name_routed.ncd (placement routage du module)pimcreate pim_dir_path -ncd design_name_routed.ncd (Place&Route design copy in the dir.

pim_dir_path)

• To be run for each module implementation• Module are separately placed and routed in their own

directories

– Timing Contraints using constraints_editor tools– Area Contraints Using Floorplanner tools

Modular Design: Active phase



Modular Design: Active phase

Each module is Placed and routed in the constrained Top-level design

>fpga_editor module_name_routed.ncd



Modular Design:Final Phase

> ngdbuild -modular assemble -pimpath pim_dir design_name (Enterring into the Final phase) > map design_name.ngd (mappping of the top-level design)> par -w design_name.ncd design_name_routed.ncd (place-route of the top-level design)

• Assembling the Top-level Design

– Merging the Placed & Routed modules in the Top-level design



Modular Design:Final Phase



Modular Design:commands samples

\Implementation\top > ngdbuild -modular initial top.ngc> floorplanner top.ngd

> ngdbuild -uc ..\ application\ application.ucf -modular module -active object ..\ application\ application.ngo object.ngd> map object.ngd -o object_map.ncd> par -w object_map.ncd object_routed.ncd> pimcreate ..\Pims\ -ncd object_routed.ncd

\implementation\object\

1. Initial Budgeting Phase1. Initial Budgeting Phase

2. Active Phase2. Active Phase

> ngdbuild -modular assemble -uc ../application/ application.ucf -pimpath ../Pims application.ngo> map application.ngd -o application _map.ncd> par -w application _map.ncd application _routed.ncd

3. Final Phase3. Final Phase\implementation\application\

4. Bitstreams generation4. Bitstreams generation\bitstream\

>bitgen -w -g Binary:yes application_routed.ncd application_total.bit



• 2 Flows for Partial bitstream [4]:–Module Based reconfiguration

• Mandatory based on Modular Design

–Difference based reconfiguration.• For small bit manipulation

• 2 types of partial reconfiguration –multi-columns modules without comm.–multi-columns with inter-module

communication (-> Using bus macro)

[4] XAPP290: Two Flows for Partial Reconfiguration

Partial Reconfiguration:Overview



• Design Constraints on a module :– minimal reconfigurable area 4CLB rows. (->Bus

macro)

• The IOBs adjoining the reconfigurable area are dedicated to this area.

• All communications throw Bus Macro.• The Same Overall I/O declaration in

each module configuration– ex: PRmoduleA uses 5 e/s E1:{clk,in1,in2,in3,out1}– PRmoduleB uses 4 e/s E2:{clk,in1,in4,out2}– Then I/O to declare in each configuration are :

– E1 U E2 : {CLK, in1, in2,in3, in4,out1,out2}

Partial Reconfiguration:Module based flow



• Specific commands during Modular Design flow:– In the contraints file .ucf : AREA_GROUP

"AG_prmodule" MODE=RECONFIG;– Command line of bitgen adds the following option

ACTIVERECONFIG=YES• UCF file sample (Virtex-II constraints):

AREA_GROUP "AG_U0" RANGE = SLICE_X78Y111:SLICE_X79Y0 ;AREA_GROUP "AG_U0" RANGE = TBUF_X78Y111:TBUF_X78Y0 ;AREA_GROUP "AG_U0" MODE = RECONFIG ;




• Xilinx Bus Macro features:– Provided by Xilinx for Virtex -E/-II / -II pro Devices families– Communication Bus on 4 bits.– Using 8 TBUFs.– Horizontally placed between 2 modules– Use of Dedicated routing long line for Tri-State Buffer


component bm_4bport(

LI : in std_logic_vector (3 downto 0);LT : in std_logic_vector (3 downto 0)RI : in std_logic_vector (3 downto 0);RT : in std_logic_vector (3 downto 0);O : out std_logic_vector (3 downto 0)

);end component;



Bus Macro

Module Fixe

Partie reconfigurableModule AModule B

Partial Reconfiguration:Animation



> bitgen -g ActiveReconfig:Yes -g Persist:Yes -r top_c1.bit top_routed_c2.ncd c1_c2_diff_partial.bit

Partial Reconfiguration:difference based flow

PAR

ncd(Top-level design)

Placed/routed

Top-level design PAR manipulation

Top-level difference(Bitstream)

bit(Total Bitstream)

Partial Bitstream

•Small bit manipulation–Design entry:

placed&routed top-level design



-Edit placed-routed design in fpga_editor

-Modify LUT/blockRAM small functions

-Save new design in a .ncd file

-Generate bitstream by difference

> bitgen -g ActiveReconfig:Yes -g Persist:Yes -r top_c1.bit top_routed_c2.ncd c1_c2_diff_partial.bit

Partial Reconfiguration:difference based flow

•Small bit manipulation



Xilinx partial reconfiguration Sum-up

Partially reconfigurable module/ partFixed Modules and top level logicBus macro

•Small bit manipulation•Module based Partial reconf



Module-Diff-Based Design Flow

Partially reconfigurable module/ partFixed Modules and top level logicWrappers

•Module difference Flow is a Mixed Flow:

–Design entry: HDL

–Use of Standard Modular Design flow

–Use of Wrapper : comm. interface between reconfigurable and fixed modules

-Use of Difference-Based Partial bitstream creation



N columns: Initial budgeting

Initial budgeting for the reconfigurable Logic Area

Module-Diff-Based Design Flow•Module difference Flow: Optimize the Partial bitstreams

Reserved but never used logic (x columns)

•With Module-based Flow :

–Bitstream size = N Columns

•With Module-Diff-based Flow :

–Bitstream size = N-x Columns A

P&R Module A in N-x columns

B

P&R Module B in N-y columns (y>x)



Module-Diff-Based Design Flow•Module difference Flow: Optimize the Partial bitstreams

•Module-Diff-based Flow benefits:

Reconfigurable Module

The MD-based Flow enable the Partial Columns Reconfiguration (2D reconfiguration)

Fixed Logic

Fixed Module runs during the partial reconfiguration !



Module-Diff-Based Design Flow•Module difference Flow: Wrappers can replace Bus Macro

Reconfigurable Logic

Fixed Logic

Wrappers are Relationally Placed Macro of logic cells to constrain the routing resources between reconfigurable part and Fixed parts of a design

Wrapper



Module-Diff-Based Design Flow•Module difference Flow: reduce further more the bitstream !

Reused Logic blocks in several configurations: The logic blocks location constraints of a reconfigurable module decrease the partial bitstream size



- Xilinx Guides: available on c:\xilinx\doc\english\

[1] : Development System Reference Guide (dev.pdf)[2] : Constraint Guide (cgd.pdf)[3] : Libraries Guide (lib.pdf)

- Xilinx XAPPs:[4] XAPP290: Two Flows for Partial Reconfiguration[5] XAPP151: Virtex Series Configuration Architecture User Guide

- Support:www.support.xilinx.com

- From the web:Tutorials:

http://appsrv.cse.cuhk.edu.hk/~ceg5010/tut/fpga.htmhttp://ic2.epfl.ch/~gmermoud/files/publications/DPRtutorial.pdf

Mailing list:http://www.itee.uq.edu.au/~listarch/partial-reconfig/archive/2005/09/index.html

Main Technical documentations

Starting with Partial Reconfiguration

http://www.support.xilinx.com/





http://appsrv.cse.cuhk.edu.hk/~ceg5010/tut/fpga.htm














http://ic2.epfl.ch/~gmermoud/files/publications/DPRtutorial.pdf








http://www.itee.uq.edu.au/~listarch/partial-reconfig/archive/2005/09/index.html
















Overview ofConcepts, Architecture, Definitions,

Rules, …Xavier Revés, Antoni Gelonch, Vuk Marojevic,

Radio Communications GroupUniversitat Politècnica de Catalunya

P-HAL: Platform-Hardware Abstraction Layer [1]

[1] ''FPGA's Middleware for Software Defined Radio Applications'', X. Revés, V. Marojevic, R. Ferrús, and A. Gelonch, 15th International Conference on Field Programmable Logic and Applications (FPL’05), Tampere, Finland, 24-26 Aug. 2005



P-HAL: Introduction

P-HAL stands for Platform and Hardware Abstraction Layer. It extends the HAL definition towards any kind of underlying resource, either hardware or software, and orienting its offered services towards a particular set. In particular, the supported function set is useful for radio applications, although not limited to this kind of application.

• What’s P-HAL? (initial view)



Objectives behind P-HAL Develop Radio Applications on Heterogeneous Platforms:

General-Purpose Processors (GPP) Digital Signal Processors (DSP) Field Programmable Gate Arrays (FPGA)

Complete independence between application and platform running it: abstraction.

Independence between the different pieces compounding the application.

Independent sources for programs.

Application runs within some given temporal restrictions: crucial in radio applications.

Offer mechanisms to monitor and control the application. Parameterisation, Statistics and Behaviour



HAL

Hardware

OperatingSystem Services

OS API

Application

OS Layer Stack

Platform 2.e.g. with API forcommunications

HW HW HW

Abstraction AbstractionAbstraction

Different Abstraction Depths

Application

P-HAL Layer Stack

P-HAL Abstraction Level

Platform 3.e.g. with OS

Platform 1.e.g. pure hardware

P-HAL: Introduction• Different Layer Views



• Object-Oriented Programming An application is made of several objects running

independently on one or more processors.

Each object interfaces with other objects through FIFO-like interfaces.

Interfaces carry packets of data. Data represent samples of signals. The meaning of samples is contextual: waveform samples, symbols, bits, characters, etc.

An object only uses P-HAL API to access the external resources (parameters, etc.) or to use the interfaces.

An interface is defined including information like bits per sample, samples per second, logic format of data, etc.

P-HAL: Application Model



•From abstract model to real executionObjects do not interface with other objects but with P-HAL structures. P-HAL may require to introduce special objects to adapt interfaces: e.g. two’s complement 14-bit samples to binary natural 12-bit samples.

Virtual Layer P-HAL

Task 1Task 2

Task 3Task 4

Task 5Task 6

Real Application Execution

Abstract Application Description

Object Task 1

Object Task 2

Object Task 3

Object Task 4

Object Task 6

Object Task 5

?Other Layers




•The software model architecture




FPGA object program (likely in VHDL or similar) is “linked” with P-HAL library functions to generate the FPGA program. It is adequate for the target platform.

The initialisation, execution and stopping of an application follow the same sequence than in GPP or DSP.

Set of “API” functions defined so far: General data interface (for data flows) RAM interface (to store tables on external memory) [NEW!!] Initialisation interface. Request interface. Statistics interface. Serving interface. Control word interface Time flags

Application Construction FPGA parts

•The P-HAL API adaptation to FPGA



OBJECT

ALGORITHM

P-HALINTERFACE

SWITCH (ROUTING TABLE)

DATA LOGICAL INTERFACES: FIFO-LIKE

PHYSICAL INTERFACES

P-HAL RAMADAPTATION

LOGICAL RAM INTERFACE

SBSRAMSDRAMSRAM

MEMORY POOL

ENABLE/DISABLE/RESETSTATUS MONITOR

P-HALCONTROL

PORT

CONTROL WORD

BIDIRECTIONAL SERIAL PORT FOR REQUESTS (IN/OUT)

PHYSICAL INTERFACE

TIMEREGISTER

TIME STAMPON-BOARD TIME INTERFACE

•The P-HAL API adaptation to FPGA




BU

S B

RID

GE

P-HAL ONLYFPGA

Serial ControlInterfaces(32 Mb/s)

Bus Interfaces(128 MB/s peak)

IBU

S

VM

E

Shared BufferP-HAL controlSerial Interface

DedicatedInterfaces(128 MB/s)

VMEInterface

(<60 MB/s)

I/O C

onne

ctio

nI/O

Con

nect

ion

RAM InterfaceIBUS InterfaceObject Area

FPGA 1FPGA 2FPGA 3

FPGA 4 FPGA 5 FPGA 6

FPGA 7

BU

S B

RID

GE

P-HAL ONLYFPGA

Serial ControlInterfaces(32 Mb/s)

Bus Interfaces(128 MB/s peak)

IBU

S

VM

E

Shared BufferP-HAL controlSerial Interface

DedicatedInterfaces(128 MB/s)

VMEInterface

(<60 MB/s)

I/O C

onne

ctio

nI/O

Con

nect

ion

RAM InterfaceIBUS InterfaceObject Area

FPGA 1FPGA 2FPGA 3

FPGA 4 FPGA 5 FPGA 6

FPGA 7

SHaR

e B

OA

RD

P-H

AL S

truc

ture

•The P-HAL API adaptation to FPGA: A real example




IBUS Interface

Object

RAM Interface

Shar

ed B

uffe

r

Serial Interface

P-HAL control

FPGA

Object 1 &P-HAL API

StandardImplementation

Full Design Reconfiguration

FPGA

Object 2 &P-HAL APIFull FPGA

Reconfiguration

IBUS Interface

Object 1

RAM Interface

Sha

red

Buf

fer

Serial Interface

P-HAL control

Goal : Reconfigure only the Object DesignGoal : Reconfigure only the Object Design

Object 2

Partial Reconfiguration

•The P-HAL API adaptation to large FPGA

P-HAL in FPGA: Enhancements to Partially Reconfigurable Design




•P-HAL:

Place&Route Design

–Designed by P&R Module

– Partially reconfigurable

Object

–Paramatrable Wrappers and Interfaces

Object

Wra

pper

Object

P-HAL API

L_DC Interface

IBUS Interface

R_DCInterface

P-HAL APIIBUS Interface

L_DC Interface

R_DCInterface

Wra

pper



LARGE FPGA

COMON P-HAL

OBJECT 1

OBJECT 2

SMALL FPGA

SINGLE P-HAL

OBJECT 2

SMALL FPGA

SINGLE P-HAL

OBJECT 1

A single FPGA can be shared by multiple objects if development tools can separate configuration for them.

Single-threaded FPGAs can easily exchange the running object but introduce more overhead..


•The P-HAL API adaptation to large FPGA



Partial FPGAReconfiguration

Object 1P-HAL API


Single Object implementation

Multiple Objects implementation

Object 2P-HAL API

Reconfigurable P-HAL Interfaces

Fixed Logic

Partially Reconfigurable Logic

Reconfigurable to Fixed Logic Communications Interfaces (Wrappers)

Partial FPGAReconfiguration Obj.Obj.

33 P-HAL API

Obj.Obj.44

Obj.Obj. 11 P-HAL

API

Obj.Obj.22



External reconfiguration• µP device– downloads

bitstreams– through

SelectMap interface

• SRAM– bitstream

storage

µPConfig.

controller

SelectMap/JTAG linkConfiguration transfert(bitsream)

Interface Controller

SRAMBitstream Storage

Rec

onfig

urab

leL

ogic

Part

s

Rec

onfig

urab

le M

odul

eFu

ll co

lum

ns (L

ogic

, IO

Bs)

FixedLogicParts

IOs Logic

Prototyping platformSystem Architectures to perform reconfiguration



Internal reconfiguration• Boot loader– initial config.– instanciates

ICAP, config. Controller, etc.

• µBlaze– Read/write

bitstreams– Auto-

reconfiguration through ICAP

ComPort (Data transfert)

SRAM

Bitstream Storage

Data Memory

Rec

onfig

urab

leL

ogic

Part

s

Rec

onfig

urab

le M

odul

eFu

ll co

lum

ns (L

ogic

, IO

Bs) PPC/µBlaze

Config.controller

OPB

ICAP

ICAPInterface

Fixed

Logic

Parts

IOs Logic

Boot loader




• Heterogeneous processing platform– GPP + Memory as a host (PC Workstation)– Sundance carrier board (PCI interfaced)– DSPs TI C64– FPGAs Xilinx Virtex –II


SMT310 carrier board



Discussion

INSTITUT D’ÉLECTRONIQUE ET DE … · Institut d’Electronique et de Télécommunications de...

Documents

Transcript of INSTITUT D’ÉLECTRONIQUE ET DE … · Institut d’Electronique et de Télécommunications de...