Wrong data clocked in when using direct daisy chains of 594/595 shift-registers

Question

I was a bit surprised to find this question and its answer.

^{simulate this circuit – Schematic created using CircuitLab}

When daisy chaining several HC595 or HC594 shift registers, with shared SCLK (serial input clock) and RCLK (output register clock), can there indeed be a timing violation that leads to wrong data being clocked into SDI of the 'later' chips (SR 2 on the right side of the schematic)?

The answer in the link above implies that - upon receiving an SCLK edge - an SDI data could be sampled after the SDO data from the previous register has updated. I have never paid attention to this because I thought that by design the propagation delay will make this impossible. My understanding was that the CLK would always arrive first and the SDO update would be delayed by the propagation delay from CLK to SDO inside the preceding chip in the chain.

Examples:

Generic 74HC parts seem to confirm that the minimum required SDI hold time is usually <3 ns, whereas the minimum CLK-to-SDO propagation delay is at least 12 ns.

The faster LVC series is not quite so clear in this regard (example from Nexperia): the minimum propagation delay is 1.5 ns only, but the typical hold time requirement is around 0.1 ns with the absolute worst case value given to be the same as the CLK-to-SDO propagation delay values. This suggests to me, that even the LVC is designed such that SDO can never overtake the CLK in a daisy chain.

Have I been careless/lucky? If so, under which conditions can these violations appear and how to fix them assuming I want still want to use a highish SCLK of ~20 MHz?

Answer 1

the minimum propagation delay is 1.5 ns only, but the typical hold time requirement is around 0.1 ns with the absolute worst case value given to be the same as the CLK-to-SDO propagation delay values. This suggests to me, that even the LVC is designed such that SDO can never overtake the CLK in a daisy chain.

Well yeah, it's designed to be used in daisy chain, but there's not a lot of margin!

IMO it is important to not screw up the layout with these chips, especially the LVC ones. That's definitely not the type of chips to prototype with flying wires everywhere...

You could run the clock "counter-current" to the data, so the last chip in the shift register daisy chain gets its clock edge first. Then it would have a bit more hold time as the clock propagates towards the previous chip, which updates its output, and that propagates back in the other direction towards the next chip. So this arrangement would add the clock and data traces propagation times between chips to the timing margin, turning them into an advantage instead of a problem.

However if you run the clock "counter-current" to the data, of course the propagation time in both traces must be below one clock cycle (with margin), so that each chip gets the correct bit, without timing violation, when its clock input sees an edge.

Note this has nothing to do with frequency, because in this case setup/hold violations occur near the clock edge as the clock and data propagate through their respective paths. Clock frequency only determines how many times it happens per second, but not if the violation happens or not. Frequency would matter if it was so high that the sum of setup and hold times plus accessories wouldn't fit in a period.

There's also the issue of signal integrity on the clock since it is going to feed many clock inputs: if it is routed with long stubs or not terminated you could get ringing, double clocking or messy edges. I'd want the clock edge to be clean and quick without lingering in the dead zone, so that differences in threshold voltage between the chips don't add more timing uncertainty.

If it changed the output on one edge of the clock, and sampled the input on the other edge, then it would have one half cycle timing margin, which would make it work even with the worst possible layout. But that would also halve the maximum clock rate, making the chip less useful.