Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
917 Views

Data error using TSE at 1Gbps with SERDES in Cyclone V

I have instantiated the TSE using a 1000BaseX interface and the SERDES in the Cyclone V. the fabric interface is GMII. I get errors at the beginning of each received packet. When I send packets generated in the fabric and loopback the optical ethernet interface, the first receive byte of every packet is overwritten with 0x55. I built a 500MHz data collection element in the fabric (SignalTap does not work at 500MHz) to look for a potential timing issue, but the first byte is really 0x55 instead of the 0x01 I am sending. Packet contents are just a counter. The packet length is correct. I have attached 4 images of the logic capture output showing the start and end of the transmit and receive packets. The transmit data and transmit enable are the top two traces. The bottom 2 traces are the receive data and receive data valid. 

 

Even more strange: When I connect an Ethernet test set to the optical port, the fabric receives six bytes of 0x55 prepended to the packet, and the remainder of the packet is complete. That is, the packet is extended by 6 octets at the start. 

 

Anyone have an idea what could cause this? When the TSE is configured for 1000BaseX and GXB (SERDES) interface, there are not many options to toggle in the IP. 

 

Thank you
0 Kudos
7 Replies
Highlighted
Valued Contributor III
10 Views

0x55 is the token used in the ethernet frame preamble. From your description it sounds like you are looking at data before it gets to the TSE where the preamble would have been processed? 

 

The overwritten first byte in your looped back data could simply be wrong assertion of the valid qualifier on the data that you transmitted. i.e. the first byte you transmitted on your transmit side was your "0x02" byte, not your 0x01 byte. You could confirm this by looking at the data you receive from an external source - if the packet is correct except for the leading preamble bytes, examine your transmit path. 

 

Edit: what does the Avalon-ST output of the TSE look like in both your looped back and externally generated data ?
0 Kudos
Highlighted
Valued Contributor III
10 Views

Edit: what does the Avalon-ST output of the TSE look like in both your looped back and externally generated data ? 

--- Quote End ---  

 

 

I agree the 0x55 looks like the preamble. The transmit data looks correct as you can see from the "Start of packet Tx" image attached in the original post.  

I have not attempted to use the Avalon-ST interface, only the GMII. 

I have attached an image showing the reception of a packet from an Ethernet test set. The top trace is rcv data valid. the sample rate is 500MHz for the 125MHz bus.The value 0x55 is present for 7 clock intervals followed by one octet of 0xD5. This is followed by the correct destination address: 00-18-63-00-BC-28 

This packet has 8 octets prepended to the packet. Something is wrong with the receiver. It seems to be presenting the preamble and start of packet delimter (SPD) octets as belonging to the packet. Is there a way to correct this? I can't imagine an option which would allow it. 

 

Once I have the receiver fixed, there is likely to be some other issue with the transmitter side. 

regards
0 Kudos
Highlighted
Valued Contributor III
10 Views

I went back to the parameters on the TSE IP. When core variation is set to "1000Base-X/SGMII PCS only", the only available interface is GMII. The Avalon-ST interface is not an option.

0 Kudos
Highlighted
Valued Contributor III
10 Views

 

--- Quote Start ---  

 

I have not attempted to use the Avalon-ST interface, only the GMII. 

--- Quote End ---  

 

Sorry, I misunderstood what you were doing.  

 

In ug_ethernet.pdf, I think Figure 1-4 is what you're doing but I think you're expecting the behavior from Figure 1-3 ? 

 

With GMII, you need to transmit the preamble and discard it when received. With Avalon-ST and MAC, the MAC does that for you. 

 

See Table 6-39 gmii_rx_dv description and how it matches your trace.
0 Kudos
Highlighted
Valued Contributor III
10 Views

OK, that is exceptionally strange, but I will work on it. 

My user's guide only goes up to table 6-19. The gm_rx_dv signal is described in table 7-10 and it does say data valid includes the preamble and SPD. That is not how standard GMII works. 

The gm_tx_en signal description does not mention the requirement for a preamble. I assume insertion of preamble and SPD is needed.
0 Kudos
Highlighted
Valued Contributor III
10 Views

 

--- Quote Start ---  

OK, that is exceptionally strange, but I will work on it. 

My user's guide only goes up to table 6-19. The gm_rx_dv signal is described in table 7-10 and it does say data valid includes the preamble and SPD. 

--- Quote End ---  

 

The figure and tables I referred to are in the current copy you get right now if you go to https://www.altera.com/en_us/pdfs/literature/ug/ug_ethernet.pdf 

 

--- Quote Start ---  

 

That is not how standard GMII works. 

 

--- Quote End ---  

 

Well, ignoring Altera and going straight for the horses mouth, IEEE 802.3-2012 Clause 35.2.3  

35.2.3 GMII data stream Packets transmitted through the GMII shall be transferred within the data stream shown in Figure 35–17. <inter-frame><preamble><sfd><data><efd><extend> Figure 35–17—GMII data stream  

 

A GMII PHY chip might support preamble suppression, but the Altera TSE doesn't (search ug_ethernet.pdf for MF_PREAMBLE_SUPPRESSION).
0 Kudos
Highlighted
Valued Contributor III
10 Views

You are entirely correct. Thank you. This is a revelation to me as to how GMII works. I appreciate it.

0 Kudos