Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Can you get RGMII working with the EQFP package parts

I am working on a design that looks to need about 16MB/s of bandwidth. That, unfortunately, is more than a single 100Mb/s link can manage. We presently have two ideas to solve this:

1) Use 2 10/100 PHY's at both end of the link, using all four twisted pairs in a standard Cat-5e cable. This ends up looking like a Gig-E hybrid running at 100Mb/s data rates. This yields an effective data rate of about 20MB/s, but is non-standard, so normal switches, hubs, and NICs couldn't be used. However, for a point-to-point link, that may not be an issue - and in return, RMII runs at 50MHz SDR, which is trivial to implement in the FPGA.

2) Use a single Gig-E PHY at both ends of the link. This would have more than enough bandwidth, but is starting to push the board into higher frequencies - not to mention pushing the FPGA a lot harder. The media access control layer will need to use DDR I/O at 125MHz.

The latter wouldn't be an issue, except that we are trying to stick to a 4-layer board (6-layer max) by using either the EP3C25 or EP4C22 in a 144-pin EQFP package. This part is also only offered at speed grade 7 or slower. I'm just wondering, before I get started, if I'm asking for trouble by trying to implement RGMII in these parts? The DDR I/O doesn't worry me, but the getting it all to work at 125MHz does.

Also, we are not planning on implementing a full MAC. Instead, I'm planning to use rate-change FIFO's and a just enough logic to implement a minimalist interface. Essentially, I want to push data into one FIFO, and have data come out of a corresponding FIFO on the other end. We probably won't even bother with Ethernet framing beyond what is required to keep the PHYs happy (though I do plan to implement CRC32 on the packets)

Thanks!

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    A EP4C22 should handle an RGMII interface just fine, especially a -7 speed grade. I believe some of Altera's C4 reference designs use an RGMII interface (http://www.altera.com/products/devkits/altera/kit-cyclone-iv-gx.html). If you have the pins, you could use a GMII interface instead (SDR), which would reduce the switching rates on the data lines if you're concerned about it.

    I use raw L2 Ethernet interfaces for internal communication all the time to communicate with our main system processor. Works great, Just need mac dst/src, length/type, data and crc, and you can use a raw socket interface.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Just out of curiosity, if all you want to do is push data from one board to another why use something as complex as Ethernet? There are all kinds of SERDES chips out there that could do the job much more simply.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Just out of curiosity, if all you want to do is push data from one board to another why use something as complex as Ethernet? There are all kinds of SERDES chips out there that could do the job much more simply.

    --- Quote End ---

    A fair enough question. I actually looked at a LOT of SERDES chips before settling on Ethernet PHYs. We needed a galvanically isolated interface to isolate the host processor from the test set. That meant either capacitively or magnetically coupling everything going between the two boxes. The current system uses an array of iCoupler devices to isolate a bunch of high-speed SPI buses. (one for each ADC/DAC) This has has worked fine, but we now want to up the data rate by a factor of 10, as well as move our signal generator into the isolated domain (as opposed to using an analog signal isolator). The signal generator uses a 100Msps 14-bit DAC, which made the current scheme unworkable. So, we opted to put a local FPGA on the board to manage the board, house the signal generator firmware, and packetize the ADC data streams. Serializing the data stream to the host CPU seemed fairly obvious at this point.

    I actually found a few very nice SERDES chips, but the I/O count was usually too high. The TBI devices had a minimum of 11 lines in each direction as well as the clock, and needed firmware to do the 8b/10b encoding in addition to clock-crossing/rate change FIFO's. The TI parts that were suitable had two 16-bit interfaces plus control lines, which put the I/O count near 35. Given that we only have 79/81 pins (depending on which part we opt for), that's a pretty high ding to the pin budget. Both the RGMII and dual RMII interface can be managed with 13 lines or less. I even poked around a little on the idea of using a GX part, but that meant using a BGA or QFN part - which for boards that are hand assembled was a no-go. (We do have a BGA machine, but it's getting old and cranky)

    I was also worried about using devices that were a bit too specialized, and thus might not be available in the future. This system will need to be serviceable for at least 10 years. I don't mind specifying a lifetime buy, but if I can use commodity parts that are expected to be widely available, I prefer to go that route. Ethernet PHY chips met all those requirements. They use magnetic coupling, the parts are cheap and plentiful and should be around a while, and the interfaces are highly standard.