SoC FPGA Evaluation Guidelines
FPGA is a constantly evolving technology, especially in terms of logic density and speed. Among the newest improvements in the FPGA world are System on a Chip (SoC) FPGA devices. A SoC FPGA integrates a hard processor core and programmable logic on the same die. The three largest FPGA vendors, Xilinx, Altera and Microsemi (Previously Actel), have all started to manufacture such devices. Although having in common that they all put a hard 32-bit ARM processor together with programmable logic, there are also considerable differences between the designs that will be discussed in this article.
The number of commercially available SoC FPGA devices is continuously increasing, giving a large variety of configurations to choose between. If you encounter a project where a processor and an FPGA is needed or preferred, you should know what a SoC FPGA is and understand when such a solution could be useful. The purpose of this article is to highlight the most important questions to resolve when evaluating and selecting SoC FPGA solutions.
A SoC FPGA could be useful for replacing the following traditional configurations:
• A stand-alone processor and stand- alone FPGA
• An ASIC including a processor
• A stand-alone processor
Compared to using a stand-alone processor and a stand-alone FPGA, a solution using a SoC FPGA is cheaper, uses less power consumption, and is easier to put into a design. Two circuits are replaced by one, which means less time for designing and less space on the PCB.
If external RAM is used for both the processor and the FPGA, these memory circuits can be consolidated into one RAM chip, saving space, cost and reducing complexity. Communication between processor and FPGA can also go much faster with both units on the same chip.
Compared to manufacturing an ASIC, a SoC FPGA is first of all much cheaper and requires much less design time. You will also have a much more flexible design process, as the firmware may be rewritten at any time.
Compared to using a stand-alone processor, a SoC FPGA will be more flexible, since hardware structures can be added throughout the whole design process when needed. It also gives the possibility of parallelising the data processing by allocating computing intensive operations to dedicated FPGA firmware. In the rest of this article, we will go through the most important issues that must be resolved when picking an appropriate SoC FPGA solution for a given application. We will look further into performance, reliability, flexibility, cost, power and software tools.
What ultimately constrains your system performance is the communication between processor, memory, FPGA logic, and interconnects. Normally, when selecting the SoC FPGA to use, the processor speed and the FPGA logic are carefully evaluated and checked, but the same is sometimes not done properly for memory and interconnects.
In terms of memory, there are different specifications that determine the memory performance – the supported memory frequency is not necessarily what gives the highest performance. One of the first things to check is:
• Does the SoC FPGA have an independent, hard memory controller for both the processor and the FPGA logic?
• Is the memory controller able to extract data in sufficiently high speed, manage priority, reorder command and data, and schedule pending transactions?
A slow memory controller with smart data handling could perform better than a high frequency memory controller with simplistic data handling. It is important to make sure that the memory controller can provide the required throughput of mass data transfer and have the minimum latency to meet real-time requirements.
When it comes to connections between major building blocks inside of the SoC FPGA, like hard CPU and data processing FPGA blocks, it is important to check the interconnection speed, and make sure it supports the required data throughput between FPGA logic and processor. In addition, to prevent blocking the high-speed transfer between the FPGA and the processor, a low latency path should also exist to do simple setup and configure access to the hardware accelerators in the FPGA logic.
In terms of reliability, there are especially two things that have to be carefully checked, and that is memory protection and software bug handling. With increasing CPU and Memory speed and decreasing semiconductor-manufacturing technology, there is an increasing probability to have memory errors. It is therefore important to protect your memory, for example with Error Correction Codes (ECC).
If both the processor and the FPGA share the same memory, you must be sure that the memory is protected from overwriting data. If there is no protection, one can spend weeks on debugging software bugs which may be caused by the FPGA overwriting memory used by the CPU. A memory protection unit can fix this.
One thing that is certain is that you are going to encounter bugs during your software development, and it is important to handle these in an appropriate way. Implementing a watchdog timer to reset the CPU in case of a system hangup is a classical approach. A good architecture lets you choose if you want to reset both the CPU and reconfigure the FPGA or only reset the CPU.
Flexibility and cost evaluation
We have already discussed the reduced cost of a SoC FPGA compared to a standalone FPGA and a processor devices. Component cost, design cost and PCB space can be saved simultaneously. Selecting a sufficiently flexible SoC FPGA can also contribute to a significant cost reduction for your application. An important issue to look into is the question of which hard IP blocks are integrated into the device. Things to look into here could be PLL circuitry, appropriate memory controllers and communication modules (for example SPI, UART, I2C, USB, and CAN).
Although most required units can be generated by soft IP, it is more efficient in terms of performance, cost and logic utilisation when hard IP blocks can be instantiated directly.
Boot setup is another topic to explore: Does the SoC FPGA`s processor have the option to boot independently of the FPGA configuration, and then configure the FPGA from the CPU? And vice versa, is the FPGA able to boot first, and then boot the CPU through FPGA logic? Even though both the processor and the FPGA is in the same device, it is important that they can operate like two separated chips.
With increasing clock speeds and higher performances, power consumption has become one of the biggest challenges, if not the top design criteria, for many new designs. By replacing a stand-alone CPU and FPGA solution with a SoC FPGA, one can reduce the power down to 50% of the power consumed by the original twochip system.
The SoC FPGA can also save a considerable amount of power if it is able to put the FPGA in a low-power standby mode while keeping the CPU alive and running. We have already mentioned that a memory controller supporting high frequency RAM is not necessarily better than a memory controller that runs at lower frequencies. It all depends on the way the memory is handled. A slow DRAM controller does also have the advantage of lower power consumption.
Evaluating the software tools
When looking at Software tools, one of the most important things to explore is debugging capabilities. In a development project, one can assume that 60-70 % of the project time is spent on debugging. Compared to CPU debugging on a fixed hardware platform, one has to be aware that the SoC FPGA firmware may be changed at any time throughout the design process. It is therefore important that the software-debugging tool is able to adapt to changes in the FPGA logic.
Another issue is cross-triggering. When a breakpoint is set in software, you would want the FPGA to freeze at the same time. Like that, you may perform a proper inspection. Similarly, when setting a logic analyser trigger in the FPGA, you would like to freeze and inspect the CPU software. You would also like to have a debugging tool that not only helps you find the mistakes in the code, but also tells you something about the performance of your code. For example, you would like to know if it can be optimised, and if there are functions/code that are not being used or are no longer running.
For ARM processors with two or more cores, it is desirable to have multicore debugging. Multicore debugging makes you able to control and monitor both cores simultaneously. For example, you may put a breakpoint on one of the cores while the other is still running, or have the possibility to stop both cores at a given breakpoint.
When carefully selected, SoC FPGA circuits can perform better than their traditional counterparts can. They have therefore become a highly relevant competitive alternative.
Throughout this article we have highlighted important features to evaluate when selecting an appropriate SoC FPGA for a given application. We have looked into aspects like performance, reliability, flexibility, cost and software tools, and we have explored important issues to resolve before arriving at a particular circuit solution. These are all general guidelines and you will probably have to do some exploration work yourself to arrive at a SoC FPGA solution which is suited for your particular application.