Ethernet problem turned out to be a memory / DMA problem

I would first try to reproduce the problem with a simple test system.

Does your memory tester use the SGDMA controller to generate transactions?

Its quite possible that your test cases are not generating the same burst transaction, or combination of burst transactions that the ethernet controller interface is generating.

Could you use SignalTapII to track the transaction of an invalid packet? Eg. put a hardware checksummer in the design, and use the failed checksum to trigger the analyzer. Then look at SignalTapII traces of the memory interface. If you can find the transaction corresponding to the data corruption, this should provide the memory transaction or sequence that leads to the problem. Eg. perhaps there is a refresh that occurs, screwing up the pipeline, or perhaps a problem in one of the FPGA controller FIFOs.

The other thing to try is to use the Micron device model in a testbench, and see if your controller timing generates any violation messages from the memory device model.

If you do have a high-speed scope, then sure, probe the pins. If you don't, then try slowing the memory controller clock down to see if the problem changes or goes away, or try increasing the clock to see if it gets worse (but the SDC analysis must still indicate the interface meets timing of course).

Cheers,

Dave