DS92LX1621 PCLK logic levels

Hi Eric,

The PCLK is categorized as an input and LVCMOS type I/O on the DS92LX1621. All the LVCMOS I/O’s are referenced to the VDDIO supply; meaning if inputs are switching at 1.8V levels then connect VDDIO to 1.8V power supply. The LVCMOS logic levels (min/typ/max) limits are listed on the ‘Serializer Electrical Characteristics’ under LVCMOS DC SPECIFICATIONS on pg 8 of datasheet -- http://www.ti.com/lit/ds/snls327h/snls327h.pdf

Dac Tran

SVA APPS

When I set up service request #1 -1017524660 the TI engineer said that PCLK did not act like the other I/O.  He viewed the schematic for the chip and indicated PCLK was always going to remain interfaced at 1.8V independent of the VDDIO level.  He appeared to be very concerned about this.  I thought it might be like this because the LX16EVK01 has the oscillator for PCLK always powered at 1.8V independent of the VDDIO level.  It is either wrong there or wrong in the chip.  You can't have it both ways.  This engineered vowed to get back to me on this.  But he dropped the ball and sent me an email to use E2E.

Either explain why it is always at 1.8V on the LX16EVK01 or explain how it works in the chip.

Eric

Hi Eric,

Not sure how the engineer came to that conclusion, but that’s not how the PCLK on DS92LX1621 functions. The device does always require 1.8V power for the VDD core supply pins. The PCLK is a LVCMOS input and thresholds are biased to the VDDIO supply voltage. If there is no valid PCLK input, then it will switch over to its internal oscillator.

I’m not seeing where it mentions it’s always 1.8V on the PCLK for LX16EVK01 user manual. Can you point out the reference?

Dac Tran

SVA APPS

Hi Dac,

On the LX16EVK01 serializer board the power pin for the on-board oscillator is set to 1.8V regardless of the setting for VDDIO which I set on the VDDIO select jumper.  It appears to work even when we have the VDDIO set to 3.3V.  We are not sure if it is working completely reliably.  But it works too well for an input which is set to 3.3V LVCMOS voltage levels.  Please review the schematic for the LX16EVK01 serializer and let me know if the power pin for the oscillator is supposed to be always set to 1.8V or if this is a mistake on the board.  The engineer who took my case looked at the schematic for the DS92LX1621 chip and saw that the PCLK was interfaced in the 1.8V power domain only.  Have you reviewed it with him?  You should be able to reference to his identity since I gave you the case number.

Thanks,

Eric

Hi Eric,

Thanks for the clarification. There may be confusion between the DS92LX1621 operation and the LX16EVK01 board functionality. On the LX16EVK01 board, I believe you are referring to the Y1 on-board oscillator option (unpopulated by default) which is connected to 1.8V VDD power supply only. This is an external option intended for 1.8V VDD oscillators and 1.8V VDDIO for BIST validation (see Table 5 in datasheet). In that case, only 1.8V VDDIO is supported with JP2 set to +1.8V; since Y1 is directly connected to the PCLK signal. On the other hand, PCLK input (includes all LVCMOS I/O’s) is biased to the VDDIO supply. If there’s no valid PCLK input, the device will run off an internal on-chip oscillator at 25MHz.

Dac Tran

SVA APPS

Hi Dac,

It just seems odd that the designer of the LX16EVK01 constrained the usage of Y1 to 1.8V only.  I should think users of the board might wish to use a local oscillator with 1.8 as well as 3.3 voltage levels.  I don't know why you are saying that Y1 would only be useful for BIST validation.  Can't you run the link in general communication modes with the external PCLK?  Then why wouldn't a user possibly want to use Y1 for testing general communication modes?

Additional comments about the LX16EVK01 serializer board:

1.  The silkscreen for VR1 says +1.8V.  VR1 really controls +3.3V.  This can cause a problem for the user of the board if they popoulate VR1 and the corresponding regulator.

2.  The silkscreen for VR2 says +3.3V.  VR2 really controls +1.8V.  This can cause a problem for the user of the board if they popoulate VR2 and the corresponding regulator.

The deserializer has the corresponding silkscreen labels correct.

