After working with RISC-V CPU's produced by SocHub, and CVA6 running on FPGA and projects like Keystone Enclave during my "industry sabbatical", here's my thoughts on the topic enumerated in random and chaotic order:

1. Specifications are ambiguous and sometimes plain incomplete. WFI opcode is a great example of ambiguity. The lack of ability to define caching properties (like MTRR on x86 ) for physical memory is a great example of incompleteness.
2. IRQ handling is worst I've seen in any modern CPU architecture. It is slow and badly engineered.
2. CPU's behave quite differently depending on vendor, especially cache. For this reason I spent almost two months fixing trivial page table boostrapping code for Keystone Enclave (on CVA6).
3. Commercial CPU's are proprietary as hell given that the "openness" means that companies just fork and tailor and obviously do not publish any changes back to the community.
4. There is neither shared repository for hardware definition in VHDL nor Verilog.
5. There's no open source community. There is only corporate body called OpenHW Group. It is all about companies doing together an open hardware brand, not individuals making together great things.

To have actually open hardware the design and HDL should be copyleft licensed. Not sure if that is commercially realistic but otherwise it is all just as fake as having a BIOS based on Tianocore, and claiming that BIOS is open source.

It is more open to have a proprietary vendor that either sells CPU's (Intel) or licenses the spec (ARM). It is also better for individual because you have an entity that talks you back if you are a customer of them.

#riscv #hardware #opensource #sifive #arm #intel

@jarkko realistically, without a chip fan plant, would any of it be useful? I expect it's a bit too complex to just build one on an fpga.

I have zero knowledge about it, just curious.

@Netux ive done a lot of work with CVA6 running on Kintex7 FPGA. After todays job interview it might be that I end up working with RISC-V but disliking *in detail* is where engineering starts 🙂 If you are happy with the status quo, it can be hard to be distruptive which essential in tech business.

@jarkko found a fun link you'll appreciate.

CPU bugs reached a level of yikes that speculation side channels can only dream of

https://ghostwriteattack.com/riscvuzz.pdf

a) Address-handling: RISCVuzz finds different bugs around virtual address handling. ...

https://mastodon.gamedev.place/@harold/112922089904933549

@Netux I'm not sure what RISC-V architecture even is.

The spec does not have any even pseudo code for opcodes, let alone upstream with official VHDL/Verilog.

How come RISC-V be open hardware when there is no hardware *at all*? It's like I would explain some imaginary specs for imaginary CPU in this comment would claim that here's a new open CPU ecosystem, fast-forward to the future and beyond ;-)

One can at most say from current specs that there is a collection of abstract ideas of register layout, opcodes (some of which are *ambiguous*) etc. AND a marketing brand for corporations involved :-) I still like to work on this stuff because when the shit is still broken, that is *exactly* the fun zone :-)

@Netux Linux has arch/riscv tree but that could be just as well arch/sifive tree. I.e. there is a single proprietary vendor for MMUfull RISC-V, which defines how that category works. Others will follow. Not that different from e.g. Intel in the end.