[libre-riscv-dev] KCP53010 in danger

[Samuel Falvo II]

Hello Luke, et. al.

I'm going through something of an existential crisis.

Due to the natural attention deficit that comes with advancing age, being
overburdened from my daily job, and familial distractions combined, it is
becoming increasingly clear to me that I just don't have the resources to
dedicate to evolving the KCP53000 processor design into the KCP53010.  When
resources *do* become available, I'm at such a loss as to where I left off
in the project, that I spend almost the entire time available to me
re-acquainting myself with it.  By the time I've made any progress at all,
it's time to go back to my day-job, at which point I just page everything
out again.

The modularity of nMigen does not help, at least in the way that I'd've
hoped.  Maintaining documentation doesn't seem to help in any material way,
either.  The micro-architecture is just too complicated for me to handle.
(Sorry, Mitch.)

It is no wonder why high-level synthesis is such a hot topic.  It's *so
very much* easier to come back to a software project than it is a hardware
project, and to the extent that you can just "write software" which
just-so-happens to also be compilable to valid hardware netlists, HLS is a
major design win.

This is frustrating to me on several levels.  I feel frustrated that the
Kestrel project is at a total and utter stand-still.  I should at least
have a simple machine language monitor running by now.  My original plans
were to actually have working video and mass storage protocols designed by
now, possibly a port of Tripos as well.  As you can see, I'm *terribly* far
behind my own expectations.

There are several ways to resume work on Kestrel-3 going forward:

1. Re-use the KCP53000 as-is, and just eat the 200-400% performance hit
that implies.  This will require building Furcula bus to TileLink bridges
to make it work with the current hardware, though.  This will take a toll
on total LUTs used; the 53000 alone is known to just *barely* fit in a
iCE40HX8K part (untested, though).  It's unlikely to also fit with the
UART, ROMA, and RAMA cores.

2. Switch back to a stack-architecture (Forth-optimized) processor.  This
will restore performance levels back to where I'd like them to be.
Additionally, the processor will also be significantly smaller than even
the KCP53000 (estimated 2000 total LOC in raw Verilog based on prior
experience; nMigen should be no greater than this), let alone the
KCP53010.  Zero to full implementation in about one or two man-months of
time, thanks to more cohesive modules and looser coupling between them.
The major disadvantage is that the software tooling will need to be
rebuilt, and I lose RISC-V compatibility (which has been something of a
mainstay of Kestrel-3's promised features for at least three years now).

3. Continue to evolve the design, but back away from the scoreboard
approach (KCP53010) and start over with a 6502-inspired PLA style execution
unit (KCP53000B), fully synchronous, and fully in charge of instruction
fetch as well as instruction execution.  No pipelines (except where
explicitly permitted by the currently executing instruction, the same way
6502 does it).  This should deliver performance closer to the original
KCP53000 but with some incremental yet measurable improvements, while
having a hardware complexity more or less on par with a stack CPU.

4. Retire the Kestrel-3 project all-together and just go back to
retrofitting and maintaining the Kestrel-2DX.

I don't know what I want to do.  I just know that I need to do something.
I'm going stir-crazy, and I really feel that the Kestrel-3 is in serious
jeopardy.  I guess I'm selfishly hoping saner minds more experienced with
larger designs can provide some spare guidance.

Thanks for listening to me vent. *sigh*


-- 
Samuel A. Falvo II