DS90UB914 routing questions

I now have another board that is exhibiting the I2C programming issues. It maintains a stable LOCK and does not lose LOCK anywhere around where the I2C programming is happening.

I have monitored the I2C transactions on the deserializer side (the board I designed) and the far end (serializer demo board). I can see transactions getting through and then they just stop. I don't see loss of LOCK when they stop. I see a transaction on the local deserializer side, but no transaction on the remote serializer side.

On one of the channels, I was able to get all the transactions through successfully 3 times, but most of the time, the transactions fail to get through at some point. It is also not always at the same point. Sometimes more transactions get through than other times.

IS there something else I could be looking at to find out why these I2C transactions are failing to get through to the far end? Any help with this issue would be appreciated.

Thanks,
Ben

Hello Ben,

Are you using the power over coax (PoC) network from the 913A/914A EVM User's Guide? This network uses Coilcraft inductors of 100uH + 4.7uH and these are the recommend inductors for customer designs. Please follow this EVM User's Guide when choosing components and making electrical connections surrounding our FPD-Link devices: www.ti.com/.../snlu135a.pdf

We also have a PoC application note seen here on ti.com: www.ti.com/.../snla224.pdf
Have you designed your system with the requirements outlined in this app note?

Currently, we are also updating this application note to include a 1kOhm (or higher) @100 MHz ferrite bead on both the 913A and 914A EVM networks. The ferrite bead should replace R29 on the 913A EVM and R38 on the 914A EVM. Please make this change (also add the ferrite on our 913A-EVM) and see if this helps in eliminating the I2C errors.

Regarding your previous questions:

Is the coaxial cable you are using shielded and automotive-grade? This is essential to reducing reflections and ensuring signal integrity of the high-speed signals. Please follow our cable requirements guide shown here: www.ti.com/.../snla229.pdf

For layout, even in single-ended mode it is highly recommended to keep the RIN+ and RIN- traces the same length and coupled together as a differential pair on the board from board connector (RIN+ goes to connector; RIN- is terminated with 50 Ohms resistor near the connector) to FPD-Link device. This increases noise immunity and also reduces common-mode noise going into our part. It is also essential to make sure that these traces are both 50 Ohms and routed away from other signals that might interfere (i.e. cross-talk) in addition to not routing these high-speed traces through vias (i.e. they should be routed on one layer only such as TOP).


One final thing: When your system starts up, do you see a difference if you reset the 914A devices (PDB reset; PDB goes from 0 ==> 1) AFTER the 913A devices have powered up (PDB =1)? Please try this and let me know if this reduces the errors that you are seeing.

-Sean

Sean,

 Thank you for the detailed response. 

 We have read the user guide and PoC application note. Our BOM uses the same parts as on the demo board. 

 For the 5V bypass capacitors, we use a Samsung CL05A475MP5NRNC 4.7uF, 10V capacitor and a Kemet C0402C104K4RACTU 0.1uF 16V capacitor both in 0402 packages. These are used on either side of a Taiyo Yuden FBMH1608HM102-T Ferrite bead with 500mA max current, 350mOhms DCR and 1K impedance @ 100 Mhz in an 0603 package. For the filter inductors, we are using the Coilcraft MSS7341T-104MLB 100uH power inductor and the Coilcraft 1008PS-562KLB 5.6uH inductor that are used on the demo board. Would you recommend going to the 4.7uH inductor in the PoC app note over the 5.6uH inductor on the demo board? According to the PoC app note, the 100uH inductor is the one that is filtering the I2C backchannel band anyway. Our original design did not incorporate the zero ohm resistor or filter bead between the inductors and RIN+. We also did not route the board as differential pairs. 

 I added the 1K @ 100Mhz bead on our board and on the EVM and it does not seem to help the I2C programming of the demo board. I did find that this does help the stability of the video signal when connected to our customer camera. The customer camera uses two BLM18AG102SH1D beads in series off of the power feed and they only use a 100uH inductor for filtering (I do not know the manufacturer of this part). I am able to program their camera module over I2C from our board much more consistently than I am able to program the demo board. The I2C programming makes sense since the 100uH inductor is there, but it seems that they are leaving out the inductor that filters the forward channel. I'm not sure why this would work better than the demo board. 

Additionally, when I read the Serializer registers from the deserializer on our board, I always see CRC errors reported on the backchannel when linked to the demo board (registers 0x0c and 0x0a). I see this with the added 1Kohm @ 100Mhz bead or without it. When I read the registers on the customer camera, I see no CRC errors, but 0x0c reads back as 0x04, which would indicate no cable link and no LOCK, but my local deserializer definitely detects a lock and I see video. I did read some other registers and they all seem to be set to default values, so I'm not sure what to think. 

For cabling, we ordered the following from Pasternack. It is RG316/U coax. 

https://www.pasternack.com/fakra-jack-fakra-jack-rg316u-cable-assembly-pe38754z-12-p.aspx

I found another forum thread where 60 in RG174U/A coax was recommended: 

https://e2e.ti.com/support/interface/high_speed_interface/f/138/p/339731/1187496#1187496

