Another MEM11 update

Guy Sotomayor ggs at shiresoft.com
Sat Feb 20 23:25:07 CST 2016


Just to let everyone know, I'm making pretty good progress.

I just hit "code complete" on the FPGA.  That means I've written all of the
Verilog code for the FPGA that is the heart of the MEM11.  This includes
*all* of the Unibus functionality.  It all synthesizes for the FPGA and
the remaining warnings are all "understood" and best of all it *fits* in
my chosen FPGA.

Interrupts were fun because I had to figure out how to propagate the bus
grants from one (internal) device to the next since their ordering isn't 
fixed
(you can re-arrange the order of the interrupting devices...ie change their
slot order).  In addition, the interrupting devices aren't fixed to specific
request priority...so it ended up being a bit more complicated than I had
originally envisioned but once I sat down and thought about it and started
writing the code, it wasn't all that hard (just a lot of code).

DMA was just a pain but one good side effect is that I created a 1KW(*) FIFO
for DMA transactions and the DMA state machine will run as long as there
is data in the FIFO.  This means that the J1 only has to deal with DMA at
the start, end or when the FIFO needs refilling rather than on every word.
The DMA also has a programmable "delay" so that it won't swamp the Unibus
and starve the PDP-11 CPU.  For the RF11 (the only DMA device on the MEM11)
this will typically be set to the original transaction speed of the RF11 
disks
(for 60Hz machines that would be a word every 16us or 19.2us for 50Hz
machines).  There are configuration settings in the RF11 emulation that
specify the rotational speed of the RF11 disks as well as the DMA transfer
delay.

I'm now off to start writing a bunch of test cases for the various blocks so
that I can start to simulate the design.  Once I'm happy with the simulation
results, I'll start to create the schematic for the MEM11.

Because I'm so tight on pins (I'm using 129 out of the 158 I/O pins), I'm
having to use some of the "multi-function" pins.  The main implication is
that I might need to use a small CPLD so that I can switch between the
different functions.  The main set of multi-function pins that I have to 
use
are the ones used by the FPGA to load it's bit-stream on power on reset.
This is an understood problem and isn't something that I have to worry
about now.  The only impact will be in re-assigning pins so that low speed
I/Os (LEDs, and sense jumpers) are only shared with those pins.

I'll post another status update once I've made some significant progress on
the simulation and testing.

TTFN - Guy

(*) The reason that I chose a 1KW FIFO rather than something smaller is that
the "block RAM" in the FPGA comes in 18Kbit "chunks".  So the easiest course
was to use one of them configured as 1K x 16 (I'm ignoring the 2 
"parity" bits
in the "block RAM") as the memory for the FIFO.  Since I'm using less 
than half
of the "block RAMs" (all of the other used "block RAMs" are used for the 
RAM
for the J1) I can make the FIFO substantially larger if I need to.


More information about the cctech mailing list