Sizing of Processing Arrays for FPGA-Based Computation *

1. Adapt to size of PEs Different members ofthe applicationfamily have data types and PEs requiring different amounts of FPGA resources. Complex PEs and widedata in some apps should not limit numbers of PEswhen computations and data are simpler. Linear array. One architectural parameter Rectangular array. Parameters N1, N2Parameter value ≠ number of PEs! N N1 N2 Nonlinear growth 2N-1 PEs N Expand to FPGA capacity Larger FPGAs should give immediate performance boost to applications, with recompilation. Compilers should automate instantiationof PEs upto the limit set by the FPGA capacity. BOSTON UNIVERSITY Sizing of Processing Arrays for FPGA-Based Computation* Tom VanCourt, Altera Corporationtvancour @ altera.com110 Cooper St., Suite 201Santa Cruz CA USA, 95060 Martin Herbordt, Boston Universityherbordt @ bu.eduECE Dept., 8 St. Mary’s St.Boston MA USA 02215http://www.bu.edu/caadlab Obey growth laws Numbers of PEs are functions of architectural parameters. The shape of the computing array constrains the number of PEs allowed. For example, rectangular arrays grow in units of whole rows or columns • Computing ≠ System design • Computing with FPGAs puts different demands on design tools than traditional logic-design problems do. In order to get top performance, the implementation must be highly tuned to the application and FPGA family. But, in order to amortize development cost, the application must be reusable across a wide range of different applications. • Application families address reusability, by defining reusable control and communication structures in terms of application-specific data types and leaf calculations. • Parallelism: as much as possible • Because of relatively low clock rates, FPGA computation depends on parallel processing elements (PEs). Parallelism usually isn’t a fixed number, but the most that a given FPGA can support for a given application. • That number is a balance of three terms: • Resource usage per application-specific PE, • Resource availability in a given FPGA, and • PE array sizes allowed by the application family. Coupled structures.Related sizes N, N2, N3 N Logic RAM Multiple resources Mutually dependent allocation No current, widespread design tools perform this optimization at compile time. They require manual setting of the architectural parameters that define parallelism, and new settings with every change. Although intuitively clear and amenable to analysis, this maximization problem is hard to apply directly. The functions Sj(N, B) require information from the whole design hierarchy. They are difficult to express in closed form, and must track design change at all levels. Instead, the LAMP design tools automate estimation for primitive functions and data elements. LAMP1 also allows each design unit to define its own estimation function in terms of its own resource usage, usage of inner design blocks, and values of architectural parameters. All design information for that block is localized to that block. Local changes in any one block propagate to the uppermost, root design block, where architectural parameters are set, parameter validity is checked, and total resource usage is checked against amounts present in the specific FPGA being used. 1 T. VanCourt and M. Herbordt, LAMP: A Tool Suite for Families of FPGA-Based Computation Accelerators, Proc. FPL 2005 * This work was supported in part by the NIH through award RR020209-01, and facilitated by donations of software and equipment from Xilinx Corporation.