Kestrel Computer Project

Recently, I discovered a commercial company, Raptor Engineering, which released a small computer (what they call a BMC) which they named the Kestrel.

Whereas,

• their hardware stack is build entirely from open source software and hardware, and,
• my project is built entirely from open source software and hardware, and,
• where Raptor Engineering has similar end-goals to myself (except approaching the market from the high-end instead of the low-end),

therefore, I consider the opportunity for market confusion is too great to continue using the Kestrel name.  This is a name that I've been using since early 2004.  Many projects and even commercial products with the name Kestrel have come and gone since then, but none so closely aligned with my project.  So, to that end, I'm terminating further discussion of the Kestrel Computer Project on Hackaday.io.

I cannot accept the risk of legal interference from Raptor should they decide to pursue it.  So, I'm pro-actively archiving this project effective immediately.  I can't afford any time in court right now, and I know my organization skills aren't anywhere close to that required to pose a competent legal defense.

Followers know that I've pivoted this project several times.  And I'm sure I'll pivot several times more in the future before I am satisfied with the outcome.  This post is to announce my most recent pivot.

To help factor the project down into more manageable chunks, I've been convinced by others (and I agreed) to target the RC2014 backplane standard; specifically the RC80 variation, with a CPU card and one or more supporting I/O cards.  However, I need to get my feet wet with designing FPGA logic that couples with a 7.3728MHz, 5V bus that speaks the Z80 protocol first.  Therefore, before I decided to not start with the CPU card, but rather, with some manner of I/O card.  I already completed the MGIA core for the Kestrel-2 family, so I figured this would be a good option to get working first.

There are some problems that I needed to resolve first though, like how to access video memory and so forth.  The TMS9918A uses an indirect approach for this, but so does another chip which seemed closer to my immediate needs: the Commodore CSG 8563 and 8568 VDC chips.  As I was studying the Commodore 128 Programmer's Reference Guide, I noticed this chip has a fair bit of similarity with what I'd originally hoped to see in the CGIA core as well.  Not only that; but, the HBIOS software on my RC2014 has a CSG 8563 driver in its source tree already, so a motivated developer can have a much easier time porting the system software.  Creating a VDC variant seemed to be the logical choice.

So, I've decided to make a small diversion and focus my development efforts on building a project with a reasonable successor to this chip, which I've dubbed the VDC-II core.  To minimize costs and as many risks as I can, I've decided to build the prototype of the core in a TinyFPGA BX module.  Although far more resource limited than the icoBoard Gamma, it does at least have 16KB of block RAM inside it, which is enough for an 80-column text display with 16 colors, or a 640x200 monochrome bitmapped display, which is a good match for what the Kestrel-2's MGIA core can already do, and what CP/M software reasonably expects.  I suspect I'll be able to reuse much of what I'd already written for the MGIA.

I want to see the VDC-II core to completion; if nothing else, once the basic core is working, I think I can expand upon it in ways similar to how the V9958 expands upon the TMS9918A.  If so, then perhaps the VDC-II and its successors can become the new video core for the Kestrel-3 (see?  I told you I was making progress on the Kestrel-3!).  I can also see this project as being something which I could perhaps sell one day on Tindie, CrowdSupply, or some similar outlet as an RC2014 board kit.

So, with that in mind, I think I'm going to document this project separately from the Kestrel-3 project.  Yes, it'll most likely end up as the Kestrel-3's video core; but it has wider applicability if I can drive it to completion.  I know my track record here isn't stellar.  But, I'm willing to at least try.  I see this challenge as practice for more ambitious goals in the future.

So, it has been quite a while since I made any progress updates on this project.  At least, on Hackaday.io (I'm vastly more active on Mastodon).  Surprisingly, though, the project is not dead.  Progress is slow, yes.  But, you've always known that.

Since acquiring my current day-job, work has drained me of both time and initiative.  I am, however, and perhaps nonetheless, progressing.  I just haven't always had the process down to where I post every time progress is made.

I have sort of pivoted the project somewhat.  My long-term goals remain the same as they always have: a single-board computer with a RISC-V processor and custom video core, some reasonable means of expansion, and so forth.  How to achieve those goals, however, has so far diverged from my last recorded plan.  (If you can call it a plan.)  In fact, my current tack appears to qualify more as a "plan" than any prior approach I've taken so far.

To keep the topic of these posts poignant, I'll stop here, and post my current plans in a follow-up post.  For now, though, just be aware that Kestrel-3 isn't dead.  I'm still here, and I'm still hacking.  :)

I now have another group interested in the evolution of the Kestrel Computer Project.  In particular, I collaborate on the design and construction of various fursuit/cosplay ideas, and my Kestrel project has come to light there.  We have been having some issues with the Teensie board we've been using in the past (not enough I/Os), and with Raspberry Pis (too slow I/O; the AXI -> AHB/APB bridge is just too costly to keep up sometimes; also, not enough I/Os), and so now they're interested in the possibility of using FPGAs programmed with a KCP53000 or KCP53000B processor for their embedded development needs.

Cool!

