Kestrel-3

Update of "Development Strategy"
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: 1d51dfaa4c8a97909fa9ceea90e8d6fc5514ec0d54f9bdf1f7387233cdd326da
Page Name:Development Strategy
Date: 2018-05-30 23:48:32
Original User: kc5tja
Mimetype:text/x-markdown
Parent: f6760ef03fdefaa1a6ea577b22a2bd5c64624b03d0b9cecb2f6dff89fe1aa869 (diff)
Next 0053266578bc25369cf69b1948cfa6fd3936e62980c447d7735a01e7a45c93d2
Content

Introduction and Problem Statement

Due to the need to reinstall the OS on my FPGA development workstation, I have lost the Xilinx Webpack/ISE FPGA development environment. This implies I cannot refine the Kestrel-2DX to function as I'd originally intended: as a terminal or diagnostic tool for developing the Kestrel-3's I/O hardware. I could attempt to reinstall it, but it took me months last time to track down a missing dependency. I'm not sure I want to go through that hassle again.

So, I've decided to bring the Kestrel-3 up in exactly the same way that I brought up the Kestrel-2DX, the Kestrel-2, and the Kestrel-1 before it: manually.

As you've known from elsewhere on this site, the Kestrel-3 has always been specified as a two-FPGA computer system. One FPGA houses the main processor while the other FPGA houses the video, audio, keyboard, mouse, et. al. hardware. The two FPGAs would share minimal yet complimentary blocks of logic to allow them to cooperate.

The original plan was to focus on the Kestrel-3 A/V hardware first, and retrofit a kind of revised, bug-fixed Kestrel-2DX to drive that hardware. Then, the plan changed due to practical matters: the need to build the link between the two FPGAs required that I work on a minimal computer first, then getting the A/V hardware working second.

Although even more practical matters have intervened so as to cause even the development of the ByteLink interface to be deferred, it turns out that this second plan is still the right way to go. However, the specific order of operations that implements that plan has changed. (Consult the history of this wiki page to see previous plans if you're interested.)

High-Level Development Plan

  1. Order a couple of USB/serial interfaces. Le sigh; I'm just going to pay the FTDI tax on this one. This will let me talk to the FPGA boards from a host PC running a dumb terminal (operator's console on serial channel 0) as well as implement secondary storage (via serial channel 1).
  2. Replace Kestrel-2DX with minimum configuration Kestrel-3. On the CPU FPGA, build a stripped down, yet streamlined, Kestrel-2DX. Replace Wishbone B3 with TileLink TL/UL interconnects. Upgrade 2DX's KCP53000 with the 3's KCP53010 CPU. Talk to the outside world with (DMA-backed?) SIA cores, and via a GPIA-2 core for user I/O needs. Kiss SD support goodbye (good riddance!). Port DX-Forth to Kestrel-3. (Update DX-Forth to use file-based I/O? Maybe!) First public release of Kestrel-3 technology. This step ensures I'll never run into either "can't port Kestrel because we don't make your FPGA boards anymore" and "we can't install your FPGA dev environment" again.
  3. Port BOAR Project as VertigOS. This will implement a proper subset of AmigaOS, implementing only exec.library and dos2.library. Note that I've decided to change the name of dos.library, because BOAR Project switches away from using BPTRs to point to structures and uses APTRs instead. This is a binary-incompatible API breakage from Commodore-Amiga's operating system, so a new name is justified. Extend DX-Forth to look for "auto-boot" signatures on installed devices, and if found, automatically boot them. Thus, VertigOS should automatically boot if mounted in a storage volume.
  4. Design a System for Expansion. This is where I will design something akin to IBM PC's ISA bus. Will it remain ByteLink, or will I go with something capable of supporting a backplane? It's presently too early to tell, but at least I have ByteLink to fall back on if I can't come up with a good solution by then.
  5. Design the A/V Hardware. Up until now, we've been doing everything on one FPGA, the CPU FPGA. This is where the A/V FPGA now becomes important: the CGIA, native keyboard and mouse support, and audio are implemented. Implemented as a second icoBoard Gamma, it should plug into the CPU board via the expansion mechanism designed previously.

The Plan for Project Replacement

High-level step 1 is trivial: place a few phone calls, and you're done.

The real work begins with step 2, which is to replace the Kestrel-2DX with the smallest configuration Kestrel-3.

The steps I've come up with are as follows. As usual, I reserve the right to change them at any time and without notice.

  1. Implement the flash ROM Adapter (ROMA) core. Rig it to a simple TileLink transaction generator to read out words starting at some address. The address generator is completely ignorant of the fact that it's talking to a flash ROM, so whatever startup sequence the flash needs ahead of time must be taken care of exclusively by the ROMA core. Data which is successfully delivered by the ROMA core is then fed directly to a set of PMOD LEDs (I received a board with 8 LEDs as part of my icoBoard Gamma order). Since I should know what appears in flash at what addresses, and if I clock it slow enough, I should be able to manually confirm it's reading the contents of the ROM correctly.
  2. Implement the transmit-side of the console's SIA core. Default to 2400 to 9600 baud (whatever is most convenient to derive from the clock). Alter the ROM-fetch-and-store-to-LED circuit from step A to stuff bytes instead to the SIA transmit buffer. On a host PC, receive the data transmitted, and use xxd to dump the binary file produced. This should match the contents of the ROM, but more importantly, it tells me I can depend on logging output from the host CPU when it is implemented.
  3. Port my S16X4A processor to use TileLink interface instead of Wishbone B3. Replace the faux DMA engine with the stack CPU. Confirm that I can print "Hello world" to the console. NOTE: The S16X4 family of CPUs are what drove the original Kestrel-2, and was originally intended only to help me test peripherals. It was never intended to be, nor will it ever be, the main CPU for the Kestrel-3. It only happened for the Kestrel-2 by pure accident!
  4. Implement the RAM adapter (RAMA) core. Confirm that I can copy ROM into RAM, then read it back out via the SIA port. Again, use xxd to confirm that RAM is holding the desired contents. (Alternatively: implement some kind of RAM test logic.)
  5. Pull the S16X4A CPU out of the circuit. We now know we have a working minimal set of peripherals that a "real" CPU can talk with. Implement said real CPU (the KCP53010; basically a revised, bug-fixed, and hopefully more efficient KCP53000 used in the Kestrel-2DX. This will involve multiple sub-steps on its own). With new firmware in place, confirm that it can copy itself into RAM, then print Hello World to the console.
  6. Implement the receive-side circuitry of the console's SIA core. This completes the SIA core implementation as a proper UART. Implement a stupid echo program for the CPU to execute. Confirm that a file sent to the terminal is received with good fidelity.
  7. Port Kestrel-2DX's DX-Forth to the Kestrel-3 firmware. Confirm it can do basic math and otherwise talk to low-level devices. Confirm it can compile new code interactively. At this point, a host PC should be able to talk to the Kestrel-3 via a serial/USB interface cable and running a terminal program such as minicom.
  8. Update Kestrel-3's Forth to support file I/O via a second SIA core dedicated to that purpose. This will (eventually) require programming an Arduino or some such to act as a file server on behalf of the Kestrel-3. (Think of the relationship between the Commodore 64 and a Commodore 1541 disk drive.) At this point, the Kestrel-3 becomes, insofar as software is concerned, capable of self-hosted software development and refinement (at least for RAM-resident system software). First public release!