cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
chsdkj
Explorer
Explorer
5,152 Views
Registered: ‎07-10-2013

GTY Xcvr RX OOB Functionality

In an application utilizing a proprietary serial protocol with a dararate of 10/20GPs, OOB (signal-squelch) can happen.  A quickly-responding, no-nonsense indication is needed from the xcvr RX of whether OOB is occurring or not.  (Here, "no-nonsense" means "independent of and unrelated to whatever current data is being received".) 

 

UG578 (v1.1) indicates in Table 4-6 on p.176 that the GTY xcvr RX output signal RXELECIDLE "...indicates the status of OOB signal detection and is only valid for PCIe, SATA/SAS, and protocols/applications using OOB."

 

Such a description is much simpler and much more straightforward than, for example, the description of the same signal output for 7-Series GTH xcvr RX, with UG476 (v1.11.1) discussing in Table 4-9 on p.180-181 how the signal is to be interpreted for several specific protocols.  It seems that other than for PCIe and SATA, OOB RX is actually not really supported for 7-Series xcvrs, and that RXELECIDLE can typically not be relied upon to provide any sort of "no-nonsense" OOB RX indication generally.

 

Please clarify whether with the GTY xcvr RXELECIDLE output, the RX OOB detection circuitry has had its act cleaned up (so to speak) compared with 7-Series xcvrs, or whether it in reality functions basically the same as for previous architectures, and so should not be relied upon to provide a simple, clean, data-independent OOB indication, inspite of the description provided by UG578.

 

 

Tags (4)
0 Kudos
Reply
1 Reply
venkata
Moderator
Moderator
4,833 Views
Registered: ‎02-16-2010

As of now, there is no errata item related to RXELECIDLE as you mentioned.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Reply