Soft IP

Soft IP can be any form of IP for which physical implementation is decided upon by  the end-user. For example, IP delivered as RTL can be considered “soft” because  we are at complete liberty to compile, synthesize and lay-out the IP in any way that we choose. Therefore, in our earlier discussion of the various RTL delivery, with  our without encryption, we were in fact exploring soft IP.

However, any form of IP for which we do not receive layout or any other physical  information should be considered “soft.” For example, netlists or binary forms of  the IP, or IP that is pre-compiled into an intermediate library. Relatively low value  IP or IP for which performance and area targets are reasonably easy to achieve are  often be delivered as soft IP. 

A very common example soft IP is the DesignWare Building Block library from  Synopsys. DesignWare is an extensive library of infrastructure IP for design and  verification including arithmetic and datapath components, AMBA interconnect IP  and microcontrollers. The datasheet for an example DesignWare component is  shown in Figure 126 where we see an excerpt from the datasheet of a multiply accumulate function, or MAC.  

SoC designers will make use of such a soft IP block in one of three ways:  instantiation, inference or operator replacement. Instantiation is the simplest, with  the block’s module described and instantiated in the normal way. The descriptions  would be available from a library or directly in the RTL. An example instantiation  only is shown in the code excerpt in Figure 127.

Figure 127: Instantiation of DesignWare® MAC IP in Verilog HDL

module DW02_mac_inst( inst_A, inst_B, inst_C, inst_TC, MAC_inst );

parameter A_width = 8;

parameter B_width = 8;

input [A_width-1 : 0] inst_A;

input [B_width-1 : 0] inst_B;

input [A_width+B_width-1 : 0] inst_C;

input inst_TC;

output [A_width+B_width-1 : 0] MAC_inst;

/ Instance of DW02_mac

DW02_mac #(A_width, B_width)

 U1 ( .A(inst_A), .B(inst_B), .C(inst_C), .TC(inst_TC), 

.MAC(MAC_inst) );

endmodule

