TSE doesn't have data on RGMII output, functional simulation works fine (Max 10)

Hi Alex,

I assume the RGMII uses DDIO (Double Data rate I/O), and we cannot tap out DDIO by using SignalTap II. What we can do to ensure Tx activity is tapping out GMII signals (input signals of the DDIO) instead of RGMII signals.

Hi Kkaibara,

thanks for your input, appreciate that! Yeah, I realised that SignalTap can not monitor DDIO outputs, it took a while!

I added PLL output shifted 90deg to run PHY.

I was actually finally able to see the packets coming to the PC and monitor them their with WireShark.

However, another issue came up - the packets have screwed headers time to time. So I am sending 400 bytes of data + 16 bytes of headers.

And headers have same data that Payload has.

I tried to monitor mentioned GMII signals in SignalTap but they also could not be gathered - marked as blue in SignalTap and stay always at zero.

Are you sure they can be monitored?

Any idea about screwed header data?

Hi aj26,

I think I have a similar problem that the problem you had. I am using DE2i-150 board, which has the same Marvell 88E1111 PHY as yours. I am using also the Altera Triple-Speed Ethernet (TSE) MegaCore MAC function.

For now, I just want to connect two boards and send frames from one board to another board through the Ethernet port.

I have used the tse_tutorial provided by Altera as the starting point. And I have initialized the registers following the instructions of the Triple Speed Ethernet Megacore manual when FIFO buffers are used.

Here it comes the problem. In the transmitter board, the TSE says that the frames have been transmitted (I checked the statistics), but in the receiver board nothing is received, i.e., the software program never enters the interruption subroutine.

When I connect the receiver board to a computer, frames are received with normality. Therefore, I understand the problem is the transmitter.

I tried to shift the PLL output 90º and it does not work either.

Which register initialization have you used? Could you share the lines?

Thank you very much in advance.

Arly

Hi Kkaibara,

I truly appreciate that, you helped a lot!

Followed your instructions, These signals are monitored successfully.

We also added timing constraints for Tx path according to

"AN 477: Designing RGMII Interfaces with FPGAs and HardCopy ASICs"

and now Transmitting data is stable.

Only concern we have left - monitor on PC (we use WireShark) receive more data than TSE core statistics counters show.

For example, aFramesTransmittedOk is 20.000 and WireShark somehow has 20.087.

Debugging at this point.

Regards,

Alex

Hi Arly,

1. Be advised that standard TSE MAC core works in Evaluation mode - works only for 1 hou after FPGA is programmed. To have full version, you need to purchase the license.

2. At this point, use PC to receive data. We've been using WireShark - I think it's free. You may have few issues:

a. source and destination MAC address. double check it.

b. Tx timing constraints. once I put the 90 degree shifted Pll output, we transmitted our first packets. However, relieble transmission was only with fully set constraints.

refer to "AN 477: Designing RGMII Interfaces with FPGAs and HardCopy ASICs"

c. Wireshark can receive packets even if your MAC addresses are corrupted (we had this issue), but the TSE will not receive it unless you configure in in Promiscuous mode (a bit in configuration register located at 0x02 address)

As for initialization, we used self-written core instead of NIOS processor. If your counter aFramesTransmittedOk is working ok and incrementing with every send packet - your core is TOTALLY FINE.

Pay attention to 1. the proper connection of PHY lines 2. Proper clock to PHY 3. Timing constraints

And you also can use SignalTap to see output activity on RGMII port - see the post of Kkaibara ahead - it helped a lot. Once you send a packet, you can see it appear on GMII output data lines (0..7)

Hope it helps.

Alex

--- Quote Start ---

Hi Arly,

1. Be advised that standard TSE MAC core works in Evaluation mode - works only for 1 hou after FPGA is programmed. To have full version, you need to purchase the license.

2. At this point, use PC to receive data. We've been using WireShark - I think it's free. You may have few issues:

a. source and destination MAC address. double check it.

b. Tx timing constraints. once I put the 90 degree shifted Pll output, we transmitted our first packets. However, relieble transmission was only with fully set constraints.

refer to "AN 477: Designing RGMII Interfaces with FPGAs and HardCopy ASICs"

c. Wireshark can receive packets even if your MAC addresses are corrupted (we had this issue), but the TSE will not receive it unless you configure in in Promiscuous mode (a bit in configuration register located at 0x02 address)

As for initialization, we used self-written core instead of NIOS processor. If your counter aFramesTransmittedOk is working ok and incrementing with every send packet - your core is TOTALLY FINE.

Pay attention to 1. the proper connection of PHY lines 2. Proper clock to PHY 3. Timing constraints

And you also can use SignalTap to see output activity on RGMII port - see the post of Kkaibara ahead - it helped a lot. Once you send a packet, you can see it appear on GMII output data lines (0..7)

Hope it helps.

Alex

--- Quote End ---

Hi Alex,

Your information was really helpful!!! I followed your advice and I went through the document "AN 477: Designing RGMII Interfaces with FPGAs and HardCopy ASICs" and I understood (among other things) why and which clock should have the 90 degree delay. Now, everything is working perfectly. I can switch on and switch off LEDs and control different components of one board from another board sending frames through the Ethernet port .

Thank you so so much!!!

Best regards,

Arly