Backplanes and daughter boards. Connecting the same signal lines to a large number of boards/chips
in [Design]
|
Prev: 6 months with no result, No wonder why, you dumbasses are too SuperPower people.
Next: Printer server
From: John Larkin on 11 Aug 2010 22:25 On Wed, 11 Aug 2010 17:30:07 -0700 (PDT), "M. Hamed" <mhelshou(a)hotmail.com> wrote: >On Aug 11, 5:03�pm, "markp" <map.nos...(a)f2s.com> wrote: >> 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. > >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
From: markp on 12 Aug 2010 05:52 "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message news:llm666hf1tscbe0l973950acpnm3bra5jd(a)4ax.com... > On Wed, 11 Aug 2010 17:30:07 -0700 (PDT), "M. Hamed" > <mhelshou(a)hotmail.com> wrote: > >>On Aug 11, 5:03 pm, "markp" <map.nos...(a)f2s.com> wrote: >>> 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. >> >>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 > 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.
From: markp on 12 Aug 2010 06:10 "markp" <map.nospam(a)f2s.com> wrote in message news:8chuj7Fpm6U1(a)mid.individual.net... > > "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in > message news:llm666hf1tscbe0l973950acpnm3bra5jd(a)4ax.com... >> On Wed, 11 Aug 2010 17:30:07 -0700 (PDT), "M. Hamed" >> <mhelshou(a)hotmail.com> wrote: >> >>>On Aug 11, 5:03 pm, "markp" <map.nos...(a)f2s.com> wrote: >>>> 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. >>> >>>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 >> > > 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.
From: John Larkin on 12 Aug 2010 10:27
On Thu, 12 Aug 2010 11:10:24 +0100, "markp" <map.nospam(a)f2s.com> wrote: > >"markp" <map.nospam(a)f2s.com> wrote in message >news:8chuj7Fpm6U1(a)mid.individual.net... >> >> "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >> message news:llm666hf1tscbe0l973950acpnm3bra5jd(a)4ax.com... >>> On Wed, 11 Aug 2010 17:30:07 -0700 (PDT), "M. Hamed" >>> <mhelshou(a)hotmail.com> wrote: >>> >>>>On Aug 11, 5:03 pm, "markp" <map.nos...(a)f2s.com> wrote: >>>>> 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. >>>> >>>>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 >>> >> >> 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. > Use One Clock to Rule them All. John |