- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page