[HN Gopher] Hazard3: 3-stage RV32IMACZb* processor with debug
___________________________________________________________________
Hazard3: 3-stage RV32IMACZb* processor with debug
Author : EvgeniyZh
Score : 49 points
Date : 2024-08-11 06:12 UTC (16 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| johndoe0815 wrote:
| This is the RISC-V core used in the RP2350, the new Raspberry
| Pico 2 SoC.
| cpldcpu wrote:
| 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 wrote:
| I dunno if it will be that interesting due to area
| differences. Maybe if Raspberry publish the area stats too?
| cpldcpu wrote:
| 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.
| doctorpangloss wrote:
| Is a RISC-V core just the serial numbers filed off an ARM
| core?
| throwaway48476 wrote:
| 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.
| phire wrote:
| 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.
| jsheard wrote:
| 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
| klelatti wrote:
| Just to clarify
|
| > so ARM code is emulated (varmulet) on RISC-V
|
| As I initially read this the other way around.
| johndoe0815 wrote:
| 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...
| cloudy_craggs wrote:
| 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 wrote:
| 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"
| irdc wrote:
| 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.
| jsheard wrote:
| 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.
| irdc wrote:
| 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.
| gary_0 wrote:
| > 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.
| nadius wrote:
| im fascinated with the idea of using the same photomask
| for different "kind" of ICs
| jsheard wrote:
| 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.
| klelatti wrote:
| 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.
| Rochus wrote:
| 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.
| gchadwick wrote:
| 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
| Rochus wrote:
| But if they do formal verification, then at least SV
| assertions should be present; will talke another look at the
| code.
| gchadwick wrote:
| 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 wrote:
| Would be an interesting experiment to run hazard3 against
| RISVuzz, that found the ghostwrite bug.
| alex7o wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-11 23:01 UTC)