FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

TSE ff_rx_data problem

Altera_Forum
Honored Contributor II
1,668 Views

The data I actually sent to the board is : 

 

0000 ff ff ff ff ff ff 00 1d 7d 75 c4 24 08 06 00 01 ........}u.$.... 

0010 08 00 06 04 00 01 00 1d 7d 75 c4 24 c0 a8 01 07 ........}u.$.... 

0020 00 00 00 00 00 00 c0 a8 01 64 .........d 

 

 

but as i observed from signaltap, what ff_rx_data received is "0000fdff ffffffff ffffffff ffff0f00 d01dd17d 577547c4 4c248208 60060000 10018008 ......"  

 

 

And ff_rx_mod is 00. ff is 32 bit width.
0 Kudos
18 Replies
Altera_Forum
Honored Contributor II
664 Views

What is the speed of the link and the interface between the TSE and the PHY? 

It looks like the TSE is expecting a DDR signal while the PHY is sending SDR.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

the link speed is 100M, and rx_clk is 25Mhz.  

ff_rx_clk is 125mhz (it saids ff_rx_clk is completely independent from rx_clk).  

 

what do you mean by the interface between TSE and PHY? Avalon-ST? 

 

here is parameters of the core:  

Core variation: 10/100/1000mb Ethernet MAC 

Interface: MII/RGMII
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

I think you are right Mr. Dai.  

 

RGMII Transmit Data. In RGMII mode,. RXD[3:0] are used as RD[3:0]. In RGMII mode, RXD[3:0] run at double data rate with bits [3:0] presented on the rising edge of RX_CLK, and bits[7:4] presented on the falling edge of RX_CLK. In this mode, RXD[7:4] are ignored. 

 

In RGMII 10/100BASE-T mdoes, the transmit data nibble is presented on RXD[3:0] on the rising edge of RX_CLK. 

 

As said on ds, now the PHY is operating in 100BASE-T mode ( I don't know why, because i've set set_1000 to 1). data is presented on rising edge of clk.  

 

But what is don't understand is that when it's in RGMII giga mode. though RXD[3:0] is running at double data rate, but only bits[3:0] are presented on rising edge, and bits[7:4] which presented on falling edge are ignored. Is that means either in giga mode or 10/100 base-t mode, we can only fetch data on rising edge? If so, how come TSE would think that the PHY will give out DDR signal?  

 

I am confused, please light me.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Sorry, my misunderstanding.  

 

So the PHY is now running in 100base-t mode, and TSE is running in giga mode. 

I guess have to set ETH_SPEED and set_1000 back to false, but then should I still connect PHY rxd to rgmii_in or to m_rx_d ?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Problem solved, Thanks Dai. 

 

But I still got one problem.  

 

See the attached jpg. the data I sent from PC this time is: 

 

0000 ff ff ff ff ff ff 00 0b 2f 35 17 41 08 06 00 01 ........ /5.A.... 

0010 08 00 06 04 00 01 00 0b 2f 35 17 41 0a 08 00 03 ........ /5.A.... 

0020 00 00 00 00 00 00 0a 08 00 64 ........ .d  

 

the received data is as shown in the jpeg file. 

 

There are 2 bytes of zero ahead first byte of sent data "ff" and 17 bytes (ff_rx_mod=1h) of zero following the last 32bits "0a 08 00 64".  

 

I guess the first 2 bytes of zero would be preamble or sfd, but what is the last 17 bytes of zeros? and where is the CRC field?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

You figured out the solution before I could answer ;) 

The PHY uses auto-negotiation to find out the fastest speed it can use on the link. For some reason it decided that it can only go in 100Base-T. The TSE mode isn't automatically set according to the PHY mode, it is up to you to read the PHY status through the MDIO interface and configure the TSE in gigabit or 100/10 Mbit mode. 

The first two null bytes could come from the fact that you enabled the "Align packet headers to 32-bit boundaries (applicable to 32-bit FIFO only)" option when configuring the TSE core. When this option is enabled (and I think it is enabled by default) the core adds two 0 bytes, so that the header is 16 bytes long and the packet data is aligned on a 32-bit boundary. It makes life easier for the driver. 

