編輯

刪除

?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).

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:

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

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).

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.