I think I've completed the (Tilelink) IFU design.  I emphasize "think", because without the rest of the processor being built, it's not yet possible to know if I'm truly done or not. My next major step is to work on the IXU design.  But, before that works, I would like to make an intermediate design which couples the IFU with the ROMA core (thus letting me read from flash ROM) and passing the lower 8-bits of each "instruction" fetched out to a set of LEDs.  This will provide visual confirmation that everything is working.

I'm kind of wondering if creating a Wishbone B4 pipelined IFU has value as well.

I'm happy to report that I've completed the CSR Unit, or CSRU for short.  This is the block of logic which implements all of the CSRs (Configuration and Status Register) mandated by the RISC-V Privilege Spec 1.10 as of this posting.

It's my first real implementation of logic using nmigen as a hardware development tool.  And, I must say, I'm really quite impressed with it.

The CSRU takes up 1157 of the 7680 logic cells of the iCE40HX8K FPGA.  This might well be entirely too big for the finished design, however.  If I remove all of the performance counters, some of the useless read-only registers like MARCHID and MVENDORID, etc., I can drop the resource consumption down to 769 LCs.  And, I can reduce this still further by ignoring the priv-spec requirement for WLRL fields (treating them instead as WARL fields, as the original KCP53000 does), which will let me throw away 59 of the DFFs used to build out the MCAUSE register, just to name one example.

Also, with the CSRU as-is, the fastest clock speed is just a smidge above 50MHz.  This isn't very much, unfortunately; once the rest of the processor is implemented, I predict the completed processor circuit will need to be clocked somewhere in the 16MHz to 25MHz range.  Of course, reducing the CSRU complexity will help drive maximum clock speeds higher, but not by much (52MHz in the above example reduction); and, it'll come at the cost of no longer being compatible with the RISC-V priv-spec.

For now, I'm going to stay the course with the 1157 LC design, knowing that it's just a few small tweaks to the source code to enable or disable certain features.  Using a higher-level HDL representation like nmigen is a big confidence booster for experimenting with different design configurations later on.

Next Steps

According to my personal project plan, my next step is to work on the Integer Execution Unit, or IXU.  This is the state machine logic that handles actual instruction execution.  It'll accept instructions from an instruction queue (IQ), rather than fetch them directly.  It'll also be responsible for helping to detect and act upon interrupts and synchronous trap conditions as well.

Per the last project log, I will be working on a revision of the KCP53000 suitable for proving the Kestrel-3 design.  As with all things on this scale of complexity, I'm starting out by drafting a crude set of specifications that'll help guide the development.  You can find the specs here: http://chiselapp.com/user/kc5tja/repository/kestrel-3/artifact/d0c100b35693b93b

I'm happy to announce that the Kestrel-3's Serial Interface Adapter (SIA) core is now hardware proven and works reliably.  This is a major stepping stone towards the evolution of the Kestrel-3 design.  The complete test circuit comes to about 495-ish look-up tables, which is surprisingly large for how limited the SIA is; however, it's at least not gigantic either.

My current roadmap from this point forward is as follows:

Port the KCP53000 away from Furcula/Wishbone and retrofit it to use a TileLink 1.7-compatible bus interface.  This will allow me to build a simple echo server so that I can fully test the SIA core, perhaps even interactively.  (I won't have any RAM to work with at this point, as the RAMA core has not yet been designed.)

Only after the 53000 processor has been ported to run on the Kestrel-3 will I start work on the RAMA core.

Once both the 53000 and the RAMA core are implemented, I can then try to port the Kestrel-3 port of DX-Forth onto the platform.  This will also involve somehow using a second SIA core for a prototype mass storage interface as well; not having the ability to load and save blocks of source code would be a severe inconvenience.  Regrettably, at this point, nothing will be DMA-driven.  But, interrupts will be supported, so there's that.

Finally, after all that is done, I can start to design the next-generation processor, the 53010.

I'm currently encountering significant difficulties using Verilator to write some integration tests for the Kestrel's SIA (Serial Interface Adapter) core.  Formal verification says everything should work, but Verilator is giving completely different results.

Some external help from ZipCPU suggests that the problem lies in the specific subset of Verilog I'm using to write my core's logic, so I'll be looking to retrofit the cores as time permits.  Unlikely to be this week or next, though, due to holidays.  Hopefully, I can get some time in to fix this before December though, as I'll be busy with a whole new set of holidays!

The relatively recent and on-going legal actions between Cloanto and Hyperion Entertainment has me concerned about implementing VertigOS as a port of the BOAR Project.  The BOAR Project is a clean-room implementation of a proper subset of AmigaOS. including only the exec.library and dos.library components of the operating system.  While not binary compatible with AmigaOS, it should be source compatible with a large number of native AmigaDOS console applications, particularly those which treat BPTRs as opaque references.  (BOAR implements all DOS pointers as APTRs instead of BPTRs.) BOAR's library and device driver APIs are sufficiently powerful to enable a significant reproduction of actual AmigaOS libraries (albeit disk-resident) that, frankly, has me concerned that I might become a future target for litigation.

Read the full article here.