Brings a tear to the eye, I say.
@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.