Close
0%
0%

Kestrel Computer Project

The Kestrel project is all about freedom of computing and the freedom of learning using a completely open hardware and software design.

Similar projects worth following
With each passing day, technically capable consumers of computing technology increasingly lose their rights with computer hardware. While some look to prominent Linux suppliers as an escape from the Intel/Microsoft/Hollywood oligarchy, I have taken a different route -- I decided to build my own computer completely from scratch. My computer architecture is fully open; anyone can review the source, learn from, and hack it to suit their needs.

From the main project website:

  • No back doors. No hardware locks or encryption. Open hardware means you can completely understand the hardware.
  • No memberships in expensive special interest groups or trade organizations required to contribute peripherals.
  • No fear of bricking your computer trying to install the OS of your choice. Bootstrap process is fully disclosed.
  • Designed to empower and encourage the owner to learn about and even tweak the software and the hardware for their own benefit.
  • Built on 64-bit RISC-V-compatible processor technology.

More precisely, the Kestrel-3, my third generation design, aims to be a computer just about on par with an Atari ST or Amiga 1200 computer in terms of overall performance and capability, but comparable to a Commodore 64 in terms of getting things to work.

kcp53001-block-diagram.jpg

This block diagram illustrates my vision of a Furcula-to-Wishbone bus bridge. The KCP53000 CPU exposes a Furcula bus for both its instruction and data ports. Once these buses are arbitrated to a single interconnect, the KCP53001 is used to talk to Wishbone peripherals and memory.

JPEG Image - 205.76 kB - 11/13/2016 at 15:59

Preview
Download

block-diagram.jpg

This block diagram illustrates how the pieces of the CGIA fit together to serialize graphics data to the VGA port.

JPEG Image - 1.10 MB - 06/16/2016 at 18:57

Preview
Download

forth-3.png

Here, I draw a GEOS-inspired dialog box-like thing, interactively as you can see.

Portable Network Graphics (PNG) - 22.93 kB - 04/11/2016 at 20:23

Preview
Download

forth-2.png

Here, I'm writing software to draw simple boxes to the screen using the XOR operator directly on the framebuffer bitmap.

Portable Network Graphics (PNG) - 54.16 kB - 04/11/2016 at 20:22

Preview
Download

forth-1.png

Finally got block storage working inside the emulator, and along with it, a visual block editor. It's based on my own Vi-Inspired Block Editor (VIBE).

Portable Network Graphics (PNG) - 52.55 kB - 04/11/2016 at 20:21

Preview
Download

View all 8 files

  • Serial Interface Adapter Now Hardware Proven

    Samuel A. Falvo II11/26/2018 at 18:33 0 comments

    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.

  • Big Trouble with Little Verilator

    Samuel A. Falvo II10/31/2018 at 16:39 0 comments

    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!

  • On TRIPOS vs. BOAR Project

    Samuel A. Falvo II10/28/2018 at 03:59 0 comments

    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.

  • Symbiyosys, Formal Verification, and ROMA Core

    Samuel A. Falvo II08/31/2018 at 20:57 0 comments

    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.

  • E2 Emulator

    Samuel A. Falvo II08/15/2018 at 03:50 3 comments

    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.

  • Thoughts about a Software Managed MMU

    Samuel A. Falvo II07/27/2018 at 17:34 8 comments

    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.

  • Whoops! Here's some bulk updates!

    Samuel A. Falvo II07/24/2018 at 23:15 0 comments

    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.  :)

  • Development Plans Updated

    Samuel A. Falvo II05/30/2018 at 23:51 0 comments

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

  • Ideas for Kestrel-3

    Samuel A. Falvo II03/14/2018 at 17:16 2 comments

    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).

  • SVFIG Presentation on Kestrel-2DX

    Samuel A. Falvo II03/02/2018 at 16:23 0 comments

    Behold!!

View all 101 project logs

View all instructions

Enjoy this project?

Share

Discussions

f4hdk wrote 09/20/2017 at 21:09 point

Hello, 

I'm happy to see that you still continue with this project.

Have you seen my A2Z project here?

https://hackaday.io/project/18206-a2z-computer

It is quite a similar project, a full computer based on FPGA, but it is much simpler than yours. I've also coded a homemade compiler.

  Are you sure? yes | no

Samuel A. Falvo II wrote 09/22/2017 at 16:56 point

