Tweet
Hi, How should be I2C and SPI routed ideally ?
-
-
For reference: https://docs.toradex.com/102492-layout-design-guide.pdf -
-
Lakshmi It was awesome,Thanks for sharing, if you still have similar documents, please share itComment
-
For I2C, I've always steered towards using flyby topology with a single set of pullups furthest from the master.
I feel like this might be wrong, or too cautious though.
What are you supposed to do?
Honestly, I've just never bothered to check myself on this because there's never any time and there's always a more complicated thing to learn.Comment
-
-
-
I do it similar way.For I2C, I've always steered towards using flyby topology with a single set of pullups furthest from the master.
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.Comment
-
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?Comment
-
Sorry, other forums have mentioned placing the resistors at the master. But the placement value is low at I2C rise/fall speeds.
It's so confusing with so many signal types requiring terminations at the end of the bus and so many others at the start of the bus.
I guess it depends on your application. Is there a chance that the end of the bus will be disconnected and leave the rest without pullups? Is the bus so long that the placement of the pullups actually matters?
Also, see if this helps.Comment
-
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.Comment
-
To quote Rick Hartley: "If the propagation delay is less then 1/4 of the rise time, you do not need termination."Comment
-
Originally posted by Lakshmi View PostComment
-
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
Comment
Comment