Peripheral IP

So far we have discussed handling of small elements or blocks of IP embedded in our RTL. For relatively low-level elements such as the DesignWare Building Blocks, the creation of an FPGA equivalent is a reasonable task but what of the subsystem level IP or whole CPU cores or peripheral functions, such as PCIe or USB? In some cases, we may need to spend a substantial effort replacing this kind of core IP with an FPGA equivalent or external component so before we do, we should be sure of our purpose.

There are a number of reasons high-speed IO needs to be prototyped and we summarize these in Table 28.

Table 28.png

Use mode 1: prototype the IP itself

The prototype project is mainly performed in order to verify the IP design itself. In that case, our task is actually a small-scale version of a normal SoC prototyping project. We would prefer as high a speed as possible up to the full expected speed of the IP in its final use in silicon. We would also prefer to make the prototype as accurate as possible and to interface with real-world peripherals. This is the use model for most of the prototyping performed within the Synopsys IP groups, for example in Figure 130 (as previously mentioned in chapter 2) from Synopsys IP design group in Porto, Portugal, we see the IP under test at the bottom of the FPGA block diagram while the rest of the FPGA is used to create a validation environment for the IP under test.

The channel from the HDMI Rx IC through the audio/visual processing out into an external PHY transmitter is what we want to prototype. However, we also need support elements for control and integration with the AV channel. This would be performed differently in each SoC implementation but for the purposes of running some software to test the HDMI channel, we pull together an infrastructure inside the FPGA using IP readily available from Xilinx and standard external memory components. The two halves are linked together using standard Synopsys IP for the ARM AMBA® interconnect.

Figure 130.png

In this chapter, we shall focus not so much on this use mode as, in many ways, prototyping a specific piece of IP is really a subset of the tasks involved in SoC prototyping in general. In fact, IP prototyping is probably easier than for a whole SoC because many IP designs will fit into a single FPGA and thus we avoid partitioning. Let us move on to the more general case, then, of including peripheral IP into a larger SoC prototype.

Use mode 2: prototype the IP as part of an SoC

The second use model, and the one most relevant to this chapter, is the use of an IP within a larger SoC. In that case, although we would indeed prefer to run at fullsilicon speed, we will probably find that our overall system speed is limited by the performance of the SoC RTL when mapped into the FPGA core. In that case our task becomes a matter of providing a method for scaling the overall system speed in order to more closely match the peripheral IP speed with the SoC core. This may involve data buffering or splitting an input stream into parallel processing channels.

Rate adapting between core and peripheral IO

What can we do when the peripheral data is arriving too fast for the FPGA to be able to handle? A common way to remedy clock differences between the FPGA system and an external interface is to add “rate adapter” circuits between the external stimuli and the SoC. These circuits are logically FIFOs that “absorb” (and drive) the external stimuli at the full external speed, although probably at its lowest acceptable rate to still meet the standard. The adaptor then only processes a subset of the stimuli that the FPGAs can process with its reduced clock rate, and it then drives the stimuli to the external interface at the reduced clock rate.

For example, if an FPGA-based prototype runs at one-third the speed of the SoC then, to properly emulate the SoC’s performance, the FPGAs should be driven by one-third the amount of stimuli.

Another alternative is to predict the maximum amount of data that will arrive in a burst at the full peripheral rate. We can then implement a shift-register first-in-first- out (FIFO) buffer to receive it at full rate and then pass forward to the FPGA prototype at the reduced rate after all data is received. The same approach is used in the other direction to step up the rate from the FPGAs to the external interface. Some designs will not tolerate this approach but for many others this rate-adapting is adopted with great success.

The FIFO can be implemented in external components, in another FPGA, as in the example in Figure 131 or in the receiving FPGA itself, depending in speed and size requirement. In the example, designed by Synopsys consultants in New England, we FPGA-Based Prototyping Methodology Manual 307 see two external USB2.0 channels being run at 125MHz, and asynchronous FIFOs being used in each case to buffer incoming and outgoing packets. Complete packets themselves are recognized by the “sniffer” circuit and signaled to the rest of the prototype as being ready to read in at one-tenth speed.

This kind of rate adaption works very well for regular packets of data and can handle reasonable rates as long as data is in bursts. It can also handle deep data if enough FIFO memory is available but, obviously, continuous data traffic would overflow the FIFO and packets would be lost or would need to be discarded until the rest of the prototype is ready to receive.

Figure 131.png

This area of prototype design requires some additional engineering beyond that already in the SoC, but many find that to be the most interesting part of a prototyping project. The best time to consider buffering between internal and external data streams is when the SoC is originally being designed. Having the prototyping team involved at this early stage will allow rate-scaling design to be completed in time and for software teams to pre-empt the necessary scaling changes in their code.

Use mode 3: prototype IP for software validation

The third common use case in Table 28 (on page 304) is when we want only to run applications software on a platform and our task is to provide data to the software and receive results as if we were running on the final system. From a software viewpoint we do not have to be cycle accurate as long as the channels run with “enough speed” to keep the channels in sync and provide approximately the required functionally. For example, as long as that the software thinks that it is Figure 131: Rate adapter concept for 10x USB reduction 308 Chapter 10: IP and high-speed interfaces receiving video data from an HDMI source, then the transceiver channel for that video data might be quite different from that instantiated in the SoC design itself. In fact, we could even completely replace the SoC IP with an FPGA version. We could also consider replacing the HDMI channel with a transactor that performs the same job, as we shall see in chapter 13.

TABLE OF CONTENTS

Use mode 1: prototype the IP itself

Use mode 2: prototype the IP as part of an SoC

Rate adapting between core and peripheral IO

Use mode 3: prototype IP for software validation