This log is more for me than it is for you; yet, you might find this somewhat informative.  ;)  I need to remember this for posterity, especially considering I'm taking forever making real progress from an external point of view.

To reaffirm, my immediate goal is to make a circuit inside a Lattice iCE40HX8K-compatible FPGA that can:

• Accept addresses and data from my host PC, and populate static RAM and/or I/O registers accordingly.
• Accept addresses from my host PC and report back the contents of memory and/or I/O.

That literally is it.  No Turing completeness.  No asynchronous behavior of any kind.  However, I do want it to do these things using RISC-V instructions.  Here's how I intend on making this work.

The IPA

The Initial Program Adapter (IPA) is a core I've developed which causes the reading bus master to block until the next 16-bit halfword arrives over a serial interconnect.  This could be a Z-80, a 6502, a 68060, or your choice of RISC-V hardware.  It exposes no addressable registers; rather, it's intended to sit throughout the address space you'd normally place ROM.

This core is already done.

The "Processor"

The KCP53010 is not a self-standing processor at the moment.  In fact, it's only now starting to resemble a proper five-stage pipeline.  The pipeline is naked at the moment; to feed it instructions, you must do so using the pipeline's own control signals.  The pipeline currently implements STORE instructions (8, 16, 32, and 64-bit), as well as all OP-IMM instructions.  This is sufficient for populating RAM, but not for inspecting its contents.  For example, to load a code or data image into static RAM, you might want to send the following instruction stream to the IPA:

ADDI X1, X0, 0      ; x1 points into RAM, where code image is to go.
ADDI X2, X0, aaa    ; x2 is first byte
SB   X2, 0(X1)
ADDI X2, X0, bbb    ; x2 is second byte
SB   X2, 1(X1)
ADDI X2, X0, ccc    ; If x2 happens to get valid halfword,
SH   X2, 2(X1)      ; then we can optimize and store it.
... etc ...

Before implementing an "instruction fetch" stage to the pipeline, though, I need to complete the LOAD class of instructions.  This will enable me to support inspection of memory as well, so I can implement, for example, a memory test routine on my host PC.

After LOAD and the instruction fetch stage is complete, I intend to implement JAL and JALR instructions.  This should make the KCP53010 Turing complete, although still not a complete RISC-V implementation.  This should be good enough to support basic programs like "Hello world, what is your name?" "Oh, hello Foo!" type programs.

The SIA

The Serial Interface Adapter (SIA) core implements the serial interface used to communicate with the host PC using a basic 4-wire synchronous serial interface.  This core is already done.

The Host PC Interface

I dread this step the most.

This is actually an ESP8266 device which I had received courtesy of Dr. Ting from an SVFIG meeting.  This will adapt the USB interface from the host PC to the 4-wire synchronous serial that the IPA and SIA implements.  This will make programming the device challenging, since I will need to bit-bang the interface to the FPGA.  Absolute yuck.  It's not even very clear to me how to go about testing this module to know it's working properly.

Summary

Things were much, much easier with the Kestrel-2, where I could rely on block RAM, a significantly simpler processor model, and a working video interface from day one.  Bootstrapping the Kestrel-3 is significantly more complex, and I'm not too happy with it.  However, as my log history shows, every attempt to go a simpler route has so far failed.  I truly wish I had a better way of bringing a system up quickly.