Question : Avalon OpenCores 10/100 Ethernet MAC TX problem

[Altera_Forum]

Hi All, 

 I am experiencing strange behaviour with the transmit side of the OCM version 9.1, I have created a sof for a Cyclone II custom board that includes a Nios II/f, 16MB SDRAM (32bit databus) and OCM using Quartus 10.1.    My SBT project utilises Interniche superloop mode. I have also have recently tried a uC + Interniche project as well - same problem.   When run, I receive messages as expected and I have traced the generated replies all the way down to the low level send OCM routines. The problem is that the data that appears on the wire (verified via Packetyzer) is different to that what is held in the SDRAM. For example, here’s the memory contents from the descriptor data pointer for an ARP reply....   5C 26 0A 32 2B 9F 00 07 ED 08 02 6F 08 06 00 01 08 00 06 04 00 02 00 07 ED 08 02 6F C0 A8 0B 0A 5C 26 0A 32 2B 9F C0 A8 0B 0B C0 A8 0B 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00   And here is what appears on the wire...   5C 36 2B 9F 0A 32 2B 0F 00 07 ED 08 02 6F 08 06 00 01 08 00 06 04 00 02 00 07 ED A8 02 6F C0 28 0B 0A 5C 96 0A 32 2B 0F C0 A8 0B 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   This can also be seen in the attached jpg which shows Packetyzer and NIOS debug screen grab.   As you can see it appears that there is a word swap at the beginning of the message and 2 lost characters in addition to odd bits been set or cleared. The strange thing is that the ‘corruption’ is not random – i.e. the same bits are set/clear and word is swapped in an identical fashion each time the message is sent.    Also, this is a known working board. It has been in commercial use for 4 1/2 years using the wishbone OCM running a Quartus 6.1 sof.    Further related information,   - system clock of 80Mhz for NiosII, SDRAM and OCM - no data cache - with debug mode set to 5 (ETH_OCM_DBG_LVL) no debug error messages (on RX and TX) are generated. - MDI and MDO pins are connected via a tristate buffer using MDOE. I have also tried using a altiobuf. - PHY is National DP83848C, running from 2.5MHz osc.  - OCM Burst Modes disabled (due to size constraints) of 2C8 device   As RX works I am at a complete loss as to why this is occurring.. anybody got any ideas?   Thanks in advance  Ade

[Altera_Forum]

If the TX buffer aligned on a 4 byte boudary, or a 4n+2 one (more likely). 

Might be worth doing a data copy to word align it - if only to see if it makes a difference.

[Altera_Forum]

I used the same MAC and same PHY but I've never had such a problem. The only difference being I used version 9.0sp2. 

Could it be a clock or timing problem? Is your design fully constrained? Do you get any negative slack report from TQ?  You say the DP83848 is clocked by a 2.5MHz osc. Is this correct? AFAIK the correct clock frequency for this phy is 25MHz. Moreover, is this clock synchronized with the ones you use for mac rx and tx? Or do you use phy rx_clk and tx_clk output pins?

[Altera_Forum]

Thanks guys... 

 dsl, I also had my suspicions re alignment.. I tried doing exactly what you suggested. Unfortunately, this resulted in the same behaviour.   cris72, there's no negative slack in the TQ report. You are right, it's a 25MHz osc. Not sure about the phy clocking though.. I'm having it checked out by someone else (hardware engineer).    (Un)fortunately I'm on holiday as of 5pm today so will be resuming investigation in a weeks time. I'll keep you posted on any significant observations and progress.   Thanks Ade

[Altera_Forum]

Before I do finish for the day, attached are a couple of screen grabs illustrating missing 16 bit values on a hand crafted packet (set to 0x11 0x12 0x13 etc) . 32bit alignment does make a difference, but only in the sense of which/where the 16 bit value is getting lost.  

 Right now I don't know if it's a MAC to PHY or MAC to SDRAM issue. Any thoughts?

[Altera_Forum]

Hi AdeColes, 

I have the same problem as you. Did you find a solution?