STM32F427/9 FSMC continuous clock mode

[jshamlet]

Posted on April 05, 2014 at 05:00

I am working on porting a soft-core processor presently hosted in an FPGA application to an external processor. The application logic is memory mapped, so that the CPU can control the hardware using ordinary read/write instructions. While this has worked well, the block RAM required to hold the processor's ROM image is getting to be a problem.

I have been considering microcontrollers because they have internal ROM and RAM, replicating some of the benefits of a soft-core system. However, I would like to retain the memory-mapped nature of the design in this new architecture. I found the STM32F4 family while researching the topic, and the FSMC seems to fit the bill - mostly. I would like to use the external memory mode to connect to the rest of the logic in the FPGA in the same way as the present system - using a synchronous, memory mapped bus. I noticed from reading the datasheet, user manual, and playing with the configuration tool that the STM32F4xx parts have synchronous memory interfaces, but that they only issue clocks during memory access.  My goal was to actually use the memory clock to source the FPGA. The STM32F427/9 parts have an option to continuously source the clock, but it forces burst reads to be enabled. My questions are 1) If I feed the microcontroller a stable external clock, would the derived memory clock be stable enough to source the FGPA? The current design is hosted in an Altera Cyclone III FPGA, and from perusing the datasheets, it seems that the PLL in the STM32F4 parts actually have better jitter performance than the PLL in the Cyclone, however, I know that's not the end of the clock chain. There are at least two more dividers between the PLL and the memory clock pin. The waveform generators are based around cascaded NCOs, with a sample frequency of 66MHz, but the final output frequencies are all below 1kHz. 2) If I go with the STM32F427/9, what consequence will having burst reads enabled cause? Will it disrupt normal single-access reads? Most of the registers require read/modify/write style access, so read bursts would necessarily have a length of 1. 3) Is the phase offset of the master clock out pins low enough that I could simply drive SYSCLK/2 out and still be synchronous to the FSMC?  (assuming HCLK = SYSCLK) Essentially, could I set up the FSMC to do synchronous transfers, but instead of connecting the memory clock, connect one of the master clock outs set to the same frequency? I know this is dubious, and I won't be surprised if that isn't an option, but if it could be made to work, the less expensive 405/415 parts could be used. Is there anything else I need to consider? I really only plan to use the microcontroller as a microprocessor with internal memory, and maybe connect a UART for debugging. Thanks! #fsmc

[Tesla DeLorean]

Posted on April 06, 2014 at 17:22

I haven't done a huge amount of analysis of the FSMC/FMC implementation, but the use of option #3 would seem the most viable.

You could output a clock via the MCOx pins and that would be synchronous with other clocks, and it would certainly be possible to get AHB/APB2 clocks at a single rate somewhere below 100 MHz (84 or 90 in most common configurations), and have a single/common clock domain throughout the design. You don't mention a specific frequency, or speed requirement for the system, but there is no particularly compelling reason to drive the processor at it's maximal frequency, and a lot of opportunity to pick rates that suit/fit the STM32 and FPGA, or make slight changes to the FPGA interface to meet exact requirements.

[jshamlet]

Posted on April 08, 2014 at 17:43

Thanks for the feedback.

I suspect the only way to really answer this is to try it. I'm going to put in for a discovery board with the STM32F427/9 part on it to hedge my bets, and give it a try. I have an FPGA development board that I can easily route both clock and data to. As an aside, I have a great deal of flexibility over the FPGA clock so long as I maintain a high enough core clock for the NCO-based waveform generator. I have had suitable versions running between 50 and 100MHz that met our performance criteria. The 66MHz oscillator was chosen because it could be shared with a PCI back-end interface.