Re: SPI unterminated

From: Mac (foo_at_bar.net)
Date: 03/04/05 

Date: Fri, 04 Mar 2005 03:17:06 GMT

On Thu, 03 Mar 2005 15:47:35 +0000, Dave Boland wrote:

> I saw some postings about cards that have an SPI interface,
> which made me think about a few things relative to a project
> I'm doing. In this case, the plan is to run the SPI signal
> lines and three chip selects to some header pins. Up to
> three daughter cards can be stacked on the processor card,
> and some or all may have SPI devices.
>
> My concerns are for unterminated SPI lines and radiated EMI.
> Initial calculations look like reflections from an
> umterminated line shouldn't be a problem because a 12.5 MHz
> signal has a wave length of about 79 feet, which is much
> longer than trace lengths for the SPI bus. This ignores the
> effects of the rise time of the waveform though.

I agree. I'm not a real EMI/EMC expert or veteran, but I picked up a
little from some EMI engineers I used to work with at a big company that
did its own certifications.

If possible, I would put a series resistor at the clock driver (there is
only one clock driver, right?), and a small shunt cap at every clock load
(if you have control of that). Probably you will be able to just use a
zero ohm jumper for the resistor and leave the caps unpopulated, but if a
scan reveals problems, you'll be able to tweak the edge rate of the clock.

The data lines aren't as critical, but depending on the topology, you
could put series resistors near the data driver chips, too.

>
> I haven't attempted to deal with EMI at this stage of
> development, but it is always a concern.

Actually, you should incorporate EMI from fairly early in the design
phase. It affects pinouts, and chassis design and all kinds of things.

> This is especially
> true when a clock is passed from card to card and there will
> be a pin radiating the clock (top card on the stack).
>
> Has anyone done a design similar to this and got it through
> UL/CSA/IEC? If so, I would appreciate any helpful advice.
>
> Thanks,
> Dave

It sounds as though you are not using any cable, but just stacked boards
and board-to-board connectors. That's an assumption built-in to the
following comments.

Make sure the connector pinout provides good referencing for the clock
signal. You may want to put ground pins adjacent to the clock pin to
prevent cross-talk, and to provide good referencing. In the connector
pinout, you can use power pins as ground references, too, provided that
you have good decoupling of power to ground on both boards near the
connector.

Are the cards going to be inside of a metal box? A properly designed metal
enclosure is or can be a big part of the EMC solution. For example, my
first real design job was a memory mezzanine card which could be
stacked up to two high for a single-board computer. It had multiple single
ended 100 MHz clock lines which never shut off. When stacked one-high,
there was an unterminated 100 MHz clock pin. But the SBC goes inside a
chassis, and it passed EMI/EMC without any drama.

I think you will be able to get your board through testing (or at least I
don't think the SPI will stop you).

But if you would rather be safe than sorry, or if the signals are going
over cables, you could always switch to LVDS signalling, and put a
common-mode choke on each diff-pair right where it passes off-board.

If you use LVDS, you won't need to be quite as careful about referencing,
so you can get by with fewer ground and power pins. This will
partially offset the fact that you need two pins for every signal.

HTH,
Mac

Relevant Pages

  • Re: Spartan 3 Mapping Problem
    ... Each of the clock signals is LOCed to a dedicated clock IO pin. ... So I went in with the FPGA editor to do a little more investigation, and it sure looked like I could just pipe the clock signals from their points of origin to the proper BUFG with no problems. ... This configuration requires that the global clock site BUFGMUX7 either be empty or contain a global buffer or mux with the inputs IN0 and IN1 either not driven by a signal or driven by the same signals as the original muxes IN1 and IN0 pins respectively in order to route up both of the inputs. ...
    (comp.arch.fpga)
  • Re: clock multipliers, dividers, and more clocks...
    ... but the Lattice parts allow a clock source to be from ... Because of the long delay in the routing, ... Altera Cyclone devices have a limited number of pins connected to the ... external signals on the clock pins. ...
    (comp.arch.fpga)
  • Re: SPI unterminated
    ... this is just a card ... > only one clock driver, right?), and a small shunt cap at every clock load ... You may want to put ground pins adjacent to the clock pin to ... > But if you would rather be safe than sorry, or if the signals are going ...
    (sci.electronics.design)
  • Re: Mixed clocked/combinatorial coding styles (another thread)
    ... I don't consider my SPI code as finished but I've seen what ... of the SPI clock at the master where it *should* be for a normal SPI system. ... But does this choice force me to, for example, clock the CPU ... this clock frequency does not need to be used when communicating ...
    (comp.lang.vhdl)
  • Re: Mixed clocked/combinatorial coding styles (another thread)
    ... I don't consider my SPI code as finished but I've seen what ... of the SPI clock at the master where it *should* be for a normal SPI system. ... But does this choice force me to, for example, clock the CPU ... If that's not your case, then you've got a wimpy CPU, but in that situation you wouldn't have a clock divider, and the data handling would be done differently. ...
    (comp.lang.vhdl)