Kestrel Computer Project

Since the progress of the project is so early, I decided now is a good time to start to learn how to develop cores using formal verification.  I've so far "proven" my ROMA core's slave TileLink port to my satisfaction, and I'm going to move on to working with the SIA.

I have implemented the baud rate generator logic using formal verification.  So far I'm pleased with the results, but I have to admit, I still have a lot to learn.  Will try to keep you folks updated with my progress.

I'm pleased to say that the ROMA core is now operational enough to meet my needs.  This is not to suggest that it implements the complete and total TileLink interface.  On the contrary, it does not.  If you send a PUT or PUT_PARTIAL request to the ROMA core, you'll deadlock, because it just doesn't know what to do with those yet.  (It will eventually, just not at the moment.)  However, if you send it a GET request, you'll get back a 64-bit word containing what you're looking for after about 97 clock cycles.  Remember that the ROM it's attaching to is a serial flash ROM, accessed one bit at a time.

So, progress!!

As indicated above, the next steps are to implement the transmit-side of the first SIA core.

I do have a SIA core implemented from last year (which is both TX and RX capable), but I'll be starting from scratch and incrementally copying the design over.  This way, I can work towards a formally-verified design from the ground up.  The alternative, taking an existing design and adding FV properties to it, takes much, much longer to complete because all the moving parts conspire to falsify your assertions in unforeseen ways.  So, by the time I'm done, the finished SIA design will inherit almost everything from last year's prototype design.  The register layout will be different, however.

Sometimes, I get burned out by the hardware aspect of the project.  When this happens, I often wonder to myself, "Man, if only I had the Kestrel *finished*, then I can work on the software."  I reached that point not too long ago.

So, I worked on developing a new emulator for the new Kestrel-3 hardware design.  It only supports the headless configuration right now (CPU module only; no I/O module).  As part of this, I also ported DX-Forth to the emulated environment.  Presently, DX-Forth boots and runs, but it has no secondary storage support.

It's not committed to the repository yet, but will be landing soon.

I wrote up some of my thoughts about how I could perhaps fit a page-capable MMU into the KCP53010 design for a future Kestrel-3 revision.

I've been so busy and distracted of late, I rather forgot I had this project website!

Recently, I've been working on building the Kestrel-3 Verilog sources.  I'm starting out with a very simple DMA Controller (DMAC) core, whose responsibility it is to just sequentially scan through memory, and read the results back through a series of attached LEDs.  If done slowly enough, this will permit me to read out the contents of flash ROM and confirm that I am programming it and the FPGA bitstream correctly at a human scale.  BUT, to interface to the flash ROM, I must further build another core, called ROMA, for ROM Adapter.  This will couple the 64-bit TileLink TL-UL interface to the bit-serial, SPI-based interface that the flash ROM resides on.

I've been recording my progress via a video blog, which is named Over the Shoulder II (a long awaited sequel to my original Over the Shoulder video on using Forth in development).  I've recorded four episodes so far:

https://peertube.mastodon.host/videos/watch/b3a870d6-a2f9-4560-8837-1a0200352c93

https://peertube.mastodon.host/videos/watch/8ce25ead-b643-48e3-a633-1ab5e73b019f

https://peertube.mastodon.host/videos/watch/4d393226-a70f-4f7c-bea1-1973fd9f7c8b

https://peertube.mastodon.host/videos/watch/dd97c19d-4cdc-4d95-9a36-e07f6a60d78c

Over time, I'll be adding more videos, as I find the time to work further on the project.

What's in store for episode 5?  Well, hopefully, a change in format that won't be quite as boring to the viewer.  The Bob Ross-like approach to watching me work seems to work great as long as you can contain everything in a single video.  Beyond that, viewership drops off asymptotically.  More poignantly, though, hopefully a simulated-working ROMA core.  :)

I've updated the Kestrel-3 development plans page.  These plans seem far more actionable to me than my previous set.

I'm recording some ideas for Kestrel-3 here before I lose them.  Standard disclaimers apply -- not all of these may see light of day, at least right away.  These are nice-to-haves.

