Spartan 6 interface with STM32F7

[sanwal209]

Hi Guys,

I am building a project. In this project 3x OV9655 cameras are connected to spartan 6. Spartan6 function is to merge data streams from cameras and if require do some video processing and fpga send processed data streams to STM32F7 via 8 Bit parallel port and UART.

I dont have extra GPIO available on Spartan6 because i am using QFP package and i am not satisfied with only 8 bit parallel port connected to MCU due to lack of high data rate.

Solution i thought is to convert LVDS of Spartan6 to parallel outputs but i couldn't find deserializer for this purpose.

Please guys can you suggest a deserializer or any other method to interface Spartan6 to STM32F7

Thanks

[jbb]

I don’t know if it will fit well, but maybe you could use part of the FPGA to emulate a QSPI slave. I think that the STM32F7 can memory map external flash chips, thus enabling the use of quite fast DMA transfers.

Depending to the STM32 (and FPGA resources) you might be able to do DDR interface, too. 4b * 60MHz * DDR = 480 Mb/sec.

[hans]

Yes it can, more specifically QSPI can even be used to run code of it, so it's definitely well mapped into the memory region.

Even more so STM32F7 supports "dual-flash" mode operation, effectively creating a 8-bit data bus divided over 2 QSPI interfaces. The added bonus versus a normal 8-bit memory bus is the DDR.

According to datasheet of STM32F722IC, the max dual-flash Quad-spi clock frequency is 80MHz (single = 108MHz). So 8x2x80=1280Mbit/s. Takes 10 - 11 GPIO's (if you can share CS..).

Not sure if you can do much better than this, as you will either need to increase the bus width (not possible) or the bus frequency (limitations of STM32 part).
I would also certainly test if the internal AHB memory bus/matrix of STM32 is not saturated/suffers from jitter at these throughputs, and/or which SRAM regions you need to use to sustain the throughput.

[sanwal209]

Hey Guys,

Thanks for the response, I thought about a solution which is as follow:

I will connect 16bit Data output from FPGA to 2 ports(PD& PE) of STM32F7 and one clock going into two timer interrupt pins of STM32F7. Now on rising edge of clock DMA will trigger and take the data from PD port and on falling edge DMA will take data from PE Port. I dont know if this is feasible and if it is i can get a good data rate. QSPI is also a good option but i am utilizing it somewhere else on board.


Thanks for the help guys, i appreciate it.

[SiliconWizard]

QSPI is a good option if you're short on IO pins and/or for pcb routability reasons.

You could also use the "Flexible static memory controller" (FSMC), which is also memory-mapped and supports 8- and 16-bit data bus width.

[hans]

We still don't know what speed you're aiming at. Like is 10MB/s enough or do you need 100MB/s+?

The APB1 is limited to 45Mhz and APB2 to 90MHz, so you will need to chose timers from APB2. But even then you're stuck to 90MHz, and I cannot predict if it can handle 2x90MHz DMA requests sent over the AHB <> APB bridge. My gut feeling is, that it cannot, but you could test this on a development board.

With alternating buffers you also need to merge the words from both buffers together, as I don't think DMA supports custom stride values.

If the Increment mode is enabled, the address of the next transfer will be the address of the previous one incremented by 1 (for bytes), 2 (for half-words) or 4 (for words) depending on the data width programmed in the PSIZE or MSIZE bits in the DMA_SxCR register.

If you're lucky, your software algorithm can be adopted to read words from alternating buffers.

[sanwal209]

3x Digital CMOS cameras are connected to FPGA and if we take RGB 24Bit data with 30FPS then each camera data rate 118MB/s. Target application is to do video processing on video data streams and dump it to MCU. In this case maximum data rate we need is 118MB/s but i also want to have an option to get raw RGB data from each camera to MCU for which i need atleast 360MB/s.

with only available 16pins on FPGA, i have to have MCU which supports atleast 200MHz pin's toggling speed. I am also having gut feelings that STM32 will not be able to do this, so i am thinking to move to some higher end processor like sitara but even that beast cannot handle that much high speed.


