Interfacing ARM mcu with Altera FPGA

Hi,

I am busy with the design of a board with an ARM mcu (STM32F407) and an ALTERA FPGA (cyclone IV). The mcu and the FPGA are required to communicate with eachother via an interface.

I plan to use the high speed parallel port of the mcu. The FPGA will act as a slave to the mcu with a set of registers for reading status, setting configuration and reading data. The parallel bus on the mcu (APB: advanced peripheral bus) is connected to the DMA.

I am not sure if this method is correct.
I am also not sure how to setup the FPGA to handle the data coming through from the mcu.

Please can someone shed light on possible interfacing techniques.

I require a very simple and basic interface between the two.

TIA

In last project I used TI uP and cyclone IV , and as interface EMIF was used. If you design the board with arm and fpga why not use fpga with embedded arm processor ? Whole communication is trivial that way

axcdd said:

In last project I used TI uP and cyclone IV , and as interface EMIF was used. If you design the board with arm and fpga why not use fpga with embedded arm processor ? Whole communication is trivial that way

Click to expand...

Thanks for the reply.

I will have a look at the EMIF interface in more detail now.

I unfortunately can't use one of the FPGAs with embedded MCU as I was told not to.

Why would you go to the complexity of making a TI EMIF interface when the ARM has an AHB/APB, which would work just fine? Or is the plan to switch to TI because axcdd gave an example of doing something that worked for their application?

I don't have the time to read the 1700 page reference manual for the part so I can't determine which interface at a glance is the one that goes to external pins, but everything in the part is connected via AHB/APB and if the external interface isn't some sort of GPIO (bit-banging) interface I'm assuming it already has a defined protocol like APB.

Just write an interface module in the Cyclone IV to communicate with that bus. I've written AXI, APB, SPI, I2C, various proprietary parallel busses, simple addr/data/rd_wrb/csb intefaces over the years.

EMIF ist just a general term for memory mapped (date and address lines) interface, not related to a specific processor, I believe.

In most cases we implement an ansynchronous memory mapped interface when connecting a microcprocessor to a FPGA. It refers to SRAM mode of the ARM FSMC. ARM also supports synchronous PSRAM iinterface. It might allow easier synchronisation depending on how the FPGA side interface is clocked. Another important parameter is required throughput.

FvM said:

EMIF ist just a general term for memory mapped (date and address lines) interface, not related to a specific processor, I believe.

Click to expand...

Well yeah, that's true, but as a general purpose memory interface it has a lot more overhead than just a simple Address/data/read_write/chip_select memory mapped peripheral interface.

Chip select, read and write enable address and data lines are usually sufficient optionally byte enables, wait, and a memory clock.

The most interesting point is how the FPGA and processor clock domains are coordinate and how to assure consistent data transfers in both directions. The best solution depends much on the FPGA application details like datapath toplogy need for simultaneous access to registers, clock rates, if the FPGA clock can be derived from the ARM core clock.

For this reasons there's no simple answer of "do this" or "do that".

Hi,

I just considered the TI EMIF as I have been intrigued by TI mcu for a while.

I will be using the ARM STM32F4 and will be using the built in AHB matrix to communicate with the FPGA. I will create an module e within the FPGA to communicate with the MCU via this route.

I was just curious to see if there are any simpler, alternate ways to achieve this communication.

I was just curious to see if there are any simpler, alternate ways to achieve this communication.

Click to expand...

Might be, depending on the required interface bandwidth, e.g. a SPI interface.