Reducing EMI by slowing edge rates of signals that can tolerate these slower
edge rates is a typical use of ferrites.
For clocks, you have to look at the whole problem you're trying to solve.
Generally you want a monotonic rising/falling edge on clocks, and achieving
that requires a look at what is being driven. If it's point to point, as is
more and more common these days, then yes, a series R with a value selected so
that the driver 'impedance' plus series R equals the transmission line
impedance means that the wave front launched into the transmission line is 1/2
the steady state level (it's a voltage divider). This then is doubled at the
presumably high impedance load/receiver input and the full wave front reflects
back to the driver where it meets the expected impedance and there are no more
reflections.
This is academic, but I point it out because I (and many of you) have seen this
series R pop up in multi-drop topologies because the designer never really
understood this reflected wave concept. The result is that some loads see a
stair-step in the edge meaning it's not monotonic. For multi-drop topologies
(like flyby DDR), you need a driver that will launch the full height wave front
into the transmission line, and the termination is at the end with no
reflections. The driver is matched to its intended function, output impedance
wise.
Okay, but what about the edge rate of this clock? If you're driving a point to
point topology with minimal vias, you just have to keep the transmission line
consistent, which might include removing the ground layer under SMT pads on DC
blocking caps (and tuning vias so they're more transparent).
But if you're driving a multi-drop topology, the limit of the edge rate that
can be propagated depends on the topology. And here's the problem - you
sometimes end up with drivers that are simply too fast. And the root of the
problem is that the rise time is faster than that required for the frequency of
the clock you're trying to send. An example would be selecting a 'default'
driver for an FPGA DDR4 clock without simulating what it will look like at each
load. These drivers can have slew rates of less than 100ps, with frequency
content far beyond what is required for the clock. The result is high frequency
content reflecting off of every discontinuity, with each load seeing a
different waveform, possibly non-monotonic. The solution to driving this type
of topology is to select an appropriate slew rate - essentially matching the
bandwidth of the clock driver to the bandwidth of the topology being driven.
Time domain simulation is the easiest way to select the right driver for a
given design (by sweeping available drivers). You could also use frequency
domain analysis to find the bandwidth of the topology and use that as a guide
to selecting a driver with an appropriate slew rate / bandwidth.
Regarding using ferrites to adjust the slew rate, it might be possible to
select one to remove the higher frequency content, but selecting an appropriate
driver would be a more direct way to accomplish that.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Shimko, Steve (ES)
Sent: Monday, December 07, 2015 4:29 AM
To: tgsmith81@xxxxxxxxx; si-list@xxxxxxxxxxxxx; leeritchey@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EXT :Re: Ferrite Beads
We usually put a source termination resistor, 22 ohms to 33 ohms, at the output
of the clock oscillator, or even some other active device that may be receiving
the clock from an external source. This helps match the output impedance of
the oscillator or other device to the (nominally) 50 ohm signal trace.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Tim Smith
Sent: Sunday, December 06, 2015 9:58 PM
To: si-list@xxxxxxxxxxxxx; leeritchey@xxxxxxxxxxxxx
Subject: EXT :[SI-LIST] Re: Ferrite Beads
On 12/6/2015 8:07 PM, Lee Ritchey wrote:
Why would one deliberately degrade a signal that way?I have inherited this design; however I imagine that it was done in an attempt
On 12/6/2015 8:07 PM, Lee Ritchey wrote:
Why would one deliberately degrade a signal that way?
It was stated several posts back that it was intended to control the
edge rise time by that ...
