0
\$\begingroup\$

I'm using the TLC5926IPWPR in a design. It uses an SPI interface. The TLC5926IPWPR chip is on a separate PCB than the MCU that is controlling it. The Clock and SDO pin must go through a cable about a 1ft long. I want to clock this as fast as possible, and I wanted to get an opinion on my clock signal. The cable is affecting it quite a bit and I wanted to make sure I meet the minimum requirements, as this design will go into large quantity production and I don't want 1 in 1000 units to loose a bit or something.

Also note that I have two of the TLC5926IPWPR cascaded.

From the datasheet: enter image description here enter image description here

Here is my clock without the cable from the MCU IO pin: enter image description here

Here is my clock with the cable (Measured at the end of the cable): enter image description here

If I measure the time between the threshold of 0.7*Vdd and 0.3*Vdd, I get about 18nS. Is this the right way to measure the clock width requirement? It's the same time if I measure from 50% of Vdd as well. enter image description here

Questions:

1) If the max clock is 30MHz, why is the min clock width 20ns? Shouldn't it be (1/30MHz)/2 = 16.67ns or less?

2) My clocks rise time is well under the maximum, but what about the clock width requirement of 20ns min? Is my clock sufficient?

3) Any ideas on how to clean this up so it matches the requirements better at 30MHz?

4) Can I put a schmitt trigger or something that could clean the signal up from the MCU to meet the requirements at the end of the cable?

The chips are working great as is and I don't see any issues, but one or two units is hardly a valid test of that.

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

Your current clock is probably fine. You may want to slow it down a bit from an abundance of caution if the slower rate will not affect your system operation.

All of your assumptions and methods are correct as far as I can see. The datasheet values will have a some margin in them; it's common for values to be rounded to the nearest nice-looking number. Most customers are probably not as observant as you are (not that it's a bad thing!).

To precisely meet all of the datasheet requirements, though, it would indeed be safest to reduce your clock speed. It is probably not necessary. Will you be operating at 125°C (which is probably the worst case corner)? If not, that will probably help you significantly.

Besides rounding to nice-looking numbers, another reason why datasheet values are not always self-consistent is that when the manufacturer characterized the value, the standard deviation is different between the two measurements. They may be able to control/measure the frequency of the test signal to a greater accuracy than they can control/measure the pulse width. If they pad the min/max specs by ±6σ, the different standard deviations can really change the published value. This only applies if the values are actually measured in two different tests; they may just be both derived from the same measured failure threshold and padded by different amounts.

If it's really very important that you keep a high speed and also very important that you know how safe you are, you could try characterizing the clock characteristics yourself. Buy plenty of parts/boards (hopefully getting a few different date codes), and for each part, increase the clock frequency until you start to see failures, running over your expected operating voltage and temperature range. Or if your order will be high enough volume (maybe at least $1M), ask the manufacturer to do this for you.

\$\endgroup\$
1
  • \$\begingroup\$ From TI: " 1) It is hard to restrict the duty cycle of the input clock is ideal 50%, we suppose the duty cycle range of the clock is 40%~60%, so the minimum width will be (1/30MHz)*0.6= 20ns. 2) The requirements are shown in Figure4 in the datasheet, if they all meet the requirements, it should be no problem to do like this. \$\endgroup\$ May 6, 2019 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.