- Hey, everybody. Welcome to Altium Academy. I am your host, Zach Peterson, also your local technical
consultant for Altium. And today, we are gonna go over two important digital protocols that are used in most integrated circuits. And those protocols are I2C, or Inter-Integrated Circuit protocol, and SPI, Serial Peripheral Interface. So these two protocols are very common. And what we want to do in this video is look at how they are
implemented on a PCB and some of the factors that
influence their operation. So that's what we're gonna get into today. Let's go ahead and get started. (upbeat music) So to get started, let's
take a look at I2C. So we're not gonna look
at the signaling format or the addressing format
or anything like that, but really what I wanna look
at what happens on the PCB. So if you are inside your schematic and you're gonna wire up two
components with an I2C bus, you'll see two signals coming
off of the main controller. So the first is serial data or SDA, and then the second one
is serial clock or SCK. These two signals essentially come out in this kind of topology. So here we have, let's say, an ASIC, so this is one of our peripherals, and we're pulling data
directly off of this line. We're pulling the clock
directly off of this line. And then we could go down to another ASIC over here, let's say, is gonna be ASIC number 2. And it's also gonna do the same thing. It's gonna pull data
directly off of this line, pull data directly off of this line. Pretty simple. So this is one of the
things that makes it so easy to wire up an schematic,
as well as on a PCB. You can essentially just pull signals right off of these main buses and pull data directly
into your peripheral. Once you actually have
this wired up like this, there are some things you have to do because of the way that
an I2C protocol works. So I2C works as an open drain protocol. So if we look at the clock
signal just as an example, inside of the controller, you have what is essentially a transistor, you have this end
connected back to ground, and then there's a control signal here that toggles the transistor on and off. Now, when the transistor is toggled on, what it's gonna do is it's going to pull all of the charge off of this
bus and dump it into ground. Now, all of that charge
that is given to this line comes from a power bus. So each of these lines is also connected up here to a power bus. And this could actually be
built into this component, but that's not very common that at all. Normally, it's just like this
with some pull-up resistors. So the reason that you have
these pull-up resistors is because you are pulling
up the maximum voltage of these lines up to whatever
the power bus voltage is. But these resistors will
then limit the current that flows through this
bus and in the ground when this transistor is toggled on. So when this transistor is toggled on, the current path is essentially like this. When it's toggled off, the current path is essentially like this,
wherever the destination chip is. So essentially goes over here like this. (gentle music) So the next thing that we wanna look at is what determines the rise
time for signals on this bus. Because, as you know with digital signals, the rise time of that
signal will then determine whether or not we need to
implement this bus on a PCB with some of these standard high speed digital design practices. Well, as it turns out,
it's not just the resistors that determine the rise time on the bus. There is also some bus capacitance back to ground for both of these lines. So this line also has this
open drain configuration, and it has some bus capacitance,
which we can label C sub B. So the total capacitance
on the bus C sub B, multiplied by whatever the value of this pull-up resistor is, is going to give us a time constant. So if you're familiar with RC circuits, you know that they have a time constant. And so the rise time is
going to be proportional to this term here, this RC value. These values could be on
the order of anywhere from, let's say, about 100 nanoseconds, all the way up to a microsecond. So these signals are actually quite slow. So because these signals are
quite slow, in most cases, you actually don't need
to worry about doing anything like impedance
matching on this type of bus, and you don't have to design this bus with controlled impedance at 50 ohms or any other particular value. So that's one of the things that makes I2C so easy to use in a PCB. So just because this bus is running at rise times of, say, 100 nanoseconds or up to 1 microsecond in the longer case, doesn't mean that it's
impervious to crosstalk. I2C buses can still receive crosstalk just like any other trace in your PCB. So if you have a trace running nearby that's carrying a fast signal, that signal can still inject noise into the traces on your I2C bus. So just to summarize,
with these I2C buses, you don't necessarily have
to worry about impedance and you don't have to
worry about matching. You don't have to worry about any of that. And so, because of that, it's very easy to lay
this out and route this. And I've even read some accounts on forums and, like, on Stack
Exchange of people saying that I2C is pretty difficult
to route incorrectly. (gentle music) So next, let's look at the SPI protocol. So in SPI, I have my controller here. It has at least three pins coming off. So if you just have one peripheral, you only need three pins, but in general, there will be four pins,
or at least four pins. So here, we have our Master In Slave Out, we have our Master Out Slave In, and then we have a clock,
SCK, sometimes SCOK, just depends which data
sheet you're reading. And then we have a set of CS pins. So the CS pins, there
could be more than one pin. You could also toggle
some other peripherals using GPIOs as chip select pins. In this controller, I'm then going off to, let's say, this is gonna
be peripheral number 1, and we'll have, let's say,
another one down here, peripheral number 2. Now, in this case, these can
just route straight across. And then, we also pull off
on each of these signals. And then, we go down here
to peripheral number 2. Now, the chip select pins, you could actually have
chip select number 1, chip select number 2,
whatever the case may be. And that ship select pin is just gonna go to each one of these peripherals. And that is how you select
which of these two peripherals is supposed to receive this data, and then do something with it, and then give a reply back
into these different pins. So the Master In Slave Out, this is your input onto your controller, and the rest of these are all outputs. And that's how this peripheral works in terms of its topology. Now, SPI can run a much faster data rate. And in fact, if you look at some data sheets for some components that have an SPI
interface built into them, you will again see that the
rise times can be much faster. Now, the rise time on this SPI bus is going to be determined
by the load capacitance that's connected to
each one of these lines. So what is load capacitance? In these destination components
or in these peripherals, their inputs are capacitive inputs, and that capacitance acts like the load on each of these lines. So that load capacitance
will determine the rise time of a signal operating on this bus. And if you look at some data sheets, you'll actually see numbers down on the order of, like, 1 or 2 nanoseconds. Now, the rise time on an SPI bus doesn't necessarily work the same way as it does on an I2C bus. SPI buses are push-pull topology. So they have a push-pull driver integrated into each side of the bus. And that push-pull circuit is essentially just a CMOS buffer. So it's not like an
open drain configuration with a control signal. That push-pull circuit can actually source a very fast signal depending on the value of the load capacitance
that's connected to the bus. So each of these peripherals has an input on this side of the
bus that is capacitive, and it has what we call
some load capacitance. So some values that you might see in a data sheet are
maybe like 50 picofarads, something on the order of picofarads. So the rise time for
signals on the SPI bus are gonna be proportional
to this load capacitance. We'll call it C sub L. So this load capacitance
will determine the rise time. And if you look in data sheets for a driver component that
has an SPI interface in it, what you'll actually find is
you'll find a rise time value that is specified for a
given load capacitance. So some example values that you might see are something as small
as like 1 nanosecond, which will be specified
for a load capacitance of, let's say, like, 50 picofarads,
or something like this. So they will give you
a few different values and they'll pair those up. It's basically your job as a designer to know what the load
capacitance is on your bus in order to then determine
what the rise time is for the signals that are
being sent out on this bus. (gentle music) So what this all means is that if we have a
larger load capacitance, meaning that we just make the bus larger, or we're using components that have a larger load capacitance, or maybe we have more components, so we have multiple load
capacitances in parallel, we're increasing this load capacitance, it's gonna take longer
to charge in general, and that means our rise
time is going to go up. We're gonna have a longer rise time. Now, because you can see values like 1 nanosecond rise time in data sheets for kind of an arbitrary
load capacitance here, it's natural to start thinking
that SPI is going to start to need high speed design practices, like controlled impedance and termination. So one question that is
actually quite common out there is whether or not you
should actually do this. So the first thing to note
about the SPI protocol is there isn't an actual
impedance specification. And so what I mean by that is if you look in, like, a data sheet or you
look in an application note or you look online on forums,
you may see people say that SPI needs to have
controlled impedance. However, there is no
specific impedance value that you have to design to. So in other words, there's
no standard here forcing you to make each of these
traces on this bus 50 ohms. So contrast that with
something like, let's say, USB. USB has a specific impedance requirement. You have to size those
traces and space them out, such that, you hit
specific impedance values. That's not the case with SPI. You have a little bit of
freedom to design the bus in order to hit your requirements if you happen to be
operating in this regime where this bus is so long that you then need to
implement termination. So in general, the output impedance here at this side of the bus is gonna be low. It's gonna be maybe 10
ohms to maybe 30 ohms. And it really depends
on the drive strength of the signals that are being sourced here and then the current, and
then using those values, you can figure out approximately what this output impedance is. Now, let's just suppose for a moment that you're operating on a bus that has a 1 nanosecond rise
time in the extreme case, and you've designed your PCB
such that it's large enough that this 1 nanosecond
rise time forces you to then implement high
speed design practices because these traces are now
acting like transmission lines. Well, then in that case, you would need to put some
series resistors here. Now, this is actually pretty uncommon. And one thing that I've seen
in some design guidelines is the statement from different designers and even from some
application notes saying that you should always put
these series resistors here and you would actually
put them at the driver. So this one would actually go back here. And then same thing with this meso signal. It would actually go back here. So these would be your
series termination resistors. What these things do is they
not only match impedance, assuming that you've designed this trace to a specific impedance, but they actually slow down the bus. And so it's a little ironic that these series resistors
not just match impedance, but by slowing down the
bus, they create a situation where you no longer really
need the impedance control. So the main point of putting
these series resistors here is actually to slow this down and to get you to a situation where this is no longer
acting like a high speed bus. So instead of 1 nanosecond
here, typically, you may find a, let's say, 22 or 33 ohm
series resistor here on these outputs, and
then that could bring your 1 nanosecond rise time up to maybe something like
10 or 20 nanoseconds. So then in that case, the
signal's gonna be much slower, it's gonna create much less crosstalk, has the additional benefit
of on a very long bus, having impedance matching
here right at this interface between the output side of this resistor and then the rest of the trace going on to the rest of the bus. So the takeaway from all of this with SPI is just to be careful. If you see someone saying that you have to use impedance matching or that you have to route it
with controlled impedance, they don't always actually state what that specific impedance value is. So just be skeptical of those guidelines. And remember that half
the reason you place these series resistors is
to slow down the signal. Now, you don't wanna slow
down the signal too much because if that signal
rise time starts to violate set up and hold times at the
receiver, the logic circuit and that receiver is not
going to toggle properly and the bus may not work at all. So be careful of that. Don't use too large resistors here because they do slow it down too much to the point where the receiving
component can't read data and can't read the clock signal anymore. So we have some great resources
linked in the description. You can find a couple of
articles that describe this issue with trace impedance on SPI buses. Also, we've got a great guide from Mark Harris linked in the description that goes over the signaling
format used in SPI buses. And for those of you that
are gonna be programming any drivers that then need
to operate over an SPI bus, that is gonna be a great resource for you. So I encourage you to check
out both of those resources. All right, thanks everybody
for watching this video. Make sure to hit that Subscribe button, hit that Like button. If you have any questions
on this, don't hesitate, leave them in the comments section. We love getting your
questions and comments. And of course, you can send your questions and comments over to youtube@altium.com. We get a lot of questions and comments, but I always make sure to
check youtube@altium.com for any of those that need
to come straight to me. Okay. Thanks again, everybody. And last but not least, don't forget to call
your fabricator, folks. (ominous echoing thud)
