Breaking The Three Laws

# How many ASIC Gates does it take to fill an FPGA?

How many ASIC Gates does it take to fill an FPGA?

This question almost sounds like a joke doesn’t it. In reality this is a question I am asked to answer all the time and it’s not easy as ASIC designs don’t map the same to FPGA as they do to ASIC process technologies. In the ASIC design flow ASIC gates are represented as two input NAND gate equivalent and this is the base date point which should be used in the calculation as to how the design will map to FPGA.

For multiple generations of HAPS systems Synopsys has used the following  tried, true and field proven calculation as to ASIC gate equivalent capacity of the Xilinx FPGA families.

The basis of the calculation is that you can map the equivalent of six two input NAND gates per Look Up Table, LUT per Logic Cell, LC.

1* LUT = 6 Two input NAND Gate equivalent (go try it!)

With this knowledge its easy to calculate the total capacity of the FPGA in ASIC NAND Gate equivalent as you then multiply the LC count per FPGA by 6.

The Xilinx Virtex-5 series biggest capacity device was listed as 330K LC’s, so 330K times 6 = 1,980,000 two input ASIC NAND gate equivalents (~2 million)

So for the other Xilinx large devices used for Prototyping you get the following.

• Xilinx Virtex-6 = 760K LC’s = 4,560,000  two input ASIC NAND gate equivalents, (~4.5 million)
• Xilinx Virtex-7 = 2000K LC’s = 12,000,000 two input ASIC NAND gate equivalents, (~12 million)
• Xilinx UltraScale = 4400K LC’s = 26,400,000 two input ASIC NAND gate equivalents (~26.4 million)

Synopsys has shipped over 5000 HAPS units across 400 customers and with 1000’s of designs being validated using HAPS we are confident with this method to correctly set the expectations as to how many FPGA’s are needed to model the design under test. Of course you can only use this as a guideline as we all know ASIC RTL is typically FPGA hostile so you rarely get optimized mapping. Your ASIC RTL source code contains non-FPGA type resources, mux’s, adders, subtractors which don’t map nicely to FPGA resources and you have designs with intensive datapath and heavy interconnect stressing FPGA routing resources. The Synopsys defined estimation calculation has helped 100’s of customers quickly estimate the number of FPGA’s they need for their projects.

The only true way of more accurately estimating the number of FPGA’s your SoC prototype will need is by executing FPGA area estimation within a prototyping tool such as ProtoCompiler. Even running your design through the FPGA vendor tools will help you get an idea of the number of FPGA’s needed.

Simple right…… If only……. There is no standardization in the FPGA-based prototyping commercial market or across FPGA vendors so the poor prototyper is faced with multiple capacity claims for the same FPGA device!!!! A simple web search will quickly confirm this, other vendors ASIC gate equivalent capacity claims can be very different from the Synopsys calculation. This has led to some quite funny (now that I look back on it) conversations with customer. One such conversation is summarized by the quote

I have to buy two HAPS-70 systems to get the same capacity of the <other vendors> one board

I did actually laugh out loud… The hardware has the same FPGA’s !!!!!! Your SoC design does not magically shrink to fit into less FPGA’s. If your tool run estimations shows that you need four FPGA’s that’s what you need, forget the vendors claimed capacity per FPGA. Don’t be fooled by wild capacity claims, do your own area estimation based on your SoC prototyping project.

It should be noted that the software tool flow used to support your prototyping effort can make a difference in the FPGA utilization. For example ProtoCompiler has a Time to First Prototype, TTFP mode which is designed to get you onto hardware fast and as part of this can be configured to use more available FPGA capacity to reduce synthesis and P&R times. ProtoCompiler also has a performance and area optimization mode where the tool will use unique techniques to pack more logic into each FPGA. This TTFP mode is typically used at the start of a project, optimized mode when you deploy HAPS in volume to software developers.

Of course, prototypers, one way for you to neutralize the vendor capacity claims is just to compare the number of FPGAs, apples to apples.

One final point, the way Xilinx “counts” gates and markets seems to be a much more sophisticated calculation which I *think* includes much more than the raw LUT NAND gate equivalent. I reached out to my Xilinx contacts and asked them to clarify, I’ll post a blog on the results if they give me permission to. (Hey maybe I can twist their arms and get them to guest blog!!!) I think their calc includes memory, hardened IP blocks and other logic but I’m just speculating.

Do you count FPGA capacity in another way? If yes drop me a note or comment and share.

Click the links to the left and below to subscribe and get blog updates as soon as I post them