SN75DPHY440SS: Does the D-PHY 2nsec limit apply to the output side independent of the input side?

Hi,

Flight time can also be defined as propagation delay. Instead defining a fixed length, the MIPI D-PHY spec uses the flight time. The DPHY440 as a retimer, will re-generates the DPHY signaling at its output.

But instead 25cm+25cm = 50cm, the input trace length or loss can be defined by the source TX capability and DPHY440 RX equalizer. The output trace length can be defined by the DPHY440 TX capability and sink RX capability.

An example given in Figure 17 of the DPHY440 datasheet shows a 12in 10mil trace at the DPHY440 input and a 1in 10mil trace at its output. With the example data rate of 1Gbps, the TX pre-emphasis is configured to a setting of 0 dB. The input signal trace of 12in suffers a loss of 1.5 dB at 500 MHz. Thus, the RX EQ setting can be either 0 dB or 2.5 dB.

Thanks

David 

David

I believe I am interpreting flight time correctly.  

I think you are answering my question but I'm not entirely sure.  If each connection link on each side of the retimer is governed by the 2nsec rule, assuming good cable choice and careful PCB layout, both links should be able to support a 2nsec defined distance of around 25-30cm based on nominal VF of cabling and FR4 PCB traces.  The existence of MIPI extenders through LVDS or other alternate serial link for long distances (>>1 meter) would imply the absolute link-layer to link-layer delay is not the issue. The fig 17 example is halfway to my goal; if the D-PHY output connection to the sink device is governed by the 2nsec rule irrespective of input-side cable length, my question is answered.

if you were able to get the signal across using a perfect cable with no signal loss, phase degradation and perfectly matched group delay, the 2nsec value would be meaningless.  it is the ominous wording in the D-PHY spec "...shall not exceed 2 nanoseconds." that throws everyone off as it seems to imply a hard physical limit that cannot be overcome.  

Regards

Rick

Rick

The 2ns flight time applies to the DSI D-PHY application which one of the four lanes is used for back channel communications between GPU and DSI panel. This back channel is a bi-directional bus, so the 2ns needs to account for the round-trip delay. The CSI D-DPHY does not have this back channel, so this 2ns flight time does not really apply for the CSI D-PHY application.

Since this 2ns flight time does not apply in a CSI D-PHY application, you have more freedom on where to place the DPHY440. The input trace length or loss can be defined by the source TX capability and DPHY440 RX equalizer. The output trace length can be defined by the DPHY440 TX capability and sink RX capability. My recommendation is to place the DPHY440 as close to the RX as possible. The DPHY440 provides higher level of EQ than the TX pre-emphasis, and more selection levels. Putting the DPHY440 closer to the RX side is that DPHY440 is a re-timer, which can compensate any lane-to-lane timing skew, as long as the input skew is within DPHY440’s spec. One other thing you want to make sure is the input setup/hold timing meets the DPHY440 input requirement.

Thanks

David

David

You appear to have access to more detailed information about MIPI than I.  Our company is a non-contributing member of MIPI Alliance.org and have access to all the specs.  The D-PHY flight-time is presented in the D-PHY 1.2 specification in Section 8.2.   I cannot find any mention of DSI exclusivity of this particular line item, thus the spec reads as if it also applies to CSI-2.  It is odd for such an important parameter to show up as the last item in the section, as if it was added in some last minute edit. I have also looked in the CSI-2 V1.3 specification, and it directs users to refer to D-PHY V1.2 for physical layer details with no stated exceptions or exclusions.   

I am familiar with the DSI BTA function, which runs with a much lower speed higher amplitude non-differential line protocol where 2nsec would appear to be inconsequential.  Why the D-PHY spec does not make this clear is a mystery I have not pursued and just assumed 2nsec represented the longest delay time for which proportional values of differential delay and insertion loss of typical cable and PCB traces hit the D-PHY spec limits for setup/hold, inter-lane sync, minimum signal, etc.  at bit rates below 1.5Gb/sec.   The use of the term "Shall" for flight-time compliance, however, is pretty definitive and seems unusually strong for a parameter that one would expect to be governed by the quality of the connection medium.

I haven't looked too deeply yet but expect that the DPHY440SS timing needs align with MIPI D-PHY specification for the maximum specified bit rate of 1.5Gb/sec.  Our application will need around 1.3Gb/sec per lane so I believe we are safe and will also be able to achieve a 25-30cm input-side cable distance.  The output side will be more than 1in but somewhat shorter than the input side via PCB and the receiving port is rated up to 1.5Gb/sec so I don't foresee any issue based on your statement regarding DSI.

Thanks

Rick

David

Thank you for confirming.  Since this is an issue that comes up occasionally on your forum, it would be useful to post user application results or perhaps TI's own lab tests confirming the doubled-length link capability.  I think potential users of the DPHY440SS retimer are a bit unsure as the TI application example shows only a 1-inch link to the sink port from the retimer output without clarifying that this link can also stretch to the 2nsec limit.

Rick

We have the freedom to place the DPHY440 in the middle of the channel, but we also want to place the retimer to maximize the benefit of the retimer as much as possible. With the DPHY440 has a bigger equalization on the RX than the TX plus its deskew capability, it would make sense to place the DPHY440 away from the source transmitter and closer to the sink receiver. Unless there is a system design constraint, by putting the DPHY440 in the middle, we took away some benefit of the DPHY440 and shifted the burden onto the sink receiver.

Thanks

David