MEM11 Status Update

[Guy Sotomayor]

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