DesignWare IP may also be inferred as function calls. This relies upon the inclusion  of support references in the RTL (via and `include statement in Verilog or library  reference in VHDL). In the example shown in Figure 128, the tool must also be set  up so that a search path points to the files to be included. Here we see that one of  two different functions are included each inferring either a two’s complement or an unsigned version of the MAC. The synthesis combines these together into a  common MAC with configurable least-significant-bit. Different forms of the IP may  have been created, for example a power-optimized or a performance-optimized  version of a multiplier. The user or the tools would have the ability to choose the  most appropriate version in the context of the design at compile time.

Some tools may even infer soft macros synthetically during operator replacement or  during a sub-function of synthesis called module compilation. For example, a  multiplier soft IP macro would be inferred by the code simple code c<=a*b with  the result that the gate-level netlist would have an extra level of hierarchy  containing gates optimized for the target constraint. 

Considering the value of soft IP, it is not surprising that most SoC designs today  include such elements and so we need to be able handle them during FPGA-based  prototyping. Continuing with DesignWare as an example of soft IP, each of the  above three methods for including the IP in the SoC design will require different  solutions for their correct operation in FPGA.

Figure 128: Inference of DesignWare® MAC by function call

module DW02_mac_func (func_A, func_B, func_C, func_TC, MAC_func); 

parameter func_A_width = 8; 

parameter func_B_width = 8; 

/ Pass the widths to the multiplier-accumulator function 

parameter A_width = func_A_width; 

parameter B_width = func_B_width; 

`include "DW02_mac_function.inc" 

/* requires search path to point to file */

input [func_A_width-1 : 0] func_A; 

input [func_B_width-1 : 0] func_B; 

input [func_A_width+func_B_width-1 : 0] func_C; 

input func_TC; 

output [func_A_width+func_B_width-1 : 0] MAC_func; 

assign MAC_func = (func_TC) ? DWF_mac_tc(func_A, func_B, func_C) :

 DWF_mac_uns(func_A, func_B, func_C);

endmodule

Replacing instantiated soft IP

An IP instantiation may not be understood by the FPGA synthesis in the same way  as the SoC synthesis, if at all. In most cases, the IP instantiation would appear as a  black box, requiring contents at some point in the FPGA flow. If we are able to  advise the SoC designers during their initial choice of IP, then we should ask them  to ensure that only IP with an available and proven FPGA equivalent is chosen. In  this way the original SoC design could have `ifdef branching between two  instantiations, based on a single `define variable. 

Perhaps even more preferable would be a single instantiation which serves both SoC  and FPGA purposes, with the tools in the two different flows providing the  appropriate contents for the instantiation. In that case the SoC designers would not  be required to make any special provision in their RTL, except to choose only from  a supported library of soft IP for which FPGA equivalents are available. 

One way to provide this in the FPGA flow is for the prototyping team to write an  additional RTL file with the same functionality as the soft IP. To enable this more  easily, we would use wrappers in the original SoC design, as we did for memories  in chapter 7. We could ask the SoC team that each time they instantiate a soft IP  element that it is placed in a wrapper so that it can easily be replaced with the FPGA  equivalent. This is another example of good Design-for-Prototyping practice as  discussed in chapter 9.  

A more automated approach may require some investment in time and effort, but if  a particular soft IP library is to be used often, then it would be worth the investment.  For example, at Synplicity®, Bangalore, before the acquisition by Synopsys, each  DesignWare building block was analyzed and functionally equivalent RTL was  created for use in the Certify® tool. In that case, all properly instantiated  DesignWare elements would be automatically interpreted, not as a black box but as  a new bottom-level of the RTL hierarchy. This was not particularly optimized for  FPGA, but during FPGA synthesis was interpreted in the same way as any other  piece of RTL. 

More recently, Synopsys has modified its FPGA synthesis tools to allow native use  of the DesignWare blocks for FPGA designers. In addition the DesignWare IP  developers themselves have also performed some optimization for the blocks to  better operate in FPGA. Any instantiation or inference of a DesignWare building  block element in an SoC design will also be automatically interpreted correctly by  the FPGA synthesis tools.

Replacing inferred soft IP

The result for inferred soft IP is very similar to that for instantiated, however, now it  is not a matter of “filling” an empty black box but of the FPGA tools inferring the same functionality as the original SoC synthesis for a given piece of RTL. In both  cases, the library references and/or `include statements must be resolved to the  respective target’s implementation. In the example RTL in Figure 128, the SoC  synthesis tool (Design Compiler®) has its search path set up to include the path to  the functions for all the DesignWare used in the design. When this same RTL is  passed to the FPGA tool during the prototyping project, the equivalent path variable  needs to be set to point to a set of functions for the DesignWare used. Alternatively,  if the DesignWare elements are few in number and rarely used, then the required  extra function definitions could be placed in a local include file.

The function definitions included will not be identical to the design blocks used to  fill the instantiations mentioned in section 10.3.1, however, we refer to other  sources for how to use functions in Verilog HDL.

Referring back to our dw02_mac example in Figure 128, if we synthesize that in  FPGA synthesis then the resultant logic created is show in Figure 129 and it is  simple to see how this would be mapped into FPGA.

Replacing synthetic soft IP

In SoC synthesis, an RTL operator – whether built into the language, like +, -, and  *; or user-defined, like functions and procedures – can be linked to a synthetic  operator. A synthetic operator is an abstraction that makes it possible for the  synthesis tools to perform arithmetic and resource-sharing optimizations before  binding the operation to a particular synthetic module.

The linking mechanism will vary from tool to tool but in Design Compiler it is a  recognized HDL comment called a pragma. When the compiler sees the pragma, the  map_to_operator as a comment in the RTL, then the logic is used in place of the  operator. Operator inference occurs when the synthesis tool encounters an HDL  operator whose definition contains a map_to_operator pragma. The tool finds the  specified synthetic operator, inserts it into the user’s design, and performs highlevel optimizations on the resulting netlist. In fact, this is the mechanism used for  the functions in the example of inferring the dw02_mac in Figure 128.

Table 27, taken from the DesignWare Developers Guide, lists the HDL operators  that are mapped to synthetic operators in the Synopsys standard synthetic  library for Design Compiler (for more information in the references).

When soft IP is inferred by the SoC synthesis tools in the above way from generic RTL then its replacement for prototyping is an almost trivial task. The same RTL  which infers the soft IP in the SoC synthesis will be automatically interpreted by the  FPGA synthesis tool and mapped into relevant FPGA resources. For example, the  SoC synthesis might employ a synthetic operator bound to a dw02_mult block in  order to represent the * in a simple statement c<= a*b; . The exact same * will be  inferred as a multiplier by the FPGA synthesis and mapped to a dedicated FPGA  multiplier resource by default. 

Because of this automation and simplicity, SoC teams should try to employ  synthetic operators as often as possible rather than instantiate the soft IP directly  into the RTL.

Other FPGA replacements for SoC soft IP

Xilinx has a large variety of IP which are licensed for use only within their own  FPGAs. We can look at the functionality of the soft IP in the SoC design and find a  close, or maybe even exact, equivalent in the FPGA library. Of course its use would  be only temporary for the sake of prototyping but it may be that we can use a  wrapper in the same way that we do for RAM. The more complex the IP, the more  useful that this would be, but also the less likely that a match can be found between  the SoC IP and the FPGA IP. The one exception to this is in the area of standardsbased peripheral IP. Let’s look at that more closely now.