Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Novice
95 Views

Triple speed Ethernet & SGMII

Jump to solution

Hello,

I experience a problem with the triple speed ethernet in SGMII mode (10/100/1000Mb Ethernet MAC with 1000BASE-X/SGMIIPCS in a Cyclone 10GX device).

I configured both external PHY device (Texas Instruments chip) and Intel PCS. All seems to be ok: leds on my switch are on, external PHY status register indicates that the link is up, PCS status register  gives good result (@1=0xAD: link up).

When looking signals coming out TSE with SignalTap (TSE sould receive an ARP packet in 100MBits/s Ethernet mode), I can't explain the results:

pb_ethernet.jpg

For example:

  • I don't understand the first 0xD5
  • Only 8 LSB bits seem to be OK (remaining 24bits are just a copy)
  • broadcast address is 15bytes long (instead of 6)
  • First byte of my PC address if 3bytes long (instead of 1)

It is the first time I use SGMII mode, and I am a bit confused (I previously use RGMII mode)...

I checked my SignalTap clock, my external reference clock [...], can you assist me in resolving this problem?

Many thanks!

0 Kudos

Accepted Solutions
Highlighted
Moderator
74 Views

Hi,


The extra 0xD5 value looks like a start frame delimiter (SFD) packet that byright TSE MAC should removed. User should see destination address as first packet coming our from TSE RX path to Avalon ST interface.


You can refer to TSE user guide doc (page 195, Figure 82 : MAC Ethernet Frame Format" for detail.


I think you need to slowly trace back the RX path to see where does this extra 0xD5 come from

  • Eg : External RX PHY -> TBI -> TSE PCS SGMII -> GMII/MII -> TSE MAC -> Avalon ST bus
  • For a start, maybe you can add in MII interface bus (since you are running 100M) into signal_tap to check on the receive data first. Refer to (page 107, figure 46) to check out MAC interface signals list that contains the MII interface bus
  • This helps to isolate whether TSE MAC is receiving correct Rx data in the first place or not


You can also generate TSE simulation example design project using your existing TSE IP setting. This will give you extra flexibility to look into TSE IP interface signals to understand the expected behaviour


Thanks.


Regards,

dlim


View solution in original post

0 Kudos
3 Replies
Highlighted
Moderator
75 Views

Hi,


The extra 0xD5 value looks like a start frame delimiter (SFD) packet that byright TSE MAC should removed. User should see destination address as first packet coming our from TSE RX path to Avalon ST interface.


You can refer to TSE user guide doc (page 195, Figure 82 : MAC Ethernet Frame Format" for detail.


I think you need to slowly trace back the RX path to see where does this extra 0xD5 come from

  • Eg : External RX PHY -> TBI -> TSE PCS SGMII -> GMII/MII -> TSE MAC -> Avalon ST bus
  • For a start, maybe you can add in MII interface bus (since you are running 100M) into signal_tap to check on the receive data first. Refer to (page 107, figure 46) to check out MAC interface signals list that contains the MII interface bus
  • This helps to isolate whether TSE MAC is receiving correct Rx data in the first place or not


You can also generate TSE simulation example design project using your existing TSE IP setting. This will give you extra flexibility to look into TSE IP interface signals to understand the expected behaviour


Thanks.


Regards,

dlim


View solution in original post

0 Kudos
Highlighted
Novice
58 Views

Sorry for the delay...

Thank you @Deshi_Intel for the reply.

It's (partly) solved...

Ethernet scheme was the following:

RJ45 <-> External PHY <-- TBI --> PCS SGMII <-- GMII/MII --> MAC <-- Avalon --> Own code

RJ45 and external PHY previously operate at 100M while others devices (PCS and MAC) operate at 1G.

It seems that the PHY was not able to perform 100M to 1G translation. When I connect all four pairs of the PHY to the RJ45, it works.

So, it's not totally satisfying (I think that I must configure PHY, PCS and MAC at the same speed and not in autonegotiate mode and I think that I've got a clock problem too) but I can move forward on my own now.

Many thanks!

 

 

0 Kudos
Highlighted
Moderator
54 Views

okok, good to know you are making progress.


Alright, I am setting this case to closure.


Feel free to file new forum post if you still need help in future.


Thanks.


Regards,

dlim


0 Kudos