Loading in 2 Seconds...
Loading in 2 Seconds...
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.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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.
One architectural parameter
Parameters N1, N2Parameter value ≠ number of PEs!
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.
UNIVERSITYSizing 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
Coupled structures.Related sizes
N, N2, N3
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.