Hazard3: 3-stage RV32IMACZb* processor with debug
62 points
28 days ago
| 5 comments
| github.com
| HN
johndoe0815
28 days ago
[-]
This is the RISC-V core used in the RP2350, the new Raspberry Pico 2 SoC.
reply
jsheard
28 days 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

reply
klelatti
28 days ago
[-]
Just to clarify

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

As I initially read this the other way around.

reply
johndoe0815
28 days 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...
reply
cpldcpu
28 days 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.

reply
phire
28 days 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.

reply
IshKebab
28 days ago
[-]
I dunno if it will be that interesting due to area differences. Maybe if Raspberry publish the area stats too?
reply
cpldcpu
28 days ago
[-]
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.
reply
Zeetah
27 days ago
[-]
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.
reply
doctorpangloss
28 days ago
[-]
Is a RISC-V core just the serial numbers filed off an ARM core?
reply
throwaway48476
28 days ago
[-]
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.
reply
mrlonglong
26 days ago
[-]
No support for floating point. It would have been nice to have that.
reply
gchadwick
28 days 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.

reply
captn3m0
27 days ago
[-]
Would be an interesting experiment to run hazard3 against RISVuzz, that found the ghostwrite bug.
reply
Rochus
28 days 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.
reply
gchadwick
28 days 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
reply
Rochus
28 days ago
[-]
But if they do formal verification, then at least SV assertions should be present; will talke another look at the code.
reply
wren6991
26 days ago
[-]
Yosys supports very basic SVA (immediate assert/assume, $past etc) in addition to Verilog 2005
reply
cloudy_craggs
28 days 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?

reply
InvaderFizz
28 days 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"

reply
irdc
28 days 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.
reply
jsheard
28 days ago
[-]
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.
reply
irdc
28 days ago
[-]
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.

reply
gary_0
28 days ago
[-]
> 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.

reply
nadius
28 days ago
[-]
im fascinated with the idea of using the same photomask for different "kind" of ICs
reply
jsheard
28 days ago
[-]
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.
reply
klelatti
27 days ago
[-]
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.

reply
rcxdude
27 days ago
[-]
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.
reply
klelatti
27 days ago
[-]
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.

reply
snvzz
27 days 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.

reply
mrlonglong
26 days ago
[-]
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.
reply
snvzz
26 days ago
[-]
I now have a Bus Pirate 6 on its way as well :)
reply
mrlonglong
22 days ago
[-]
I was shocked to discover the Hazard3 cores doesn't do floating point. It would have been quite nice to have that.
reply
alex7o
28 days 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.
reply
p_l
27 days 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.
reply