Prev: Another burned transistor
Next: Nice circuit but...
From: markp on 12 Aug 2010 17:45 "markp" <map.nospam(a)f2s.com> wrote in message news:8cj7phFk2fU1(a)mid.individual.net... > > "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. Having said that, the VMEbus also has SERCLK and SERDAT* signals (up to 32MHz) that could be hijacked for this, in which case you have a ready made synchronous serial backplane. Mark. |