IP in many forms

Digital IP may take many forms and originate from many sources, internal and  external. The obvious examples would be a CPU core from third-party suppliers  such as ARM®, or peripheral IP from Synopsys. Smaller elements such as the  DesignWare® Building Blocks from Synopsys or generated by the Xilinx® CORE  Generator™ tool are also examples of IP and have very widespread use in SoC and  FPGA respectively. Even the reuse of another designer’s block can be considered IP  as long as it is packaged with all the documents, infrastructure and support  necessary to bring the IP through the whole SoC tool flow. However, that is where  we draw the line for the purposes of this discussion – just using somebody else’s  RTL in our design does not qualify as IP. 

IP is delivered in a number of forms, each of which presents us with a different  challenge. The main formats are listed in Table 25 and most methods of IP delivery  will fall into one of the listed categories.

Any mix of these types of IP may be found in any given SoC design. Sooner or later  we may need to address all of them in our prototyping projects. Let’s look closer at  each of these forms of IP in turn and explain how each can be handled in an FPGA based prototype.

IP as RTL source code

When we have the RTL source code for an IP block, our task would seem to be no  different than it would be for any other RTL in the SoC design. There are, however,  some differences in how much we can understand or alter the RTL within an IP  block. For example, it may be that the RTL is delivered under a license that governs  that it may not be altered without voiding any warranty or support agreements. In  that case, the IP vendor could be asked for a separate license or consulting contract  for support of prototyping.

Alternatively, the IP vendor may already have an FPGA-ready form of the IP but  that may require an extra license agreement, possibly at extra cost. When choosing  IP for the original SoC design, some thought might be given to the availability of  FPGA versions of the IP from the vendor. 

Licensing and support agreements aside, as long as the RTL is complete and well  documented, there is no fundamental reason why we might not successfully  prototype it along with the rest of our SoC design. Although the functionality of the  IP will be the same in the FPGA, as with other SoC-targeted RTL, we should lower  our expectations regarding performance. RTL that is developed and tailored for a  leading edge SoC process will run considerably slower in even the fastest FPGA  today.

What if the RTL is not available?

One of the issues with supplying IP as RTL to large numbers of people within a  company or to any third-party developers is IP pollution and even theft. IP pollution  is the accidental or even deliberate alteration of the IP for a design-specific purpose  without the knowledge of the IP vendor, leading to licensing and support issues. IP  theft needs no explanation and is a key issue for to all IP vendors and RTL supply is  something that is very carefully monitored and protected between supplier and  customer. 

As RTL is so valuable, many IP providers and users minimize their exposure by  using a secure method of delivery, limiting the spread of the RTL and the possibility  of “reverse engineering.” Methods used for this include supplying the IP in more  abstracted formats such as simulation models, encrypted netlists, encrypted FPGA  bitstreams and full-silicon test chips. The advantages and limitations of each are  listed in Table 26.

A model is really only a representation of the IP for the purposes of simulation.  Whether written in RTL or in a higher-level format such as SystemC, it is not  intended for synthesis or implementation in FPGA or any other physical form.  Models are nevertheless required, not only for simulation but also because they  recover some of the visibility otherwise lost by using an encrypted or test chip form  of the IP. For example, a test chip of some IP may be delivered with a transaction level model (TLM) for inclusion in a high-level testbench but we should not synthesize the TLM into silicon. A good measure of the maturity of an IP block  (and indeed a good measure of the IP vendor) is the amount of extra support, such  as models, provided with the IP. 

In the case of CPU IP, models may also be provided for instruction set simulators  which have very limited knowledge of the cycle accuracy of the IP but are very fast  and ideal for use in software development before RTL is available. As we shall  explore in chapter 13, models running on functional, virtual or instruction-set  simulators can be interfaced to real hardware using standards like SCE-MI to give a  solution partitioned between models and the real SoC RTL. 

Let us now consider how we can prototype with these forms of IP for which we do  not receive the raw RTL.

IP as encrypted source code

