Sizing of Processing Arrays for FPGA-Based Computation *

1
Field-Programmable Logic and its Applications INTERNATIONAL CONFERENCE Madrid, August 28-30, 2006 Tom VanCourt, Altera Corporation tvancour @ altera.com 110 Cooper St., Suite 201 Santa Cruz CA USA, 95060 Sizing of Processing Arrays for FPGA-Based Computation * N opt = argmax U(N) N | V(N) j : r j F S j (N, B) Martin Herbordt, Boston University herbordt @ bu.edu ECE Dept., 8 St. Mary’s St. Boston MA USA 02215 http://www.bu.edu/caadlab BOSTON UNIVERSITY * 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 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. 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 U(N) Utility function higher values indicate more desirable application accelerators. If U(N 1 ) = U(N 2 ) N 1 = N 2 then the two configurations are tied. V(N) Validity test Check the application family’s constraints between values of individual parameters n Width n Height is a validity test. B (b 1 , b 2 , … b K ) application-specific values for resource utilization in parts of the application accelerator. N opt Most desirable configuration, or configuration tied for most desirable N (n 1 , n 2 , …n I ) Set of structural parameters that define an accelerator configuration . R F (r 1 F , r 2 F , … r J F ) Resource quantities, the integer amounts of resource j available in FPGA F. S j (N, B) Synthesis estimation functions Consumption of FPGA resource j, given structural parameter values N and application-specific usage B. Adapt to size of PEs Different members of the application family have data types and PEs requiring different amounts of FPGA resources. Complex PEs and wide data in some apps should not limit numbers of PEs when computations and data are simpler. N Linear array. One architectural parameter Rectangular array. Parameters N 1 , N 2 Parameter value = number of PEs! N 1 N 2 N Nonlinear growth 2 N -1 PEs N Coupled structures. Related sizes N, N 2 , N 3 Logic RAM Multiple resources Mutually dependent allocation Expand to FPGA capacity Larger 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 S j (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. LAMP 1 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

description

Adapt to size of PEs Different members of the application family have data types and PEs requiring different amounts of FPGA resources. Complex PEs and wide data in some apps should not limit numbers of PEs when computations and data are simpler. Linear array. One architectural parameter. - PowerPoint PPT Presentation

Transcript of Sizing of Processing Arrays for FPGA-Based Computation *

Page 1: 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