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.


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?

  • \$\begingroup\$ Another factor in favor of proper timing: hold time and delays are referenced to 1.5V (table 8), but switching levels are below / above that, i.e. later. \$\endgroup\$
    – asdfex
    Nov 5, 2021 at 12:36
  • \$\begingroup\$ I didn't check what you claim suspicious, but it just does not sound agreeable. Probably, you are seeing the artifact of SCLK & RCLK correlation. What is the skew between SCLK & RCLK? \$\endgroup\$
    – jay
    Nov 5, 2021 at 18:48
  • \$\begingroup\$ @jay please re-read the question and especially the link. I don't claim anything, all the circuits in which I have used daisy chained 595s have worked flawlessly. The answer in the link claims that wrong data in SDI is a common problem due to timing issues between SDO/SDI and SCLK. RCLK doesn't matter for the question, it is just drawn for completeness \$\endgroup\$
    – tobalt
    Nov 6, 2021 at 0:21
  • \$\begingroup\$ tobalt I read yours and Ti's 74HC595 datasheet, and that "this question" . @WoutervanOoijen should have a chance to withdraw it, before we all get confused. There is no base to his statement: "The daisy chain output changes at the same clock edge as the input of the next chip samples." The datasheet only says the other way around \$\endgroup\$
    – jay
    Nov 6, 2021 at 3:57

1 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.

  • \$\begingroup\$ I see, so it boils down to not screw up layout (which I always pay quadruple attention to). If I run a long and winding SCLK trace between the chips, the SCLK could indeed take too long :) My note about the 20 MHz, was because I could obviously add R or C to SDO, to slow down the SDOs and guarantee they would toggle later, but that would eat into timing budget at fast SCLK rates of course. \$\endgroup\$
    – tobalt
    Nov 5, 2021 at 12:57
  • \$\begingroup\$ @tobalt R/C would be my suggestion as well. There's still a factor of 100 between the 50 ns clock period and the 0.x ns possible hold time violation. \$\endgroup\$
    – asdfex
    Nov 5, 2021 at 13:14
  • \$\begingroup\$ In fact a resistor on the data output would probably be enough to delay the signal just a little bit by reducing the slew rate, without using extra current. These chips are used in pretty much every matrix LED panel in existence, and that works just fine... \$\endgroup\$
    – bobflux
    Nov 5, 2021 at 14:55
  • \$\begingroup\$ Cap on the data line may do the trick, while talking about 20Mhz clock speed, by the side effect, not as the real resolution. However, it kills the noise margin, while the clock speed does not represent circuitry operating speed, while suspecting something related to the signal integrity. I would be surprised if any company made 74HC devices with that sort of impractical timing spec. \$\endgroup\$
    – jay
    Nov 5, 2021 at 19:59
  • 1
    \$\begingroup\$ @jay I guess what I take from this question and bobs answer, is that I can continue to not care if I layout carefully and especially if I stay with HC. Indeed LVC might become a little tricky, but it is not needed for my applications. If I need something really fast like 100 MHz that requires LVC, then again I don't see much headroom for RC elements on SDO. Instead, in that case I would rely on the fact that these chips are designed for daisy chaining, so that they should work when laid out properly. \$\endgroup\$
    – tobalt
    Nov 9, 2021 at 11:26

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.