Is there a more comprehensive document on the LX16EVK01?

Can we get the artwork for all of the PCB planes for the LX16EVK01?  In the manual only the top and bottom layers are provided.

Can we get characteristic eye diagrams for the ser/des link?  We need to know how much margin we have.

We have done a lot of testing using I2C over the eval boards in Camera Mode and Display Mode.  Generally, it has worked fine.  However, we notice I2C timeout errors when we are in Camera Mode.  When we run 20 I2C reads per second we get a timeout every 1.5 minute on the average in which the data takes over 1 second to respond.  On the next read the data is correct.  If we switch the exact same hardware over to Display Mode then the I2C timeouts never happen.  Is this a built-in characteristic of the chip-set?

Can I phone you and talk about this?  Do you have a phone number?

 Thanks,

Eric

Hi Eric,

The 1.8V supply is only a limitation on the local oscillator option. Typically running a standalone oscillator, the DIN data sampled would be asynchronous to the oscillator clock (unless it you sync or buffer it). In most cases, you would want it fully synchronous to the pixel rate including data, HS, VS, etc.

Thanks for pointing out the errors on silkscreen markings. We will correct this on next revision.

For more comprehensive documentation on the LX16EVK01, you can refer to the SERDESUB-16USB EVM which uses the same platform -- http://www.ti.com/lit/ug/snlu100/snlu100.pdf  You will also find all the pcb layers in the document.

The CMLOUTP/N loop-through output driver (pins 32, 33) on Deserializer. These are equalized data output and are designated as reserved pins. These are mainly used for signal monitoring and eye diagram tests. In default mode these are disabled but by setting bit 4 of register 0x3F to 0 you can enable this output. Signals can be accessed by the P1 connector on EVM board.

For the I2C timeouts, is this a NACK from the remote device? Do you have a plot of the failure?

Dac Tran

SVA APPS

Hi Dac,

Thanks for replying to my posting.  Is the DS90UB901Q a drop-in replacement for the DS92LX1621?  Is the DS90UB902Q a drop-in replacement for the DS92LX1622?  We would, of course, not exceed 43 MHz for the PCLK on either chip.  Judging by the evaluation board user's manual it seems like the FPD-Link III is better supported than the Channel Link III.  We anticipate a long period to get our I2C operation verified to be reliable.  It will help to be using the best supported chips.  If you could direct us to the SER/DES chips set with the most reliable I2C we would appreciate it.

We will check if the I2C timeout is a NACK as soon as we can get back on the air with the evaluation board sets.

Eric

Hi Eric,

Yes, the DS90UB901Q/902Q and DS92LX1621/1622 are pinout compatible. In terms of functionality, both are the same. Channel-Link III is targeted for industrial/consumer applications whereas FPD-Link III is intended for automotive applications. Channel-Link III chipsets have a lower temp range but are extended frequency range. Alternatively, FPD-Link III chipsets are AEC-Q100 certified and go through a different production test flow.

In regards to support, I would say both chipsets are equally supported product lines.

Dac Tran

SVA APPS

Dac,

TI seems to have SERDESUB-16OVT in stock.  Do you know where I can purchase an OmniVision image sensor and an Omnivision USB interface board to make the complete unit work?  I have not had any luck today finding them.

Thanks,

Eric

Hi Eric,

We obtained the Omnivision sensor evaluation kits directly from Digikey; i.e. mfr p/n OV10620-ECJC-BA0A. However, kits seem to be no longer offered by Digikey or discontinued. You may need to contact Omnivision support for details.

http://dkc3.digikey.com/PDF/US2011/0804.pdf

Dac Tran

SVA APPS

Hi Dac,

We see a posting from March 2012 indicating the DS92LX1621/DS92LX1622 will operate with 2.5LVCMOS voltage levels if we connect Vddio to 2.5V.  We want better substantiation of the chipset's ability to operate at 2.5V.  Do you have any documents indicating it works at 2.5V levels?  Is the logic designed to continuously vary and track the Vddio voltage level for the I/O pins?  There are IO voltage registers in the DS92LX1621/DS92LX1622 which specifically identify 1.8V and 3.3V.  In the DS92LX1621 register 3 bit 4 is the Vddio Mode bit.  The DS92LX1622 has the same thing.  When VDDIOCONTROL=0 this bit is to be a 0 for 1.8V and a 1 for 3.3V.  What is the purpose of this bit?  If we run from 2.5V IO then how does it affect the operation of this bit?

