Hazard3: 3-stage RV32IMACZb* processor with debug

by EvgeniyZh • 2 years ago

62 35 2 years ago

This is the RISC-V core used in the RP2350, the new Raspberry Pico 2 SoC.

cpldcpu2• 2 years ago

It's also an interesting juxtaposition, because it directly allows to benchmark the architectures in the same system environment.

In the RP2350 it is possible to either use the RISC-V cores, the CM33 cores or even use one of each.

IshKebab• 2 years ago

I dunno if it will be that interesting due to area differences. Maybe if Raspberry publish the area stats too?

phire• 2 years ago

But such benchmarks don't tell you anything at all about general ARM vs RISC-V performance.

Those benchmarks would only tell you about those exact two cores, Cortex-M33 vs Hazard3. There are many other ARM and RISC-V implementations that are better and worse, depending on what customers need.

jsheard3• 2 years ago

Fun fact: to save space in the RP2350s ROM it contains a minimal ARM emulator for RISC-V, so that it can (mostly) use the same boot code for both architectures.

https://github.com/raspberrypi/pico-bootrom-rp2350?tab=readm...

https://github.com/raspberrypi/armulet

klelatti3• 2 years ago

Just to clarify

so ARM code is emulated (varmulet) on RISC-V

As I initially read this the other way around.

johndoe08152• 2 years ago

Ah, I read the rumor that there was an ARM emulator but didn't think it was open sourced. Thanks, that'll be a great example for my students...

mrlonglong3• 2 years ago

No support for floating point. It would have been nice to have that.

cloudy_craggs• 2 years ago

Any ideas about why the cores have been included? The best I can come up with is de-risking shipping RISC-V by doing a trial run.

What are the rational use-cases for these cores, do they use less power?

InvaderFizz• 2 years ago

I would guess it is to:

1. Build out a RISC-V ecosystem for almost zero cost. The value-add is quite large for a segment of potential buyers as they get the same excellent ecosystem, but can target RISC-V as the uArch.

2. De-risk dealing with ARM in the future as their moves in licensing changes foretell a bleak future for licensees

3. Eventually a bargaining chip with ARM on licensing. "Give us favorable terms, or we drop ARM from this design"

irdc2• 2 years ago

3b. Eventually, should ARM increase their prices, be able to produce a chip that only has the RISC-V cores but is otherwise 100% compatible with the RP2350. And thereby giving their clients the option of porting their software to RISC-V and shipping a single firmware image that runs on both older devices with the (now expensive) RP2350 and new devices with the (still cheap) RISC-V-only chip.

snvzz2• 2 years ago

4. Make the chip attractive to those who favor RISC-V and would not buy it otherwise.

This includes myself. I'll always pick a RISC-V option over an ARM one, if I can do so for the purpose.

On that note, I have already ordered some rp2350-based development boards.

Rochus2• 2 years ago

Amazing that it's apparently implemented in plain Verilog, not SystemVerilog; or did I miss something? Would be interesting to hear from the author what the motivation was for this choice.

gchadwick2• 2 years ago

At a guess it's because the author has been using Yosys for some formal verification work and maybe for doing some synthesis trials and it doesn't support system verilog natively. Though things are improving there: https://github.com/chipsalliance/synlig

Rochus2• 2 years ago

But if they do formal verification, then at least SV assertions should be present; will talke another look at the code.

gchadwick2• 2 years ago

Would be interesting to know what verification they've done on this core. Given it's included as a bonus feature presumably they haven't done full DV on it.

The repository has a testbench for running binaries, which includes the RISC-V compliance suite plus some usage of RISCV formal https://github.com/YosysHQ/riscv-formal which is intriguing. Though nothing obvious of the level you'd need to close production level verification on a design.

captn3m0• 2 years ago

Would be an interesting experiment to run hazard3 against RISVuzz, that found the ghostwrite bug.

alex7o• 2 years ago

Can't wait to see how somebody hacks it to run code on all four cores at the same time. If this is technically/physically possible.

p_l• 2 years ago

It's not - even assuming the cores don't share actual silicon, it's been mentioned that there aren't enough ports on the bus fabric to run 4 CPUs - each RISC-V + ARM pair shares common AHB port.

Hazard3: 3-stage RV32IMACZb* processor with debug

Related Stories