I've read numerous posts advising that trace length must be kept short on a high speed board to reduce the effects of impedance. If my traces are routed through a pin header that has an IDC ribbon cable "to nowhere" does that have an effect to manage too? If so, how do I manage it?

Longer explanation

I want to integrate some high-speed logic with my Raspberry Pi 4 via its GPIO header. I plan to make a PCB containing the logic in question and it will sit atop the Raspberry Pi, using a female socket header that connects to the Pi's (male, 40-pin) GPIO header. My target application speed is 20--25 MHz. I'm using 74LVC-series logic (IC propagation time 3.7--6.5ns, edge rise/fall time <= 2.5ns per datasheet) and is powered from the 3v3 pin of the Raspberry Pi; power consumption should be ~50 mA (well within spec for the Pi 4's regulator). On the Pi side, I would be reading a 16-bit bus of signals through the GPIO header.

I plan to put all this in a case, and I would also like to have the GPIO pins available outside the case so I could attach other devices as needed later. (The logic on my PCB has chip select pins that would set them to high-Z in this case.) So I am planning to add another 40-pin header on the top of the custom PCB - mapped 1:1 to the Pi's - that I could then connect to a ribbon cable that would bring those pins to the case edge.

Here's a side-view / cutaway shot of what I'm planning (not to scale):

Side view of enclosure with Pi, custom PCB, and extra IDC cable to GPIO header on enclosure sidewall

When the PCB logic is active, there wouldn't be anything connected to the external GPIO pins; [16 pins on] the ribbon cable would just be implicitly being driven by the PCB's logic as it takes over them.

Does this plan create challenges for the performance of my application? I have a vague idea that the cable constitutes a radiating antenna in this case, but since it's up and away from the board, will that affect the integrity of the signal path and/or add capacitive loading that prevents it from operating at the target speed? (This is a hobby project, not for mass production, so I'm not too worried about radiated EMI -- the device doesn't need to pass an interference certification test.)

And, would it matter if the extra header is "inside" or "outside" the signal path? Consider the following overhead sketch of the PCB:

An overhead view of a PCB schematic with two GPIO headers and some ICs, all connected

If header 1 is to the Pi, and the traces go "through" the pins of header 2 (which connects to the IDC cable) and then to the onboard logic, is that different from the case where the Pi connects to header 2 and the IDC cable is on the "outboard" header 1 connection? (Note that per figure 1, the Pi-side connector will be on the bottom layer of the board, although with THT mounting that is a somewhat moot distinction.)

The system is simple enough that everything could be routed on a 2 layer board. But I am leaning toward a 4-layer board of (signal--ground--power--signal) for speed purposes -- necessary, or overkill here? I am fairly confident the high speed data signals can all be routed on the top layer, the bottom signal plane is only for the underside connector, and infrequently-changing signals like chip-select and other control lines.

Assuming that, yes, the cable is an issue... is there any way I could electrically isolate or decouple the two "sides" of the system using passive components? Preferably without sourcing current unnecessarily from the Pi's GPIO pins? (I cannot use a buffer w/ chip select like 74LVC245 between the ribbon cable and the main connection because each of the Pi's GPIO pins would need to be independently selectable as input or output to retain its original capability.)

I'm new at PCB design and grateful for the advice. Thank you in advance!


1 Answer 1


For high-speed applications (i.e. IDC length > wavelength/10 or so), this is an open-circuit stub and is harmful to high-speed performance, no matter how good your custom PCB layout may be. Even without considering radiation, signals are reflected off the un-terminated IDC stub and end up back at your main signal line from pi to PCB, but with a delay.

A passive isolator doesn't seem feasible - the exact stub impedance depends on the operating frequency, geometry, manufacturing variations in IDC cable, etc. In order to prevent edges from entering the IDC (with whatever characteristic impedance it has to ground), such a component would prevent signals from entering it, or from returning - this blocks the use of the IDC for communication.

You may want to consider your active buffer approach, but with a different buffer IC that provides bidirectional signal flow and independent enables, and a GPIO expander that allows you to drive those enables from a single I2C or SPI interface. Transmission gate or analog switch ICs could work.

  • \$\begingroup\$ Thanks for explaining, that is what I feared. Do you have any ICs in mind? The PCA9600 is a true bidirectional buffer but operates only up to 1 MHz. 74LVC125 is unidirectional; 74LVC245 is 8 lines bidirectional but a control signal sets the direction for all 8. (And 16245 is just two '245's glued together.) I was hoping to allow the "native" Raspberry Pi GPIO header to go thru rather than expose a subset of lines, or forcing the Pi to multiplex several signals via SPI or I2C... \$\endgroup\$ Apr 4, 2022 at 21:45
  • \$\begingroup\$ @AaronKimball I don't have a chip in mind off the top of my head unfortunately \$\endgroup\$
    – nanofarad
    Apr 4, 2022 at 22:01
  • \$\begingroup\$ Understood. Thanks again! \$\endgroup\$ Apr 4, 2022 at 22:15
  • 1
    \$\begingroup\$ Update - I found an analog switch IC (SN74CB3T16210) that looks like it would do the job. Thanks for the tips! \$\endgroup\$ Apr 4, 2022 at 22:42
  • \$\begingroup\$ @AaronKimball No problem - just note that this part switches multiple pins together at the same time (from a glance at datasheet) although it does support bidirectionality \$\endgroup\$
    – nanofarad
    Apr 4, 2022 at 22:44

Your Answer

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

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