In short in am stuck:)

[andersm]

Getting it to the MCU is only half of the problem, what are you going to do with the data once it's there?

[sanwal209]

Dumping on Ethernet or USB or LCD. There will be 3 options.

[andersm]

How are you going to pump 100-300 megabytes/second over either high-speed USB or 100Mbit Ethernet?

[sanwal209]

I thought of compressing the data send it to ethernet. STM32F7 have USB2.0 Full speed and USB2.0 Supports 480MBps isnt?

It will be too much to STM32F7 as i said before and that is why i am looking for some higher end processor like AM3358 but its GPIOs are also not that much fast.

Can you please suggest something?

[nctnico]

I thought of compressing the data send it to ethernet. STM32F7 have USB2.0 Full speed and USB2.0 Supports 480MBps isnt?

It will be too much to STM32F7 as i said before and that is why i am looking for some higher end processor like AM3358 but its GPIOs are also not that much fast.

Can you please suggest something?

FFS use a SoC with a camera interface. If pins are a problem then use MIPI.

[sanwal209]

Using SoC will be so obvious solution. I haven't worked on FPGA before and i thought about this project for learning purpose. Point is to have healthy discussion on a solution.

I could have used Zynq and forget about using external MCU but BGA package will increase the cost of PCB by at least 3x times.

Thanks

[andersm]

STM32F7 have USB2.0 Full speed and USB2.0 Supports 480MBps isnt?

USB high speed is 480 megabits per second, and realistic throughput tops out at about 35MB/s. For the data rates you're describing, you'd need superspeed USB, or 5GBASE-T Ethernet. FTDI have a new series of superspeed FIFO ICs that they claim can do 5GBps.

[SiliconWizard]

STM32F7 have USB2.0 Full speed and USB2.0 Supports 480MBps isnt?

USB high speed is 480 megabits per second, and realistic throughput tops out at about 35MB/s. For the data rates you're describing, you'd need superspeed USB, or 5GBASE-T Ethernet. FTDI have a new series of superspeed FIFO ICs that they claim can do 5GBps.

sanwal209, just to be precise, USB full-speed is 12Mbps, no matter what the USB revision. High-speed, available in USB 2.0 and later, is 480Mbps as andersm said.
I think STM32F7 actually supports USB high-speed (OTG).

I agree with the 35MB/s at maximum for USB high-speed, and even so, I doubt you'll get that kind of sustained bandwidth with an STM32F7. I got a little above 30MB/s sustained with USB high-speed (bulk transfers) on an ARM SOC @1.2GHz... and even that took some optimization time. You may have better luck with isochronous transfers but good luck with that.

For super-speed USB or multi-gigabit ethernet, you will need a powerful processor. STM32F7 just won't cut it.

[andersm]

It should be pointed out that even if you manage to export the data to a PC, sustaining those kinds of speeds are going to require some effort. For example, 360MB/s exceeds the random write speed of most mass-market SSDs. Your priority really needs to be reducing the amount of data that needs to be moved (for example, do the camera sensors actually provide 24-bit color depth? Can you do a Y'CbCr color space transform without losing too much data?)

[Siwastaja]

You already have an FPGA, which is just the right tool for the job of transferring massive amounts of data quickly. Do it completely there: move the ethernet thing to the FPGA. If you need some complex control where a CPU is more handy than writing HDL, use a softcore.

[sanwal209]

@andersm Yes there is an option in camera to use YUV output data format and  also for cropping the frame. You guys are right it would be pain in the arse to transmit that huge amount of data. 

@SiliconWizard Yes you are right, i studied the datasheet thoroughly. As i said to andersm i will take a resort on other data formats like YUV plus a compression algorithm in FPGA will not be a bad idea.

@Siwastaja yes it is possible but i am always fascinated by the idea of FPGA and processor based hard real time applications, so i will try to keep this architecture to learn more because this going to be my first project based on FPGA and MCU.

[sanwal209]

So finally decided to go with Octavo OSD335X SOM based on TI Sitara AM335x. FPGA will be connected to it via GPMC.