8 ms·

Glacial – Microcoded RISC-V core designed for low FPGA resource utilization

retrac 6y ago
Along the same lines of minimizing the amount of logic used at the cost of cycles, there's SERV which uses a bit-serial implementation with a 1-bit data path: https://github.com/olofk/serv https://github.com/olofk/serv From time to time, I have been tempted to design a RISC-V implementation out of discrete 74xx components. Sure, there are plenty of projects out there to build your own processor from scratch like that, but most of them aren't LLVM targets! The 32-bit datapaths and need for so many registers makes it a bit daunting to approach directly. That approach would probably end up similar in scale to a MIPS implementation I once saw done like that. (Can't find the link, but it was about half a dozen A4-sized PCBs). Retreating to an 8-bit microcoded approach and lifting all the registers and complexity into RAM and software is a very attractive idea. Might even fit on a single Eurocard. It's not like a discrete TTL RISC-V implementation would ever be a speed demon, either way.
- klelatti 6y ago
  Very interesting. Any sense of how many transistors / gates would be a likely minimum needed for an RISC-V implementation like this?
  - retrac 6y ago
    My last rough sketch came out to about 400 gates, excluding the flip-flops. If one cuts even more corners, that number could come down much further. For example, an adder isn't actually necessary and can be replaced with lookup tables and bit-twiddling, again at the cost of cycles and more microcode. See https://hackaday.io/project/161251-1-square-inch-ttl-cpu https://hackaday.io/project/161251-1-square-inch-ttl-cpu -- while not RISC-V it demonstrates some of these principles in action, taken to the extreme. That design consists of: one 4 bit counter, four 8-bit flip-flops, one quad OR gate, one dual 2-to-4 demux, and one 128 KB Flash ROM. Including the flip-flops (and obviously excluding the Flash memory) that comes out to about 200 or so gates by my count, and the microcode/emulation program implements a fairly typical CISC 16 bit processor. It's not even all that inefficient, with under 100 cycles per instruction on average.
    - klelatti 6y ago
      Thanks. As you say having LLVM be able to target a CPU built with so few gates is pretty remarkable!
- monocasa 6y ago
  If you don't know of it already, you might like the book Bit-Slice Microprocessor Design written by Mick and Brick. It's written to be very AM2900 specific, but a lot of the techniques would apply to microcoded TTL processors with just a little more work on your end. And it really does a good job of exploring the space of microcoded minicomputer design in an interesting way.
  - retrac 6y ago
    Ooh. I had not seen that one. Thanks!
mechagodzilla 6y ago
But what's the resource utilization??
- monocasa 6y ago
  Reading through it, it's making the right tradeoffs for good utilization. Basically trading LUTs for BROM, which is what you'd want at this level. I haven't synthesized it though, so I can't say for sure.
- mng2 6y ago
  It's indeed a pet peeve of mine when an FPGA project doesn't give example utilization, but in this case they mention iCE40UP5K and M2S025 at least.
kiwidrew 6y ago
I'm surprised that there aren't any specialised instructions or hardware resources to handle the RISC-V instruction decoding/dispatching. [1] Like, sure, it's not meant to be a fast implementation, but even just a "mask byte with 0x7C and set PC to that value times 8" instruction (which in an FPGA implementation is just rearranging the wires) could save 5-6 cycles per instruction. Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? [1] https://github.com/brouhaha/glacial/blob/master/ucode/ucode.asm#L456 https://github.com/brouhaha/glacial/blob/master/ucode/ucode....
- nullc 6y ago
  I assume this would be an obvious starting point for looking at for the smallest specializations that give the greatest performance improvement. I understand that there are some FPGAs now that essentially have RISC-V ALU hard blocks, so use of them might be a speed and area improvements.
  - brucehoult 6y ago
    The MicroChip "PolarFire SoC" FPGA chips have five 64 bit RISC-V cores (SiFive U54-MC) currently running at 600 to 667 MHz (depending on speed grade) inside. So far the only available device has 250k logic elements (LUT4 + FF) for $340 qty 1, but there are part numbers in the data sheet for other sizes in future. I have an "Icicle" board based on this chip. The FPGA comes preconfigured to boot Linux from the included pre=programmed SD card, so you can just use it to run Linux if you don't care about FPGAs. Or you can replace or enhance the default FPGA programming.
- throwaway81523 6y ago
  > Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? Don't know, but the amount of "microcode" or emulation code required is itself a reasonable measure of an ISA's complexity. Doing an x86 that way would surely take tons more code.
- brucehoult 6y ago
sprash 6y ago
I never understood the hype around RISC-V. It is an ISA on the level of a mediocre early 90s design and does not address any of the problems we have today such as the memory latency bottleneck and the resulting topology challenges. Several completely open source designs are available that are vastly superior and real world battle tested such as OpenSPARC-T2. So why do we need RISC-V? Is it another case of NIHS?
- duskwuff 6y ago
  Off the top of my head: 1. RISC-V is completely unencumbered from an IP perspective. There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019). 2. RISC-V is legacy-free. It's an extremely "clean" design, free of weird quirks like the MIPS branch delay slot or SPARC register windows. 3. There are subsets of the RISC-V architecture defined for different sizes of systems, e.g. 32/64 bit versions, an embedded subset with fewer registers, etc. They all share an instruction set and a general architecture, and most compilers can target any subset. Some of the smaller subsets are well within the realm of what a single student can be taught to implement within a semester. 4. Numerous real implementations of RISC-V exist -- both as hardware and HDL -- are being maintained, and the hardware is available on the open market.
  - MaxBarraclough 6y ago
    > There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019) What happened with MIPS in 2019? Shouldn't that kind of thing be impossible, the way it's impossible to revoke the GPL licence on software?
    - duskwuff 6y ago
      > What happened with MIPS in 2019? https://www.hackster.io/news/wave-computing-closes-its-mips-open-initiative-with-immediate-effect-zero-warning-e88b0df9acd0 https://www.hackster.io/news/wave-computing-closes-its-mips-...
