Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,359 Views

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

Hi everyone, 

 

We are using MAX 10 FPGA development kit that supports 10/100/1000 base-T Ethernet using an external Marvell 88E1111 PHY and Altera Triple-Speed Ethernet MegaCore MAC function. 

 

TSE core v15.0 configuration is as follows:  

10/100/1000Mb Ethernet MAC, Gigabit mode, RGMII output, Internal FIFO 2048 x 8bits, with statistics counters, with local loopback. 

 

We are using self-written FSM with Avalon interface to configure the TSE and send data to Tx FIFO. 

 

These steps works perfectly in functional simulation:  

- configuring TSE registers,  

- set in gigabit mode (EthMode is going '1') 

- read registers from TSE to verify data (Tx ena = 1),  

- transmit data to TSE Tx FIFO,  

- see RGMII output data, see statistics counters working ok. 

 

However, then using SignalTap the TX RGMII lines (TX RGMII data and TX RGMII control) are always zero. 

We verified that configuration registers are correct, Tx FIFO flags are correct. 

 

RGMII output has no data but counter aFramesTransmittedOk is increasing with every transaction, i.e. it thinks that data was transmitted. 

Error counters ifOutErrors and etherStatsDropEvents are zero. 

 

Loopback also does not work since it takes RGMII output data but these lines have no data.  

 

TX clk is 125Mhz and is ok. 

Tried with/without connected ethernet cable, tried disconnecting the TSE from PHY, Tried with/without local loopback. 

 

Any feedback and suggestions are highly appreciated 

 

Regards, 

Alex
Tags (1)
0 Kudos
7 Replies
Altera_Forum
Honored Contributor I
114 Views

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.
Altera_Forum
Honored Contributor I
114 Views

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?
Altera_Forum
Honored Contributor I
114 Views

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
Altera_Forum
Honored Contributor I
114 Views

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
Altera_Forum
Honored Contributor I
114 Views

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
Altera_Forum
Honored Contributor I
114 Views

Congrats Alex. You are almost there.

Altera_Forum
Honored Contributor I
114 Views

 

--- 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
Reply