Memory/cache on the 11/70
bqt at softjar.se
Thu Jan 1 16:46:37 CST 2009
Guy Sotomayor <ggs at shiresoft.com> wrote:
> On Dec 31, 2008, at 6:14 PM, Johnny Billquist wrote:
>> 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.
> 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.
Still, the level of integration today is much higher. So if it could be
done 20 years ago, it should definitely not be a problem today.
>> 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.
There are built in limitation in the bus which always will cause it to
be much slower than running against cache. This should be obvious when
we talk about an asynchronous bus. You have a protocol with handshakes
and acknowledges that goes back and forth for each memory access. And
each of those phases of the protocol needs a minimum time.
Of course, the 600ns minimum times of the MK11 are are partially because
of the limitations of the MK11, but exactly how much you should blame
each half for is unknown.
After all, the access times for the memory chips in the MK11 box are not
anywhere near 600ns.
> 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
Me neither. As I said before, if someone wants to do it, I'll definitely
not try to prevent it.
But it's not something that I find particularly interesting myself.
> 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).
Well, both the 11/70s around here have enough memory as it is, so that
if anything, it's the speedup that I'd be interested in.
Power...? Well, we have two -2060s, as well as two VAX-8650 around as
well. Compared to those, the 11/70s are nothing. :-)
The biggest power consumer is the memory system of the DEC-20 by the
way. It uses a linear power supply... Heavy as hell as well. :-)
(I couldn't possibly talk you out of a HC-70/PEP-70 combo would I?
Anything you might want in return?)
>> 70ns memory will definitely be sufficient for whatever we would
> 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.
Definitely overkill. But there is nothing wrong with overkill, as long
as it don't cost a lot extra.
>> 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.
I think I have the drawings somewhere, along with a bunch of manuals
that aren't on bitsavers either.
One of these years I really should try to get it scanned, or
something... (Along with a bunch of other documentation that I have
lying around for various DEC stuff...)
And as someone else said, the MJ11 drawings should also be good for the
information you're asking for.
(And yes, I've kept one real MJ11 around, just for nostalgia. But it's
not hooked up.)
I also have some third party memory boxes. I think they were made by
Plessey. You could try find something from there as well.
More information about the cctech