Backplanes and daughter boards. Connecting the same signal lines to a large number of boards/chips

Q#1: How many daughters?

Q#2: Are you sure they can't be serially communicated.

We're thinking perhaps 10-15 boards at a time.

Could you please elaborate? What would the topology be?

Is it a parallel bus or serial? What bandwidth do you need? Would RS485 do the job?

Stacking is going to cause a lot of signal integrity issues, I'd go for the backplane (like in a 3U or 6U rack)

If you are thinking parallel bus, the VMEbus backplane is a good example. Basically you need to control the impedance of the backplane PCB. VME backplanes are quite thick, and need termination resistor pairs on each line and at each end of the backplane (or you can use active termination). VME also defines the driver characteristics, and you can buy chips specifically for VME. There should only be one load on each signal, and the drivers mounted close to the connectors to minimise stub lengths (which are 3 row DIN41612 type for standard VME16 and VME32).

Mark.

BTW high speed parallel backplane design is a tricky subject and somewhat of a black art, you really need to know what you're doing to avoid problems. Also you'll need to test it thoroughly with some good test gear. You might find it quicker and easier to buy an off-the-shelf VME rack or backplane (such as those from BICC-VERO,) use the DIN41612 connectors and the VME driver chips on your cards, even if you end up implementing your own bus protocol instead of VME. At least that way you'll avoid some signal integrity issues.

Mark.

o

he

ine

ly

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?

The design I was thinking of is probably a backplane that has an on- board controller. The controller would receive commands from a PC through USB or serial. Each daughter board would be enabled one at a time using relays. Perhaps using MOSFETs for turning on power and relays for routing clock and data. Once a daughter board is enabled, another on-daughter-board controller (instructed by the main-board controller) would route the signals to each chip perhaps using analog switches or another set of relays. I don't know if this is too much from a signal integrity standpoint.

The serial bandwidth is somewhere from 5 MHz to 20 MHz, i.e. each serial clock would take from 50 ns to 200ns. The faster the better but we could make it slower if signal integrity problems are unsolvable at the high speed.

Does that sound reasonable? I'm also not sure how we would go about characterizing capacitances, impedances, and such.

I agree with Mark: use VME or some other standard bus/cardcage/connector convention. You can redefine the logic protocols and power voltages if you want, but you'd be starting with a structure that works.

Power mosfets on each board sounds sensible.

John

Should be manageable.

Sound like they are already serial SPI (SCK/SDA or SCK/MSI/MSO). SPI is more for point-to-point. USB is for point-to-multipoint.

Why can't you have independent USB to SPI controller on each board? Such as:

USB hubs: 1 main hub, 4 sub hubs.

One caveat, if you use a VME backplane (or any parallel backplane) you should use it as a parallel bus only and use the same strobe signals, data signals and address signals as VME does. The backplane may not have particularly good crosstalk figures between data or address lines (as they ususally are all generated at once and strobed once stable), so it's not a good idea to send individual clocks on them.

You could use a custom backplane with RS485 (i.e. differential serial) and power, your speeds are in the right ballpark for that. In this case you could have RS485 receivers on a card that grabs the packet, determines whether it was addressed, powers up the relevant logic on the card, passes the serial stuff on to the local device, then sends the reply back down the backplane.

Mark.

Having said that, it seems your serial interface is synchronous. The RS485 approach assumes asynchronous data (with a fast UART for reception and transmission on the cards and the controller). One problem you are going to face is skew between the clock and data in any synchronous system on the backplane, unless you Manchester encode or somehow embed the clock, but that will reduce your bandwidth.

Mark.

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.

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.

I did something similar with a product that wasn't very well defined when we started. The flexibility of the serial interfaces meant the data to and from each end point could easily be modified as the client came up with more functionality he wanted.

I was getting 50mbps across 30cm of 4 layer PCB with single ended transmission lines and source termination resistors. I also ran 10mbps down ribbon cable (alternating signals and grounds) over 2 metres with an LVDS clock, the rest single ended. I did a test with 10 metres of ribbon cable with no errors.

Keep it as simple as possible.

:-)

Nial.

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

Use One Clock to Rule them All.

John

er'

USB is guaranteed to work.

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.

First of all you need to determine what kind of bandwidth you need and how many modules need to be connected.

Another hint: have a power supply on each module and use a 12V central PSU to distribute power throught the backplane. Also make sure to use chips that allow for hot-swapping to connect to the backplane.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

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.

Why?

USB to ethernet adapter can go in both directions, with synchronous

100Mbits on the ethernet side.

Probably and "I don't know" -- but if you're just looking to build yourself a few proof-of-concept prototypes, using off-the-shelf VME racks will be cheaper than hiring outside help.

The other approach would be... spend the weekend reading, e.g., some book on signal integiry with good reviews from Amazon and just built a board and see what happens -- at the data rates you're talking about, there's a very good chance it'll just work fine.

USB is polled, but it's usually the controller IC (not the main CPU) that does the polling, so while you do lose on latency compared to truly bidirectinoal busses, USB isn't really as bad as you might initially think.

USB does have a much larger learning curve that some simple SPI-type peripheral.

If you have tight deadlines and aren't cash-strapped, by all means, find yourself a good consultant. If either of those isn't true, you'll learn a lot just trying it out on your own first...

---Joel

The performance is similar, too?

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

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

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

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.

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.

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

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.

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.

lf a

eaper

on

see

od

does

oal

Unless you are writing the OS, you don't really have to deal with much of that. The device side is relatively simple.

I am working with a technical instructor having students controlling multiple USB devices from a single PC with virtual com ports. If they can do it after several days of studying, why can't you? They don't have to understand the detail USB stack, just enough to use them.