Backplanes and daughter boards. Connecting the same signal lines to a large number of boards/chips
in [Design]
|
Prev: Another burned transistor
Next: Nice circuit but...
From: Nial Stewart on 12 Aug 2010 08:33 > 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. 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.
From: Joel Koltner on 12 Aug 2010 13:59 "M. Hamed" <mhelshou(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. > 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. 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
From: markp on 12 Aug 2010 17:00 "M. Hamed" <mhelshou(a)hotmail.com> wrote in message news:6a206a7e-de35-4dbd-b785-e45643c05bc7(a)v35g2000prn.googlegroups.com... > 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. If you were implementing a parallel addressed asynchronous bus, possibly using your own protocol, then an off-the-shelf VME rack could speed up design time. Since you want serial I'd say it was OTT. Personally I would use a 4 wire RS485 along an impedance controlled backplane and use high speed UARTs (or possibly small FPGAs) and a micro on each card to convert to your local SPI interfaces and control the multiplexing. Using 4 wire RS485 means that you don't need to worry about when you turn the drivers on, so it can be treated as if it were a half duplex serial interface from the controller's end. If you are switching power on and off I agree with the sentiment of having a higher voltage supply on the backplane and regulate locally on the cards. BTW I believe FireWire is full duplex, as is USB 3.0. USB is possibility, there are 'helper' USB chips and device interface chips, but you do have some software issues and you'd need point-to-point connections via hubs (Linux supports USB though). Mark.
From: John Larkin on 12 Aug 2010 17:03 On Thu, 12 Aug 2010 22:00:08 +0100, "markp" <map.nospam(a)f2s.com> wrote: > >"M. Hamed" <mhelshou(a)hotmail.com> wrote in message >news:6a206a7e-de35-4dbd-b785-e45643c05bc7(a)v35g2000prn.googlegroups.com... >> 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. > >If you were implementing a parallel addressed asynchronous bus, possibly >using your own protocol, then an off-the-shelf VME rack could speed up >design time. Since you want serial I'd say it was OTT. Why? It's a backplane with a lot of bussed signals. You can use those wires for anything. You can buy a couple of crates on ebay and be experimenting in a week. All the hardware, panels, connectors, and PC board dims are standard. John
From: markp on 12 Aug 2010 17:35
"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message news:18o866tfr277krnv741d2bmqr574uqdfju(a)4ax.com... > On Thu, 12 Aug 2010 22:00:08 +0100, "markp" <map.nospam(a)f2s.com> > wrote: > >> >>"M. Hamed" <mhelshou(a)hotmail.com> wrote in message >>news:6a206a7e-de35-4dbd-b785-e45643c05bc7(a)v35g2000prn.googlegroups.com... >>> 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. >> >>If you were implementing a parallel addressed asynchronous bus, possibly >>using your own protocol, then an off-the-shelf VME rack could speed up >>design time. Since you want serial I'd say it was OTT. > > Why? It's a backplane with a lot of bussed signals. You can use those > wires for anything. You can buy a couple of crates on ebay and be > experimenting in a week. All the hardware, panels, connectors, and PC > board dims are standard. > > John > Well yes, the question was whether it was OTT - from a hardware point of view I think it is. However, if you do use a VME backplane for synchronous serial you have to be careful which signals you use. The data lines, for example, may not have particularly good crosstalk figures between them (they are designed to be driven at the same time, setlle then be strobed). So the AS*, DS0* and DS1* strobes are IMO the most suitable for clocks. The address bus has the same issue. With those caveats, a VME rack could be used, and as you say would speed things up a lot. Mark. |