On December 27, 2023, StarFive successfully submitted the ACT test results for the Dubhe-90 (Click here for more details). Thus far, StarFive has obtained ACT certification for two products: JH-7110 SoC and Dubhe-90 CPU IP.
RISC-V CompatibleTM
RISC-V architecture testing serves as the fundamental screening tool, aimed at ensuring software written for a specific RISC-V configuration or specification can seamlessly operate on all implementations that adhere to that configuration. Furthermore, RISC-V architecture testing assists in ensuring implementers’ accurate understanding and implementation of the specifications.
Through RISC-V architecture testing, we provide users with results that guarantee correct interpretation of the specifications and assure that the tested implementation (DUT) complies with RISC-V architecture assurances. Only by passing the architecture tests compliant with the RVI20 standard and obtaining approval from the RISC-V International organization can authorization to use the RISC-V trademark in designs be granted.
Dubhe-90 presents the pioneering solution enabling the Hypervisor Extension within the RISC-V ACT. Simultaneously, StarFive’s software team successfully ported the ACT Reference framework from the SAIL C simulator to the Spike platform and operated it successfully, marking the industry’s first successful case.
Passing the tests and gaining recognition from RISC-V International signifies that StarFive’s release of the Dubhe-90 solution is classified as a RISC-V ISA compatible product. This achievement marks not only another significant milestone for StarFive in the RISC-V domain but also establishes a technological benchmark in the industry.
Can you confirm whether the StarFive JH8100 will have Vector 1.0 extension? It has 4x Dubhe-80 cores and 2x Dubhe-90 cores. The Dubhe-80 page on your website claims it supports Vector 1.0 extension, but the person submitting patches to the Linux kernel for the JH8100 is saying that the JH8100 will not have support for Vector.
I see what you mean here: https://lore.kernel.org/lkml/09c51c5301c54659828c5cce748d3762@EXMBX066.cuchost.com/T/ starfive,dubhe-80 and starfive,dubhe-90:
riscv,isa = “rv64imafdch”;
iscv,isa-base = “rv64i”;
riscv,isa-extensions = “i”, “m”, “a”, “f”, “d”, “c”, “h”, “zicntr”, “zicsr”, “zifencei”, “zihintpause”, “zihpm”, “zba”, “zbb”, “zbs”, “sscofpmf”;
I suspect that the Dubhe-80 in the JH8100 will indeed support vector 1.0 extension. But currently I also suspect that the easy solution to get all 6 cores initially working with the features currently available in the Linux Kernel is if the support for vectors within the Dubhe-80 cores is hidden so that only common RISC-V extensions with the Dubhe-90 cores are exposed to the Linux Kernel. I could be wrong but I suspect that there is currently no feature for the RISC-V Linux kernel scheduler to deal with different RISC-V harts having different extensions.
It is probably similar to why CPU0 is hidden/disabled (rv64imac_zba_zbb) to the Linux Kernel for the JH7110 SoC and only CPU1, CPU2, CPU3, CPU4 (rv64imafdc_zba_zbb) are available.
I second that… if there is a miss match between the 80 and 90 core’s vector support it will hamstring Linux.
From what I understand the processes can’t guarantee wether they are on a vector core, and can’t be switched between low and high power cores. Essentially this locks one or the other sets of cores out from the running system.
It is something that you need enough hardware out there in the world with these features before the scheduling software is updated to support them. If different features in different cores previously existed under x64 and/or ARM (Which they do not under Linux. You do have some ARM microcontrollers e.g. LPC4370 which has an Arm Cortex-M4 for embedded applications, includes an Arm Cortex-M0 coprocessor and an Arm Cortex-M0 subsystem for managing peripherals, but they have insufficient resources to run Linux), the functionality would be already in place for RISC-V. And no one writes code for things that might be added to hardware at some later date maybe, the hardware needs to exist first - there is always a lag when people spend time thinking of the best way to solve new problems.
While there is no technical reason why the scheduler cannot track the ISA required by a running process and only assign it to appropriate cores, there are both implementation and theoretical questions (eg is anyone actually working on this? would upstream accept it? etc…)
More practically, are we expecting lots of ‘mixed ISA’ risc-v systems in the future.? If the JH8100 is like this, will it just be some ‘weird’ one-off, or a herald of a world where system designers can mix-n-match cores on a chip without needing to ensure they all support the same ISA.
I remember Intel have this project with their E/P core scheduler(P core have AVX512, but E core only have AVX2 256bit).
AVX10 seems give up 512bit, maybe Intel found out this is hard.
PS: Old BIOS can let 12th core disable E core & enable AVX512 support with P core. I think hybird instruction is only a soft problem, but it is depend on a new system degisn.
