20 Jan
2015
20 Jan
'15
5:27 a.m.
As some of you know I've been working (on and off again) a
multi-function Unibus board that contains all of the more difficult
items to allow a PDP-11/20 to run Unix V1 entirely within the CPU
chassis. Other than the CPU and the RK11-D controller, everything else
will be on the MEM11 board. Here's the background on what the MEM11 is
and the current progress.
What's on the board is the following:
* Up to 124KW of non-volatile memory
* Console Emulator ROM
* 4 Boot ROMs selected from 32 images on the board
* 2 DL11 SLUs
* RF11 controller with non-volatile memory emulating 8 RS11 drives
* KE11 EAE
* KW11K
* KW11L
* KW11P
* KW11W
I know I went overboard with the KW11s as only the KW11L (line-time
clock) is needed.
Early on, because of the number of devices and trying to fit all of this
on a SPC-sized board so it can fit in the 11/20 chassis (can't fit in
hex sized cards) I decided to "soft" configure everything. That is, all
of the configuration of the MEM11 will be done over one of the serial
ports. To get everything to fit on a board that small, I would need to
have a reasonable level of integration. This meant that I would be
using an FPGA and with a few exceptions all components will be SMT
(sorry folks, no kits on this one).
I originally thought I would do everything in Verilog with no
microprocessor (for a whole host of reasons). I quickly realized that
my Verilog coding skills were not up to a task that large so I put the
project on hold while I regrouped. I figured that I would have to
integrate some sort of microprocessor core into the FPGA but was not
happy with any that I was finding. They were either very simple cores
with poor tools support or very complex (ie big) cores that had
reasonable tools.
About 18 months ago, I came across a paper by James Bowman titled "J1: a
small Forth core for FPGAs". Best of all it was implemented in about
200 lines of Verilog (ie it was incredibly small). Also available was a
complete cross environment (written in Forth of course). It produced
very tight code. I spent a while trying to understand the J1, the cross
build environment and getting familiar with Forth again.
I got serious in November 2014 in laying out the structure of how to put
everything together. I decided that the J1 would be fast enough (should
see ~100MIPs on the FPGA I plan to use) to actually do most of the
device emulation code in Forth with only enough Verilog to offload some
of the more performance critical bits. For example, the J1 is fast
enough to actually receive the Unibus transaction, read a word from the
FRAM and complete the Unibus transaction and still be close to maximum
Unibus throughput.
I've spent most of my time writing Forth code to implement the emulation
of the devices and the configuration UI. I decided that by writing the
Forth code first, I would have a pretty good idea of how everything will
go together. What the H/W will look like will fall out from that and if
I do have to change the H/W interface only small changes will need to be
made to the S/W. Forth lends itself to building up from a very low level
to a high level where the high level is isolated from many of the low
level details.
I've been coding furiously. As of tonight I have ~60% of the emulation
code written and 100% of the configuration UI (and it all builds). I'll
be working on finishing off the emulation code and then starting on the
Verilog. Since I want to get familiar with running the J1 in a real
FPGA, I'll be building code and testing the configuration UI on one of
my FPGA development boards. This also has the advantage of having
(mostly) tested code when I actually have real MEM11 hardware.
A few comments on the capabilities. Everything is configurable through
the configuration UI (ie you'll be able to change everything regarding
what devices are enabled, what they're base addresses are, the interrupt
vector, priority, frequency of the line clock, etc, etc). Basically, as
I've been reading up on the devices, if there's a jumper or option on
the device, there will be a way to set it through the configuration UI.
I also decided that to upload/download ROM images, memory images, etc
that I would provide XMODEM capabilities.
One thing that I decided on was that I wanted to be able to send code
updates to folks and not require them to have a JTAG probe in order to
perform an update (and hence the desire for XMODEM). So the code in the
FPGA is basically just a boot-loader that loads an image from an area of
non-volatile memory on the board. I'm allowing for 4 J1 images (16KB
each...the code address space for the J1) plus a "safe" boot image that
no matter how screwed up everything is, you'll be able to fall back to
that image.
As I was competing the configuration UI, I found that I couldn't have
both the configuration UI and the emulation code both fit in 16K
(strings take up a lot of space). By the time I was done with the
configuration UI I was hitting up against the 16K limit (presently
there's about 200 bytes free and there's a bit more refactoring that I
could do if I need to get really aggressive). So my insight in having a
boot loader and organizing along those lines paid off. ;-)
I'm sure there are a number of folks who will want one and are eager to
know what it'll cost. ;-)
I have a basic BOM for the MEM11, but I haven't cost it out in a while
so while I *think* I know what it'll cost to produce, I'm not going to
give out pricing (even though a few folks know what my target is) until
after I have a prototype built and working.
Also, since there will be a high level of integration, I'm only going to
offer this only as a fully assembled and tested unit with all of the
FPGA programming, ROM emulation images, J1 code images and a reasonable
configuration setup.
As I said, as of tonight, I've finished the configuration UI. I'll be
working on finishing up the emulation code. This is the biggest risk
since I won't really be able to test the emulation code until I have an
actual prototype board built. Once all of the code is written, I'll be
working on the Verilog. During all of this, I'll be doing some testing
on my FPGA evaluation board.
Given my progress so far, I'm hoping (fingers crossed) to be testing a
prototype some time in June/July 2015. Once I have the prototype
tested, I'll have a good idea of the remaining work that needs to be
done. At that point, I'll let folks know what the cost will be and will
start to take orders. Once I have a reasonable number of (committed)
orders, I'll do a production run.
Ok, so this has been much longer than I expected. ;-)
I'll update folks as the project progresses.
TTFN - Guy