complexity of arithmetic

Nov 16, 2005 3 Replies

i everyone,



i'm teaching a vlsi design class, and we're covering datapath this week.



we use weste and harris' new edition of "cmos vlsi design". it's a great book; however, it doesn't discuss actual delays/area costs for adders, multipliers, dividers, etc., and the other sources i've looked at tend to be focused on asymptotics (O(log N) type analyses).



does anyone know off the top of their heads what the actual delay/area numbers are like on a modern FGPA for the following:



- addition, multiplication, division


- 16/32/64 bit


- number of pipeline stages for these implementations.



i'd also be interested in knowing correspondnig values for floating point arithmetic,



suggestions for survey articles would be welcome



thanks in advance,



adnan



Don't forget to include distributed arithmetic as a space time tradeoff, which for certain applications is a substantial win after dealing with the data flow archtecture and pipelining for it.

Area in a "modern FPGA" for arithmetic varies widely, due to the recent addition of dedicated blocks for multiply/accumulate functions. If you're only interested in functions using the FPGA fabric, your best bet is to use COREgen (or some other vendor's equivalent IP generator) to make the functions you want. The Xilinx version allows you to see the resulting coverage if you check the "Display Core Footprint" box in the dialog for the core. Most cores allow you to check off whether to use dedicated hardware if the FPGA family has it, the alternative being to generate the function using only the fabric (LUTs and flip-flops).

The nice thing about the core generator is that you don't actually need to build the project to see the resource requirements. If you don't have ISE with COREgen, you can get some representative usage values from the IP function datasheets, mostly available at the Xilinx IP center.

That might have to be a different class. It seems to me that custom cmos design and fpga design have very little in common in terms of primitive elements.

-- Mike Treseler

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required