Support heterogeneous uArches features

[VynDragon]

Is your feature request related to a problem? Please describe.

There is currently no canonical way to handle uArch-specific features in Zephyr RTOS, this is problematic as there is a canonical way to handle arches (ISAs) and a canonical way to handle SoCs, but no way to handle uArches which may be used in multiple socs.
This is exemplified by this review issue: #95427 (comment).

Describe the solution you'd like

Some method to handle features specific to a CPU core / CPU core family that isnt specific to a SoC or not generalize-able to a arch.

Describe alternatives you've considered

There is curently 3 suggested places:

• a new folder in the root, /core
• folder arch/*/core
• soc/common/core

[JarmouniA]

This is not specific to RISC-V as @tejlmand mentioned here #95427 (comment), if we go forward with a separation of Cores from Arch, we will have to apply it to Cortex-M/A/R & others as well.

[tejlmand]

Thanks for raising this, and ideas are more than welcome.

But to not forget, I would like to highlight this part: #95427 (comment)

My main concern long term is that risc-v is open standard, so several vendors can start creating IPs which in same way can be argued to be an arch, not a SoC, while at the same time someone can create a risc-v SoC where similar Kconfigs are placed in SoC. End result becomes very muddy, and hard to know where a given config should go.

and moving into another folder, being named core or something else doesn't change the part regarding some vendors consider their RISC-V to be a SoC directly, and for others being a uArch.

This comment is only to have it in mind when designing the structure so both use-case are considered and proper guidelines can be made.
It should not prevent this work from going forward.

[VynDragon]

doesn't change the part regarding some vendors consider their RISC-V to be a SoC directly

Do you have a example of this? I have only seen this for neorv32 which is arguably just bad naming, while on the other side sifive, xuantie, andes, wch (qingke series), spacemit, ultrarisc, etc all consider their cores as a separate element

[tejlmand]

Do you have a example of this?

This is more on a general view.
If going in this direction, then one can probably argue that every single SoC regardless of arch (riscv, arm, arc, sparc, etc.) should be split this way, even if only a single SoC is using the specific core.
This is where arm is special, partly both because toolchains, such as GNU and llvm, directly supports the cpu type as flag, but also because the arm series are so widespread and re-used with common features sets that there is a lot of reusability in having common Kconfigs. Currently there are 765 boards with arm architecture.

We need to consider if doing a split everywhere create actual value in terms of reusability and ease of understanding Zephyr ?
Especially in cases where only a single SoC is using the particular core.
Making this split, just for making the split doesn't make it easier for new-comers to create a PR supporting their SoC.

[josuah]

On the topic of RISC-V having more diversity to handle than single-vendor families like ARM:

• arch: riscv: introduce common layer for RISC-V custom CSRs  #93697

[jimmyzhe]

I think the category for the architecture, RISC-V custom extension, core and SoC would be like:

Vendor	Andes	THead	Nuclei	WCH	SiFive	ARM
Arch	RISC-V	RISC-V	RISC-V	RISC-V	RISC-V	ARM
Custom Extension	Andes V5	THead	Nuclei	XW	(Standard)	-
Core	D25, AX45 .etc	Xuantie E907	Bumblebee	QingKe V2, V3, V4	E31, U74, E24	Cortex-M0+/M3/M4/M33/M55
SoC	AE350, TLSR951x, ET171	BL61x	GD32VF103	CH32V003, CH32V303	FE310, FU740, BL60x, BL70x	STM32F4, nRF52840, RP2040

I believe Andes V5, T-Head and Nuclei ... extensions at the same category level and these vendors are part of RISC-V (at least Andes announce that).

If there is a root/core in the future, it would be great to separate T-Head’s Xuantie case into:

• T-Head extension (belong to arch/riscv)
  The custom CSR and instruction that follow RISC-V spec.
• Xuantie E907 core

Since there is RISC-V GCC option for xthead and xandes.

[VynDragon]

If you want to make it exhaustive there is bl60x and bl70x with sifive E24.

xtensions at the same category level and these vendors are part of RISC-V

Are vendor extension actually part of RISC-V in that sense though? Or maybe it is limited to things under review (P extension) or accepted at the risc-v level?