Shift register delay TLC59283

[ilmalavoglia]

Hello everyone! New to the forum here

I'm designing a led driver with TLC59283. Because of led number in the design I'd like to max out the SPI bitrate of my STM32s driving multiple TLC59283, at 32MHz. (It's a constant current output led driver in shift register fashion).
My concern is about the clock and data synchronization using one shared clock and multiple shift registers daisy chained. According to the TI datasheet, the typical propagation delay is rated at 11ns and the max delay at 20ns. Now, from what I know,

• If the delay is < 15.625 ns, clock and dout are not perfectly in sync, but I can resync the two signals with a cheap D flip flop and one NOT gate after the original clock to feed rising edges to the next shift register
• If the delay is > 15.625ns, clock and dout are completely out of sync, so the only way to make them readable again is by delaying the clock precisely to match the propagation delay. This route is expensive, and hard to implement, since I don't know the exact propagation delay of each shift register. 

Am I obliged to make the circuit work at 25MHz to stay safe behind the max 20ns delay? 

[ilmalavoglia]

Moreover, because the SPI signal is sampled at each rising edge of the clock occurring in the middle of the data semiperiod, I fear I have to be safe behind 7.8125ns instead of 15.625ns. Any creative ideas to make this stuff work at 32MHz?

[Peabody]

I don't have any solutions to suggest, but would just say that I'm not clear on what the problem is.  It seems that if the maximum propagation delay, plus the minimum setup time on the data input pin, is less than 31.25ns, it should work at 32MHz.  The propagation delay doesn't multiply with the number of chips in the daisy chain. They would all shift at the same time, and as long as the inputs are correct at that time, it should work.  But I'm not an EE, so maybe I'm just wrong about that.

[Manul]

The data at the daisy chain serial out will already be there ready to be clocked to the next shift register if you don't exceed max clock rate (35Mhz). Beware of the fanout of clock signal. Every IC input and PCB traces add to the total capacitance of clock line. With high fanout you may start to see signal itegrity issues.

[PCB.Wiz]

Am I obliged to make the circuit work at 25MHz to stay safe behind the max 20ns delay? 

Where does 25MHz gives max 20ns come from ? 
You have 40ns between clock edges, and need to satisfy Tfd + Tsu < Tclk  plus some margin for clock skew or slew
TI specs 20ns + 4ns and their 35MHz max clock has about 4.5ns of slew margin on top of that.

I'm designing a led driver with TLC59283. Because of led number in the design I'd like to max out the SPI bitrate...
My concern is about the clock and data synchronization using one shared clock and multiple shift registers daisy chained.

How many parts and what PCB area / trace length ?
You may need to consider clock loading, which may require a clock buffer, and some anti-ringing terminations.
When buffering the clock, it can help to use a gate in the same buffer to also buffer the data to preserve skews.
 

[ilmalavoglia]

Linear traces between ICs are 50mm, so the clock is almost instantly there after the first shift register. We're speaking about picoseconds clock delay in copper trace. Data, however, is delayed by 11ns nominal, so the rising edge of the data output is delayed by 11ns after the clock. Am I getting something wrong?
According to the simulation, if I scope the clock input unchanged and the data out, I get the first FF of the second shift register sampling data with 11ns delay but with the same exact clock. How could this work?

[Manul]

Before the clock positive edge happens, there already is a bit at SOUT. When positive edge happens, that bit is clocked into the next shift register. Simultaneously, next bit is clocked to SOUT. But it comes there with a propagation delay, so it's relevant only at the next clock cycle.

So you just need to ensure that the old SOUT is clocked into next register before the new SOUT appears. There is usually enough time margin for that due to propagation delay.

[Peabody]

But to be safe, the clock line should link to the daisy chain in reverse order, meaning the clock line goes first to the last chip in the chain, and then successively to the others, and finally to the first chip.  That means the existing output value of any chip is clocked into the next chip before it has a chance to change.  The propagation delay is probably enough to cover this anyway, but why not buy the insurance.  Of course that means no fanout of the clock signal - it should go to the last chip, then to the penultimate chip, then ...,  and finally to the first chip (the chip that gets the data input from the MCU).

+1 on making sure the clock line is properly driven, and terminated if necessary.

[Peabody]

Linear traces between ICs are 50mm, so the clock is almost instantly there after the first shift register. We're speaking about picoseconds clock delay in copper trace. Data, however, is delayed by 11ns nominal, so the rising edge of the data output is delayed by 11ns after the clock. Am I getting something wrong?
According to the simulation, if I scope the clock input unchanged and the data out, I get the first FF of the second shift register sampling data with 11ns delay but with the same exact clock. How could this work?

The value clocked into a chip is the value appearing on its input as a result of the previous clock, not the current clock.  So the propagation delays all occur simultaneously, not successively.