MEM11 Status Update

[Guy Sotomayor]

Yes, it'll be useful for anything you want and will work in any Unibus 
PDP-11.  The original motivation was to allow Unix V1 to run on an 11/20 
without requiring an expansion chassis or trying to find unobtainium 
devices (how may RF11/RS11s have you come across?).

TTFN - Guy

On 1/19/15 11:10 PM, Mike Ross wrote:
> Splendid news Guy!
>
> I presume this won't be restricted to just the 11/20, and just Unix V1.0?
> It will, tweaked as necessary, have more general utility?
>
> If so, the question won't be 'if?', it'll be 'how many can I afford??!!' :-)
>
> Mike
>
> On Tue, Jan 20, 2015 at 6:27 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
>
>> 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
>>
>>
>>
>