Brings a tear to the eye, I say.
@vertigo holy cow, congratulations friend!
@djsundog Thanks! Adding some finishing touches to the BIOS is now my next step. I need to expose a function to set the mtvec vector to some place outside of ROM so a future OS can make use of it (if it wants), and to set a new system font (if it wants).
@vertigo I don't know exactly what that machine is, but that looks beautiful anyway you look at it. Congrats on getting it running.
@epl692 It's my home-made, completely FOSS/FOSH home computer. Inspired by the Jupiter ACE, TRS-80 series, Commodore PET, etc. But it is made with a 64-bit RISC-V CPU of my own design.
Entire stack (hardware, software, etc) all licensed MPLv2.
@vertigo That's even more awesome. Congrats!
@tomas Yes; the FPGA I'm using right now is the Xilinx Spartan 3 device, XC3S1200E, 4ns delay.
The board I'm using is a Digilent Nexys-2, which unfortunately are no longer manufactured. However, I can't imagine this design would be difficult to port to a different FPGA board.
@tomas This computer is a stepping stone to another computer design I've been wanting to build for some time, which I've dubbed the Kestrel-3.
The Kestrel-3 will be color, have programmable video resolutions, maybe audio if I can figure out a good built-in solution, etc.
The Kestrel-3 will also be built using nothing but FPGA boards that can be targeted with Yosys, although it'll take multiple FPGAs to make everything work.
@tomas Surprisingly no; the iCE40HX4K and 8K are plenty big enough to house a 64-bit RISC processor as long as you don't go overboard with features.
My Kestrel-3 design is slated to use just two FPGA boards: one for the CPU, local RAM controller, and basic I/O (e.g., serial interface for hardware bring-up), and the other is for all the I/O that the Kestrel-3 will use (video, keyboard, mouse, etc.).
@tomas The specification is not standardized, however, which is why instruction encodings for it aren't published yet. But, IIRC, it's supported in the Spike emulator, which is the reference (non-hardware) used to define the specifications with, so I'm glad it's there!
Yes, it'd make crypto easier, but lack of constant-time instructions is a big drawback. A task force exists now which is looking to add constant-time extensions to the spec. It's been slow-going though.
@tomas For me, the 128-bit specification is important because it opens up opportunities for finally realizing object-capability-based operating systems and applications. Both forward and inverted page tables starts to break down at 128-bit address space sizes (by which I mean a hardware walk is about as slow or slower than an optimal software TLB fill), so we'll start to see some nice innovations here, I think.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!