Sizing of Processing Arrays for FPGA-Based Computation *
-
Upload
wilma-allen -
Category
Documents
-
view
17 -
download
0
description
Transcript of Sizing of Processing Arrays for FPGA-Based Computation *
Field-Programmable Logic and its Applications
INTERNATIONAL CONFERENCE Madrid, August 28-30, 2006
Tom VanCourt, Altera Corporationtvancour @ altera.com
110 Cooper St., Suite 201Santa Cruz CA USA, 95060
Sizing of Processing Arrays for FPGA-Based Computation*
Nopt =argmax U(N)
N | V(N) j : rjF ≥ Sj(N, B)
Martin Herbordt, Boston Universityherbordt @ bu.edu
ECE Dept., 8 St. Mary’s St.Boston MA USA 02215
http://www.bu.edu/caadlab
BOSTONUNIVERSITY
* This work was supported in part by the NIH through award RR020209-01, and facilitated by donations of software and equipment from Xilinx Corporation.
Computing ≠ System designComputing 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.
Obey growth lawsNumbers 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
U(N)
Utility function
higher values indicate more desirable application accelerators.
If U(N1) = U(N2) N1 ≠ N2
then the two configurations are tied.
V(N)
Validity test
Check the application family’s constraints between values of individual parameters
nWidth ≥ nHeight is a validity test.
B
(b1, b2, … bK)
application-specific values for resource utilization in
parts of the application accelerator.
NoptMost desirable configuration,
or configuration tied for most desirable
N(n1, n2, …nI)
Set of structural parameters that define an accelerator configuration .
RF
(r1F, r2
F, … rJF)
Resource quantities, the integer amounts of resource j available in FPGA F.
Sj(N, B)Synthesis estimation functions
Consumption of FPGA resource j, given structural parameter values N and
application-specific usage B.
Adapt to size of PEsDifferent members of the 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. N
Linear array.
One architectural parameter
Rectangular array.Parameters N1, N2
Parameter value ≠ number of PEs!N1
N2
N
Nonlinear growth
2N-1 PEs N
Coupled structures.
Related sizesN, N2, N3
Logic RAM
Multiple resources
Mutually dependentallocation
Expand to FPGA capacityLarger FPGAs should give immediate performance boost to applications, with recompilation. Compilers should automate instantiation of PEs up to the limit set by the FPGA capacity.
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