I am designing a high speed, high resolution camera for robotics vision and digital cinema, and I'm trying to figure out whether any of the cyclone5 parts are up to the design requirements. I've found answers to most of my questions in cyclone5 documentation, but haven't found answers to the following questions.
-----
My device will support a few different image sensors, but they all output the pixel data on 8 to 64 LVDS signals of some sort. Some signals are LVDS, others are sub-LVDS I believe (the HiSpi interface) and the data rates vary from 64 lanes at 300Mbps (CMOSIS CMV12000) to 16 lanes at 480Mbps (CMOSIS CMV20000) to 24+6 lanes at 700Mbps (aptina AR1411HS) to 8+2 lanes at 800Mbps (aptina AR1820HS). When I say something like "24+6 lanes", that means 24 LVDS pixel/data signals plus 6 LVDS clock signals (because the HiSpi interface has a separate LVDS clock for every 4 lanes of pixel/data).
As you can see, there are far too many LVDS signals to attempt to capture this data with the high-speed transceivers in the GX or GT variants of the cyclone5 FPGAs. And so, I've got to capture this LVDS data with GPIO pins. I am fairly sure that all these signals are DDR (data is captured on the rising and falling edge of the LVDS clock signals).
As a separate question, most differential signals I've read about before are "self-timing" (the clock is recovered from the data). But at least some of these image sensors output a LVDS or sub-LVDS clock for every 4 LVDS data signals. Is this supported by the FPGA, or does it expect to recover the clock from the data-signals --- which would make the FPGA operate in a way not consistent with what the image sensors expect?
Try as I might, I just can't find anywhere in the cyclone5 documents that tells me what is the fastest clock and data rates the cyclone5 GPIO receiver pairs can support to reliably read LVDS data like this. I found some information like that for the special high-speed transceivers in the GX and GT variants, but not the GPIO in any parts. This information is probably right there in front of my face (in those several thousand pages), but I don't see it. What's the answer, and where did you find this information?
-----
The device will be sending image data across 4 x 10Ge (10 gigabit ethernet) interfaces. My current idea is to interface to a quad 10GBASE-T PHY via the 32-bit XGMII interfaces. This should make the speed of those (probably non-differential) signals 10Gbps / 32 == 312.5 Mbps (presumably not DDR, but I don't have the specs on the 88x3140 or 88x3240 parts yet). So that's my next question, can the cyclone5 GPIO pins read and write at 320+ Mbps? This is another bit of information about the GPIO speeds that I cannot find (probably very close to the where the speed of LVDS signals is given). What's the answer, and where did you find this information?
-----
I was looking at the cyclone5 GT parts thinking maybe then I wouldn't need external any 10Ge PHYs. But... the more I look, the more I think that's not true. I'm guessing the cyclone5 GT parts do not transmit and receive 10GBASE-T signals, and that all the talk about 10 gigabit ethernet with cyclone5 is just marketing talk, because you still need an external PHY anyway. Am I right about this, or does the cyclone5 GT implement a 10GBASE-T PHY in the FPGA? Maybe the cyclone5 GT can send and receive data to a 10GBASE-T PHY via the XAUI interface, which is 8x narrower than the SGMII interface, but if so, that doesn't save any parts at all (just GPIO pads on the FPGA). But the cyclone5 E parts are vastly less expensive than the cyclone5 GT parts, so the bottom line is, saving a bunch of I/O pads on the FPGA is a huge waste of money. Set me straight... do I understand this correctly?
-----
I fiddled with a cyclone3 FPGA a few years ago, and was amazed they didn't make the FPGA know how to configure itself from standard 1-bit flash memory chips. Instead, you need to buy some fancy and expensive altera configuration chip, or design in an external microcontroller to fiddle pins on the flash memory chip and FPGA chip to configure the FPGA. Has this silliness been eliminated yet, or is this still the situation?
-----
Thanks to anyone who answers these questions. Getting back up to speed after so long is not easy... so many thousands and thousands of pages. Yikes!
PS: I attach 2-page fliers to the image sensor and PHY parts I mentioned above, in case that helps clarify my questions.