Hazard3: 3-stage RV32IMACZb* processor with debug | Hacker News Reader

Hazard3: 3-stage RV32IMACZb* processor with debug

github.com

62 pointsEvgeniyZh35 comments

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

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.

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

They mentioned somewhere that they could not designate the actual area increase since it is part of the synthesized digital area. The area increase to include the RISC-V cores was negligible, apparently.

Is a RISC-V core just the serial numbers filed off an ARM core?

The core design isn't tightly coupled to the front-end ISA. AMD zen was going fo be offered in both x86 and ARM but the ARM front-end was canceled.

I wonder if without the RISC-V cores the design was pad limited i.e. it had due area that wasn't used. So, they put in the RISC-V cores for no die cost. There will be some cost to test the RISC-V cores.

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.

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

Just to clarify

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

As I initially read this the other way around.

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

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

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.

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

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.

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

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

Yosys supports very basic SVA (immediate assert/assume, $past etc) in addition to Verilog 2005

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?

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"

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.

The RP2350 already has an OTP bit which permanently disables the ARM cores when set, so they wouldn't even have to sacrifice their economies of scale in order to make that play. A RISC-V-only variant could be exactly the same hardware, just with the OTP pre-set at the factory.

Exactly. And should RISC-V turn out to have been a hype (which I don’t think, but I do recognise that convincing the various MBA types that think they make the world go ‘round is not a given) they can do the opposite.

Which is nice for a chip they plan to make up to the 2040’s.

> And should RISC-V turn out to have been a hype

Over 10 billion RISC-V devices have shipped, including microcontrollers in millions of Western Digital storage devices, nVidia GPUs, etc. They have no reason to go back to ARM; in many cases it's not even possible as ARM is very restrictive about extensions to the ISA. RISC-V is here to stay.

What remains to be seen is if RISC-V makes it to the CPU big leagues and ends up powering smartphones and such.

im fascinated with the idea of using the same photomask for different "kind" of ICs

Basically everyone does it, the economy of silicon design means it is very often cheaper to make one or just a handful of masks and then artificially disable features to create granular variants inbetween the actual hardware variants. It's also used to salvage defective dies, if the defect is in an optional part of the chip then they can disable that part and sell it anyway.

This makes it sound as though

1. Arm can increase royalty rates on existing already shipping designs.

2. That increases in royalty rates would be material to the price paid by the end user - making the device ‘expensive’ for the end user.

Neither of these reflect the actual nature of licenses in practice.

If you're buying a large quantity of them for a product the license fees can certainly be relevant (As can, e.g. the number of pins on the package). I suspect it's there for that kind of customer.

Sure and what is possible is that some users develop RISC-V based applications and RPi can offer a slightly cheaper version for those really price sensitive customers.

The comment I replied to was unduly alarmist though in suggesting Arm could make the Pico ‘expensive’ vs ‘cheap’ now with a royalty increase on an existing license.

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.

Pimoroni does a very sweet rp2350 board with 16MB flash and 8MB PSRAM. It landed on my desktop a few days ago but I've not had a look at it yet. I might bring up a Rust-based operating system on it, I already have have it up and running in QEmu but it will need a lot of changes to even boot as the Hazard3 cores only supports machine and user modes, there's no paging.

I now have a Bus Pirate 6 on its way as well :)

I was shocked to discover the Hazard3 cores doesn't do floating point. It would have been quite nice to have that.

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.

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.

Reply on news.ycombinator.com