http://www.pasternack.com/showProduct.aspx?SEName=fakra-jack-fakra-jack-rg174au-cable-assembly-pe38750z-60&ProductID=

Our customer is using double shielded automotive grade cable. Pasternack PE-C100-LSZH

http://www.pasternack.com/50-ohm-low-loss-lszhjacket-aluminumtape-over-tinnedcopperbraid-outerconductor-double-shieldedpe-c100-lszh-p.aspx

Regarding trace layout, it is not possible in the current layout to route them only on the top layer and not use vias. My plan is to route them on the bottom layer of the board as that should provide the least amount of stub. The via goes all the way through the board to the bottom layer and then connects to the through hole connector at the bottom of the through hole. The only stub would be the via connecting the PoC into the line. The demo board also routes the traces on an inner layer using vias. Do you see this as critical? I could possibly move things around to keep all diff pair routing on the top layer, but it would mean a lot more work on my part. 

Finally, we have PDB pulled down with a 1K ohm resistor on our DS90UB914 design. This line is controlled by an FPGA and is brought high after the FPGA is programmed fully. I looked at the PDB on our board vs the DS90UB913 demo board and the demo board comes out of reset before our DS90UB914 parts. 

I'm going to continue testing, but it looks like the specific customer camera is working. Ideally, we would like to be able to plug in any camera using a DS90UB913 serializer and have that work, but I'm not confident that would be the case based on my testing. 

Thanks,

 Ben

Hello Ben,

4.7uH or 5.6uH shouldn't matter much as the impedance vs. frequency response curves of both are very similar.

If the customer is NOT using the 4.7uH inductor (and instead using two ferrite beads in series) this is not good. The 4.7uH inductor (in series with the ferrite bead) is crucial for preventing reflections on the forward channel (which can affect the back channel signal integrity as well when the back channel is filtered off of the forward channel.

For the recommend cable type, Pasternack RG-174 is OK but does not have the best ground shield. The best cable to use and the one that we recommend is the Leoni Dacar 462 Coaxial cable. This is automotive-grade and special order through Leoni.

Routing on the inner layers is OK and even preferred for EMI/EMC testing. HOWEVER, of course if you route on the inner layers then there must be a via somewhere to route up to the chip.... It's kind of a double-edged sword but it depends on what you're designing for. Typically, signal integrity is a greater care about and that is why our boards and most customer boards are laid out with the signals on the top or bottom layer and no vias to inner layers.

Best regards,
Sean

Sean,

 The problem I have now is that the customer camera works with our board over cable lengths from 36 in up to 5m, but the demo board does not. I am able to consistently program and get video without loss of lock from the customer camera.

 When I try to program the demo board, the I2C programming does not go through most of the time. On the occasion that the I2C programming does work to the demo board, I see stable video and no loss of LOCK. I do not see loss of LOCK during I2C programming to the demo board, but I always see CRC errors reported in register 0x0c and 0x0a on the demo board. In our setup, I have added JP10 and all of the 0 ohm resistors around that header and I have an Omnivision OV10635 camera eval board plugged in. I have also reworked the demo board to include an FBMH1608HM102-T bead in place of R29. 

 Here is the PoC circuit on the deserializer side of our board. Note that L200 was not in our original schematic. I have reworked the part onto our boards.  

 Below is the customer PoC design: 

 I do know that when we first tested with the customer camera, it would program I2C, but LOCK was not stable with shorter cable lengths. We did get stable video using a 5m cable, but not a 36 in or 60 in cable. Once the FBMH1608HM102-T beads were reworked into our design, the customer camera showed stable video and no loss of LOCK over all cable lengths. 

 While it is good news that our board works with the customer camera, we want to ensure that the board will work with any camera that is plugged into it, which is why I'd like to figure out why the customer camera works and the demo board does not. 

 Regarding the cable, I do not see 462 listed on the Leoni DACAR website. They do have a 362. IS that what you were referring to? Additionally, our customer does not use standard RG-174. They use the Pasternack PE-C100-LSZH, which is double shielded. We are getting both cable types in house to test if there are any differences. 

 Any help or feedback you could provide to help us figure out why the customer camera works and the demo board does not would be appreciated. 

Thanks,

 Ben

Hi Ben,

We meet the same situation as you.

Do you solve your issue finally?

If possible, could you advise how to solve this?

Thanks.

BR,

Rex

Rex,

We never got our board to program the demo board every time, but we did make some improvements. The routing on our boards was not ideal and I'm sure that has an effect.

If you are routing the power separate from the data, which is not recommended by TI, then the best bet is to place the recommended 1K ohm chip inductor as close to the connector as possible. At the very least, you want to avoid having a trace from that inductor to the data line. If you look at the dev board layout, you can see how they routed the power into the data line.

Another thing you could try is using a Wurth WE-CBF 742 792 097 1500 ohm filter bead for the recommended inductor between the power section and the data. I found that inductor to perform well.

Thanks,
Ben

Ben,

Our HW routing is same as yours (power separate from the data), so we experienced the same way you went through.

We're still working with TI local support and try to find the solution.

Thanks for your valuable information.

BR,

Rex