Beyond the relatively trivial example of including IP as RTL source code we find  the first degree of difficulty is in RTL which is delivered only in an encrypted form.  This means that we need the license to use the IP and the decryption mechanism to  Table 26: Advantages and limitations of IP delivery formats in place of RTL IP format Advantage Limitation Security Model Great for  simulation. Performance limited  by simulator. Cannot  be used for prototype “Secure” since  it is not the real  IP. Encrypted  FPGA  netlist Harder to reverse  engineer than raw  RTL. No visibility for  simulation Security only  as good as  encryption. Encrypted  FPGA  bitstream Faster than  simulation. Less flexible and may  involve compromise Very secure. Test chip Highest  performance.  Lowest flexibility.  Long development.  Very secure. FPGA-Based Prototyping Methodology Manual 293  access it. IP vendors will each have their own approach to encryption and  decryption, including common public domain methods such as PGP (“pretty good  privacy”) as well as proprietary methods. If the protection is only used for shipping  the source code then after decryption we will be in possession of the RTL, and, as  above, fully able to proceed with our prototyping work. 

However, some RTL is not only shipped encrypted but remains encrypted  throughout the tools flow, automatically decrypted “on-the-fly” at each step as  required. This is only possible if each tool has built-in understanding of the required  decryption and the necessary keys. Two common examples of such an approach are  the synenc encryption flow from Synopsys® and the encrypted ngc files generated  by Xilinx® tools.  

The overall aim is to get the source code for the IP of possible, or create some route  where the IP instantiation black box can be filled. This is an exercise that we will  not go into in any further here except to say that the industry will eventually move  towards an IEEE standard for IP encryption and encapsulation.

Encrypted FPGA netlists

Encrypted netlists can be supplied to companies for inclusion into their own FPGA  designs but offer a low level of security since they are inevitably decrypted in the  design flow. The resulting output from the design flow is encrypted again to ensure  the final image file can only be used in a deterministic way in the target FPGA  hardware.  

FPGA vendors offering encrypted IP (from third parties) for their products rely on  different techniques to limit the use in the target FPGA hardware, this can range  from IP that will only work for a limited time when programmed into an FPGA  and/or requires the use of the download/debug hardware and software used to  configure the FPGA. These are special netlist designs with additional logic to  perform checking and security. They still rely on a legal agreement to ensure the  final level of protection of the IP. 

Encrypted FPGA bitstreams Some 

FPGAs have built-in encryption keys which are used to decrypt an encrypted FPGA bitstream on the fly as it is read in by the FPGA and configured. The latest -6  devices and the largest Xilinx® Spartan®-6 devices all use AES 256-bit  encryption/decryption. The decryption key is stored in battery-backed key memory,  or it may also be stored in a less secure poly eFUSE key. The battery-backed key is  the most secure, as there are no known means to obtain the key from a device.  Powering the key memory off causes the key to be lost completely. The eFUSE key is less secure, as destructive tear-down of the device may be used to read the value  of the eFUSE bits. However, even then the eFUSE bits are not easy to read since  there are three times as many bits used than are strictly required for the security key,  further confusing the would-be key-copier.  

This encryption methodology was originally intended to stop design cloning of  FPGA-based products, but it is also a useful way to secure IP blocks supplied in  FPGAs. Since all the decryption is performed within the FPGA and only the  encrypted FPGA image is visible outside then the security of this is very good and  an excellent method for vendors to deliver high value IP. 

Figure 123 (courtesy of ARM) shows how the FPGA image would replicate the  integration (top) level of an IP block design. This would effectively be the same interfaces that would be exposed when using a hardened macro from the silicon  provider or when we have hardened an IP block to our requirements. Due to the  high number of signals that are normally associated with this level of the design,  there may be a requirement to multiplex these signals to and from the FPGA. This  then requires the opposite logic to reconstruct the signals to join them to the rest of  the design. The vendor supplying the FPGA image should also provide the  application notes and support to enable us to do that.

A useful feature of IP delivered in this form is that the clocks in the FPGA do not make use of the internal MMCM and such elements. This allows the system to be  clocked at speeds below that minimum limit that would have been imposed had they  been present. Indeed, this approach may even support clock stopping and single  stepping in the IP block. 

