Regarding the latency of ADIN6310/ADIN3310

Hello,

thanks for your message and questions. 

1. Can you please clarify the question, do you mean "HSR"? 

In terms of cut-through the switch is inherently Cut-Through. In basic switching operation, the cut-through is configurable on a per-port, per-queue basis. User has a choice of Store & Forward or Cut-Through (default)
Switch will fall back to Store & Forward if port is already busy transmitting. Once enough of the frame has arrived to determine where to send, the frame may begin egress
Cut-through operation is only possible when ports are same speed or faster to slower [1000M to 100M].
Cut-through operation is not possible from slower speed port to faster speed [100M to 1000M]

If your customer is using HSR (high availability seamless redundancy), then cut-through is possible for traffic across the ring ports, so between the HSR ports Port A <-> Port B. Cut-through is not possible from the LRE/Host to the ring, as the switch hardware needs to know the size of the frame in order to provide the correct LSDU information into the HSR tag. Therefore traffic from LRE to the ring ports will always be sent store and forward. 

2. There are RGMII and SGMII latency values specified in the datasheet spec table Can you please clarify your question? 

Please provide additional information on the use case and requirements in terms of latency and we can advise further. 

best regards,

Catherine. 

Thank you for contacting us.
"HRS" was a typo; as you pointed out, it should be "HSR".
Regarding Q2:
The datasheet lists "RGMII Bridge Latency" and "SGMII PHY Latency," but not "RGMII PHY Latency."

Is my understanding correct when estimating total latency as follows?
(1) In the case of RGMII output:
I considered RGMII Bridge Latency to be the internal conversion delay between MAC and RGMII (different from Switch Latency).
The total latency should be estimated by adding the RGMII Bridge Latency and the delay of the external PHY.
(2) In the case of SGMII output:
Consider not only RGMII Bridge Latency but also SGMII PHY Latency. Estimate the total latency by adding the internal conversion delay between MAC  RGMII  SGMII PHY Latency and the delay of the external PHY.

Hello,

thanks for clarification. 

1. The RGMII Bridge latency is the latency from RGMII port to another RGMII port. The total latency of the hop depends on the Tx/Rx latency of the external PHY used. 

In the ADI evaluation boards, we use ADIN1300 PHY for Gb links, the latency of that PHY is documented in the datasheet. We do also take opportunity to reduce the RX latency of the PHY. During the init routine, the switch will check with the PHY what cable length it sees and the MSE mean squared error (signal quality on the diff pairs) and can make an assessment to reduce the RX latency and overall latency. See picture below for detail. 

2. In the SGMII case, the switch has integrated SGMII/Serdes block, it connects directly to the RGMII interface. When considering the latency of the switch you need to consider both the RGMII latency and the SGMII numbers to understand what the switch contributes. If there is some external PHY (e.g. copper SFP module), the latency contributed from that would need to be added for overall latency.