1
\$\begingroup\$

I'm working on a project where I need to control a large number of shift register outputs updated at 44.1kHz audio rate. I built a board in the past that worked well for controlling 64 outputs (8 shift registers), I'm now working to expand it to more outputs for a different application.

To control more outputs I'm designing a daisy chainable PCB . The master PCB will have a Teensy 4.1 microcontroller populated sending SPI data to the shift registers. This PCB will send output to a series of daisy chain PCBs without the 4.1 populated using differential encoders between each PCB.

The intention for this project is to control a very large number of shift register outputs (somewhere in low thousands). To this end I'm planning to run SPI at around 50-100 MHz clock speed (100MHz / 44.1kHz = ~2267).

For sending SPI between the PCBs I'm using SN65LVDS32DR and SN65LVDS31DR differential transmitter + receivers with shielded Cat6 cable. For the shift registers I'm using 74LVC595 high speed shift registers. I'm also using SN74LVC2G17 schmitt trigger buffers for signal cleanup on the input and output of the PCB. I expect the CAT6 cables to be most < 12" always < 36".

Please find my schematic attached. Does this seem like a reasonable approach to the stated application? I'm trying to make my solution as modular as possible for different numbers of outputs while using a single PCB design.

Signal flow is as follows:

[Differential Receiver / Teensy] -> [Schmitt Buffer] -> [Shift Registers] -> [Schmitt Buffer] -> [Differential Transmitter] -> [Shielded CAT6 to Next PCB]

In particular there are two questions I'd like answered in regards to this design:

Is the combination of SN65LVDS32DR and SN65LVDS31DR differential transmitter + receivers with shielded CAT6 cable and the SN74LVC2G17 schmitt trigger buffers the best approach for sending high frequency SPI signal between daisy chained PCBs and maintaining clean signal on the boards themselves? Is there a different approach to buffering and board to board connection that would work better for this application?

If there is a way in which this approach fails, what is the likely point of breakdown? Is there a certain SPI clock rate at which this becomes unfeasible, a certain number of daisy chained boards, or a certain cable length at which this will cease to work? What is the mechanism causing this failure? In particular I'm worried about phase misalignment between clock and data due to rise time and propagation delays, but these signals are experiencing the same effects at each buffer point in the signal chain, which theoretically would keep them consistent.

enter image description here

\$\endgroup\$
9
  • 2
    \$\begingroup\$ Do you really mean millihertz (mHz), or do you maybe mean Megahertz (MHz)? Capitalization really matters for physical units… \$\endgroup\$ Commented Feb 9 at 8:05
  • \$\begingroup\$ Control several thousand shift registers in SPI daisy chain with a 100 MHz clock? Are you sure you wont have signal integrity problems? What about reflections? \$\endgroup\$ Commented Feb 9 at 10:44
  • \$\begingroup\$ Please also include proposed PCB layout, and how the cable will be terminated (physically: connector system, type and lead dress). \$\endgroup\$ Commented Feb 9 at 11:05
  • \$\begingroup\$ There's no schematic. And contrary to what you say, the SN74LVC125 isn't a Schmitt Trigger. \$\endgroup\$ Commented Feb 9 at 11:15
  • \$\begingroup\$ Bad idea on many fronts. Signal integrity, clock skew, ground bounce etc. you might want to look at Manchester encoding the data or maybe Ethercat. \$\endgroup\$ Commented Feb 9 at 13:58

1 Answer 1

Reset to default
2
\$\begingroup\$

I don't see any decoupling capacitors on the schematic. But it looks like the image in the question is a part of a larger schematic, so they're probably offscreen. In any case you need good local decoupling.

If you expect a signal with slow edges, Schmitt triggers make sense to avoid spurious oscillations around the threshold voltage. This is not the case here, as the signal going into the Schmitt triggers comes directly from a nearby logic chip, so the Schmitt trigger part is probably not needed. Your LVDS receivers look like they have enough drive strength to take care of the inputs connected to them, worst case is 5 inputs (4 shift registers plus LVDS transmitter). So you can probably get rid of those buffers altogether.

