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.

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:

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 rocendo.bracamontes@atmel.com.