We are using a TSE IP on a Cyclone V GT, configured as follows:
Core variation: 10/100 / 100Mb Ethernet MAC with 1000BASE-X / SGMII PCS
Interface: MII / GMII
Transceiver Type: GXB
This FPGA is on a proprietary PCB along with a KSZ9897S Microchip Ethernet switch. It is connected to port 7 of this switch (which is exclusively an SGMII interface).
TSE IP works as expected at 1Gbps. However, it is desirable for us to lock the operation at 100 Mbps. Based on what we interpreted from the user guide, we have been trying to configure the IP, however we've had no sucess changing the interface speed from 1Gbps to 100Mbps, no matter what we do.
Even disabling auto-negotiation and setting the interface speed to 100Mbps (via the “IF_Mode Register” register, PCS offset 0x14) the speed does not seem to change in the status registers (via “PCS Control Register”, offset 0x00). Such behavior can be confirmed because the interface continues operating correctly at 1 Gbps.
We've already tried different approaches. We have even tried to force the "set_1000" internal signal to '0' in the RTL at the top of the IP to see if it would operate at 100Mbps, but without success. Although the synthesis was performed without errors, Ethernet traffic does not pass in this scenario.
Could anybody confirm if it is possible to force IP operation in SGMII at 100 Mbps? If so, what is the correct procedure to achieve it?
Thank you in advance.
You more or less are doing the right thing here and looking at the correct register.
Anyway, let's look at your issue together.
- Typically 3 main setting that will affect the issue are speed, duplex mode and auto-negotiation
- Pls check to ensure you set similar setting on both MAC, PHY and for both transmit device and receiving device
- Having said so, on your customer board. Is there any external PHY chip between FPGA (TSE MAC + PHY) and your network switch device ? If yes, pls confirm the setting on the external PHY chip side
For TSE MAC and PHY setting (I have uploaded the relevant register setting screenshot)
- on MAC side - command_config reg, eth_speed = 0
- on PHY side - control reg read back, speed_selection = 10 ? Still stay at 1G, not 100Mbps ?
- On PHY side - if mode reg
- SGMII_ENA = 1
- USE_SGMII_AN = 0
- SGMII_SPEED = 01
- SGMII_DUPLEX = 0 (assume you are using full duplex)
Thank you for your quick reply.
We don't have a PHY between the switch and the FPGA on our card. I would like to point out that we have no reason to suspect that there is an error in the configuration of the switch so far, since when configuring the interface speed, its status registers reflect this promptly and, as expected, traffic on the interface stops immediately.
Our suspicion falls on the TSE-Mac since even setting the rate of 100 Mbps in the registers, we did not observe any change in the behavior of the interface (both in the registers and in the bus itself).
As you can see in the attached file, the IP configuration is as suggested:
- Command_config register (dword offset 0x02) - ETH_SPEED (bit3) = 0;
- PCS IF_Mode register (dword offset 0x14) - SGMII_SPEED (bit2, 3) = 0 1 (100Mbps);
- PCS Control register (dword offset 0x00) - SPEED_SELECTION (bit6, 13) = 1 0 (1Gbps).
Please let us know if we could provide any further information.
Couple suggestion for you to try out :
- To to confirm with you again if you have providing the correct clocking for different data rate switching in your TSE design ?
- 125MHz (1G), 25MHz (100M), 2.5MHz (10M)
- Try out TSE MAC local loopback to isolate external PHY factor
- referring to chapter 4.1.9 MAC local loopback
- Test out the TSE example design simulation instead of hardware design
- You should be able to generate TSE simulation example deign to play around with the sim test bench
- Lastly, I found out there are another 2 TSE SGMII hardware test example design from AN647
- Although the example design belongs to Arria 10 and Startix V FPGA but the TSE IP is soft IP and reused over different FPGA device family
- So, you still can refer to it as reference.
I have not hear back from you for quite sometime.
Hopefully my earlier debug suggestion is useful to you or perhaps you have made progress in your issue debug.
Anyway, I am setting this case to closure. Feel free to file new post if you still need further assistance on issue debug.