--- Quote Start ---
I don't remember if this is possible with the small TSE core, but can you disable CRC checking?
--- Quote End ---
I already have it off. I do need the full core anyway; the small TSE can't do TX store-and-forward mode, which my design will need to eliminate a potential source of TX packet loss.
--- Quote Start ---
Are the clocks correctly connected between the TSE core and the PHY chip?
--- Quote End ---
As far as I can tell, yes. For plain MII mode I am getting both RX and TX clocks directly from the PHY. Both clocks are definitely toggling, the TSE will get stuck in its software reset if they don't (I had it happen). Further, the RX MII data looks perfect in SignalTap.
--- Quote Start ---
Does the hardware design complies with all the timing requirements?
--- Quote End ---
Aside from a couple of harmless issues, yes. (There is an asynch reset that feeds all the reset-CDCs which has overly tight constraints on it). All clock domains related to the TSE should be good. The entire rest of the system (3 clock domains) works flawlessly.
--- Quote Start ---
If you could replace the DMAs with Altera's SGDMAs and try to run a standard software example with uc/OS and Niche stack (such as the sockets server example) you could check if this as a hardware of software issue.
--- Quote End ---
Hm, now we come to the tough one. This isn't a Nios system, it is a 4-CPU superscalar MIPS with full cache coherence (yes, cache-coherent DMA). The CPUs and system design are well-proven, and the fact that the MAC and ST interfaces are what's stuck should hopefully rule out all the really tough problems. But unfortunately I can't just drop in Altera's software stack and test it out.
One particularly notable issue related to the different CPU type is the I/O access width when poking the TSE registers. The driver I wrote is very careful to do only aligned full-word reads/writes, so that byte-enables are unnecessary for the TSE. The TSE registers do get written with the intended values so I know this is done right. The Avalon-MM transactions look correct on SignalTap as well. If it would help to post and annotate the exact sequence of read/write transactions to the TSE let me know.