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

PHY Transmission - Arria II GX

Altera_Forum
Honored Contributor II
911 Views

I am attempting to send a packet over the PHY (Marvell 88E1111) on my Arria II GX board. I followed instructions on how to generate the correct signals. This is done through a large state machine in which I wait 100000000 clock pulses between sending packets then I put the TX_CONTROL signal high and start sending 4 bits over the RGMII_OUT bus. I first start with the preamble and then the contents of the packets that I would like to send. This is done until the end of the packet is reached where TX_CONTROL is set low and the state machine is paused for another 10000000 clock cycles. I run the state machine at 250 MHz so that 4 bit can be send at both the positive and negative edge of the 125 MHz TX_CLK.  

 

With this state machine I can get the TX light on the PHY to turn on but when I used wireshark on the server attached to it I see no packets coming over the wire. The hexadecimal values being sent over the RGMII_OUT bus are as follows: 

 

555555555555555D 

ffffffff 

ffffb8ac 

6faaa2ed 

08004500 

006e12fc 

00008011 

035c0a0a 

1a1effff 

ffffe490 

04bb005a 

bbfd0103 

80647070 

3a2f2f2f 

76646361 

66687672 

36327274 

336a6963 

6d707832 

6e686e75 

736b7a35 

68736d7a 

75793470 

75363200 

bc09c001 

1e1a0a0a 

2e00da8f 

13693134 

2c312c30 

2c343736 

31000101 

1e1a0a0a 

1e1b0b0b 

 

Would anyone have an idea as to why this would either not be acceptable to send to the PHY or why the server would disregard this packet so I would not be able to see it in wire shark? 

 

Has anyone else done any work with the Arria II GX transceiver that could lead me in the right direct as to how I can send packet over the PHY? 

 

- Thank you
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
251 Views

Some PC network cards automatically disregard malformed packets or packets with invalid CRCs, so if you have a problem on the packet it could explain why you don't see it in Wireshark. Have a look at the driver properties and see if you can disable any hardware acceleration, CRC/cheksum calculations or error check. Some drivers also show error counters. 

You could also try a loopback test, either by changing a register in the PHY chip or by physically connecting the RX and TX pairs on the network connector. Then you can have a look at the RX signals and check that what you receive is exactly what you sent. 

 

Are you sure that the PHY negotiated correctly a gigabit connection? Are you using a DDR I/O block? In that case are you sure that you use correctly the high and low inputs and are sending the 4-bit words in the right order? Did you properly constrain the RGMII interface and does your design meet all timing requirements?
0 Kudos
Altera_Forum
Honored Contributor II
251 Views

I looked into this problem further. 

 

 

--- Quote Start ---  

Some PC network cards automatically disregard malformed packets or packets with invalid CRCs, so if you have a problem on the packet it could explain why you don't see it in Wireshark. Have a look at the driver properties and see if you can disable any hardware acceleration, CRC/cheksum calculations or error check. Some drivers also show error counters. 

--- Quote End ---  

 

 

Viewing netstat through the command console I found that when the Arria II GX development board is transmitting the discard count increases at the same rate of transmission so the packets must be malformed when they get to the computer somehow. I cannot see anyway to turn off CRC/checksum or hardware acceleration but I am reading the reference manual. The NIC is a Broadcom HP NC373i. 

 

 

--- Quote Start ---  

You could also try a loopback test, either by changing a register in the PHY chip or by physically connecting the RX and TX pairs on the network connector. Then you can have a look at the RX signals and check that what you receive is exactly what you sent. 

--- Quote End ---  

 

 

I have done a loop back test in hardware where I send the exact same bit sequence from input to the output but this programs packets are also recorded as discards. 

 

 

--- Quote Start ---  

Are you sure that the PHY negotiated correctly a gigabit connection? Are you using a DDR I/O block? In that case are you sure that you use correctly the high and low inputs and are sending the 4-bit words in the right order? Did you properly constrain the RGMII interface and does your design meet all timing requirements? 

--- Quote End ---  

 

 

In terms of the PHY negotiating correctly the Gigabit light turns on which I assumed indicated correct negotiation although I could be wrong. 

 

I'm not sure what you mean by a DDR I/O block but I did try the altddio_out megafunction described in the timing in the altera an477 documentation. 

 

The megafunction never worked so I created the necessary timing by hand using PLL and state machine. These are the timing requirements I followed for the current program I am testing. 

 

I have tried the bit order in both ways for a sample packet but have gotten rx crc errors in both cases. Does the bit order matter if I am not using a DDR I/O block?
0 Kudos
Altera_Forum
Honored Contributor II
251 Views

What exactly didn't work in the ddr i/o megafunction? Maybe we should start by looking at that. 

Did you put timing constrains on the RGMII interface? Does the design meet all timing requirements? he PHY chip can be configured with a 90 degrees clock shift to read/write data at the clock center instead of the edges, by using a special MDIO register.
0 Kudos
Altera_Forum
Honored Contributor II
251 Views

I followed the RGMII interface specified by Altera more closely and I have a receive and transmit unit working. The ALTDDIO_IN/OUT work very well for this. Also the timing of the TX clock was still shift by 90 degrees.  

 

The only thing that remains is how to make a better basic receive interface? I found that using different equipment preambles vary and even just checking for the preamble itself doesn't work 100% of the time. Do you know of any basic receiver that work very well besides the Altera TSE MAC?
0 Kudos
Altera_Forum
Honored Contributor II
251 Views

The preamble length can vary, depending on the time the PHY needs to lock on the incoming clock, but it should always finish with 5D. If it doesn't, you may still have a problem with your RGMII input, possibly a timing problem.

0 Kudos
Reply