Live data from Hacker News

Faulty instructions in C910 RISC-V CPUs

ghostwriteattack.com

31–35 of 35 posts

Re: Faulty instructions in C910 RISC-V CPUs

#31

Earlier quoted context omitted.

Is it the logical end that we have custom cores everywhere? Yes RISC-V is open and relatively straightforward to implement (coincidentally I did just that over the weekend in a circuit simulator game), but I can also see economies of scale making it so that a few vendors end up making cores that are good enough for all use cases between them and end up dominating the market. A few low-powered 32E cores, a few desktop…

May I ask what circuit simulator game? I've attempted something similar with my very limited and hobby level hardware knowledge in Virtual Circuit Board and I learned that it would take me much longer than a weekend, heh.

Turing Complete - https://store.steampowered.com/app/1444480/Turing_Complete/

I also made my own assembler as part of learning the ISA and put it at https://github.com/Arnavion/riscv . You can see a screenshot and video of the CPU in action there.

The game's campaign walks you through creating a simple 8-bit CPU and then a larger CPU similar to old ARM. But then it also has a sandbox to do whatever, and you can use whatever design you want to solve the puzzles intended for the original two CPUs.

Re: Faulty instructions in C910 RISC-V CPUs

#32
post #6

I've definitely had this thought about this sort of openness that RISC-V inherently promotes. Sure, anybody can make a RISC-V CPU, but who really has the capabilities to verify them? There's a reason the ARM model has succeeded-- that is, providing totally off-the-shelf IP with pre-verified cores (because of their own large verif team). The logical end of RISC-V is that we have custom cores literally everywhere, but…

Yes, it would be disastrous if a widely-used chip had a bug in its division opcode.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

It would be disastrous if a widely-used chip had a bug in a lock prefix that allowed crafted untrusted binaries to soft-brick the whole machine.

https://en.wikipedia.org/wiki/Pentium_F00F_bug

I'm not even mentioning the weirdnesses from the eight-bit era. We all know those chips were heroic efforts to get anything done given transistor budgets, and error checking was simply not possible. The point is, even mature proprietary companies have had severe hardware bugs for longer than many here have been around, even if you discount stuff like spectre and meltdown.

Re: Faulty instructions in C910 RISC-V CPUs

#33
post #26

Has anybody noticed that malformed vsetvli instruction is using x0 register as destination (returning vl to be used by app) which in most RISCs is hard-wired zero. Very unlikely that writing to zero reg was not tested during design verification process as it's one of the obvious corner cases.

vsetvli with x0 as destination is well defined by the spec.

There's the mild note that the behavior of the 'x0, x0' form changed between RVV0.7.1 and 1.0 - on 0.7.1 it sets VL=VLMAX, while on 1.0 it inherits the previous VL. That said, the 0.7.1 behavior is still useful, and improper behavior would certainly be caught by basic testing, never mind the users who have had chips with it for a while.

Re: Faulty instructions in C910 RISC-V CPUs

#34
post #6

I've definitely had this thought about this sort of openness that RISC-V inherently promotes. Sure, anybody can make a RISC-V CPU, but who really has the capabilities to verify them? There's a reason the ARM model has succeeded-- that is, providing totally off-the-shelf IP with pre-verified cores (because of their own large verif team). The logical end of RISC-V is that we have custom cores literally everywhere, but…

The same used to be said of open source competition to Oracle's database. An open source DATABASE? Unthinkable! First off it would be prima facie insecure, and secondly, it would be a toy that could never compete on important things like performance!

Re: Faulty instructions in C910 RISC-V CPUs

#35
post #6

I've definitely had this thought about this sort of openness that RISC-V inherently promotes. Sure, anybody can make a RISC-V CPU, but who really has the capabilities to verify them? There's a reason the ARM model has succeeded-- that is, providing totally off-the-shelf IP with pre-verified cores (because of their own large verif team). The logical end of RISC-V is that we have custom cores literally everywhere, but…

My takeaway from this is that the existence of RISCVuzz will make future verification much easier. Just run your prototype (or even an emulation of it) against a known good array of implementations.
Post reply on HN