31 Dec
2008
31 Dec
'08
6:14 p.m.
Guy Sotomayor <ggs at shiresoft.com> wrote:
The problem with replacing the cache is that it is composed of 4 hex
boards (M8142, M8143, M8144 and M8145). I haven't looked at the
backplane signals, but I'm dubious that it could be done with less.
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.
On Dec 31, 2008, at 8:16 AM, Ethan Dicks wrote:
>> Skip the memory bus and the original cache. The original cache is
>> just 2 KB
>> of 2-way associative memory. If you set up a 4 MB cache, the CPU
>> can run at
>> full steam the whole time, with a cycle time of about 150 nS, if I
>> remember
>> right.
> Handy, since 70ns SRAM is easy to find.
True. And 70ns is definitely fast enough.
It is more complicated, though. You'll have access
paths from CPU,
Unibus
and four massbus controllers to deal with. But it should definitely
be
doable (heck, SETASI have already done it once).
I might be interested in such a project myself, since the 11/70s we
have
around here still are on MK11 boxes. I could deal with PCBs and
design, but
I'm very short on time, as usual... :-(
No experience at all with FPGAs or any such fancy stuff.
If such a thing were to
be designed (I could participate in the design
phase, but not drive it), I'd probably be interested in two,
especially if the blank board was only a few hundred dollars. If it
came closer to $1000, I'd really have to think about passing on the
second one (I used to order multi-layer DEC backplane boards, and at
the time, $500 was a good price for orders between q10 and q100, but
things in the PCB market have changed radically).
I'm in no hurry - my 11/70s are in storage and I won't be able to even
pull them out to look at them in the next 90 days. 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.
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.
70ns memory will definitely be sufficient for whatever we would design.
Surface mount or through? Well, I don't really have much of a
preference. Of course, through hole is easier to solder, test and
repair, but they do take more space. And I can do either.
My cad program have extensive libraries for all of it, so that's not a
problem.
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.
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.
But of course, since I'm not offering to do this, except as a spare time
project to aid in a community effort (unless I could actually make up
for the time I would spend on it, and I somehow doubt there is a
commercial case for this nowadays). So if anyone else wants to design a
memory card to hook to the 11/70 memory bus, I definitely won't stop
them, and might try to atleast give some helpful comments.
Johnny
1 Jan
1 Jan
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
5595
days inactive
5595
days old
1 comments
2 participants
participants (2)
-
bqt＠softjar.se -
ggs＠shiresoft.com