drmpeg 6y ago
Is Glacial (as in glacially slow) a good name for a CPU project?
- jacquesm 6y ago
  In this case it is highly appropriate.
starkruzr 6y ago
so RISC-V has been around for decades, right? why does it seem like it's blowing up now?
- pjscott 6y ago
  The RISC approach to microprocessor design has been around since the 1980s, but the specific instruction set called "RISC-V" has only been around since 2010.
- _chris_ 6y ago
  It takes years for tooling to improve and for industry designs to start making it out into the world. As more designs make it into end-users' hands, the tooling has even more motivation to improve. I feel like that slow evolution can make it appear "suddenly popular" despite being around for a few years. =)
- brucehoult 6y ago
  Design work was started on RISC-V in 2010 and an initial frozen spec was released to the public in 2015. The first proper 32 bit chip and board (HiFive1/FE310) shipped in December 2016, and the first Linux-capable 64 bit chip and board (HiFive Unleashed/FU540) in April 2018. It's pretty new.
ekiwi 6y ago
Glacial was one of the entries for the 2018 RISC-V SoftCPU Contest, but I think it wasn't ready by the deadline. If you look at the winners there was another 8-bit CPU with a RISC-V interpreter, SERV, VexRiscv but also Reindeer which seems like a more balanced implementation: https://riscv.org/blog/2018/12/risc-v-softcpu-contest-highlights/ https://riscv.org/blog/2018/12/risc-v-softcpu-contest-highli...
- brucehoult 6y ago
  SeRV is 1 bit ALU and datapath ("bit serial") PicoRV32 is 8 bit ALU and datapath. VexRISCV is full 32 bit ALU and datapath.
Scene_Cast2 6y ago
What's the cheapest FPGA that 1) has / can fit a CPU, and 2) has high-speed (~5 GHz) IO? In my quick searches, I found that high speed FPGAs are around $10k+, and have much more fabric than I really need or want.
- diarmuidc 6y ago
  How big is your CPU. I develop on Microsemi and the PolarFire range should do it. 12G transcievers and a decent amount of logic. At about €200+. And considering Microsemi are usually behind the curve, Xilinx and Altera must have similar https://www.microsemi.com/product-directory/fpgas/3854-polarfire-fpgas https://www.microsemi.com/product-directory/fpgas/3854-polar...
- tails4e 6y ago
  What do you intend to do with the 5GHz IO? Assuming it's for peripheral connectivity, then maybe the Ultra96 would work. It does not have general purpose transceivers availbals, but it has a PS (processing subsystem) that has lots of connectivity. The PL is pmenty big for many applications.
  - Scene_Cast2 6y ago
    I was thinking of hooking it up to GDDR6. I've programmed an FPGA before (a couple of school projects), but never interfaced with anything serious like modern high-bandwidth memory.
