On Jan 5, 2014, at 10:19, Al Kossow <aek at bitsavers.org> wrote:
On 12/28/13 6:54 PM, Philipp Hachtmann wrote:
I once "tried" to count the amount of
bus drivers and receivers to cover *ALL* on the Omnibus. Lots of signals. But having an
FPGA with full access would be quite handy.
I thought some more about the form factor last night, and it occurred to me that using a
mezanine is a waste of PCB space.
You can fabricate two boards connected with one or two pair of right angle DIN-96
connectors and stiffen the joint with two
small steel flats that have been tapped for four screws that attach to the edges just
inside the card guide space.
The bars wouldn't go up far enough to interfere with the .1" connectors coming
out the side.
I got the idea from Brad's disk interface; you don't need the boards to be a
normal quad board height.
At 5 or 10 dollars a square inch from OSH Park that is a big difference in board cost. It
might even be possible to
use the same top board with different bus interface boards if I can get the signals and
power/ground pins to route so they
don't interfere. I was also thinking of trying to make all of the FPGA ins and outs
to the card unidirectional. That sort
of falls out from using DS3662's and 74vhct541's as the level shifter and bus
driver/receiver pair.
I came to pretty much the same conclusion for QBUS.
It takes 42 drivers and 44 receivers (assuming your
board will never be driving POK or DCOK, which seemed
like a reasonable assumption). I'm using a high-speed
comparator for the input buffer, though, since the
DEC spec is 1.5v threshold, far away from any current
manufacture ICs. Comparators of appropriate specification
turn out to be expensive, though; even in quad gate
packages, they tend to be around a dollar a gate.
My current paddle board design (not yet fabricated) connects
to the host via a 40-pin ribbon cable, and supports 80-
conductor ATA cables (there are some ground pins
internally tied together in those, so you lose some
functional pins). It gives me a design that can be used for
both QBUS and UNIBUS using the same host, though.
> I'd think of using a larger FPGA instead of an external ARM SoC.
Currently, the QBUS adaptor fits nicely in a small
"CPLD" (in quotes because the MAX II and V families are
actually just very small FPGAs). The current design requires
an FPGA or another CPLD on the host end for the very
timing-critical custom bus, but that still is easy to bolt on
to a micro.
- Dave