How to interface FPGAs to microcontrollers

编辑

删除

?pageNumber=0

Rocendo Bracamontes Del Toro, Atmel 7/30/2008 2:12 PM EDT

As many as half of all embedded designs have an FPGA next to a microcontroller. The FPGA can be used to implement anything from glue logic, to custom IP, to accelerators for computationally intensive algorithms. By taking on some of the processing tasks, FPGAs help to improve system performance, thereby freeing up the MCU from cycle-intensive tasks. FPGAs also provide excellent performance characteristics and lots of flexibility to accommodate changing standards.

There are two basic implementations of MCU-plus-FPGA designs: putting a soft MCU core into the FPGA logic structure or using a standard product MCU with a discrete FPGA. Putting a soft core into the FPGA can be effective, but it can also be an expensive and power-hungry way to implement a microcontroller when compared to a standard product. This is especially true when using a 32-bit ARM-based core. As a result, only about one-third of FPGA-plus-MCU designs are implemented with an MCU core inside the FPGA logic. The remaining two-thirds consist of a standard product microcontroller next to a discrete FPGA.

Neither standard product microcontrollers nor FPGAs were developed to communicate with each other efficiently. They even use different languages. Thus, interfacing the two can be a challenge. FPGAs do not have any dedicated logic that communicates with microcontrollers. This logic module must be designed from scratch. Second, the communication between the microcontroller and FPGA is asynchronous. Special care is needed to resynchronize the MCU to the FPGA clock domain. Finally, there is an issue of bottlenecks, both at the interface and on the MCU bus. Transferring information between the MCU and the FPGA usually requires cycles on the MCU bus and usually ties up the resource (PIO or EBI) used to effect the transfer. Care must be taken to avoid bottlenecks with external SRAM or Flash and on the MCU bus.

There are basically three hardware options for interfacing the FPGA to the MCU: programmable I/O (PIO); external bus interface (EBI), if available; and, finally, a dedicated interface between built into the MCU between the advanced high-speed bus (AHB) and the FPGA. Which approach to use depends on the end application and the desired result.

PIO Interface
Interfacing the MCU to the FPGA via the PIO is relatively simple for simple data transfers, consisting of the transfer of 32 bits of address, 32 bits of data, and some control signals for control. This requires a 32-bit PIO and an additional 2-bits on another PIO (Fig 1).

1. PIO interface to FPGA.
(Click this image to view a larger, more detailed version)

For a transfer of data to the FPGA, the direction of the bidirectional buffers in the PIO must be set to output. The software algorithm that transfers data to the FPGA is as follows:

PIO_DATA = ADDRESS; // Pass the address to write
PIO_CTROL = START | WR; // Send start of address cycle
PIO_CTROL = CLEAR; // Clear PIO ctrl, this ends the address cycle
PIO_DATA = DATA; // Set data to transfer
PIO_CTROL = START; // Data is ready in PIO
PIO_CTROL = CLEAR; // This ends the data cycle

Reading from the FPGA is similar. Again, the direction of the buffer on the PIO must first be set to output and then change directions to input to read the data from the FPGA, the following code is executed:

PIO_DATA = ADDRESS; // Set the address to read
PIO_CTROL = START | RD; // Send start of address cycle
PIO_CTROL = CLEAR; // Clear PIO ctrl, this ends the address cycle
PIO_DATA_DIR = INPUT; // Set PIO-Data direction as input to receive the data
DELAY(WAIT_FOR_FPGA); // wait for the FPGA to send the data
DATA_FROM_FPGA = *PIO_DATA; // Read data from FPGA

The above algorithms are for a basic transfer, a more sophisticated algorithm is necessary to establish a proper communication between the ARM microcontroller and the FPGA. Special care is necessary to ensure the acknowledgment of data, e.g. no data has been lost due to speed or wait cycles on each side.

The access time is calculated as the sum of:

TAccess-PIO = t1 + address phase + t2 + data phase

Using the GCC compiler with maximum optimizations, the system takes approximately 55 AHB cycles to perform the write operation to the FPGA (Fig 2).

2. PIO write to FPGA.
(Click this image to view a larger, more detailed version)