SN65LVDS32 datasheet says "Designed for Signaling Rates of up to 100 Mbps". However, note that a 100MHz clock counts as 200 Mbps, because each clock cycle is a high level followed by a low level, ie... very much like two bits. I'd suggest checking this more in depth.

RJ45 connectors have inherited a troublesome issue, due to the two middle pairs not being laid out as they should (ie, 1+, 1-, 2+, 2-) but instead (ie, 1+, 2+, 1-, 2-) which causes crosstalk and impedance mismatch as the two outside pins (3,6) couple with the two inside pins (4,5). I'd suggest placing the fastest and most sensitive signals (clock, data) on the outside pins which don't suffer from this issue, and placing less sensitive CS and EN on the four pins in the middle.

Note with timing issues, "it works" doesn't mean it actually works: propagation delays and timing margins vary from chip to chip, with temperature and supply voltage, etc. So if you test it and it works, it's no guarantee it'll always work.

Now suppose the last LVC595 receives a clock edge. It has a propagation time between clock and QH' of Tpd = 1.5 (min) 4.0 (typ) 6.7 (max) ns at 3V3 supply, so after this delay it outputs a data bit on QH'. Both the clock and this data bit (delayed by Tpd) go through the LVDS transmitter, cable, and receiver. Will the next HC595 receive it correctly?

SN65LVDS32 has 0.3ns max skew, then about 0.5ns/meter max skew in the Cat6 cable, then SN65LVDS32 has 0.6ns max skew. So total worst case skew 1.4ns.

This is very close to the minimum 1.5ns Tpd, so there is a chance the next LVC595, instead of receiving the clock edge and processing the bit, then Tpd later having a transition on the data input for the next bit... instead receives a data transition much closer to the clock edge, violating the hold time. This does not depend on SPI clock frequency, since it's purely an interaction of skew and propagation delays. You could add some delay to the last 595 data output, but if clock frequency is too high, then it may also violate timing on the other end by arriving too late.

Board layout may also add more skew, it seems best to send the clock output of the LVDS receiver straight to the LVDS transmitter and then to the 595's, rather than the other way around, which would add a bit more delay on the clock.

In any case, I'm not sure this will work.

There is also the question of distributing power to all these boards and what you do with the outputs: when 32 outputs switch at the same time, especially fast outputs, it can cause power dips on the local supply of the chips. This depends on what kind of loads you connected to those outputs too. If this is about beamforming with 2267 piezo transducers, you're going to need a lot more capacitors.

Personally I think you've kinda reached the limit of shift registers and should switch to something else... It depends on what the signals you want to output are, more details would be welcome... But if you're inputting 44.1ksps SPDIF and outputting 100Mbps data with a Teensy 4.1, even with its 600MHz CPU, the amount of processing per output bit must be pretty minimal. This means it'd probably be interesting to replicate the CPU to drive shorter strings of shift registers... or replace the shift registers with cheap FPGAs like the $5 LCMXO which will do DDR LVDS in/out and maybe even most of the processing. Or maybe something else, like a bunch of cheap microcontrollers.

\$\endgroup\$
6
  • \$\begingroup\$ This is an extremely helpful answer, thank you! \$\endgroup\$ Commented Feb 11 at 2:12
  • \$\begingroup\$ You are correct, decoupling caps will be present but not shown in the schematic snippet \$\endgroup\$ Commented Feb 11 at 2:12
  • \$\begingroup\$ as for the skew issue, any delays imposed by cabling and buffering are being applied to all signals equally, so I wouldn't think that would cause a phase issue. Each signal would just be delayed by the same amount between boards. Is there a reason this view is inaccurate? \$\endgroup\$ Commented Feb 11 at 23:33
  • 1
    \$\begingroup\$ It is correct that delay isn't an issue. Skew is the difference in propagation delay between related signals, and that is an issue. \$\endgroup\$ Commented Feb 11 at 23:54
  • 1
    \$\begingroup\$ It's never exactly the same because the paths are not perfectly matched, for example in Cat5 the twist rate is different between pairs, different circuits on the same chip (like the multichannel LVDS chip) are never exactly the same, etc. \$\endgroup\$ Commented Feb 13 at 14:49

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.