SYSTEM GATES VERSUS REAL GATES

One common metric used to measure the size of a device in the ASIC world  is that of equivalent gates. The idea is that different vendors provide different  functions in their cell libraries, where each implementation of each function  requires a different number of transistors. This makes it difficult to compare  the relative capacity and complexity of two devices.

The answer is to assign each function an equivalent gate value along the  lines of “ Function A equates to five equivalent gates; function B equates to three equivalent gates … ” The next step is to count all of the instances of each  function, convert them into their equivalent gate values, sum all of these values  together, and proudly proclaim, “ My ASIC contains 10 million equivalent  gates, which makes it much bigger than your ASIC! ”

Unfortunately, nothing is simple because the definition of what actually constitutes an equivalent gate can vary depending on whom one is talking to. One common convention is for a 2-input NAND function to represent  one equivalent gate. Alternatively, some vendors define an equivalent gate as  equaling an arbitrary number of transistors. And a more esoteric convention  defines an ECL equivalent gate as being “ one-eleventh the minimum logic  required to implement a single-bit full adder ” (who on earth came up with  this one?). 

As usual, the best policy here is to make sure that everyone is talking about  the same thing before releasing your grip on your hard-earned money.

And so we come to FPGAs. One of the problems FPGA vendors run into  occurs when they are trying to establish a basis for comparison between their  devices and ASICs. For example, if someone has an existing ASIC design that  contains 500,000 equivalent gates and he wishes to migrate this design into  an FPGA implementation, how can he tell if his design will fit into a particular FPGA? The fact that each 4-input LUT can be used to represent anywhere  between one and more than twenty 2-input primitive logic gates makes such a  comparison rather tricky.

In order to address this issue, FPGA vendors started talking about system  gates in the early 1990s. Some folks say that this was a noble attempt to use  terminology that ASIC designers could relate to, while others say that it was  purely a marketing ploy that didn’t do anyone any favors. Sad to relate, there  appears to be no clear definition as to exactly what a system gate is. The situation was difficult enough when FPGAs essentially contained only generic programmable logic in the form of LUTs and registers. Even then, it was hard  to state whether a particular ASIC design containing x equivalent gates could  fit into an FPGA containing y system gates. This is because some ASIC  designs may be predominantly combinatorial, while others may make excessively heavy use of registers. Both cases may result in a suboptimal mapping  onto the FPGA.

In order to address this issue, FPGA vendors started talking about system  gates in the early 1990s. Some folks say that this was a noble attempt to use  terminology that ASIC designers could relate to, while others say that it was  purely a marketing ploy that didn’t do anyone any favors. Sad to relate, there  appears to be no clear definition as to exactly what a system gate is. The situation was difficult enough when FPGAs essentially contained only generic programmable logic in the form of LUTs and registers. Even then, it was hard  to state whether a particular ASIC design containing x equivalent gates could  fit into an FPGA containing y system gates. This is because some ASIC  designs may be predominantly combinatorial, while others may make excessively heavy use of registers. Both cases may result in a suboptimal mapping  onto the FPGA.

The problem became worse when FPGAs started containing embedded  blocks of RAM, because some functions can be implemented much more efficiently in RAM than in general-purpose logic. And the fact that LUTs can act  as distributed RAM only serves to muddy the waters; for example, one vendor’s system gate count values now include the qualifier, “ Assumes 20 percent to 30 percent of LUTs are used as RAM. ” And, of course, the problems  are exacerbated when we come to consider FPGAs containing embedded processor cores and similar functions, to the extent that some vendors now say,   “ System gate values are not meaningful for these devices. ”  

Insider Info

Is there a rule of thumb that allows you to convert system gates to equivalent gates  and vice versa? Sure, there are lots of them! Some folks say that if you are feeling  optimistic, then you should divide the system gate value by three (in which case  3 million FPGA system gates would equate to 1 million ASIC equivalent gates,  for example). Or if you’re feeling a tad more on the pessimistic side, you could  divide the system gates by five (in which case 3 million system gates would equate  to 600,000 equivalent gates). However, other folks would say that the above is  only true if you assume that the system gate’s value encompasses all of the functions that you can implement using both the general-purpose programmable logic  and the block RAMs. These folks would go on to say that if you remove the block  RAMs from the equation, then you should divide the system gates value by ten  (in which case, 3 million system gates would equate to only 300,000 equivalent  gates), but in this case you still have the block RAMs to play with… arrggghhhh! Ultimately, this topic spirals down into such a quagmire that even the FPGA  vendors are trying desperately not to talk about system gates any more. When  FPGAs were new on the scene, people were comfortable with the thought of  equivalent gates and not so at ease considering designs in terms of LUTs, slices,  and the like; however, the vast number of FPGA designs that have been undertaken over the years means that engineers are now much happier thinking in  FPGA terms. For this reason, speaking as someone living in the trenches, I would  prefer to see FPGAs specified and compared using only simple counts of:
Number of logic cells or logic elements or whatever (which equates to the number  of 4-input LUTs and associated flip-flops/latches) Number (and size) of embedded RAM blocks  
Number (and size) of embedded multipliers  
Number (and size) of embedded adders  
Number (and size) of embedded MACs  etc.