We are very concerned about this and need to know if there is some specific function achieved at 3.3V or 1.8V IO which would not operate correctly at 2.5V.

Eric

Hi Eric,

The DS92LX1621/1622 VDDIO is only characterized for 1.8V and 3.3V operation. 2.5V VDDIO will function however not ensured. The VDDIOCONTROL register bit is to override the auto VDDIO detect circuit. Basically this bit will adjust the IO thresholds levels.

Dac Tran

SVA APPS

Hi Dac,

Thanks for your reply.  We need to know what IO threshold levels are affected by the VDDIOCONTROL register bits.  How are the threshold levels affected?  Where is this described in the datasheet?  If we are using 2.5V IO then are the thresholds not adjusted correctly?  Is there some downside to using 2.5V IO and is that why TI does not choose to characterize it?

Eric

Hi Eric,

On the datasheet page 8, there’s LVCMOS DC SPECIFICATIONS for 3.3V and 1.8V IO. The VDDIOCONTROL adjusts the thresholds levels accordingly. I don’t foresee issues using 2.5V IO.

Dac Tran

SVA APPS

Hi Dac,

So to summarize the information you provided -- TI does not officially support the 2.5V IO.  However, your professional and technical opinion is that it should work.  We have tested it on the evaluation boards since we can adjust VDDIO.  We have communicated with I2C devices running at 2.5V and everything works just like at 3.3V.

What is the life expectancy of the DS92LX1621/DS92LX1622?

What is the life expectancy of the DS90UB901Q/DS90UB902Q?

Eric

Hi Eric,

Your assessment is correct. If I understand your question on the life expectancy, there are no plans to obsolete/discontinue the products and will continue to support both chipsets unless otherwise.

Dac Tran

SVA APPS

Hi DAC,

Is there a standard number of years we can expect for TI to maintain these chips as active in their system?  My boss is asking for a specific time for life expectancy.

We are monitoring the eye using the method you suggested to Marc Koltermann last November.  This uses the RESOUTP/N pins which are not described as such in the datasheet.  Also register 0x3f is not described in the datasheet.  We are not encourage by the eye we see using this method.  At 25 MHz, 7 meter cable, we get a 54 mV, 0.7 ns opening after 5 minutes of persistance, filling up after 20 minutes of persistence.  Do you have documented results using specific test set-ups?

You did not really answer my question about TI supporting the 2.5V I/O.  I want a definite answer concerning if TI supports this or not.  My bosses want to know this.  If TI does not support it we can't use it.  If TI is not willing to state in writing they support 2.5V I/O we can't interface to the part with 2.5V I/O levels.

A co-worker, Russ Baca, found that found there is no IBIS model for the DS92LX1622 RIN+/RIN- differential pair input.  This is a significant problem for us since we can't perform the signal integrity analysis without it.  Does this exist?  You provide it for the serializer.

Eric

Hello Eric,

   To address your question regarding lifetime - as a general rule TI does not obsolete products. There is no intended end of life for this chipset.

   Regsarding models of the high speed differential inteface : we do not currently offer models of this interface. IBIS AMI models are required to accurately simluate the effects  of tne signal conditioning offered by these products. The IBIS models provided support only the parallel interface (inputs to SER, outputs of DES).

Best regards,

Sue

Hi Sue,

I have been referred to an article on using common mode chokes with Channel Link III by Tsun-kit Chin of TI.  Do you recommend using common mode chokes on CLIII?  We have found the CLIII link to be somewhat brittle.  Error rates can escalate with minor changes in connectors and cabling.  I am trying to come out with a reliable PCB.  We don't have the luxury of multiple revisions to get to a working configuration.

Thanks,

Eric

