2016-04-27 06:43 AM
Hi all,
I'm just starting to embark on the problem of accessing external registers (implemented in a FPGA), via the FSMC on the STM32F4 core. What I'm interested in doing is accessing these registers as SRAM (memory mapped registers) from the uC, which is obviously the data interface between the core logic on the FPGA, and the uC core itself. I'd also be interested in hearing about any other options of accessing 32 bit register data from the FPGA.Has anybody had any experience accessing an external FPGA in this manner?Thanks!2016-04-27 07:55 AM
Hi,
You should look at the STM3240G-EVAL example which describes how to configure the FSMC controller to access the SRAM memory: STM32Cube_FW_F4_V1.0\Projects\STM324xG_EVAL\Examples\FSMC\FSMC_SRAM Maybe this should help you. Regards2016-04-27 04:16 PM
I have an Altera FPGA tied to a F429 and shift the data in and out via a 16bit bus but
that was tricky making a whole 16 bit port free even on a 176 pin device. Using the FSMC sounds like a good idea so long as you your not using SDRAM as well. For an alternative, how about using high speed SPI and a double buffered DMA to pipe the data in from the FPGA, so it?s always ready when you want to read it.2016-04-27 11:45 PM
I've done (am doing) this, with an STM32F407 and a Spartan-6, using the FSMC as the comms interface.
I considered doing it with SPI or even SDIO but the simplicity of having the FPGA design's register set literally memory-mapped into the MCU makes life (and firmware!) so much easier than the alternatives. In hindsight, I'm satisfied that I made the correct choice.2016-04-28 04:16 PM
OK, if you need random access to the data in the FPGA then the FSMC interface looks like the best option.
However, if you are accessing the data sequentially (or even discontinuous sequentially) then the extra pins taken up by the address bus seem a waste of pins to me, unless you have the pins to spare. In my case I use the the FPGA's connected to cameras and the information I want from them is either the whole or a block of the image, the resultant data or the JPEG data. I use a programmable counter within the FPGA to generate the address value and an edge triggered signal to update it. The data passed over SPI is status data so I can detect events without having to address and read a register. Which I think is the optimal solution to my application, but am always happy to consider alternatives :) Vive La Forum.2017-07-29 11:05 AM
I've a question about this if I may. What did you use for the system clock on the FPGA? (Crossing clock domains can result in metastability which in a critical system would need to be addressed).
2017-07-30 08:47 AM
I prefer unified clock domains, you could add a resynchronizer if you expect to cross them.
The STM32 parts generally will take an external clock source of up to 50 MHz, ie from a TCXO rather than an a crystal driven by the HSE IN/OUT pins, so you could have the FPGA + STM32 driven by the same source clock. Check fHSE in the data sheet.
The STM32 also outputs internal clocks via the MCO (PA8) pin (MCO2 also on some parts, also secondary taps from PLL, or different PLL). The SDRAM interface will expose a clock.
From a synchronous input from a different clock domain, look at the DCMI interface.
2017-07-30 12:04 PM
Thanks for the reply - much appreciated. I wanted the views of someone who has actually tried this before investing lots of time developing this.
Our first thought is to use the MCO2 to provide a clock source to the FPGA, so the clock remains unified throughout (albeit at different rates). Our data rates are only around 10kHz, so we've got a bit of slack.
So far, we've setup the FMC in SRAM mode (Nice and simple) with fairly long setup times. Next task is to write some VHDL to read/write. A slight snag is that I've got MCO2 configured down to 2MHz simply because I want to use this for a class I'm teaching, and the FPGA is connected via prototyping wires (not great I appreciate, but we don't have time to build 80 x PCBs).
This means scaling the clock back up in the FPGA with a PLL. Slightly concerned about clock drift between MCO2 edges (I need to check the Altera specs on the Cyclone IV).
Regards,
Nick
2017-07-30 12:50 PM
http://andybrown.me.uk/2014/06/01/ase/
http://www.stm32duino.com/viewtopic.php?t=1276
There have been people using the STM32 + Cyclone, have to be some boards out there.
HAYOU has this one
The PLL is likely to introduce some amount of jitter, and probably isn't phase aligned.
2017-07-30 02:40 PM
Thanks for this - I'll take a look at those projects.
The board we are using is this one:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=593
I'm going to do some further reading in the Altera clocks and PLL system ( nice light reading for tonight ). I seem to recall quite a number of options for maintain phase relationships with the input clock, but it was a whole ago I read it.
Cheers,
Nick