I'm considering options for connecting a DUE to a FPGA running at 50MHz. An easy (for me) option would be to use a serial protocol (3v3 level RS232 style), but I'm struggling to find information on what baud rates are available. I'd like to run at the highest speed possible to keep the latency down. Non-standard speeds are completely acceptable to me 
.
The SAM3X datasheet suggests that baud rates of the master clock divided by multiples of 8 are achievable, so I was considering a divider of 32 (19 on the FPGA) for a baud rate error of 0.25% at 2.625Mbit/s.
Does that sound reasonable? Something like Serial1.begin(2625000);
After much thought, I think implementing a simple SPI slave on the FPGA should be easy and allow a much faster transfer rate.
This page:
Suggests I can transfer bytes in both directions simultaneously along the lines of:
for (byte i=0; i<128; i++)
{
 RxBuffer[i] = SPI.transfer(4, TxBuffer[i]);
}
Does this seem like a sensible option? I suspect 28MHz transfer should work well.
(I admit there is a waste in RAM by having the buffers the same length in that example, but for simplicity, meh 
).
Just out of interest why do you need the high data rate?
If it's to trigger an event or something like that then it would be better to simply toggle a pin on the FPGA and connect it to an interrupt pin on the arduino.
There's a lot of data going back and forth over a network, the Arduino is there to make the Ethernet part of the equation simple. I could control the wiznet chip with the FPGA directly but I'm trying to make this as easy as possible. This particular project isn't Arduino-centric, all of the work is already on the FPGA, I'm just looking at a simple option to transfer data to another FPGA via ethernet, adding arduino's and wiznet chips would seem to be the least hair pulling solution.
Fair enough but personally I would have thought you'd be better off incorporating it into your FPGA design but I don't have any experience with them.
It's certainly possible, but it's a lot of work, potentially faster as well as there are no software overheads (nothing between SPI commands for example).
I'm wondering what the potential there is for a parallel read or write of 8 bits, ideally I'd want a byte input and a byte output rather than a bidirectional byte worth of pins, safer on the oopsie moments...