Hi Eric,

  Common mode chokes can be useful to help minimize common mode noise that can contribute to EMI and also compensate for skew between the + and - signals of a differential pair. You should bear in mind that common mode chokes to do have an insertion loss component (typically about 0.5 - 1 dB). If you are already operating the chipset at maximum frequency over a long cable  you may be approaching the maximum loss with the addition of a CM choke.

 For your PCB design, I would recommend providing the footprint for a CM choke as an option. You can also choose to short across the pads with zero ohm resistors.

I would like to understand more about your interconnect. You should not be experiencing a "brittle" solution. Please feel free to send along information describing the cable/connector solution you are using, and any details of the issues. 

If you'd prefer, you make send directly to my email : susan.poniatowski@ti.com

Best regards,

Sue 

Hi Dac,

On this SER/DES chipset will the I2C interface work with 3.3V pull up resistors if the VDDIO is set to 1.8V?  We need the full range of 3.3V on the I2C even though we are using 1.8V for all of the other I/O.

Eric

Sue,

I have repeated the email I sent to you directly below:

We are making assumptions about the brittleness based on our evaluation efforts.  We bought three sets of evaluation boards (LX16EVK01).  Since we are planning to use RJ45 connectors with CAT6 Ethernet cable we attached RJ45 connectors to the high-speed SER/DES lines.  Our software guy used I2C mainly to check errors.  He would be able to see the CRC register incrementing, I2c timeouts, or actual I2C data errors from a remote I2C EEPROM.  I used various logic analyzers on the BIST pin to look at BIST errors when we enabled BIST.

 We found it was very difficult to get the RJ45 connector patched onto the board to get better than an average of one error every few Kbytes transferred.  We only have one deserializer board from the LX16EVK01 purchases which give us decent error rates.

 Thinking that our problems may be caused by the RJ45 connections we found the SERDESUB-16OVT which already has an RJ45 mounted on it.  It also has the automotive grade FPD-Link III which we think may be an improved version of the chip set.

 Here is the BIST result for this:

 We ran BIST overnight using the SERDESUB-16OVT evaluation board set (the automotive grade SER/DES chip set).  This was with a 25 MHz clock which implies 700 Mbps serial clock rate.  The 700 Mbps may be correct since we measured a UI of 1.5 ns on the DSA70604B.  We subsequently measured a 1.7 ns UI at a 10 MHz parallel clock rate.  It should have been 3.6 ns if the serial clock was tracking the parallel clock rate with a multiplicative factor of the 28 frame bits.  Why doesn’t the UI track the clock rate?

 The results for 14.5 hours of BIST operation were 9 errors.  The errors were counted using the TLA715 Logic Analyzer.  The total number of bit is:

 700 Mbps * 14.5 hours * 60 minutes/hour * 60 seconds/minute = 3.65(10^13) bits transferred.

 1 error every 4(10^12) bits on average.

 I have attached a sketch of our set-up for this testing (This sketch was attached to the email I sent to you directly).

 We have not been able to repeat this for the LX16EVK01.

The reasons for concluding brittleness are the following:  

1. We can add a few coupler stages and the error rate goes down precipitously.
2. We see a high degree of variability on the error rate when we connect the RJ45 connectors ourselves to the LX16EVK01.
3. TI literature Number SNLA213 does not supply eye margin photos for CLIII or FPDLIII even though they show it for CLII.
4. I asked Dac Tran for eye margin documentation from TI and he never supplied any.
5. We monitored the eye using the method Dac Tran suggested to Marc Koltermann last November.  This was with a 7 meter cable only.  We got a 54 mV, 0.7 ns opening after 5 minutes of persistence, filling up after 20 minutes of persistence.  This did not appear to be encouraging.

 Thanks for helping us in our time of need,

 Eric

Sue,

We have another question on this SER/DES chipset.  If we use 1.8V for the core voltage and 3.3V for the I/O does it matter which rail comes up first?  I want to regulate the 1.8V from the 3.3V and will consequently have 1.8V come up after 3.3V.  Is this going to cause a problem?

Eric

Hi Eric,

   No problem - either rail may come up first.

  It is important to note that the PDB pin should be released (transition to HIGH state) after BOTH the VDDIO and VDD core have reached their intended supply voltage.