• DX-Forth 2.0
  • Support loading code from files.
  • Support for ALLOCATE and FREE for larger data-sets.
  • Dictionary between 512KB and 2MB in size (easy to use with JAL instructions).
  • Forth compiler that emits native RISC-V instruction streams, at last.
  • Arbitrary-length names for words (allows UTF-8 in names).
  • Remove 256 word dictionary limitation.
  • Significantly more ANS compliant than DX-Forth 1.0.
• Port of the CoSy vector primitives to DX-Forth
  • Needs better web presence; Geocities-esque site layout is hard to find useful info.
  • Inspired by the K programming language.
  • Primitives useful for numerical and string processing.
• Port of the CoSy UI
  • Depends on overall capabilities found in VertigOS.
• VertigOS
  • Minimal GUI, enough to make a usable console (make it Intuition 1.3 compatible?  Make it GEM-like?  GEOS-like?  Mix and blend?)
  • Port of a clean subset of AmigaOS based on BOAR Project (written permission to port).

Behold!!

Ideation process is already under way.  I have to proceed carefully, as the initial version of the 3 will be a two-chip computer design.  More details will be covered in today's SVFIG presentation.

For now, I'm going to spend time with the Kestrel-2DX and enjoy it for a while.  I haven't felt this much joy using a computer since I had my TRS-80 or Commodore 64.

From my most recent project log on the Kestrel-2DX project page...

I'm throwing in the towel once more on the Kestrel-2DX project.  However, not because I'm aggravated, or feel defeated over some seemingly insurmountable technical issue (*cough!* Pseudo-SDRAM *cough!*).  Oh no -- this is far, far better than that.  I'm throwing in the towel because I've won.  The Kestrel-2DX, as I've come to envision the computer design, is complete.

This computer is, bugs and/or feature requests notwithstanding, fully operational.

For the last two weeks, I have spent zero time using my workstation PC for the purposes of Kestrel development.  My entire interaction with the Kestrel, backups notwithstanding, has been with developing software directly on the Kestrel, inside of DX-Forth.  It's even largely the reason why I haven't been making updates as of late.

This has lead me to what I think is perhaps my first Law of Computing:

You know you're finished when you spend more time with your project than you do with the tools to build it.

I've been having a blast.  I spent the last week or so building up a set of slides to present at today's SVFIG meeting.  Despite DX-Forth not being a super-high performer, I'm planning writing a simple, terribly elementary game -- you know, the sorts of games one would write in BASIC on a Commodore 64 or Apple II.  I doubt it'll push its limits; but, it's all that I know how to do, and it should show nicely what is possible to accomplish with the machine to others.  I'm considering creating some videos along the way as well, so folks can see what it's like working with the system in real-time. 

So, a wee bit of progress since I last wrote a log entry.  I can now CREATE a new word and ALLOT a buffer.  I can also comma-compile data into the dictionary space.  There are enough word header slots in the symbol table to create up to 256 words upon a freshly booted Forth environment.

Since this is a 64-bit Forth running with a 16-bit dictionary space, I have four comma words: , (64-bit) W, (32-bit) H, (16-bit) and C, (8-bit).  Similarly, where required, I also have ALIGND, ALIGNW, and ALIGNH for aligning HERE appropriately.

This doesn't sound like much, but it represents a surprising amount of code investment.  I had to make a word which properly constructed a RISC-V JAL instruction to use as a word's code-field, which proved to be an "interesting" exercise in debugging.

I think my next steps include (in no particular order):

• Adding flags field to word headers to identify immediate words.  This will let me implement : and ; sooner, since ; is an immediate word.
• Adding CONSTANT, VARIABLE, and CVARIABLE as convenience words.
• Implementing EMPTY to reset the state of HERE and the symbol table.  This will save me from having to BYE back to TIM/V and re-start Forth from a g command all the time.
• Adding S" for use both interactively and when compiling, so that I can use BLOCK, UPDATE, S", and CMOVE as the most primitive way to self-host software development on the Kestrel-2DX, at least until the CLI editor is done.

Of course, I'll work on a more usable command-line block editor once I'm happy with the interpreter.  It won't be a full-screen editor though, for the simple reason that  I'm already at 10KB - 11KB of code, which is regrettably larger than I would have liked.  (To be fair, 3KB of it is reserved space for word headers.)  I rather expect to max-out my 16KB self-imposed limit for DX-Forth code image size.  :(

Until next time...