Assuming t2 (wait for FPGA response ready) is also around 25 AHB cycles, the system takes approximately 85 AHB cycles for a read operation from FPGA (Fig 3).

3. PIO read from FPGA.
(Click this image to view a larger, more detailed version)

The interface from the MCU itself is fairly simple and straight forward. However, special logic must be implemented in the FPGA to decode all the traffic generated by the PIO. In the majority of cases, the traffic from the microcontroller is completely asynchronous. As a result, the FPGA must be able to oversample the control signals from the microcontroller; otherwise the FPGA will miss the time window and the traffic will not arrive at the final destination inside the FPGA.

A vendor-supplied template can be used to instantiate the AHB masters and slaves to the FPGA interface. Specific examples are provided. In the FPGA template, a module called "Custom MP" requires the least amount of effort to integrate AHB/APB peripherals. The usage of this template gives the designer the option of migrating the two-chip MCU-plus-FPGA implementation to a single-chip customizable microcontroller with virtually no extra engineering effort since the logic in the FPGA will have been proven in the system.

The external ZBT-RAM and NVM/SDRAM/SRAM are optional, based on applications and system requirements.

Designers also may add non-AHB logic to the FPGA, providing the flexibility to add other functions unrelated to the AHB bus.

As mentioned before, the transfer speed depends from the ratio between all clocks related to the communication between the microcontroller and the FPGA and whether it is in single or dual serial mode.

In single configuration mode, it takes four AHB-Clock cycles to transfer all the AHB information for a single-AHB interface from the microcontroller to the FPGA and vice versa (Fig 11). In dual configuration mode, it takes eight AHB-Clock cycles to transfer all the AHB information for a dual AHB interface from the microcontroller to the FPGA and vice versa.

11. Timing for read/write transfers with direct FPGA interface.
(Click this image to view a larger, more detailed version)

The timing related to a transfer happening between the ARM7 MCU and the FPGA is as follows:

t1: Time for a standard 2 cycles AHB

t2: Time to transfer the request to FPGA (4 cycles single AHB interface, 8 cycles dual AHB interface)

t3: Time for FPGA-Peripheral response

t4: Time to transfer response back to CAP7E (4 cycles single AHB interface, 8 cycles dual AHB interface)

t5: Time to read back the response/data from FPGA to the internal CAP7E AHB bus

t6: Time for introduced wait cycles

The following formula is used to approximate the access time, from the ARM to the peripherals in the FPGA:

Taccess = t1+ t2 + t3 + t4 + t5

Note: t1 and t5 are AHB cycles that could be ignored for comparison to PIO and EBI timings.

Conclusion
In situations where the data rate is low, such as a dot matrix LCD, an interface the MCU to the FPGA through the PIO or the EBI is sufficient. However, a high data rate between the FPGA and the MCU, or between some other peripheral and the memories, could monopolize CPU cycles and create bottlenecks on the peripherals. For example, a TFT LCD graphics color will require substantial amount of data to be transferred from the frame buffer to the LCD that would most likely completely overwhelm both the CPU and the EBI. This kind of application will perform better with direct interface from the MCU to the FPGA, while allows the LCD data to be transferred over the DMA, keeping the processor free for processing and the EBI free for other data transfers, such as the main application software running from flash, or in the case of the TFT LCD the usage of SDRAM for single or multiple frame buffers.

In addition, the logic defined in the FPGA on the AHB appears to the MCU as if it "inside" the MCU. This makes migration to a customizable microcontroller an easy future design path.

Development time is also shorter with a direct FPGA interface because the interface is already defined inside the microcontroller and the logic module for the FPGA is provided by the MCU vendor. The designer does not need to write any interface RTL. A microcontroller with a dedicated FPGA interface is likely to improve overall system performance and ease of design.

Rocendo Bracamontes del Toro received his bachelor's degree in electrical engineering from Tecnologico Cd. Guzman, Jalisco Mexico in 1997 and his master's degree in computer and electrical engineering from John Hopkins University, Baltimore, Maryland in 2003.

Rocendo can be contacted at [e-mail].