Best regards,

Sue

Hi Sue,

We appreciate your answer on the power rails.  My boss asked me to have the ground and power planes cut out under the AC coupling capacitors on the high-speed differential pair signals of the SER/DES.  He also wants this done under the common-mode chokes.  Do you recommend this cut-out?  If so, how do we determine the shape and size of the cut-out?

Thenks,

Eric

Hi Eric,

I checked the case where the VDDIO is set to 1.8V and the I2C bus is pulled up 3.3V and this configuration is not recommended. When the VDDIO is set to 1.8V the output drive strength is reduced on the SCL/SDA (pulled to 3.3V) I/Os and VOL levels may be too high to meet required thresholds. I would suggest using an I2C level translator (ie TCA9406) to address the voltage differences.

As for the cutting up power planes, is also not recommended. First the solid ground plane is needed to keep the controlled impedance. Second solid power/ground planes paired provide the best capacitive coupling to reduce power supply noise.

Dac Tran

SVA APPS

Hi TI application engineer,

We like the SERDESUB-16OVT EVM performance and would like to emulate the layout it has.  How do we get the PCB artwork information for this evaluation board?

Thanks,

Eric

Hi TI application engineer,

We are trying to understand the date coding on the DS92LX1622.  I see the following on the case:

VM21ABE3

LX1622

What does this say about the date of manufacturing?  Where do I get information about case markings?

Thanks,

Eric

Hi Eric,

  The marking on the package reflects that this part was assembled in Jan/Feb of 2012.

The "decoder" for part marking is not publicly availlable. Certainly let us know if you have any further questions.

Best regards,

Sue

Hi Sue,

We are using the DS92LX1621 & DS92LX1622 on an imaging product.  We experience loss of LOCK periodically on our links.  As a consequence of this ROUT[3] goes low when LOCK = L.  The specification indicates that setting OSS_SEL = 1 will tri-state the ROUT outputs when LOCK = L.  However, when we set OSS_SEL = 1 ROUT[3] is still pulled low when LOCK = L.  Can you tell us what the impedance is supposed to be under this tri-state condition?  Have you tested this feature and is it your understanding that it does work?

Thanks,

Eric

Hi Eric,

I think data sheet is the other way around.  Here is what i think is the functionality of the OSS_SEL:

0: Outputs are tri-stated when lock = L

1: Outputs are low when LOCK = L

I believe this is why you see the outputs held at low. Please set the OSS_SEL to 0 and you should see the outputs tri-stated. Please let us know.

Regards,,nasser

Hi Nasser,

We have tried it both ways and OSS_SEL does not appear to tri-state ROUT[3] either way when LOCK = L.  Our software expert, Roice, has also switched ROUT[3] so it is GPIO[5] and made it a tri-state output.  This does appear to be a tri-state output.  We may be able to use this as a work-around.

Thanks,

Hi TI FAE,

The datasheet for the DS92LX1621/DS92LX1622 indicates a requirement for clock stretching from the I2C master communicating with Channel Link III.  However, it does not mention if the DS92LX1621/DS92LX1622 supports clock stretching to an I2C peripheral.  For example, can you cascade the I2C with two Channel Link III links?  Can you successfully communicate with a UCD9081 which uses clock stretching for every register access routinely?

Thanks,

Eric

Hi Eric,

Please note AN-2173 for more detailed discussion on this topic.   The channel link slave attached to the master micro controller generates or streches the clock for a period of 12uS + 9 * (I2C Clock rate) to wait for the remote peripheral attached to the master channel link III on the other side. Channel Link III, master or slave, does not accepts clock stretching. Given this, i believe cascading channel link III clock stratching will not work since the device does not accept clock stretching. 

Regards,,nasser

When the DS92LX1621/22 is placed into BIST mode does it use the equalization setting which is active at that time?  Or does it use a default equalization setting?

Thanks,

Eric

Hi Eric,

BIST mode will override the serializer input DIN signals with a built-in test pattern and then cause the deserializer to analyze BIST transmission. Other parameters like EQ control values should not change during the process from its most recently programmed settings..

Thanks,

Michael