I don't know why you have those bytes at the end... The checksum should be the last 4 bytes. Do you have any error reported? Can you have a look at the rx_err signal? Did you enable the internal CRC module in the TSE core?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Hi Dai.  

 

The first two bytes of "O" is indeed because of the alignment, and the those bytes of "O" s at the end is padding, to fill up the minimum length of the frame. 

 

you told me to check the rx_err signal, unfortunately my rx_err pin has been buried under the 88e1111 fbga and left floated. I thought rx_err was no use in RGMII mode. But now I am in the so called 88e1111 Modified MII mode, I really don't know how to check the rx_err in such case, I haven't found the answer from datasheet. But since now the ff_rx_data is correct, I can just ignore this problem.  

----------------------------------------------------- 

 

Now I've been trying to send data to PC for two days, and never worked it out.  

The attached jpeg is PHY tx_en & txd[3:0] signals. 

the preamble is 7 bytes 0x55 , sfd is 0x5d. (Note: I've never put preamble,sfd and crc data in to the tx fifo, I don't know weather they are generated by TSE or PHY.)  

Then followed by 60 bytes of 0xa5, and ends with 4 bytes of CRC.  

 

The total packet length is 64 bytes, not including preamble and sdf. 

 

All seems to me are correct, but I still can't sniff the packet from PC.  

 

And about enabling the internal CRC module of TSE core, I can't find this option in the core parameters, I am using TSE core v7.2.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

I meant the rx_err signal on the avalon bus. It is a 6-bit wide vector that indicates various problems detected when receiving the frame. 

For the CRC check it is in fact enabled in the configuration registers, not in the megawizard, sorry. 

Now from the packet that isn't received by the PC there can be multiple reasons. Does the LED on the PC network port blink? If possible, try to disable any hardware acceleretion from the PC's network drivers. Some chipsets automatically discard mal formed packets, or packets with wrong CRC. 

How is the tx_err signal cabled to your PHY chip?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Hi Dai, Thanks for the useful hint.  

 

about RX: 

the rx_err avalon bus is ok, no problem.  

yes, CRC check in enabled.  

rx seems working alright.  

 

about TX: 

1. the LED on the PC network port is blinking at the same beat of my PHY tx led. the board sends one packet to PC every second.  

 

2. I can't find any hardware acceleration option of the PC's driver. The PC is using Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC.  

I don't know if there is any problem of my tx packet, but I think the CRC of every tx packet is correct. I've manually calculated the CRC and compared with the one TSE appended, it's a match.  

 

3. the tx_err pin of 88e1111 is tied to ground.  

 

I've also read out the "aFramesTransmittedOK" and "ifOutErrors" regs of TSE after every TX. And "aFramesTransmittedOK" accumulates as tx goes. "ifOutErrors" is keeping zero. It seems the TSE consider all packets are transmitted OK.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

If you have Wireshark on your PC you can access the interface statistics on the other side too. 

Go into the capture menu > Interfaces, and next to the interface you use, click on the "details" button and go to the statistics tab. 

I think that if the network card or driver drops the packet, you should have at least one error counter that increases.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

hi Dai,  

 

I am actually using this thing to sniff packet, but I didn't notice there is a statistics funtion. Thanks.  

 

I've checked the statistics, now it seems all packets the board has sent out were reported as receive error & CRC/FCS error by the network card driver.  

 

Now I'm trying to figure out what causes this, if I've any progress, i'll let you know.
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

