Best FPGA for the job - low-speed LVDS deserializer - Page 1
Forum section: electronics / general

author: iodelay
author_rank: Newbie
timestamp: March 23, 2023, 04:58:16 pm
content: Hello everyone,recently I've been tasked with the design of a system whose main job is to act as a data-logger, collecting the data stream coming in from an external system and transmitted over two LVDS pairs, one for the data and one for the clock. The data is then sent to a remote endpoint by means of an Ethernet connection or a Wi-Fi module (connected via SPI).The data is not encoded and is supposedly coming in at a steady ~30Mbps, which is definitely low if compared to other similar forum posts asking for advice.Given the need to handle the network interface, which is definitely something I'd like to avoid to do in FPGA, I was thinking of either getting a SoC FPGA (e.g. Xilinx's Zynq 7) or a fast MCU (e.g. STM32 F7) paired with a small FPGA (e.g. Lattice iCE40) doing the heavy lifting.I'm no expert in FPGA design but I'd envision most of the complexity lies in the implementation of the clock-alignment algorithm (I don't need a SERDES block, right?) and the hard requirements are at least 2 PLLs (one for the system clock, one for the delay-tuning of the received clock) and a bunch of RAM to act as FIFO when talking to the MCU.Of the two solutions the SoC one looks simpler but greatly complicates the routing (and a more complex PCB stackup) and I can't help to feel it's definitely too powerful (and power hungry) for this task.The MCU + FPGA combo is enticing as small = less pins = easier (and faster) routingand given a connection between the two using a parallel 8 bit bus the MCU ends up having to handle "only" 30/8 = 3.75Msps, leaving the CPU a lot of time to perform other tasks (perhaps an F7-series MPU is too much for this..).What I'm asking you all is:- Is my assessment of what's needed and what's not correct? Am I under/overengineering the solution?- Would an iCE40 (or similarly cheap & small Gowin's FPGA) cut it when paired with a MCU?- Do you have any other (possibly better) solution?Thank you in advance!

author: Scrts
author_rank: Frequent Contributor
timestamp: March 23, 2023, 06:44:39 pm
content: We've used STM32F205 to capture h264 or MPEG2 encoded video data (8bit bus plus start signal) over camera interface, DMA it to external SDRAM, packetize it and send it over Ethernet. It could handle a constant video data stream of 80Mbit/s. Do you really need FPGA here? Is there a specific interface that a microcontroller doesn't have?

author: iodelay
author_rank: Newbie
timestamp: March 23, 2023, 07:14:36 pm
content: Quote from: Scrts on March 23, 2023, 06:44:39 pmThe input data is serial over LVDS and (sadly) I cannot change that, the FPGA acts as deserializer + FIFO + serial-to-parallel converter.

author: Someone
author_rank: Super Contributor
timestamp: March 23, 2023, 09:43:56 pm
content: Quote from: iodelay on March 23, 2023, 07:14:36 pmThere are microcontrollers with synchronous serial interfaces (often with FIFIO too), so that is not an inherent problem. Without specifications of what the serial stream is and what the signal timing is it's impossible to say how to proceed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 23, 2023, 09:51:39 pm
content: Quote from: Someone on March 23, 2023, 09:43:56 pmFor 30Mbps (if I got it right), many MCUs will be able to handle this with their SPI peripherals. You just need to add external LVDS transceivers, which are relatively inexpensive.

author: AK6DN
author_rank: Regular Contributor
timestamp: March 23, 2023, 10:34:08 pm
content: Quote from: iodelay on March 23, 2023, 07:14:36 pmIf it is a serial bitstream of data words of some size, how do you detect word boundaries of the data? What is the encoding used?

author: iodelay
author_rank: Newbie
timestamp: March 24, 2023, 09:51:32 am
content: Quote from: AK6DN on March 23, 2023, 10:34:08 pmThe framing is pretty simple, there's a fixed-size pilot sequence followed by N bytes of data. The frame synchronization is achieved by bit-slipping until the pilot is found.Quote from: SiliconWizard on March 23, 2023, 09:51:39 pmNot a bad idea, the only thing I'm worried about is moving all the complexity into the MCU domain.With an FPGA I can easily add the synchronization logic and a small FIFO to act as a buffer for free, while with a direct SPI connection the MCU has to always be ready to receive the data or it would be lost.The buffering could be implemented by adding a discrete FIFO IC but then the combined cost of the two components would outweigh the cost of a teeny FPGA.

author: nctnico
author_rank: Super Contributor
timestamp: March 24, 2023, 01:06:17 pm
content: Quote from: iodelay on March 23, 2023, 07:14:36 pmI'd look at the Gowin GW1N1 (IIRC) device for this job combined with a microcontroller. You can pack the FPGA configuration binary together with the firmware image and configure the FPGA at every startup and go from there. Heck, you can use the same SPI interface to configure the FPGA and read data from it. Been there, done that.But as others wrote: you likely can implement everything into a microcontroller but doing the framing (synchronisation) in software could be a bit tricky. IMHO it is worth prototyping a microcontroller only solution using a development kit. Having a software only solution will be easier to maintain.