MEM11 Update

[Guy Sotomayor]

On 7/21/15 6:25 AM, Noel Chiappa wrote:
> It was interesting to re-read your original message; I and a couple of other
> people are looking into doing a QBUS card to provide access to modern
> non-volatile storage (SD cards, USB thumb drives), and in discussing the
> internal design, we'd planned on an FPGA, and a separate micro-controller.
> Your concept to have the 'micro-controller' _in_ the FPGA is interesting! The
> only problem, from our point of view, is the 'limited' number of FPGA pins
> (the QBUS interface alone is ~50 pins) - at least, without going to a BGA
> part, which we view as undesirable.
The Xylinx Spartan 3E in a TQFP package has 144 pins and it's *just* 
enough for the Unibus
and talking to the other peripherals.  I haven't looked, but I think the 
Unibus and QBus are
comparable in terms of pin count.  I *did* have to make some compromises 
(ie the DUART
is connected through SPI...couldn't afford the pins for the modem 
controls unless I did that).
>      > Everything related to the basic simulator also seems to be functional.
>
> I'm curious as to your reasoning in doing a custom simulator (OK, it's all
> fun :-). I do understand having _a_ simulator (writing all the software
> involved on the card will be much easier if you don't have to deal with a
> flaky/new hardware), but since the J1 is in the FPGA, couldn't you just use
> the FPGA simulator? Or is it too slow to emulate a good-sized J1 program?
The J1 doesn't have any exceptions or other debugging aids.  I wrote the 
simulator to be
timing accurate from the J1's perspective (so that I could check timings 
and such) and that I
could single step the J1, set breakpoints, examine memory and do 
instruction tracing.

It's also my behavioral model for the Verilog code in the FPGA.  So 
before I commit to a lot
of Verilog code, I know how it will behave and how hard it is to write 
the firmware.  The
approach that I'm taking is that as much as possible is being written in 
forth.  It's only if it
will be too slow or too much code to implement a function, will I put it 
into Verilog.  For example,
unless I find some egregious timing problem, most of the Unibus 
transactions are written
in F/W.  I'm leaving the Verilog for handling the lowest level details.

TTFN - Guy