From: linnix on
On Aug 12, 10:59 am, "Joel Koltner" <zapwireDASHgro...(a)yahoo.com>
wrote:
> "M. Hamed" <mhels...(a)hotmail.com> wrote in message
>
> news:6a206a7e-de35-4dbd-b785-e45643c05bc7(a)v35g2000prn.googlegroups.com...
>
> > 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?
>
> 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.
>
> > 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.
>
> 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.

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

>
> > 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
>
> USB does have a much larger learning curve that some simple SPI-type
> peripheral.
>
> > 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 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.

From: linnix on
On Aug 13, 2:35 pm, John Larkin
<jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
> On Thu, 12 Aug 2010 16:12:37 -0700, Rich Grise <richgr...(a)example.net>
> wrote:
>
>
>
> >On Thu, 12 Aug 2010 16:45:44 +0000, Nico Coesel wrote:
>
> >> "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.
>
> >> 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.
>
> >This sounds like a resurrection of the S-100 bus, which sucked because it
> >took all of Intel's crappy control signals and spread them on the bus, but
> >it did account for driving the bus, and terminating and buffering the
> >signals.
>
> >Just make sure your drivers have enough OOMPH, and terminate and buffer
> >the signals on the daughters; if you have timing concerns that 1/2 nsec
> >(6 inches) would screw up your synchronicity, then you should probably
> >look into that new PCI stuff or the kind of technology that they used with
> >ECL in the Cray and stuff.
>
> >Good Luck!
> >Rich
>
> The '100' in S100 happened because the guy who did it happened to have
> a bunch of 100 pin connectors around.
>
> John

Yes, I think I still have a couple of them somewhere in my storage. I
can build 25 USB devices on one board.
But the USB connectors are nicer to work with then S100/VME bus
connectors anyway.
From: linnix on
On Aug 13, 1:37 pm, n...(a)puntnl.niks (Nico Coesel) wrote:
> Rich Grise <richgr...(a)example.net> wrote:
> >On Thu, 12 Aug 2010 16:45:44 +0000, Nico Coesel wrote:
>
> >> "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.
>
> >> 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.
>
> >This sounds like a resurrection of the S-100 bus, which sucked because it
> >took all of Intel's crappy control signals and spread them on the bus, but
> >it did account for driving the bus, and terminating and buffering the
> >signals.
>
> I don't know about the S-100 bus. I just don't like to put
> address+data+control onto a backplane. Too many points of failure.
> Async serial (iow: UART) or manchester is much better since those
> methods allow for timing errors and are less sensitive to external
> influences.

I guess you are too young to remember. Those are the days when we
need a whole board for the CPU and another board for the UART. That's
why we need a backplane for A,D and C. Nowaday, we hardly need more
than half a board.