I believe I've seen it when I first joined the Hackaday community; however, I regret that I haven't been following up on my interests.  Now that I'm fully employed, I tend to focus my free time on my family engagements and, only occasionally, on Kestrel stuff.  :)  Apologies.

You are much further along in your project than I am with mine, though.  Right now, my biggest difficulty is getting reliable SD card operation.  After that, I'll need to make some kind of bootstrap mechanism.  I'm hoping progress will be more forthcoming once I achieve those milestones.

  Are you sure? yes | no

f4hdk wrote 03/25/2018 at 06:36 point

I've seen your SVFIG presentation. Congrats for finishing the Kestrel 2DX !

But I have one question : why only 48kB of RAM? That is very small, very limiting. Why don't you use several MB of external SDRAM present on each FPGA board? With several MB, the computer would be much more useable (like A2Z : https://hackaday.io/project/18206-a2z-computer )

  Are you sure? yes | no

Samuel A. Falvo II wrote 03/25/2018 at 07:12 point

f4hdk - Thanks for the feedback.  Finishing the 2DX is a major achievement for me, and is an important stepping stone to achieving the Kestrel-3 design.

With regards to your specific question, though, I've explained this numerous times in the project logs and even in the video -- I was utterly and thoroughly unable to raise the PSRAM chip on the FPGA board.  This leaves me limited to just using the block RAM resources that are on the FPGA itself.    If *you* know how to talk to the PSRAM chip on the Nexys-2, I'd sure welcome a patch.  Because I tried, and I've failed, for about two years.

The Kestrel-3 design will target different FPGA boards with 1MB of external SRAM, a significant improvement in RAM capacity.  There is also 512KB of SRAM on the DE-1 board from Terasic.  That same board also has 64MB of SDRAM.  However, I refuse to even try to use SDRAM.  I've learned my lesson.  Avoid SDRAM like the plague.  But, again, if you have an SDRAM controller that works and is license-compatible with MPLv2 without me having to relicense the project as a whole, then I certainly will not turn away a patch to make SDRAM work.

  Are you sure? yes | no

JL9791 wrote 11/27/2016 at 01:20 point

I see you are still working with Forth :)  I came upon this by accident when researching stack CPUs http://www.strangegizmo.com/forth/ColorForth/msg01746.html
I would like to learn Forth someday, I like the simplicity of stacks (which reminds me of my Magic the Gathering days).

  Are you sure? yes | no

Samuel A. Falvo II wrote 11/27/2016 at 01:32 point

Not having to name every intermediate computation is quite liberating.  But if taken to an extreme, it can also be quite confusing.  :)  The solution is to learn to hyper-factor your code.  A single function in C could well take 16 word definitions in Forth.  Naming procedures is a nice trade-off, because it almost serves to document why your code is the way it is.  Not quite, but good enough for most purposes.  :)  Plus, it really aids in testing code to make sure things work as you expect them to.

  Are you sure? yes | no

JL9791 wrote 11/09/2016 at 01:09 point

I have been following your project for a while, particularly because you selected the RISC-V ISA to build your CPU around.  I recently came across something I had forgotten about:  the now open source Hitachi CPUs (Sega Genesis, Saturn, Dreamcast) found here http://0pf.org/j-core.html

http://j-core.org/

Did you consider those as the brain of your Kestrel?  If not, perhaps they may be a good alternative. :)

  Are you sure? yes | no

Samuel A. Falvo II wrote 11/09/2016 at 01:16 point

Nope, and I have no intentions to either.  I've invested too much into RISC-V to change now.  Switching ISAs today would literally set me back two years of effort.  Besides, performance of RISC-V CPUs are quite good in general; that my own CPU is as slow as a 68000 should not be taken as an indication that all such CPUs are that way.

In the future, I'd like to one day hack a BOOM processor into the Kestrel, which would give it a 4-way superscalar CPU.  But, for now, I just want something simple enough that people can understand.

Another reason for adopting RISC-V is that it has learned many things from both the successes and the failures of past architectures.

Thanks for the link though.  You're not the first to suggest it.  :)

  Are you sure? yes | no

JL9791 wrote 11/09/2016 at 01:18 point

Sure thing.  Yeah, I was not suggesting you scrap all your hard work, just curious.  Glad you are coming along pretty well with it now after the..uh..hiccups :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates