FPGAs Software Components Graham Bardouleau Jim Kulp Mercury

Goals l l l FPGAs can now be used as scalable processing resources in heterogeneous multicomputers, not just I/O enhancers or glue logic. Many applications need multiple processor types for “best fit” (power, weight, etc. ). We must enable FPGAs to be “full peers” in the multicomputer, without undue tax on FPGA resources. Box 1 A Component System Box 4 Pentium (e. g. Intel 1 U Dual Pentium Server) Box 2 Pentium (e. g. Intel 1 U Dual Pentium Server) © 2004 Mercury Computer Systems, Inc. Interchassis Connections (network, fabric, links) PPC FPGA Box 3 Pentium G 4 FPGA (e. g. Adapdev+Atlanta+MCOE) 2 DSP (e. g. 2 Channel JTRS Radio)

FPGAs & Software Components Approach l Our approach has two thrusts: w Component programming models at application level and component level, building on standards. • How to write applications, as a set of components • How to write components, as building blocks for apps w Infrastructure elements that enable a common control model, and common communication model between peer processors of all types, including the “middleware” for FPGAs • How components are managed • How components communicate with each other © 2004 Mercury Computer Systems, Inc. 3

FPGAs & Software Components Application Programming Model l Enable all processing resource types to be easily integrated (and changed/inserted). Support real world, flexible mixing of GPPs, DSPs, FPGAs. The Component Software model does it. w A hardware-ish way of building software, usable for FPGAs w Application building blocks that can have different implementations (even different source code), for different processor types l l Standards are established for this (OMG and JTRS). We build on this heterogeneous model to embrace FPGAs. © 2004 Mercury Computer Systems, Inc. 4

What’s a Component? l A (software/FPGA) package which offers services through interfaces. l A reusable part that provides the physical packaging of implementation elements. l An independently deliverable package of software that can be used to build applications or larger components, or be an application itself. l A unit of software that is pre-built, packaged, self-describing, which can be individually deployed or updated or replaced in the field. It can be sent as an email attachment. l A well behaved DLL on steroids? © 2004 Mercury Computer Systems, Inc. 5

What’s a Component? Component Definition l Defined for its “users” by: Ports that provide service w Ports that provide a service via an interface/protocol (component acting as server) w Ports that require (use) a service via an interface/protocol (component acting as client) Config params: - Color: red (default) w Configuration (instantiation) parameters. w An overall functional behavior l l Ports that require a service Packaging (e. g. zip archive) of compiled code files (e. g. DLLs) and descriptive metadata (e. g. XML). Metadata allows tools and runtime environments to know how to use, configure, run them, after it is compiled and packaged. Component Package (e. g. ZIP file) Definition Metadata Implementation Metadata Compiled Code © 2004 Mercury Computer Systems, Inc. 6 Compiled Code

What’s an Application? l l l An application’s functionality is created by using components as parts in an assembly, and wiring together their required and provided ports. Assemblies can be used as components in higher level assemblies, enabling an application to be used as a component in a new application. Assemblies are described in metadata (usually XML), not code. © 2004 Mercury Computer Systems, Inc. 7

FPGAs & Software Components FPGA Component Model l Effective use of FPGA technology still requires writing VHDL, and sometimes special features/macros of specific FPGAs. l Define and enable standard VHDL interfaces for external interactions, enabling peering with other component types. l Provide more portability and less dependency on choices of FPGA, fabric technology and peer processor types. © 2004 Mercury Computer Systems, Inc. 8

FPGAs & Software Components FPGA Component Model l Exposed interfaces for the VHDL designer w Local memory (scratch, LUT, or comm buffers) w Data ports for communicating with other components (FIFO style or randomly addressable comm buffers) w Runtime configuration parameters (scalars) w Execution control (start/stop/reset etc. ) w Local FPGA resources or I/O (generally not portable) Standardized Interfaces Data Input Port(s) Configuration Port Application Component Logic Local Memory Port(s) © 2004 Mercury Computer Systems, Inc. Control Port Local HW/IO Access 9 Data Output Port(s)

Infrastructure Elements How to “bring FPGAs into the first world”? l A common control model and mechanisms that can work across processor classes: w Load, initialize, configure, start, stop, connect, etc. w Top level server manages a collection of processors, assuming they can all run and connect components. © 2004 Mercury Computer Systems, Inc. 10

Infrastructure Elements How to “bring FPGAs into the first world”? l A control & deployment mechanism that works across processor classes: w Load, initialize, configure, start, stop, connect, etc. w Top level service manages a collection of processors, that can all run and connect components. w Each processor is self-managed or managed by proxy (FPGA). Deployment System/ Service Packaged Components © 2004 Mercury Computer Systems, Inc. Distributed System or Multicomputer Computer A Computer B Processor X Processor Y Processor Z Component 1 Component 2 Component 4 Component 3 11

Infrastructure Elements How to “bring FPGAs into the first world”? l A data movement and synchronization model that can be supported locally on all processor classes, including FPGAs, with no central control at runtime. w w w Streaming data flow Data reorg (striping/partitioning) Request/response messaging Interoperable between processor classes on a fabric Based on current standards, extended to cover a broader set of processor classes SIMD Input 1 SIMD Output 1 Component Set A (x 3) Component Set B (x 2) Output 1 Stream#1 Input 1 Component C Output 1 (x 1) Input 2 © 2004 Mercury Computer Systems, Inc. 12

FPGA Infrastructure Elements Outside-the-FPGA support software l l The FPGA driver and proxy code to treat FPGAs as “computers than can load and run code that talks to others. ” Implement the common component control and deployment model for FPGAs by proxy. w Loading FPGA programs • Partial loading still a challenge with today’s FPGA technologies w Configuration, control, and communication setup, via touching onchip infrastructure elements w Does not participate in data flow or synchronization Some GPP FPGA Proxy Control/Deployment © 2004 Mercury Computer Systems, Inc. FPGA Processor Other Processor FPGA Component Infrastructure Other Component Infrastructure FPGA Component Other Component 13 Data Stream

FPGA Infrastructure Elements On-chip infrastructure l Hardware abstraction (like an OS) w Memory technology w Fabric/Bus attachment technology, with DMA w I/O technology l Component abstraction (like middleware) w Configuration (runtime parameters) w Execution control w Communication with other components, local or remote w How FPGA components are written (in VHDL) I/O Timing/Control /Routing Application Component Abstraction Application Component Hardware Abstraction On-Chip and Adjacent Hardware © 2004 Mercury Computer Systems, Inc. 14 Interoperable/ Scalable Dataflow Control & Configuration Memory Buffer Management