- thrtythreeforty 6y ago
  That would be the ECP5UM-5G parts. The 5G variants are somewhat more exotic but the base ECP5 is supported by Yosys and readily available on Mouser for $15-20 or so

Along the same lines of minimizing the amount of logic used at the cost of cycles, there's SERV which uses a bit-serial implementation with a 1-bit data path: https://github.com/olofk/serv https://github.com/olofk/serv From time to time, I have been tempted to design a RISC-V implementation out of discrete 74xx components. Sure, there are plenty of projects out there to build your own processor from scratch like that, but most of them aren't LLVM targets! The 32-bit datapaths and need for so many registers makes it a bit daunting to approach directly. That approach would probably end up similar in scale to a MIPS implementation I once saw done like that. (Can't find the link, but it was about half a dozen A4-sized PCBs). Retreating to an 8-bit microcoded approach and lifting all the registers and complexity into RAM and software is a very attractive idea. Might even fit on a single Eurocard. It's not like a discrete TTL RISC-V implementation would ever be a speed demon, either way.

klelatti 6y ago
Very interesting. Any sense of how many transistors / gates would be a likely minimum needed for an RISC-V implementation like this?
- retrac 6y ago
  My last rough sketch came out to about 400 gates, excluding the flip-flops. If one cuts even more corners, that number could come down much further. For example, an adder isn't actually necessary and can be replaced with lookup tables and bit-twiddling, again at the cost of cycles and more microcode. See https://hackaday.io/project/161251-1-square-inch-ttl-cpu https://hackaday.io/project/161251-1-square-inch-ttl-cpu -- while not RISC-V it demonstrates some of these principles in action, taken to the extreme. That design consists of: one 4 bit counter, four 8-bit flip-flops, one quad OR gate, one dual 2-to-4 demux, and one 128 KB Flash ROM. Including the flip-flops (and obviously excluding the Flash memory) that comes out to about 200 or so gates by my count, and the microcode/emulation program implements a fairly typical CISC 16 bit processor. It's not even all that inefficient, with under 100 cycles per instruction on average.
  - klelatti 6y ago
    Thanks. As you say having LLVM be able to target a CPU built with so few gates is pretty remarkable!
monocasa 6y ago
If you don't know of it already, you might like the book Bit-Slice Microprocessor Design written by Mick and Brick. It's written to be very AM2900 specific, but a lot of the techniques would apply to microcoded TTL processors with just a little more work on your end. And it really does a good job of exploring the space of microcoded minicomputer design in an interesting way.
- retrac 6y ago
  Ooh. I had not seen that one. Thanks!

mechagodzilla 6y ago

But what's the resource utilization??

monocasa 6y ago
Reading through it, it's making the right tradeoffs for good utilization. Basically trading LUTs for BROM, which is what you'd want at this level. I haven't synthesized it though, so I can't say for sure.
mng2 6y ago
It's indeed a pet peeve of mine when an FPGA project doesn't give example utilization, but in this case they mention iCE40UP5K and M2S025 at least.

kiwidrew 6y ago

I'm surprised that there aren't any specialised instructions or hardware resources to handle the RISC-V instruction decoding/dispatching. [1] Like, sure, it's not meant to be a fast implementation, but even just a "mask byte with 0x7C and set PC to that value times 8" instruction (which in an FPGA implementation is just rearranging the wires) could save 5-6 cycles per instruction. Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? [1] https://github.com/brouhaha/glacial/blob/master/ucode/ucode.asm#L456 https://github.com/brouhaha/glacial/blob/master/ucode/ucode....

nullc 6y ago
I assume this would be an obvious starting point for looking at for the smallest specializations that give the greatest performance improvement. I understand that there are some FPGAs now that essentially have RISC-V ALU hard blocks, so use of them might be a speed and area improvements.
- brucehoult 6y ago
  The MicroChip "PolarFire SoC" FPGA chips have five 64 bit RISC-V cores (SiFive U54-MC) currently running at 600 to 667 MHz (depending on speed grade) inside. So far the only available device has 250k logic elements (LUT4 + FF) for $340 qty 1, but there are part numbers in the data sheet for other sizes in future. I have an "Icicle" board based on this chip. The FPGA comes preconfigured to boot Linux from the included pre=programmed SD card, so you can just use it to run Linux if you don't care about FPGAs. Or you can replace or enhance the default FPGA programming.
throwaway81523 6y ago
> Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? Don't know, but the amount of "microcode" or emulation code required is itself a reasonable measure of an ISA's complexity. Doing an x86 that way would surely take tons more code.
brucehoult 6y ago

sprash 6y ago

I never understood the hype around RISC-V. It is an ISA on the level of a mediocre early 90s design and does not address any of the problems we have today such as the memory latency bottleneck and the resulting topology challenges. Several completely open source designs are available that are vastly superior and real world battle tested such as OpenSPARC-T2. So why do we need RISC-V? Is it another case of NIHS?

duskwuff 6y ago
Off the top of my head: 1. RISC-V is completely unencumbered from an IP perspective. There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019). 2. RISC-V is legacy-free. It's an extremely "clean" design, free of weird quirks like the MIPS branch delay slot or SPARC register windows. 3. There are subsets of the RISC-V architecture defined for different sizes of systems, e.g. 32/64 bit versions, an embedded subset with fewer registers, etc. They all share an instruction set and a general architecture, and most compilers can target any subset. Some of the smaller subsets are well within the realm of what a single student can be taught to implement within a semester. 4. Numerous real implementations of RISC-V exist -- both as hardware and HDL -- are being maintained, and the hardware is available on the open market.
- MaxBarraclough 6y ago
  > There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019) What happened with MIPS in 2019? Shouldn't that kind of thing be impossible, the way it's impossible to revoke the GPL licence on software?
  - duskwuff 6y ago
    > What happened with MIPS in 2019? https://www.hackster.io/news/wave-computing-closes-its-mips-open-initiative-with-immediate-effect-zero-warning-e88b0df9acd0 https://www.hackster.io/news/wave-computing-closes-its-mips-...

