Displayport clock recovery

Question

The displayport protocol runs at a fixed frequency of either 1.62GHz, 2.7GHz, or 5.4GHz. The pixel stream (strm_clk) it carries runs at an arbitrary frequency and is likely to be asynchronous to the link clock (link_clk). The receiver is supposed to recover strm_clk from two numbers M,N, as their ratio, i.e., strm_clk/link_clk = M/N, where N is fixed to 32,768 and M depends on how many strm_clk cycles have been recorded during N link_clk cycles. In asynchronous mode, we would expect M to slightly vary in time. So far so good.

Now, the problems:

• M,N are sent once per frame, whereas they are reset every N=32,768 link_clk cycles which is in about 2-3 lines. How can the delicate changes in M be detected by the receiver who doesn't see M as often (only once in millions link_clk - during the vertical blanking)?

• the lowest 8 bits of M are sent every line - which may explain the above, but since M is reset every N=32,768 link_clk cycles, so are its lower 8 bits, which will undermine the ability to use these bits as a reference between two clocks (due to what appears as sudden resets on these bits). How does that work - are there two separate counters?

• another (minor) issue: in every stream clock, 24 bits are sent (in RGB 444 mode), the displayport sends either 4 or 8 bytes (depending on the number of lanes / their speed). Does that mean that in every lstrm_clk cycle, M should increment in a fractional manner (i.e., by 3, by 3, then by 2)?

I find the standard hard to understand - basically, page 60 here:

http://read.pudn.com/downloads98/sourcecode/others/400577/DportV1.pdf

Bottomline: can anyone explain how this N,M scheme is supposed to work given the issues above?

Any thought would be highly-appreciated!

Answer 1

I am not an expert on displayport, but from taking a look at the standard, I think I get the gist of what they're trying to accomplish. The goal is to transfer the original stream clock over an asynchronous link by transferring information about the relationship between the original stream clock and the link clock over the link, instead of doing something like deriving the link clock from the stream clock. This information can later be used to regenerate the stream clock at the other end of the link. It also allows for multiple, indpependent stream clocks to be sent down the same link and regenerated. The information transferred is simply the ratio of the two frequencies as a fraction, M/N, either both constant (in a system where the stream clock and the link clock are synchronous) or M measured and time-varying and N constant. The thing to keep in mind is that even though the stream clock and link clock are asynchronous, their frequencies should be relatively stable and hence not drift very quickly with respect to each other, so the measured M value will change slowly. Since M is measured every so many clock cycles, a new value is only available periodically. The whole value is only sent once per frame, but the lower 8 bits are sent more often, which should be sufficient to track the slowly varying value. So long as it varies by less than, say, 128 or so increments between measurements, it is even possible to track variations that cross over to bit 8 (for example, say the last M value was 0x0023f2 and the new LSB is 0x10, the new M is probably 0x002410 as that represents a smaller step than 0x002310).

From your third point, and your talk about 'resets', I think maybe you're confused about how M is measured and what it represents. It is measured using two counters, one counting cycles of LS_Clk (link symbol clock) and one counting cycles of Strm_Clk (stream clock). When the LS_Clk counter overflows after 32768 LS_Clk cycles, the value of the Strm_Clk counter becomes the new M and the counter is reset back to zero. M does not change until the next time the LS_Clk counter overflows. So if the frequency of the link clock and the stream clock do not change with respect to each other, the counter driven by Strm_Clk will always end up at the same value and hence M will not change. If the frequencies drift, then M will change slightly to track the change. The values are then used to drive a PLL at the receiver to generate something very similar to the original stream clock by using LS_Clk as a reference and multiplying it by M/N. M does not continuously increment or decrement in any way, unless the stream clock frequency is slowly increasing or decreasing over time at a continuous rate.