Yeah, well, don't get me started about Qbus timeouts. I designed the
Firefox Qbus adapter. It was an evil hideous hack, primarily because of
Qbus timeouts.
There were actually two Qbus adapters sold by DEC: their internally designed
"tape adapter" (the FTAM) and my Qbus adapter (the FQAM). The FTAM supported
only the TQK70 tape controller, and that was only because the TQK70 waits
about 20 microseconds before timing out a transaction. I have an RQDX3 that
was modified to work with the FTAM, but DEC didn't want to deliver that as
a product and they certainly didn't want to modify _everything_ to work
with the FTAM.
The difficulty with the Firefox is twofold: it uses write-back caches and
the cache has no invalid state. Since it uses write-back caches, a cache
which contains a copy of data newer than that stored in memory intervenes
in a transaction to supply the data. This is great, except it's really
slow; to get the data out of a cache, the module supplying the data has
to do a DMA request on its internal bus to get the data. This wouldn't
necessarily be a problem except for the bit about not having an invalid
state: once data gets into a cache, it's extraordinarily difficult to
get it back out again.
The Firefox is built around CVAX CPUs, so the internal bus used on all of
the modules is the CVAX pin-bus. When it became time to design the Qbus
adapter, the designer thought "Aha! All I have to do is slap a CQBIC (CVAX
to Qbus adapter IC) down on the board next to the FBIC (Firefox bus interface
chip) and wire them together!" Nope. A really annoying thing about the
CQBIC is that it does not have an actual real scatter-gather map; it just
has essentially a translation lookaside buffer. This means that it's
possible the FTAM has to do the following in response to a QBus DMA read:
- Evict whatever's in the FBIC's internal cache.
- Fetch the scatter/gather map entry, which is probably in somebody's
cache because it was just loaded with a mapping.
- Fetch the word that needs to be supplied for the Qbus read, which is
probably in somebody's cache because a program just wrote it into
the DMA buffer.
This can take an extraordinarily long amount of time on a write-back cache
bus without an invalid state. Lord help you if you have to wait for someone
else's transaction to another cache to finish before you can start yours.
Did I forget to mention that the Firefox bus has a fair arbitration scheme
to prevent bus hogging? That makes it even longer. I've seen it take
12 microseconds for the FBIC to cough up data!
By the time I got involved, they had already tried the obvious hack of
modding the FBIC to allow the QBus to have absolute priority in the bus
arbitration. That was nice because it helped me out. To tame the Firefox
bus, the FQAM had two key items: a complete on-board scatter/gather map
and a bogus transaction generator to keep everyone else off the bus while
QBus DMA was going on.
The bogus transaction generator was started whenever a QBus device requested
the bus. It kept the bus busy with short transactions so the FQAM could
guarantee that it wouldn't have to wait for someone else's outrageously long
transaction to complete before it could start its own transaction. It did,
however, mean that nothing else happened in the system while the QBus was
granted to a DMA device even if the DMA device wasn't doing anything with
the bus. In addition to shutting down the entire bus during DMA, the FQAM
itself was slow; I was only ever able to get about 250KB/s through the
thing.
The heart of the FQAM was a microcoded state machine built from registered
PROMs. To compile the microcode, I wrote a bunch of macros for MACRO32 that
turned it into my own personal microcode language. It took my poor little
MicroVAX 2000 half an hour to assemble my microcode, which wound up being
about 512 words. Try to explain the power of a true macro assembler to a
Unix person and they just look at you funny.
Anyway, AFAIK I'm the only person outside of DEC that ever designed to
the Firefox bus and I did two of them: the FQAM and MasPar's front-end
interface (MasPar got a really good deal from DEC on Firefoxes, but it
didn't take them long to move to using the DECstation 5000 as the
front end).
--
Roger Ivie
rivie_at_teraglobal.com
Not speaking for TeraGlobal Communications Corporation
Received on Fri Jun 09 2000 - 10:49:05 BST