drmpeg 6y ago

Is Glacial (as in glacially slow) a good name for a CPU project?

jacquesm 6y ago
In this case it is highly appropriate.

starkruzr 6y ago

so RISC-V has been around for decades, right? why does it seem like it's blowing up now?

pjscott 6y ago
The RISC approach to microprocessor design has been around since the 1980s, but the specific instruction set called "RISC-V" has only been around since 2010.
_chris_ 6y ago
It takes years for tooling to improve and for industry designs to start making it out into the world. As more designs make it into end-users' hands, the tooling has even more motivation to improve. I feel like that slow evolution can make it appear "suddenly popular" despite being around for a few years. =)
brucehoult 6y ago
Design work was started on RISC-V in 2010 and an initial frozen spec was released to the public in 2015. The first proper 32 bit chip and board (HiFive1/FE310) shipped in December 2016, and the first Linux-capable 64 bit chip and board (HiFive Unleashed/FU540) in April 2018. It's pretty new.

ekiwi 6y ago

Glacial was one of the entries for the 2018 RISC-V SoftCPU Contest, but I think it wasn't ready by the deadline. If you look at the winners there was another 8-bit CPU with a RISC-V interpreter, SERV, VexRiscv but also Reindeer which seems like a more balanced implementation: https://riscv.org/blog/2018/12/risc-v-softcpu-contest-highlights/ https://riscv.org/blog/2018/12/risc-v-softcpu-contest-highli...

brucehoult 6y ago
SeRV is 1 bit ALU and datapath ("bit serial") PicoRV32 is 8 bit ALU and datapath. VexRISCV is full 32 bit ALU and datapath.

Scene_Cast2 6y ago

What's the cheapest FPGA that 1) has / can fit a CPU, and 2) has high-speed (~5 GHz) IO? In my quick searches, I found that high speed FPGAs are around $10k+, and have much more fabric than I really need or want.

diarmuidc 6y ago
How big is your CPU. I develop on Microsemi and the PolarFire range should do it. 12G transcievers and a decent amount of logic. At about €200+. And considering Microsemi are usually behind the curve, Xilinx and Altera must have similar https://www.microsemi.com/product-directory/fpgas/3854-polarfire-fpgas https://www.microsemi.com/product-directory/fpgas/3854-polar...
tails4e 6y ago
What do you intend to do with the 5GHz IO? Assuming it's for peripheral connectivity, then maybe the Ultra96 would work. It does not have general purpose transceivers availbals, but it has a PS (processing subsystem) that has lots of connectivity. The PL is pmenty big for many applications.
- Scene_Cast2 6y ago
  I was thinking of hooking it up to GDDR6. I've programmed an FPGA before (a couple of school projects), but never interfaced with anything serious like modern high-bandwidth memory.
thrtythreeforty 6y ago
That would be the ECP5UM-5G parts. The 5G variants are somewhat more exotic but the base ECP5 is supported by Yosys and readily available on Mouser for $15-20 or so