Platform forum

I2C and SPI routing

pal , 03-11-2021, 07:50 AM
Hi, How should be I2C and SPI routed ideally ?
Lakshmi , 03-11-2021, 08:01 PM
robertferanec , 03-12-2021, 05:15 AM
@Lakshmi awesome document. Thank you for sharing
kazemiy974 , 03-19-2021, 12:28 PM
@Lakshmi It was awesome,Thanks for sharing, if you still have similar documents, please share it
Lakshmi , 03-25-2021, 04:50 AM
Originally posted by kazemiy974
@Lakshmi It was awesome,Thanks for sharing, if you still have similar documents, please share it
From microcontrollers and processors to sensors, analog ICs and connectivity, our technologies are fueling innovation in automotive, consumer, industrial and networking.

kazemiy974 , 03-25-2021, 05:23 AM
@Lakshmi Thank you very much.
robertferanec , 03-29-2021, 02:29 AM
For I2C, I've always steered towards using flyby topology with a single set of pullups furthest from the master.
I do it similar way.

PS: Also, I do not route I2C as a differential pair (some people do that), but I do route the signals a kind of together.
pal , 04-28-2021, 09:13 AM
Thanks for sharing document @Lakshmi ! and @robertferanec thanks for sharing experience ! is there any value in keeping pullup at the farthest from Master? as @DanR mentioned?
pal , 04-28-2021, 10:31 AM
Thanks @DanR

Those are good questions, fortunately, my design doesn't have any of such requirement, (short length, low # devices) I am just trying to settle /define constraints for I2C worst case.
qdrives , 05-03-2021, 07:48 AM
To quote Rick Hartley: "If the propagation delay is less then 1/4 of the rise time, you do not need termination."
Lakshmi , 07-11-2021, 07:56 AM
anovickis , 08-15-2021, 10:19 PM
Typically with I2C h/w problems the only ones you will have are -
- different voltage level drives on your devices
- "h/w" hanging due to the driver not being written correctly to the spec of the components, typically this is forgetting to clock out the last byte, not waiting for clock hold to complete before sending, or using the wrong clock rate for a device
- address overlaps
- forgetting pullups on bus, or some segment of the bus if you are multiplexing multiple, or hot plugging an I2C component (say on another card - it has to be in pull up state _when_ it's powered up, not slightly after) - or it may be forever stuck in the middle of a perceived "transaction"

With SPI though,
1-1 connections are easy, but if you have multiple chip selects and thus multiple devices
clock signal integrity needs to be studied if you are going for, maybe over 10" traces on that line in total
In general you should not "Y split/T split " your clock line, but rather daisy chain - unless you also place a 1:n clock buffer there as you will have reflections to deal with which need simulation confirmation

With QSPI (in the "quad spi sense" - not the infineon definition which is "queued-SPI")
- match data lengths
- keep the master/slave not more than few inches apart
- usually this is one master /one slave - so skipping the clock discussion on this type

Keep in mind all spi devices are not the same - as you have speed differences (will have to pick lowest common), and then also two choices of clock polarity and clock phase
if you have more than one species on a particular SPI bus then you will be in for some trouble

Use our interactive Discord forum to reply or ask new questions.
Discord invite
Discord forum link (after invitation)

Didn't find what you were looking for?