From: keithw86 on
On Aug 11, 6:02 pm, "M. Hamed" <mhels...(a)hotmail.com> wrote:
> Hello there,
>
> I'm part of a team that has been assigned the task of designing a
> system consisting of a backplane and a number of daughter board. Each
> daughter board will have a large number of chips. The main board will
> need to communicate with one chip at a time but the communication
> lines will go to every single chip and it's up to a controller
> (possibly on the daughter board) to enable each chip individually.
>
> None of us has enough experience with stacks of boards or backplanes.
> We are worried that connecting one signal line to that many boards and
> chips will introduce too many signal integrity problems and
> capacitance that will make it impossible.
>
> We are not sure whether the best topology would be a backplane and a
> bunch of daughter boards connected via edge connectors or a stack of
> boards with each board plugging into the board below it and the bottom
> daughter board connecting to the backplane/motherboard. We think that
> the latter approach would be worse especially for the boards higher up
> in the stack of boards.
>
> Can someone provide some advice over how to go about designing this
> and what could be possible solutions? Are there any established design
> practices? Are there any technical terms we should be looking up or
> certain resources we should be consulting? As I mentioned we don't
> have enough experience with this kind of problem. Most of what we've
> done was single board systems.
>
> Help is appreciated! Thanks.

Is this a product, or test equipment? What's the life (expected
production of backplanes and cards)?

From: linnix on
On Aug 12, 5:33 am, "Nial Stewart"
<nial*REMOVE_TH...(a)nialstewartdevelopments.co.uk> wrote:
> > It's a serial bus (CLK+DATA) plus some other control signals that are
> > relatively constant. Communication is bidirectional. would the VME bus
> > be still relevant in this case?
>
> If I had to design something that was guaranteed to work I'd have a 'master'
> FPGA driving point to point LVDS/RS485 to each plug in position.

USB is guaranteed to work.

>
> I'd use discrete transceivers for each channel for robustness (instead of
> FPGA driven lvds).
>
> The 'master' FPGA can then receive commands from the main controller and
> do the multiplexing of messages to and from each plug in card.'

If I don't have the budget to reinvent the wheel, I would use COTS
ASICs such as USB host/devices/hubs. The master (host) can command
and control slaves (devices) in each endpoint with software. Hardware/
multiplexing are all done by the USB chips/protocols.



From: M. Hamed on
Thanks all for chipping in.

to answer a few questions:

1) Yes the protocol is SPI-like.

2) To clarify, This will function more as a test equipment with the
chips to be tested on the daughter board. It's not something that will
be marketed
but it's still in the phase of determining feasibility, and whether we
can design it in-house or we'd have to bring outside experience.

3) We would expect the backplane to last for years but it can be
revised or replaced when necessary. The daughter boards should be
easily replaced.

4) The protocol of communication is already defined by the chips on
the daughter boards so we don't have much leverage here.

5) As I mentioned before the bandwidth is somewhere from 5 MHz to 20
MHz

I also have some questions unanswered:

1) Would the VME bus be an overkill for this? is there a similar
standard for Synchronous Serial busses that I can get via off-the-
shelf boards?

2) I don't know if the USB to SPI would be applicable here since the
SPI protocol is bidirectional and I thought USB is polled only. We
also would like to mimic as much as possible the setup in which these
daughter boards will be deployed. I also kind of feel that USB would
be more complicated to deal with

3) The FPGA idea sounds interesting but I'd like the lines to be
bidirectional and would like to be able to vary the voltage for
reliability testing over
multiple voltages.

From all the responses it seems to me that this project may be more
involved than what we initially thought and may go beyond our skills.
But we were hoping that it would be a learning experience and
something we'd add to our arsenal. But if it turns out to be
infeasible we'd have to outsource help.
From: linnix on

> 2) I don't know if the USB to SPI would be applicable here since the
> SPI protocol is bidirectional and I thought USB is polled only.

Why?

USB to ethernet adapter can go in both directions, with synchronous
100Mbits on the ethernet side.
From: keithw86 on
On Aug 12, 12:18 pm, "M. Hamed" <mhels...(a)hotmail.com> wrote:
> Thanks all for chipping in.
>
> to answer a few questions:
>
> 1) Yes the protocol is SPI-like.

The performance is similar, too?

> 2) To clarify, This will function more as a test equipment with the
> chips to be tested on the daughter board. It's not something that will
> be marketed
> but it's still in the phase of determining feasibility, and whether we
> can design it in-house or we'd have to bring outside experience.

Then an existing backplane is the way to go. Given the number of
boards you need, VME is probably the best solution.

> 3) We would expect the backplane to last for years but it can be
> revised or replaced when necessary. The daughter boards should be
> easily replaced.

Again, this sounds like VME. These things have been available since
the year of the flood and will be here after cockroaches are extinct.

> 4) The protocol of communication is already defined by the chips on
> the daughter boards so we don't have much leverage here.

I may be an issue extending that infrastructure through connectors,
but maybe not.

> 5) As I mentioned before the bandwidth is somewhere from 5 MHz to 20
> MHz

Without some finer work, that may be pushing things. Since it is a
piece of test equipment the EMI requirements are a lot less, so you
have that going for you.

> I also have some questions unanswered:
>
> 1) Would the VME bus be an overkill for this? is there a similar
> standard for Synchronous Serial busses that I can get via off-the-
> shelf boards?

It may be overkill, but that's a good thing in this situation. Cost
isn't your primary object so whether it's overkill or not isn't all
that important.

> 2) I don't know if the USB to SPI would be applicable here since the
> SPI protocol is bidirectional and I thought USB is polled only. We
> also would like to mimic as much as possible the setup in which these
> daughter boards will be deployed. I also kind of feel that USB would
> be more complicated to deal with

SPI is bidirectional if you make it so, I guess. It's really master/
slave with separate MOSI/MISO.

> 3) The FPGA idea sounds interesting but I'd like the lines to be
> bidirectional and would like to be able to vary the voltage for
> reliability testing over
> multiple voltages.

FPGAs have a limited I/O voltage range, so that might work. I did a
"northbridge" sort of application once where the I/Os could be varied
for schmooing the processor.

> From all the responses it seems to me that this project may be more
> involved than what we initially thought and may go beyond our skills.
> But we were hoping that it would be a learning experience and
> something we'd add to our arsenal. But if it turns out to be
> infeasible we'd have to outsource help.

I don't know what your skills are, really, but I don't think it's that
big of a deal. Development for production is a different kettle,
though.