01-02-2020 07:40 PM
I have JESD204B RX IP in my Artix 7 design. The link configuration and Artix 7 requirements need me to keep the coreclk and refclk separate. In the Basic Generic Clocking Schemes of the PG066 October 4, 2017, I see that separating the coreclk and refclk this way allows us to make the refclk independent of the coreclk.
How is the deterministic latency maintained if the coreclk is separate from the recovered clock? My confusion stems from the fact that in JESD204B Subclass 2, the SYNC~ signal from the RX core is provided to the transmitter. I am assuming that the SYNC~ is generated synchronous to the coreclk from the core. But according tot the JESD204B protocol, the SYNC~ is generated after code group synchronization occurs, this should occur in the recovered clock domain. Then isn't there an uncertainty to go from the recovered clock to the coreclk domain?
Can someone please shed light on how the uncertainty in the clock domain crossings is handled in the JESD204B IP?
01-07-2020 02:22 AM - edited 01-07-2020 02:23 AM
Hi @shparekh ,
Please refer PG066 page no 59 for understanding the functionality of deterministic latency .
01-07-2020 02:36 AM
01-13-2020 01:28 PM
Can we please dig deeper? I am looking at the gtp xcvr guide pg146 fig 4-18
The guide says - One of these clocks can be selected -
Which clock is selected in the JESD204B RX to drive to the fabric? JESD204B sc2 deterministic latency relies on the align characters, so it needs to operate in the PCS block of the transceivers. So what is the relationship between the recovered clk in the xcvr block and the coreclk and refclk of the JESD ip?
01-15-2020 09:59 PM
Hi @shparekh ,
RXOUTCLKPMA clock is used as a RXOUTCLK.
01-21-2020 10:22 PM
If you want to get a deterministic latency, you need to follow the clock scheme Figure 3‐1 or Figure 3‐2 on PG066 October 4, 2017. The other clock scheme can not ensure the deterministic latency.