Question on PTM_RX_DELAY parameter
johna-eximiusdesign opened this issue · comments
Hey Michael,
Earlier today (Thursday) you confirmed that the intent for the pl_ptm_rx_delay[7:0] signal is to be the PTM_RX_DELAY parameter expressed in nanoseconds, where the clock to ns can be gleaned from the LPIF_CLOCK_RATE parameter.
In Gen2 Full rate, this can be in increments of 0.5ns. How do you want us to express that? Round up / down? Or can we assume PTM_RX_DELAY will always be even if we are in Gen2 Full rate?
Related, since pl_ptm_rx_delay[7:0] is 8 bits, that limits the value of PTM_RX_DELAY to 127, 255, or 511 or smaller for Quarter, Half, or Full in Gen2 (and 127, 255 for Half, Full in Gen1). Am I understanding that correctly?
Thanks,
John
Rounding should be fine. Please round down as that is simpler and this is not intended to be perfectly representative signal. The limits are not making sense to me though. Eight bits is sufficient for representing an integer value between 0 and 255. But in any case the expected values for this link are well under 127. The LogPHY adds a single cycle of latency and the PHY layer will only add a dozen or so more cycles in the worst cases. At 500MHz this still put the reported value at ~30ns worst case.
OK, so PTM_RX_DELAY parameter is fed in externally. And from your comments, it sounds like that could reasonably max out as a 4 bit parameter, in which case the 8 bit pl_ptm_rx_delay[7:0] is more than sufficient to report the ns. That all makes sense.
The next question is related to the pipelining and these signals. It seems logical that the PTM_RX_DELAY indicates the round trip latency in the phy and the LPIF_PIPELINE_DELAY would increase that latency. Can we assume the instantiation will ensure these are consistent, that is if the LPIF_PIPELINE_DELAY increases, that would likely cause a corresponding increase in the PTM_RX_DELAY value? In other words, we are not trying to add these parameters internally to the phy logic, correct?
Had good conversation with Michael earlier and we generally agreed on the above understandings, but Michael did want to think on the pipeline vs PTM ramifications a bit.
I'm marking this as fixed, but I'll leave to Michael to close when he is ready.
We are aligned. PTM_RX_DELAY should be used for pl_ptm_rx_delay[7:0] and remain independent from LPIF_PIPELINE_DELAY. Closing this issue.