--- 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.
Honored Contributor
