Are there higher level abstraction efforts in the linux kernel to prevent a hypothetical custom RISC-V diversity explosion from ending up quite as messily as custom ARM did?

Afaict, most of the ARM ugliness was around non-"CPU" SoC components. But it definitely seemed like kernel code organization wasn't ready for a 10x (or 100x) explosion of popular SoCs.

And the entire point of open sourced RISC-V cores is that they would enable even more chip diversity, no?

The riscv kernel maintainer is not interested in maintaining many different configs for many different SoC. So that is one effort to avoid fragmentation. If you look at the riscv config tree we can see about 5 configs:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Compare this to the ARM tree there are a few more:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Source: https://github.com/esmil/linux/pull/6#issuecomment-844135991

There have been discussions about this, and my conclusion is that there definitely could be a problem on the order of ARM’s. With luck, RISC-V will learn from history and not doom itself to repeat the same mistakes.

Is there an existing standard that board implementations can rally around? Something like OpenBoot? Make it a defacto standard.

We have device tree. The problem on ARM is

1) Qualcomm and other SoC vendors fighting interoperability

and

2) Users not understanding device tree.

The RISC-V ISA specifically allows for custom extensions.

Unfortunately, the licensing model does require the implementations to be FLOSS. This encourages creating a lot of closed stuff with different and incompatible extensions.

It doesn't matter. As long as they implement the core RV64GC instruction set correctly, standard software will run, and if they implement privileged architecture 1.10 or later correctly then the standard Linux kernel will run.

Vendors are free to use custom extensions to implement the bootloader and SBI. Normal code and even the OS won't see that. They can also use custom extensions in hardware drivers. Even in libc, if they want, though that gives more maintenance work.

Whether RISC-V ISA extensions are allowed or not is unrelated to the problems seen with ARM SoCs putting peripheral devices at different addresses.

Could a device table [for on-chip peripherals] be put right on chip?

Yes, that's a devicetree. Those can be tacked onto the kernel image or dynamically loaded from the chip's firmware (which most likely gets it from the firmware flash).

Sure, but the question was about diversity explosion in general.

> I wish opportunities like these were available back in my college days.

I'm forgetting the source, but some book I read discussed some period of silicon valley as a place where colleges quite routinely exposed students to chip-making. It sounded like the fabs of the area greatly supported these efforts. I'm not sure where I read it but it's stuck with me across many years, always strongly affirming my belief that people, when given exposure to how & means to do, begin many great things.

I'm sure students in the valley have been routinely exposed to VLSI chip-making, and actually making ICs, since at least the early 90s. I know I was.

The main problem is there are only so many universities with so many sections therefore quite a lot of students don't get exposure, even within a given EE department. And even if they could offer it to all students, many wouldn't enroll, as you're basically doing this class constantly for like a year, for not that many credits relative to the time spent, as it sucks down just tons of hours as one gets familiar with all the nitpicky details that one needs to know. And as one learns to deal with the joy that is CAD tooling.

However, in my opinion, the experience in invaluable. And students that can pass that course, with a successful chip in hand, are hand picked by employers. We sure do.

EE272 at Stanford actually started to post their flow. Another benefit of the open source PDKs.

https://code.stanford.edu/ee272/skywater-digital-flow

There are actually many interesting student designs out there. For example this OoO RV64GC RISC-V core from Berkeley: https://chipyard.readthedocs.io/en/latest/Generators/BOOM.ht...

This was kicked off by Lynn Conway's famous VLSI design course at MIT [1], which began the Mead & Conway revolution.

You can find a more detailed write-up of that course and other courses it inspired (as well as some of the practical challenges involved) in her retrospective in IEEE Solid-State Circuits Magazine [2].

An excerpt:

> "Importantly, these weren’t just any designs, for many pushed the envelope of system architecture. Jim Clark, for instance, prototyped the Geometry Engine and went on to launch Silicon Graphics Incorporated based on that work (see Fig. 16). Guy Steele, Gerry Sussman, Jack Holloway and Alan Bell created the follow-on ‘Scheme’ (a dialect of LISP) microprocessor, another stunning design."

[1] https://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.htm...

[2] https://ieeexplore.ieee.org/document/6393023

Wow that second link ("Reminiscences of the VLSI Revolution") turned out to be a 29 page rabbit hole providing a fantastic glimpse into the history and early days of chip design and engineering, thanks a lot for posting that! Here's a direct link to the PDF: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69...

ARPA (and later DARPA) had a deal with MOSIS back in the late 70s and early 80s to fab chips for projects they funded (I remember this being used at MIT and Stanford at least, and surely others I wasn’t exposed to).

Not sure when GP went to college, but Caltech students were able to submit projects to MOSIS shuttle runs for a chip design class over 25 years ago.

i love these names: they are very intel-like

雁栖湖 → yangqi lake 南湖 → south lake

For someone unfamiliar with how the overall process works, what’s the road from this design to seeing this power laptops or desktops available to consumers? It isn’t clear to me, for example, what else needs to be designed around this - a motherboard? Will software “just works” since it is using a known instruction set architecture?

> Very cool to see a team of 25 students [in China] put this together

There will be many more stories about Chinese "Open Source" CPUs, because the USA has declared a strategy for this decade to control and limit the flow of advanced semiconductor tech to China. China would love to have bright minds from the West contribute to "Chinese Open Source" CPUs. Western contributors will find that these "Open Source" designs can only be economically fabricated in China, though, creating dependence on China.

It is a good strategy that has worked historically. Sugarcoat your real goal with some humanitarian bs and then have the best talent of the world working for you.

Chinese companies have focused on RISC-V as an alternative to ARM since the export controls. The thing with their chips is that SDK support is somewhat lacking? This is my conclusion after working with the extremely popular ESP devices.

Are you talking about the riscv esp32-3c SDK? Because I think the Espressif SDK has really matured over time for their other cores.

The documentation is far from top notch. Compare it with Zephyr OS documentation and you'll see quite a difference.