INTELLECTUAL PROPERTY (IP)

Today’s FPGA designs are so big and complex that it would be impractical to  create every portion of the design from scratch. One solution is to reuse existing functional blocks for the boring stuff and spend the bulk of your time and  resources creating the new portions of the design that will differentiate your  design from any competing offerings.

Any existing functional blocks are typically referred to as intellectual   property (IP). The three main sources of such IP are:

1. internally created blocks reused from previous designs,  

2.  FPGA vendors, and  

3.  third-party IP providers.

For the purposes of these discussions, we shall concentrate on the latter two  categories.

Each FPGA vendor offers its own selection of hard, firm, and soft IP.  Hard IP comes in the form of preimplemented blocks such as microprocessor cores, gigabit interfaces, multipliers, adders, MAC functions, and the like.  These blocks are designed to be as efficient as possible in terms of power consumption, silicon real estate, and performance. Each FPGA family will feature  different combinations of such blocks, together with various quantities of programmable logic blocks.

At the other end of the spectrum, soft IP refers to a source-level library of  high-level functions that can be included to the users ’ designs. These functions  are typically represented using a hardware description language, or HDL, such as Verilog or VHDL at the register transfer level (RTL) of abstraction. Any  soft IP functions the design engineers decide to use are incorporated into the  main body of the design—which is also specified in RTL—and subsequently  synthesized down into a group of programmable logic blocks (possibly combined with some hard IP blocks like multipliers, etc.).

Holding somewhat of a middle ground is firm IP , which also comes in the  form of a library of high-level functions. Unlike their soft IP equivalents, however, these functions have already been optimally mapped, placed, and routed  into a group of programmable logic blocks (possibly combined with some hard  IP blocks like multipliers, etc.). One or more copies of each predefined firm IP  block can be instantiated (called up) into the design as required.

FAQs

How do you decide whether to use hard, fifi rm, or soft IP?

It can be hard to draw the line between those functions that are best implemented  as hard IP and those that should be implemented as soft or firm IP. In the case of  functions like the multipliers, adders, and MACs discussed earlier in this chapter,  these are generally useful for a wide range of applications. On the other hand,  some FPGAs contain dedicated blocks to handle specific interface protocols like  the PCI standard. It can, of course, make your life much easier if this happens to  be the interface you wish to use to connect your device to the rest of the board.  On the other hand, if you decide you need to use some other interface, a dedicated PCI block will serve only to waste space, block traffic, and burn power in  your chip.

Some IP that used to be “ soft ” is now becoming “ hard. ” For example, the  most current generation of FPGAs contains hard processor, clock manager,  Ethernet, and gigabit I/O blocks, among others. These help bring high-end  ASIC functionality into standard FPGAs. Over time, it is likely that additional  functions of this ilk will be incorporated into the FPGA device.

Insider Info

Generally speaking, once FPGA vendors add a function like this into their device,  they’ve essentially placed the component into a niche. Sometimes this must be  done to achieve the desired performance, but this is a classic problem because  the next generation of the device is often fast enough to perform this function in  its main (programmable) fabric.

Handcrafted IP

One scenario is that the IP provider has handcrafted an IP block starting  with an RTL description (the provider might also have used an IP block/core generator application, as discussed later in this chapter). In this case, there  are several ways in which the end user might purchase and use such a block  ( Figure 2-26 ):

1. Blocks of unencrypted source code . These blocks can then be integrated  into the RTL code for the body of the design ( Figure 2-26a ). (Note that the  IP provider would already have simulated, synthesized, and verified the IP  blocks before handing over the RTL source code.)

Insider Info  

Generally speaking, this is an expensive option because IP providers typically  don’t want anyone to see their RTL source code. Certainly, FPGA vendors are usually reluctant to provide unencrypted RTL because they don’t want anyone to  retarget it toward a competitor’s device offering. So if you really wish to go this  route, whoever is providing the IP will charge you an arm and a leg, and you’ll  end up signing all sorts of licensing and nondisclosure agreements (NDAs).

 2. Encrypted RTL level . Unfortunately, at the time of this writing, there is no  industry-standard encryption technique for RTL that has popular tool support.  This has led companies like Altera and Xilinx to develop their own encryption schemes and tools. RTL encrypted by a particular FPGA vendor’s tools  can only be processed by that vendor’s own synthesis tools (or sometimes by  a third-party synthesis tool that has been OEM’d by the FPGA vendor).

3. Unplaced-and-unrouted netlist level . Perhaps the most common scenario  is for FPGA designers to purchase IP at the unplaced-and-unrouted LUT/ CLB netlist level ( Figure 2-26b ). Such netlists are typically provided in  encrypted form, either as encrypted EDIF or using some FPGA vendor-specific format. In this case, the IP vendor may also provide a compiled cycle accurate C/C ++ model to be used for functional verification because such  a model will simulate much faster than the LUT/CLB netlist-level model.

—Technology Trade-offs—

● The main advantage of this scenario is that the IP provider has often gone  to a lot of effort tuning the synthesis engine and handcrafting certain portions of the function to achieve an optimal implementation in terms of  resource utilization and performance. ● One disadvantage is that the FPGA designer doesn’t have any ability to  remove unwanted functionality. 

● Another disadvantage is that the IP block is tied to a particular FPGA vendor and device family.

4. Placed-and-routed netlist level. In certain cases, the FPGA designer may  purchase IP at the placed-and-routed LUT/CLB netlist level ( Figure 2-26c ).  Once again, such netlists are typically provided in encrypted form, either  as encrypted EDIF or using some FPGA vendor-specific format. The reason for having placed-and-routed representations is to obtain the highest  levels of performance. In some cases the placements will be relative, which  means that the locations of all of the LUT, CLB, and other elements forming the block are fixed with respect to each other, but the block as a whole  may be positioned anywhere (suitable) within the FPGA. Alternatively, in  the case of IP blocks such as communications or bus protocol functions  with specific I/O pin requirements, the placements of the elements forming the block may be absolute, which means that they cannot be changed  in any way. Once again, the IP vendor may also provide a compiled cycle a ccurate C/C + model to be used for functional verification because such  a model will simulate much faster than the LUT/CLB netlist-level model.  

IP Core Generators

Another very common practice is for FPGA vendors (sometimes EDA vendors,  IP providers, and even small, independent design houses) to provide special tools that act as IP block/core generators. These generator applications are  almost invariably parameterized, thereby allowing you to specify the widths  and depths, or both of buses and functional elements.  

First, you get to select from a list of different blocks/cores, and then you  get to specify the parameters to be associated with each. Furthermore, in the  case of some blocks/cores, the generator application may allow you to select  from a list of functional elements that you wish to be included or excluded  from the final representation. In the case of a communications block, for example, it might be possible to include or exclude certain error-checking logic. Or  in the case of a CPU core, it might be possible to omit certain instructions  or addressing modes. This allows the generator application to create the most  efficient IP block/core in terms of its resource requirements and performance.

Depending on the origin of the generator application (or sometimes  the licensing option you’ve signed up for), its output may be in the form of  encrypted or unencrypted RTL source code, an unplaced-and-unrouted netlist,  or a placed-and-routed netlist. In some cases, the generator may also output a  cycle-accurate C/C ++ model for use in simulation ( Figure 2-27 ).

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. ”