PCIe or GMII for FPGA CPU data transfer ?

I would use a memory mapped interface: Access the FPGA like a SRAM, if your CPU has a SRAM interface. This is very easy, on the CPU side and on the FPGA side. Bigger CPUs can do DMA transfers to this interface and you can provide some virtual registers mapped in the memory area, e.g. for reading or writing ringbuffer pointers.

But it needs a bit more wires to the FPGA and carefully routing for high speed signals. I know a system wich works without problems with 100 MHz and a Cyclone 2, with a 32 bit wide data bus, connected to a PXA CPU.

The same reasons are valid for a memory mapped interface. I don't know the physical side of PCIe, but I assume a memory mapped interface would be much easier than PCIe.

If you implement the PCIe core yourself, then you can implement DMA capbilities, too. But I don't know if it is fast enough, if there is not already some hardwired PCIe interface included in your FPGA.

A simple old fashioned 8-bit parallel bus at ~100MHz would do. At that kind of speed, the signal integrity is no problem and there is no need to do anything special about it. Of course, you can make 16 or 32 bit bus with the correspondingly slower speed.

Why do you need all that cost and complexity?

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Hi,

Thanks for the replies.

The CPU we have has a 25MHz low speed bus typically designed for placing a boot flash. Also there are other devices on this CPLD and using a direct bus is definitely not an option.

The choice for us is really between PCIe and GMII as the CPU supports these and other peripheral buses.

My question is then really choosing one of these from FPGA and system software perspective.

Thanks.

an

going

following

both

within

really

Depends some on the CPU in question, and some on the data model. If it has good DMA capability on the GMII interface (and most do), that might be simpler. You don't need all of the ethernet / TCP overhead - just use it to push data around, and set the GMII port to promiscuous mode. You don't even have to use CRCs (though it's probably not a bad idea).

PCIe brings a lot of protocol overhead as well; pulling data requires extra transactions. If your FPGA already has a hard PCIe core, just use it. I've had some bad experiences with soft PCIe cores, but it's probably far enough along in the market by now that those have been resolved.

As I said, it also depends on your data model. If the data comes in from a more-or-less asynchronous interface, using PCIe means that you'll have to either have the FPGA master the transaction into the root complex, or the FPGA will have to interrupt the root complex and it will need to pull the data.

Working from the gate-count side on the FPGA, I suspect a minimal GMII implementation is probably quite a lot less space than a PCIe implementation (again, unless you have a hard PCIe core, but if you did, you probably wouldn't be asking the question).