can cyclone5 satisfy these requirements (mostly LVDS speed issues) ???

[Altera_Forum]

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. 

[Altera_Forum]

--- Quote Start ---   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?   --- Quote End ---    http://www.altera.com/literature/hb/cyclone-v/cv_51002.pdf See Table 28 beginning on page 31    --- Quote Start ---   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?   --- Quote End ---   You will be writing your own modules (possibly using existing IP or megafunctions as building blocks) to receive your camera data. i.e. the fact that there is a clock and four bits coming at you is something you will be expressing in your Verilog/VHDL. Clock Data Recovery is not something the FPGA demands - you're just wiggling GPIO's. Probably not exactly useful for your application, but you may want to skim http://www.altera.com/literature/ug/ug_altlvds.pdf and http://www.altera.com/literature/ug/ug_altddio.pdf     --- Quote Start ---   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?   --- Quote End ---   I believe XGMII SDR uses 72-bits @ 156MHz   The capabilities of the devices are in the IO timing spreadsheet: http://www.altera.com/literature/hb/cyclone-v/cyclonev_io_timing_13.1.xls    --- Quote Start ---   I'm guessing the cyclone5 GT parts do not transmit and receive 10GBASE-T signals   --- Quote End ---   I don't have an answer for your question of tradeoffs, but for what it's worth, I don't think any FPGA terminates twisted pair copper onchip regardless of data rate. Consider not using BASE-T ?    --- Quote Start ---   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?   --- Quote End ---   I believe what you're looking for is "Active Serial" configuration, although there are other options.  Cyclone III is on page 9-13 of http://www.altera.com/literature/hb/cyc3/cyc3_ciii51016.pdf Cyclone V is on page 7-12 of http://www.altera.com/literature/hb/cyclone-v/cv_52007.pdf

[Altera_Forum]

--- Quote Start ---  http://www.altera.com/literature/hb/cyclone-v/cv_51002.pdf See Table 28 beginning on page 31  --- Quote End ---    So "high speed I/O" is a synonym for "GPIO"? The term "high speed I/O" does not refer to some special/faster I/O on a limited number of GPIO pins (like HPS or transceivers)? Is there an exhaustive glossary or something that explains what all the terms are? The reason I couldn't find this information is because I was expecting a table for "just plain old GPIO I/O". Is there also a table for "normal speed I/O" or "low speed I/O"... or "high speed I/O" is the slowest speed I/O cyclone5 parts support?    --- Quote Start ---  You will be writing your own modules (possibly using existing IP or megafunctions as building blocks) to receive your camera data. i.e. the fact that there is a clock and four bits coming at you is something you will be expressing in your Verilog/VHDL. Clock Data Recovery is not something the FPGA demands - you're just wiggling GPIO's.  Probably not exactly useful for your application, but you may want to skim http://www.altera.com/literature/ug/ug_altlvds.pdf and http://www.altera.com/literature/ug/ug_altddio.pdf  --- Quote End ---    Thanks.    --- Quote Start ---  I believe XGMII SDR uses 72-bits @ 156MHz   The capabilities of the devices are in the IO timing spreadsheet: http://www.altera.com/literature/hb/cyclone-v/cyclonev_io_timing_13.1.xls  --- Quote End ---    Thanks, but I can't download that file. I've tried many times on several different days (with two computers). It always gets about 3/4 of the way through, but then hangs up (won't complete the download). Can you check whether you have the same problem trying to view or download that file?    --- Quote Start ---  I don't have an answer for your question of tradeoffs, but for what it's worth, I don't think any FPGA terminates twisted pair copper on-chip regardless of data rate. Consider not using BASE-T?  --- Quote End ---    Okay, that's very interesting. Is the same true of other I/O standards? For example, do designers need to put PHYs or level-translators between the FPGA and PCIe bus lanes? Where do I find out when support for a given communications standard is complete (no extra ICs required), and when they are not complete (extra ICs required)? Or are they all "incomplete" and require external drivers/receivers?     --- Quote Start ---  I believe what you're looking for is "Active Serial" configuration, although there are other options.  Cyclone III is on page 9-13 of http://www.altera.com/literature/hb/cyc3/cyc3_ciii51016.pdf Cyclone V is on page 7-12 of http://www.altera.com/literature/hb/cyclone-v/cv_52007.pdf  --- Quote End ---    Okay, I'll check that out. When I was designing with the cyclone3 a while back, I sure didn't get the impression there was any way for the cyclone FPGA to configure itself. But maybe I misread or misunderstood.  Later: After a quick check on digikey, it appears the parts supported for "active serial" cost about $14, while standard 1-bit flash parts cost about $0.50 for the same quantity of memory. So, is this just a case where altera wants to rape people alive --- who don't know better? Or am I missing something here. Note that a very capable microcontroller outside the FPGA costs several times less than one of these EPCS# parts, so even including that external microcontroller the price is much lower. Again... am I missing something here?  -----  I have another question. Roughly how fast is a typical ALM in a cyclone5 part? I'll try to explain why I need to know. As my FPGA receives image pixels from the image sensor, it needs to construct an ethernet packet (the simplest kind of packet, no TCP/IP or other protocol) to send through the XGMII interface. But some portions are not of fixed length (due to lossless compression for instance), and certain values (like the 16-bit packet length field) are not known until all the input pixels for a row have been captured and processed. And so, the FPGA either needs to grab bits and pieces of data held in various places inside the FPGA and construct a complete linear packet (in 32-bit wide FPGA memory, I assume, since each packet will be roughly 4KB to 8KB long (jumbo packets))... OR... needs to switch from grabbing data from one place to another place in real time as some of the 32-bit chunks of the packet are output to the PHY (or more exactly, put into a 32-bit register in the PHY that holds the next 32-bit value for the PHY).  Unless I have some idea how fast each ALM will be, I can't make an educated guess of how many levels of pipeline I might need in this part of the design. I suspect this will be a tricky part of this design. If you have any general feelings about which of the above two approaches is best, feel free to relay them.  -----  Another question. In that table, what is "serdes factor". I note all the values shown are small numbers. So maybe I better ask this question. Can the cyclone5 parts perform serdes on 32-bit wide values (as required by the XGMII interface, for example)?  -----  Also, it appears to me that only about half the GPIO pins can perform LVDS input/output. Is that correct? That would pretty much mean there is no way for a modest cyclone5 part to operate four XGMII interfaces (not to mention the 68 LVDS signals from the image sensor). Or am I misreading something here?  -----  And finally (I hope), it appears I should switch from schematic input mode to HDL (probably verilog) for this project (ouch)! I think I don't learn the way most people do, so I wonder, is there any verilog information/training/book that pretty much just provides a verilog listing for as many MSI and common LSI subsystems as possible. You know, like "n-bit registers" and "2/4/8/16/32/64-bit multiplexers", "2/4/8/16/32/64-bit decoders/demultiplexers", "n-by-m bit RAM", CRC32, and so forth? I much prefer to look at specific (already understood) examples, and sorta learn to understand how verilog works by integration or "mental reverse engineering" or whatever you'd call that. In other words, I generally learn easier and better in a "bottom-up" rather than "top-down" fashion.