SN75DPHY440SS: Issue with SN75DPHY440SS running at data rates above 1.05Gbps

Harry

Are you seeing this issue only on lane 0? Can you use the following I2C command and see if the data can pass through the DPHY440?

(Address, Data)

(0x50, 0x1F), //Override enable for HS TX path

(0x51, 0x1F), //HS TX path enabled.

(0x61, 0x00),  // Disable LP path.

(0x70, 0x1F),  //Override enable for HS RX path

(0x71, 0x1F)  // HS RX path enabled.

Thanks

David

Hi David,

Thanks for getting back promptly.

The missing SOTs are seen on all the data lanes.

With the overrides and enables you suggested the SOTs are now passing through the part.  So what is next to try?  Also is there a way to put the part into pass through or bypass mode where both the LP and HS signals are passed through and the reclocking/retiming is bypassed?

Harry

Harry

MIPI starts from LP mode, to change to HS mode, we have the following transition for both clock/data lanes.

LP11-->LP01->LP00->HS

So I am suspecting that the DPHY440 is not seeing the sequence and therefore not able to transition from the LP to the HS mode.

Unfortunately, there is no bypass mode in the DPHY440.

Thanks

David

Hi David,

Looked at the inputs to the part and there are the LP11 to LP01 to LP00 to HS switch.  Also on the output of the part we do see the data making it through just not he SOT at the beginning of the line. The outputs are switching from LP to the HS mode as the levels of the signals do change from the 1.2volt level down to the 400millevolt level.  It just seems that it is getting into HS mode late and dropping the SOT and going directly to outputting the data portion of the line.

Harry

Harry

It shouldn't as the part was tested all the way up to 1.5G. Are you seeing this across multiple boards? Can I please take a look at the input/output scope shot with the data below and above the 1.05G?

Thanks

David

Hi David,

Just tried another test using a DS90UB960 part running at a 1.2Gbps data rate driving into the SN75DPHY440SS part and the SOTs along with the LP to HS transitions are seen and the same response is seen on the output with no SOT but the data is making it through so the part did switch into HS mode.

Harry

Harry

Can I also please take a look at your schematic?

Thanks

David

sn75dphy440ss_schematic.pdfACE2 CXP MIPI Signals 1200Mbps Repeater In--00000.pdf

Hi David,

Did you receive the schematic and scope traces?  On the scope traces the magenta/pink trace is the signal going into the SN75DPHY440SS part and the green is the trace of the signal coming out of the part.  The image being transferred is a DS90UB960 part setup to put out color bars as shown the first bar does come out of the SN75DPHY440SS part without the SOT 00011101 or 0xB8 sequence as seen on the magenta trace.  This is seen on the output at rates below 1.05Gbps.

Harry

Harry

I don't see an issue with the schematic. Do you have a scope capture of the clock lane?

Thanks

David

Hi David,

I can go and take one.  Do not know if it will help as the DS90UB960 is setup to do continuous clock so there is no LP to HS transition.

Harry

Harry

I was wondering if you are seeing the clock being turned off for some reason.

Are you seeing this issue on all the DPHY440 parts?

Thanks

David

Hi David,

No the clock is not turning off in the input side of the part.  What happens if the skew in the MIPI signals between clock and data causes the data to either miss setup or hold time for the part?

Harry

Hi David,

I meant the clock was on turning off on the input side of the part.

Harry

Harry

I have not tested this scenario in the lab. Could you check the DPHY440 input side and make sure the setup and hold time is met?

Thanks

David

Hi David,

The expectation was if setup and hold times were missed the SN75DPHY440 would reclock/retime the data and put the edges of the clock in the middle of the data eye. Was this a miss read of the data sheet?

Harry

This did not resolve my issue but the explanation to my latest question answered any further question about the part.  Now know what  is needed to work around the issue originally found.

This thread can be closed at this point.

Thanks,

Harry