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

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

As I initially read this the other way around.

reply
johndoe0815
10 months 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
10 months 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
10 months 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
10 months ago
[-]
I dunno if it will be that interesting due to area differences. Maybe if Raspberry publish the area stats too?
reply
cpldcpu
10 months 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
10 months 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
10 months ago
[-]
Is a RISC-V core just the serial numbers filed off an ARM core?
reply
throwaway48476
10 months 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
10 months ago
[-]
No support for floating point. It would have been nice to have that.
reply
gchadwick
10 months 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
10 months ago
[-]
Would be an interesting experiment to run hazard3 against RISVuzz, that found the ghostwrite bug.
reply
Rochus
10 months 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
10 months 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
10 months ago
[-]
But if they do formal verification, then at least SV assertions should be present; will talke another look at the code.
reply
wren6991
10 months ago
[-]
Yosys supports very basic SVA (immediate assert/assume, $past etc) in addition to Verilog 2005
reply
cloudy_craggs
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months ago
[-]
im fascinated with the idea of using the same photomask for different "kind" of ICs
reply
jsheard
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months ago
[-]
I now have a Bus Pirate 6 on its way as well :)
reply
mrlonglong
10 months 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
10 months 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
10 months 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