Techniques de conception et applications sur FPGAs partiellement reconfigurables

Transcription

1 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 UMR

2 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 2

3 Introduction Xilinx FPGA: architecture overview 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 3

4 FPGA Design Methodology Xilinx Modular Design [1] 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) 4

5 FPGA Design Methodology Xilinx Modular Design 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 ) 5

6 Modular Design: General design rules 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. Modules are writen as independent component. Multiple component instantiation are not supported. One Netlist for each module in the design 6

7 Modular Design: Directories structure Directories Structure Proposal 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 7

8 Modular Design: Synthesis Step 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. 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 ISE Project navigator menu: process->properties Netlist (.ngc files) is generated for each modules/top (with XST Synthesis tools) 8

9 Modular Design: Initial Budgeting Phase Initialise/Entering in the Modular Design Flow > ngdbuild -modular initial design_name (top netlist file.ngc or edif) Assign contraint on top design and each Modules : Timing Contraints using constraints_editor tools Area Contraints Using Floorplanner tools > Constraints_editor design_name.ngd > floorplanner design_name.ngd (To Apply timing contraints) (To Apply area contraints) file->write constraints Create mydesign.ucf contraints file 9

10 Modular Design: Active phase 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 > 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) 10

11 Modular Design: Active phase Each module is Placed and routed in the constrained Top-level design >fpga_editor module_name_routed.ncd 11

12 Modular Design: Final Phase Assembling the Top-level Design Merging the Placed & Routed modules in the Top-level design > 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) 12

13 Modular Design: Final Phase 13

14 Modular Design: commands samples 1. Initial Budgeting Phase \Implementation\top > ngdbuild -modular initial top.ngc > floorplanner top.ngd 2. Active Phase \implementation\object\ > 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 3. Final Phase \implementation\application\ > 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 4. Bitstreams generation \bitstream\ >bitgen -w -g Binary:yes application_routed.ncd application_total.bit 14

15 Partial Reconfiguration: Overview 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 15

16 Partial Reconfiguration: Module based flow 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} 16

17 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 ; 17

18 Partial Reconfiguration: Module based flow 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_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 Partial Reconfiguration: Animation Module Fixe Bus Macro Partie B A Module reconfigurable 19

20 Small bit manipulation Partial Reconfiguration: difference based flow PAR Design entry: placed&routed top-level design ncd (Top-level design) Placed/routed bit (Total Bitstream) Top-level design PAR manipulation Top-level difference (Bitstream) Partial Bitstream > bitgen -g ActiveReconfig:Yes -g Persist:Yes -r top_c1.bit top_routed_c2.ncd c1_c2_diff_partial.bit 20

21 Small bit manipulation Partial Reconfiguration: difference based flow -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 21

22 Xilinx partial reconfiguration Sum-up Module based Partial reconf Small bit manipulation Partially reconfigurable module/ part Fixed Modules and top level logic Bus macro 22

23 Module-Diff-Based Design Flow 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 Partially reconfigurable module/ part Fixed Modules and top level logic Wrappers 23

24 Module-Diff-Based Design Flow Module difference Flow: Optimize the Partial bitstreams N columns: Initial budgeting With Module-based Flow : B A Bitstream size = N Columns With Module-Diff-based Flow : Bitstream size = N-x Columns Reserved but never used logic (x columns) Initial budgeting for the reconfigurable Logic Area P&R Module A in N-x columns P&R Module B in N-y columns (y>x) 24

25 Module-Diff-Based Design Flow Module difference Flow: Optimize the Partial bitstreams Module-Diff-based Flow benefits: The MD-based Flow enable the Partial Columns Reconfiguration (2D reconfiguration) Fixed Module runs during the partial reconfiguration! Reconfigurable Module Fixed Logic 25

26 Module-Diff-Based Design Flow Module difference Flow: Wrappers can replace Bus Macro Reconfigurable Logic Wrapper Fixed Logic Wrappers are Relationally Placed Macro of logic cells to constrain the routing resources between reconfigurable part and Fixed parts of a design 26

27 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 Starting with Partial Reconfiguration Main Technical documentations - 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: - From the web: Tutorials: Mailing list: 28

