Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Jean-Philippe Delahaye - Techniques de concepti...

SCEE Team
November 17, 2005

Jean-Philippe Delahaye - Techniques de conception et applications sur FPGAs partiellement reconfigurables

SCEE Team

November 17, 2005
Tweet

More Decks by SCEE Team

Other Decks in Research

Transcript

  1. 1 UMR 6164 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 - FRANCE SCEE team – Signal, Communication and Embedded Systems IETR – UMR 6164 Institut d’Electronique et de Télécommunications de Rennes
  2. 2 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  3. 3 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  4. 4 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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)
  5. 5 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Xilinx Modular

    Design Xilinx 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 )
  6. 6 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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 x Modules are writen as independent component. x Multiple component instantiation are not supported. x One Netlist for each module in the design
  7. 7 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  8. 8 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  9. 9 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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…
  10. 10 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES > 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
  11. 11 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Modular Design:

    Active phase Each module is Placed and routed in the constrained Top-level design >fpga_editor module_name_routed.ncd
  12. 12 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  13. 14 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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 Phase 1. Initial Budgeting Phase 2. Active Phase 2. 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 Phase 3. Final Phase \implementation\application\ 4. Bitstreams generation 4. Bitstreams generation \bitstream\ >bitgen -w -g Binary:yes application_routed.ncd application_total.bit
  14. 15 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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
  15. 16 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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
  16. 17 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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 ; Partial Reconfiguration: Module based flow
  17. 18 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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 Partial Reconfiguration: Module based flow component bm_4b port( 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;
  18. 19 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Bus Macro

    Module Fixe Partie reconfigurable Module A Module B Partial Reconfiguration: Animation
  19. 20 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES > 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
  20. 21 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES -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
  21. 22 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Xilinx partial

    reconfiguration Sum-up Partially reconfigurable module/ part Fixed Modules and top level logic Bus macro •Small bit manipulation •Module based Partial reconf
  22. 23 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Module-Diff-Based Design

    Flow Partially reconfigurable module/ part Fixed Modules and top level logic Wrappers •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
  23. 24 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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)
  24. 25 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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 !
  25. 26 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  26. 27 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  27. 28 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES - 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.htm http://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
  28. 29 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Overview of

    Concepts, Architecture, Definitions, Rules, … Xavier Revés, Antoni Gelonch, Vuk Marojevic, Radio Communications Group Universitat 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
  29. 30 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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)
  30. 31 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  31. 32 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES HAL Hardware

    Operating System Services OS API Application OS Layer Stack Platform 2. e.g. with API for communications HW HW HW Abstraction Abstraction Abstraction 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
  32. 33 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • 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
  33. 34 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES •From abstract

    model to real execution Objects 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 1 Task 2 Task 3 Task 4 Task 5 Task 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 P-HAL: Application Model
  34. 36 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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
  35. 37 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES OBJECT ALGORITHM

    P-HAL INTERFACE SWITCH (ROUTING TABLE) DATA LOGICAL INTERFACES: FIFO- LIKE PHYSICAL INTERFACES P-HAL RAM ADAPTATION LOGICAL RAM INTERFACE SBSRAM SDRAM SRAM MEMORY POOL ENABLE/DISABLE/RESET STATUS MONITOR P-HAL CONTROL PORT CONTROL WORD BIDIRECTIONAL SERIAL PORT FOR REQUESTS (IN/OUT) PHYSICAL INTERFACE TIME REGISTER TIME STAMP ON-BOARD TIME INTERFACE •The P-HAL API adaptation to FPGA Application Construction FPGA parts
  36. 38 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES BUS BRIDGE

    P-HAL ONLY FPGA Serial Control Interfaces (32 Mb/s) Bus Interfaces (128 MB/s peak) IBUS VME Shared Buffer P-HAL control Serial Interface Dedicated Interfaces (128 MB/s) VME Interface (<60 MB/s) I/O Connection I/O Connection RAM Interface IBUS Interface Object Area FPGA 1 FPGA 2 FPGA 3 FPGA 4 FPGA 5 FPGA 6 FPGA 7 BUS BRIDGE P-HAL ONLY FPGA Serial Control Interfaces (32 Mb/s) Bus Interfaces (128 MB/s peak) IBUS VME Shared Buffer P-HAL control Serial Interface Dedicated Interfaces (128 MB/s) VME Interface (<60 MB/s) I/O Connection I/O Connection RAM Interface IBUS Interface Object Area FPGA 1 FPGA 2 FPGA 3 FPGA 4 FPGA 5 FPGA 6 FPGA 7 SHaRe BOARD P-HAL Structure •The P-HAL API adaptation to FPGA: A real example Application Construction FPGA parts
  37. 39 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES IBUS Interface

    Object RAM Interface Shared Buffer Serial Interface P-HAL control FPGA Object 1 & P-HAL API Standard Implementation Full Design Reconfiguration FPGA Object 2 & P-HAL API Full FPGA Reconfiguration IBUS Interface Object 1 RAM Interface Shared Buffer Serial Interface P-HAL control Goal : Reconfigure only the Object Design Goal : 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
  38. 40 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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 Wrapper Object P-HAL API L_DC Interface IBUS Interface R_DC Interface P-HAL API IBUS Interface L_DC Interface R_DC Interface Wrapper
  39. 41 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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.. Application Construction FPGA parts •The P-HAL API adaptation to large FPGA
  40. 42 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES Partial FPGA

    Reconfiguration Object 1 P-HAL API P-HAL in FPGA: Enhancements to Partially Reconfigurable Design Single Object implementation Multiple Objects implementation Object 2 P-HAL API Reconfigurable P-HAL Interfaces Fixed Logic Partially Reconfigurable Logic Reconfigurable to Fixed Logic Communications Interfaces (Wrappers) Partial FPGA Reconfiguration Obj. Obj. 3 3 P-HAL API Obj. Obj. 4 4 Obj. Obj. 1 1 P-HAL API Obj. Obj. 2 2
  41. 43 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES External reconfiguration

    • µP device – downloads bitstreams – through SelectMap interface • SRAM – bitstream storage µP Config. controller SelectMap/JTAG link Configuration transfert (bitsream) Interface Controller SRAM Bitstream Storage Reconfigurable Logic Parts Reconfigurable Module Full columns (Logic, IOBs) Fixed Logic Parts IOs Logic Prototyping platform System Architectures to perform reconfiguration
  42. 44 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES 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 Reconfigurable Logic Parts Reconfigurable Module Full columns (Logic, IOBs) PPC/µBlaze Config. controller OPB ICAP ICAP Interface Fixed Logic Parts IOs Logic Boot loader Prototyping platform System Architectures to perform reconfiguration
  43. 45 INSTITUT D’ÉLECTRONIQUE ET DE TÉLÉCOMMUNICATIONS DE RENNES • Heterogeneous

    processing platform – GPP + Memory as a host (PC Workstation) – Sundance carrier board (PCI interfaced) – DSPs TI C64 – FPGAs Xilinx Virtex –II Prototyping platform System Architectures to perform reconfiguration SMT310 carrier board