As users then, we would need to provide the clocks for the different domains in the  FPGA’s internal logic and the pin multiplexing and so forth for our prototyping  system in order to ensure proper clock alignment.  

This approach is used by ARM in its software macro models, or SMMs, which are  encrypted FPGA images. ARM feels that the omission of clock infrastructure gives  the SMM a greater operational flexibility, which supports a more end-user  applications without the need for altering, or even viewing, the RTL.

Test chips

Probably the most secure method of delivery for the IP vendor is for the design to  be pre-implemented in silicon, as it is very hard to reverse engineer. However, it is  also the most costly to create, maintain and support, especially if the vendor has to  build a new test chip for each revision of its IP. Test chips are usually available for  higher value IP blocks with wide usage, for example, most ARM CPU cores have  test chips. It is less likely that a test chip would be available for either a new block  (e.g., supporting a very new communications standard) or for a specialized IP block  which is customized by the vendor for each user. 

Test chips may require associated components to support their operation (e.g.,  memory controllers) but the combination of external test chip and support will allow  the FPGA-based prototype as a whole to run at the highest speed possible. However, to achieve these higher speeds we often need to compromise on features 

The biggest limitation of the test chip is its lack of flexibility, owing to pre-defined  interfaces and configuration options. This may impose restrictions on usage, for  example memory maps or interrupt structures which may not match the expected  use of the IP in the final SoC. Compromises to IP in order to allow its use in test  chips include selective adherence to cycle accuracy, use of asynchronous bridges  between the test chip and the FPGA, multiplexing of signals to accommodate the  high pin count buses and even limiting the features of the implementation to meet  the prototyper’s needs or silicon limitations (e.g., disabled test modes, less  interrupts, merging buses on chip to bring a single bus to the pins, etc.). 

Software or system settings would need to be altered to match the test chip’s  capability, rather than the other way around and it may be that a more flexible RTL  or FPGA-based delivery is required. This might mean that we need to obtain extra  licenses from the IP vendor compared to a test-chip and model approach, but it may be worth the investment if it means that the FPGA-based prototype is going to be  more useful with it. 

Figure 124 (courtesy of ARM) gives an example test chip implemented for the same  ARM processor example shown earlier in Figure 123. Here we can see the use of  the SMC (static memory controller) and DMC (dynamic memory controller) to  access to boot memory and peripherals, together with the DMC for run the time  memory.

Test chips are able to support benchmarking and OS development in the early stages  of a design ensuring that we can make an early start on the software. However  having all these features does limit the flexibility of the test chip in the hardware  prototyping system (due to memory map, interrupt and fixed configurations). The  test chip of the kind illustrated is generally best placed to support OS development,  benchmarking activities and development of extension IP blocks which will be  connected via the AXI™ bus (in the case of the ARM).

Extra FPGA pins needed to link to test chips

As we saw in chapter 5, we recommend avoiding permanently linking FPGA pins to  peripheral or other external components on the board. Instead we should keep such  connections flexible in order to increase the chances for their reuse in future  prototyping projects. In the case of IP test chips, we may need to connect our  FPGA(s) to a great number of external pins on the test chip or a board/module upon  which the test chip is mounted. We should try to make such connections via  deferred or switched interconnect (see chapter 6) and this may involve adaptors or  vendor-specific connectors.

An example of an ARM test chip mounted on a CoreTile and its associated adaptor  with which it would communicate with a Synopsys HAPS® FPGA board is shown in Figure 125.

The use of wide buses in SoCs normally means that the connections between FPGA  and test chip need to be multiplexed in order to reduce the number of FPGA pins  required or to simply fit within the number of pins of the connector. This however,  will also introduce extra delay of the interconnect IO pads and boards, probably  reducing the overall system speed. More discussion of multiplexing and its impact  on timing can be found in chapter 8. This can be mitigated to some degree by using  high-speed serial signaling techniques and higher speed multiplexing rates (see  HSTDM discussion in chapter 8). 

Having discussed the different formats in which IP can be delivered, we shall  explore the handling of soft IP and hard IP in more detail and also explain how  these can be included in our FPGA-based prototype.