> ...The problem is that this decoded data clock is locked to the incoming > data by means of a PFD in the Spartan6/Virtex6 GTP. The PFD normaly only > looks at rising edges, so any change in the clock duty cycle will translate > in a phase change in the falling edge and not in the rising edge. I am not > sure this is really the case, but we certainly had this discussion at the > time, but I don't remember if there was any real measurement made. >
Well, I don't like correcting myself but this is not right. The PFD is only used in the TX path. In the RX path the clock is decoded using CDR using a VCO which operates at the 1.25Gb/s and then is divided down to 125, so the duty cycle problem is not really a big issue here. In any case it is the typical bug one tries to avoid when doing precise timing. Notice that in this case it would not have been a good idea to sample with the system clock falling edge to increase the performance. pablo > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