29 P-HAL: Platform-Hardware Abstraction Layer Overview of Concepts, Architecture, Definitions, Rules, Xavier Revés, Antoni Gelonch, Vuk Marojevic, Radio Communications Group Universitat Politècnica de Catalunya [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, Aug [1]

30 P-HAL: Introduction What s P-HAL? (initial view) 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. 30

31 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 P-HAL: Introduction Different Layer Views OS Layer Stack P-HAL Layer Stack Application Application P-HAL Abstraction Level Different Abstraction Depths OS API Operating System Services HAL Abstraction Hardware HW Abstraction HW Platform 2. Platform 1. e.g. pure hardware e.g. with API for communications Abstraction HW Platform 3. e.g. with OS 32

33 P-HAL: Application Model 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. 33

34 P-HAL: Application Model 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. Abstract Application Description Real Application Execution Virtual Layer Other Layers Object Task 1 Object Task 2 Object Task 4 Object Task 3 Task 1 Task 2 Object Task 5 Object Task 6 Task 3 Task 4 Task 5 Task 6 P-HAL? 34

35 P-HAL: Application Model The software model architecture 35

36 Application Construction FPGA parts The P-HAL API adaptation to FPGA 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 36

37 Application Construction FPGA parts The P-HAL API adaptation to FPGA PHYSICAL INTERFACE BIDIRECTIONAL SERIAL PORT FOR REQUESTS (IN/OUT) DATA LOGICAL INTERFACES: FIFOLIKE P-HAL CONTROL PORT P-HAL INTERFACE SWITCH (ROUTING TABLE) OBJECT ON-BOARD TIME INTERFACE ALGORITHM TIME STAMP PHYSICAL INTERFACES MEMORY POOL LOGICAL RAM INTERFACE P-HAL RAM ADAPTATION TIME REGISTER SBSRAM SDRAM SRAM CONTROL WORD ENABLE/DISABLE/RESET STATUS MONITOR 37

38 Application Construction FPGA parts Serial Control Interfaces (32 Mb/s) FPGA 2 IBUS Bus Interfaces (128 MB/s peak) VME Interface (<60 MB/s) FPGA 1 VME FPGA 3 P-HAL ONLY FPGA Dedicated Interfaces (128 MB/s) FPGA 4 BUS BRIDGE I/O Connection Shared Buffer P-HAL control Serial Interface RAM Interface IBUS Interface Object Area I/O Connection SHaRe BOARD P-HAL Structure The P-HAL API adaptation to FPGA: A real example FPGA 7 FPGA 5 FPGA 6 38

39 P-HAL in FPGA: Enhancements to Partially Reconfigurable Design Object Goal : Reconfigure only the Object Design Shared Buffer Serial Interface Shared Buffer The P-HAL API adaptation to large FPGA Serial Interface Object Object21 RAM Interface Partial RAM Interface Reconfiguration P-HAL control Standard Implementation Object 1 & P-HAL API FPGA IBUS Interface P-HAL control IBUS Interface Full Design Reconfiguration Full FPGA Reconfiguration Object 2 & P-HAL API FPGA 39

40 P-HAL in FPGA: Enhancements to Partially Reconfigurable Design L_DC Interface Object Wrapper P-HAL: P-HAL API IBUS Interface Place&Route Design Designed by P&R Module Partially reconfigurable Object R_DC Interface Paramatrable Wrappers and Interfaces 40

41 Application Construction FPGA parts The P-HAL API adaptation to large FPGA LARGE FPGA SMALL FPGA OBJECT 1 OBJECT 1 OBJECT 2 SMALL FPGA OBJECT 2 SINGLE P-HAL SINGLE P-HAL COMON P-HAL 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.. 41

42 P-HAL in FPGA: Enhancements to Partially Reconfigurable Design Single Object implementation Object 1 P-HAL API Partial FPGA Reconfiguration Object 2 P-HAL API Multiple Objects implementation Obj. 1 Obj. 2 Partial FPGA Reconfiguration P-HAL API Obj. 3 Obj. 4 P-HAL API Partially Reconfigurable Logic Fixed Logic Reconfigurable to Fixed Logic Communications Interfaces (Wrappers) Reconfigurable P-HAL Interfaces 42

43 Prototyping platform System Architectures to perform reconfiguration SRAM bitstream storage SRAM Bitstream Storage Reconfigurable Module Full columns (Logic, IOBs) downloads bitstreams through SelectMap interface External reconfiguration Reconfigurable Logic Parts µp device IOs Logic Fixed Logic Parts µp Config. controller Interface Controller SelectMap/JTAG link Configuration transfert (bitsream) 43

44 Prototyping platform System Architectures to perform reconfiguration Boot loader Read/write bitstreams Autoreconfiguration through ICAP SRAM Reconfigurable Module Full columns (Logic, IOBs) µblaze Reconfigurable Logic Parts initial config. instanciates ICAP, config. Controller, etc. Internal reconfiguration PPC/µBlaze Config. controller Bitstream Storage Data Memory OPB Fixed Logic Parts ICAP Interface ICAP ComPort (Data transfert) Boot loader IOs Logic 44

45 Prototyping platform System Architectures to perform reconfiguration 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 45

46 Discussion 46