This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB638-Q1: Lock/Pass output pins vs register bits

Part Number: DS90UB638-Q1

When my link from the DS90UB635 is connected and running BIST I read registers 0x04 (DEVICE_STS) and 0x4D (RX_PORT_STS1) I can see the PASS, LOCK, PORT_PASS, and LOCK_STS bits are all set to 1.

When I probe pins 47 (PASS) and 48 (LOCK) they are both near 0V.

When I disconnect the link, the register bits all change to 0 and the pins are still 0V.

Is there a logical difference between the output pins and the register bits?

I am supplying 1.8V to VDDIO.  The output pins measure 9kΩ to ground, so I do not believe they are shorted.  

  • RX_PORT_CTL 0x0C is set to 0x81.  I tried the other settings for PASS_SEL and LOCK_SEL, but none set the output pins high.

  • Hi Barry,

    Thanks for reaching out with this question. Would you be able to share how the UB638 is configured in this situation? Was there any programming done after the power up of the deserializer?

    Best,

    Thomas

  • Hello, Thomas,

    Thank you very much for considering our issue.

    Here is a code snippet from our test setup.  Both the 635 and 638 have i2c connections to our test controller so we can configure and monitor them at the same time.

    void TestInit()
    {
      // I2cWriteReg(0,0x01,0x01); // Digital Reset 0
      I2cWriteReg(0,0x01,0x02); // Digital Reset 1 Resets Registers
      delay_cycles(1000000); // 30ms
      I2cWriteReg(0,0x0C,0x81); // deser disable imaginary port 1
      I2cWriteReg(0,0x21,0x41); // dser set FWD_SYNC_AS_AVAIL
    
      I2cWriteReg(1,0x02,0x01); // Set ser to 1 lane mode
    
      delay_cycles(1000000); // 30ms
    
      Status638();
      Status635();
    
      I2cWriteReg(0,0xB3,0x03); // set deser to bist mode possibly 0x83 or 0x85
    
      delay_cycles(10000000); // 300ms
    
      Status638();
      Status635();
    }
    

    You can see I try a reset first, then write 0x0C an 0x21 with the values recommended in the datasheet.

    I also try to set the 635 into single CSI lane mode, hoping it reduces the bit rate.

    The status functions just report a few of the status registers for the respective devices so we can validate the test.

    Does this shed any light on why the outputs do not seem to reflect the status register values?

  • Hi Barry,

    From a high level, would the goal of this script here be to run BIST? Do you know at which point we're monitoring lock via registers & via the lock pin output?

    Could you please also help to confirm which mode strap you are in? Based on the pairing of the UB638 and UB635 I'd assume you're in CSI-2 sync or async mode

    It seems like we're good to go from the perspective of configuring registers 0x0C & 0x21 in the initialization script.

    For the UB638 paired with UB635, these devices should lock without any initialization script. The 0x0C programming is helpful here to bring lock out to the lock pin locally on the UB638. Both the serializer and deserializer should receive their respective mode from the mode strap at power up, and lock accordingly.

    One other note on reducing the lane count of the 635, the link rate in CSI mode does not depend on CSI payload that is carried over the link. In the case of sync mode the serializer generates a forward channel which is a multiplier of the back channel rate. This can be seen in the table below from the UB635 datasheet where "f" is the frequency of the reference clock & data rate / bandwidth are given in Gbps.

    Hope this helps to add some background!

    Best,

    Thomas

  • Thomas,

    Thank you for all the background.  Our goal was to run in CSI synchronous Back Channel mode.  We have the 638 mode pin pulled up with 78.7kΩ and down with 97.6kΩ.

    According to 638 register field FPD3_MODE=00 we are in CSI Mode. 638 register field BC_FREQ_SELECT=100 seems to indicate the 50Mbps synchronous backchannel.

    Thanks for the tip on the link rate.  The table you provided (7-8) from the 635 data sheet shows a "Synchronous (Half-rate)" mode.  I cannot find any detail on that mode in either data sheet.  Is it applicable to the 635/638?  Would it halve the forward channel signaling rate?  Might that allow for longer cable runs?

    We are just trying to run BIST for cable testing right now.  We do not have a CSI sensor connected to the 635, so that is really all we can test.

    Any other thoughts on why the PASS and LOCK pins do not reflect the register bit reports?

  • Hi Barry,

    Based on how your script is configuring register 0x0C we should have lock and pass status based on RX0 as shown in the register map. 

    One test which we could run is testing without running BIST mode, would you be able to try to test that?

    Regarding half rate mode, this does result in half the forward channel data rate which can help to achieve longer cable reach if needed for your application.

    Best,

    Thomas

  • Hello, Thomas,

    We went ahead and tried hardware fixes for the PASS and LOCK pins.  Reflowing that corner of the device resolved the issue.  The PASS and LOCK nets now appear to report the actual status.

    I am very interested in half rate mode.  I could find no reference to "half rate" in the rest of the 635 or 638 data sheets.  

    How does one enter half rate mode?

  • Hi Barry,

    Thanks for the follow up, that makes the situation much more clear.

    Regarding half rate, we should be able to adjust to half rate by dropping the back channel frequency on the UB638 to 25Mbps in sync mode. Included below the register description for 0x58 where we'd want to change bits [2:0].

    Best,

    Thomas

  • Thomas,

    I appreciate all the help and background.  I apologize that the issue I asked about was related to our hardware.  Still surprised that 46/48 pins were working and those two were not.  I had hoped that if there were a logical difference between the pins and registers that you could point it out and we could avoid possibly unnecessary rework.

    I think your added background and support with half-rate mode will be very valuable.  I now understand how reducing the back channel frequency will reduce the forward channel rate.

    We will continue testing.

  • Hi Barry,

    Glad you were able to proceed with the testing for this project, I'm going to close this thread for now. If there's any other questions which we can help with please don't hesitate to reach out!

    Best,

    Thomas