You could have a look at the MII signals to see what is sent by the TSE core to the PHY. Did you remember to add the two 0 bytes before the header, if the 32-bit alignment option is still active? Did you try packets of different lengths? (especially one big enough so that the TSE doesn't add padding)

0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Hi Dai, 

 

Check the MII signals, you mean tx_en and txd[3:0] PHY signals? 

 

I've checked the tx_en and txd[3:0], all correct, identical to the data I've wrote to the ff. (as the signaltap snapshots I've posted early). 

I found that one old copy of my project could randomly sent out data to PC. By random I means PC was not receiving packet every second as expected, I've to wait several seconds to several minutes for the PC to receive one packet.  

 

I checked the code, and compared with the current project files. The only difference is that I've added a 32bit custom CRC data to the and of the packet, I didn't notice that I've configured TSE to add CRC. And the CRC I've added is also incorrect, so it's just a meaningless 4byte random data. I tried to remove the CRC, and filled it up with a constant 4byte data. The PC never receive any packet again.  

 

I am pretty sure it's because the random data of the packet makes the old project file works. Then I added 3bytes of tickcount data to the end of the packet, it turned out to be interesting.  

 

The 3bytes of tickcount data goes in this pattern, 0,1,2 / 3,4,5 / 6,7,8/ 9,a,b / c,d,e / f, 10, 11/ ... 

 

And the following dump data is what PC received.  

 

As you can see, when the counter goes to "38,39,3a" / "5c,5d,5e" / "94,95,96" / "f0,f1,f2", PC received the packet.  

 

 

packet1: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 38 39 3a 00 00 00 ........ .l89:... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet2: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 5c 5d 5e 00 00 00 ........ .l\]^... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet3: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 94 95 96 00 00 00 ........ .l...... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet3: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c f0 f1 f2 00 00 00 ........ .l...... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet4: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 38 39 3a 00 00 00 ........ .l89:... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet5: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 5c 5d 5e 00 00 00 ........ .l\]^... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet6: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c 94 95 96 00 00 00 ........ .l...... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

packet7: 

0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 

0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 

0020 00 00 00 00 00 00 c0 a8 01 6c f0 f1 f2 00 00 00 ........ .l...... 

0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....  

repeat ...... 

 

And soon I replaced the 3 bytes of tickcount data with constant data "38 39 3a", now PC receives data every second.  

 

I guess even if I repaced the 3 bytes of tickcount data to 2 bytes or 1 byte tickcount data. I would still found some specific value are working, and the others won't.  

 

Weird isn't it?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Correct me if I'm wrong, but it seems that the packets you actually receive are those with a CRC of 00 00 00 00. 

It seems that there is something wrong with the CRC generation. Except if the CRC is romeved by Wireshark or the network driver?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

yes, I guess CRC is removed by network driver, or maybe by the PHY of the network card. I always want to catch the CRC from PC, but the dumped data is only 60 Bytes, the 4 bytes of CRC is removed. those zeroes are paddings.

0 Kudos
Altera_Forum
Honored Contributor II
664 Views

In case it's the problem of the TSE CRC generation. I added padding & calculated CRC by myself, and the problem still the same.

0 Kudos
Altera_Forum
Honored Contributor II
664 Views

Hi 

 

Has there been any resolution to this problem? I'm experiencing the exact same issues. I can tx data, signal tap shows correct data going into ff_rx_data, and the tx LED on the dev board blinks in concert with the LED on the network port of the receiving com. 

 

The Wireshark stat details show a increase in dropped packets due to CRC/FCS error everytime I send a packet over. 

 

Anyone found a solution to this?
0 Kudos
Altera_Forum
Honored Contributor II
664 Views

 

--- Quote Start ---  

The data I actually sent to the board is : 

 

0000 ff ff ff ff ff ff 00 1d 7d 75 c4 24 08 06 00 01 ........}u.$.... 

0010 08 00 06 04 00 01 00 1d 7d 75 c4 24 c0 a8 01 07 ........}u.$.... 

0020 00 00 00 00 00 00 c0 a8 01 64 .........d 

 

 

but as i observed from signaltap, what ff_rx_data received is "0000fdff ffffffff ffffffff ffff0f00 d01dd17d 577547c4 4c248208 60060000 10018008 ......"  

 

 

And ff_rx_mod is 00. ff is 32 bit width. 

--- Quote End ---  

 

 

I have the same problem. Can you tell me how you solved the problem?
0 Kudos
Reply