LectureAcceleratorDesignintheXUPBoard.pptVIP

Lecture 16: Accelerator Design in the XUP Board Objectives Understand accelerator design considerations in a practical FPGA environment Gain knowledge in some details of the XUP platform required for efficient accelerator design Four Fundamental Models of Accelerator Design Hybrid Hardware/Software Execution Model Hardware Accelerator as a DLL Seamless integration of hardware accelerators into the Linux software stack for use by mainstream applications The DLL approach enables transparent interchange of software and hardware components Application level execution model Compiler deep analysis and transformations generate CPU code, hardware library stubs and synthesized components FPGA bitmaps as hardware counterpart to existing software modules. Same dynamic linking library interfaces and stubs apply to both software and hardware implementation OS resource management Services (API) for allocation, partial reconfiguration, saving and restoring the status, and monitoring Multiprogramming scheduler can pre-fetch hardware accelerators in time for next use Control the access to the new hardware to ensure trust under private or shared use MP3 Decoder: Madplay Lib. Dithering as DLL Madplay shared library dithering function as software and FPGA DLL Audio_linear_dither() software profiling shows 97% of application time DL (dynamic linker) can switch the call to hardware or software implementation Used by ~100 video and audio applications CPU-Accelerator Interconnect Options PLB (Processor Local Bus) Wide transfer – 64 bits Access to DRAM channel 1/3 CPU frequency Big penalty if bus is busy during first attempt to access bus OCM (On-chip Memory) interconnect Narrower – 32 bits No direct access to DRAM channel CPU clock frequency Motion Estimation Design Experience Significant overhead in mmap, open calls This arrangement can only support accelerators that will be invoked many times Notice dramatic reduction in computation time Notice large overhead in data mars