1 Jan
2009
1 Jan
'09
10:26 a.m.
On Dec 31, 2008, at 6:14 PM, Johnny Billquist wrote:
Correct. The cache and memory controller is a total of four cards.
But unless my memory fails me, all the signals needed are actually
located in just two of the slots. So you'd have to go with a two
card solution. Either one card and paddles, or two cards with
interconnects.
Actually, they used some surface mount for the memory chips. The
memory was pretty dense on that board but certainly not the majority
of the area.
The advantage of just replacing the MK11 boxes,
is that it could
be done with just one board. Depending upon signaling and such
(and with sufficient integration - ie FPGAs and SMTs) it *might*
even fit on a quad board vs hex.
Oh, it could definitely be done with just one quad board. The memory
bus is really simple.
It's just that you won't get much of a speed gain that way, so it
will mostly be a space and power save thing.
Not at all as interesting, atleast not from my point of view.
You can probably get it all in with through holes on a quad card even.
The memory bus is really simple to interface. And since you'll keep
it in the CPU box, and have the full 4 megs on one card, you can
ignore all the requirements of the bus drivers for the memory bus as
well.
The 11/70 memory bus is otherwise designed for quite a long signal
path. Total max was two cabinets full of memory boxes, or eight of
them. That would get it close to ten feet. Power was accordingly.
So, while not Unibus, there are drivers and terminators on that bus
as well. (Actually, the terminators are the same as those small
cards that terminate a massbus, if anyone ever disassembled one of
those.)
Remember, SETASI did this on a hex card something like 20 years ago,
if not more. Most of the area was probably memory chips, which can
be reduced extremely much by now.
But, as I said, I don't find that exercise very interesting.
I've a rough design right now. I spent some time last night thinking
about this and I have it pretty much blocked out (modulo timing issues
- but that's the great thing about designing with FPGAs - if I miss
something w.r.t. timing, I just have to load a new "program"). I'll
see how much spare time I have in the next few weeks and see how far I
can get.
The other issue with not replacing the cache, is
that the verilog
to implement this would *much* simpler (ie it can probably be
completed faster).
True. Simple stuff is always faster to actually do. :-) And to make a few comments on other stuff that's
been mentioned.
You don't seem to appreciate the speed of things on the memory bus.
A read cycle form the MK11 was typically something like 600ns, and
could be as much as 1200ns (when error correction was required), if
I remember right. Write was just as bad, while modify was worse. The
max speed possible is still much lower than 150 ns, which is what
the CPU will run at when you have cache hits (assuming my memory is
right). There is setups, handshakes and signal propagations on a big
bus involved.
I thought that was driven by the memory and not the memory bus. There
appear to be some minimum timings (50ns & 100ns pulses) but from what
I could tell from the docs, the speed was dictated by the MK11s and
not necessarily the memory bus. Of course there are deskew times as
well. I'll have to go into it in more detail though.
If this were 15-20 years ago, I'd agree that speed would be a
principle concern, but space and power seem to be more important these
days. Given that this solution (just like the PEP-70/Hypercache) is
completely reversible I don't see a fundamental problem with this
approach.
I mostly do this stuff out of interest in preserving the systems in as
much of a runnable state as possible. All of the the 11/70s I
acquired over the past few years have been CPUs only. There have been
no memory boxes (or peripherals of any kind). I haven't been
particularly worried about this issue since I also managed to acquire
a fair number of PEP-70's & Hypercaches. But I suspect there may be
other people out there that aren't as fortunate and want to run an
11/70 without having to have large numbers of racks. I don't worry
too much about space/power since I am restoring a 2065 after all and
11's pale in comparison (but I'm also planning to do a memory
replacement for that too which is where I discovered the SSRAMs since
they are the perfect geometry for a '10).
70ns memory will definitely be sufficient for whatever we would
design.
I plan on using 200Mhz SSRAMs 'cause they're relatively easy to
interface to. Of course, this is way overkill (5ns memory access
times) for this but they're cheap (~$8/ea and only 2 would be
needed). I probably won't clock it that fast. I figure something on
the order of a 40MHz base clock (25ns) would give me enough
granularity for any timing that would need to be done.
I very much doubt that we'd have any problems getting it all into
one or two cards.
One advantage of replacing the cache is that then we'd definitely
just talk TTL. No buses with drivers at all.
Much simpler and cheaper from that point of view.
The driver/receivers are my principle concern. I did find a bus
transceiver last night that's open-collector on one side and tri-state
on the other. That simplifies things *alot* if it's compatible
(though I suspect that with a 4-8" run of cables almost anything would
work). Now if I could just find one that was LVTTL on the tri-state
side I'd be happy (it would eliminate level shifters). :-)
Absolutely best would of course be if we could find drawings for the
HC-70/PEP-70 combination, and use those as the basis for a design,
and just improve by using current available technology.
That would be ideal. However, does anyone have drawings for the
MK11? The most I could find was the tech manual on Bitsavers. I
mainly want to understand the transceivers a bit more.
TTFN - Guy