I worked on a PCIE Gen3 retimer. The problem was you were trying to fool both ends into thinking you weren't there and was kind of violating the spec. PCIE Gen4 has explicitly defined the terms allowing you to make a chip that is compliant with the spec to retime the signal.
Nice article. Didn't even consider you'd ever need something like this in a single system. Also never considered that a "redriver" would be able to help at all with multi-GHz signals.<p>(Note: I'm very unknowledgeable about this topic.)
> A retimer is a mixed signal analog/digital device that is protocol-aware and has the ability to fully recover the data, extract the embedded clock and retransmit a fresh copy of the data using a clean clock.<p>How does the retimer recover the underlying clock if the signal is (say) all zeroes for an extended period of time?<p>And why is clock recovery from the data signal necessary in the first place? Can't the clock signal be recovered from the clock signal itself? Iow, why is the clock signal not one of the inputs to the retimer?
This article makes me realize how messy the underlying world of digital communication really is. As a software engineer, I send a file "into the cloud" and assume that it is going to be magically copied bit-by-bit with zero errors while going from my disk through the PCIe bus, the Ethernet cable, the fiber and similarly on the other side. Turns out "digital" is just an abstraction of messy, noisy, distorting, attenuating physical reality.
How does a retimer deal with spread spectrum clocking?<p>Would it achieve a lock at its internal receiver, then apply the spread spectrum on the retransmitted clock?