TSE ff_rx_data problem

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.

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

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.

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 ?

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?

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?

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.

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?

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.

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.