DeepComputing: Early Access Program for RISC-V Mainboard for Framework Laptop 13

This JH7110 is from 2021. Some specs: https://www.cnx-software.com/2022/08/29/starfive-jh7110-risc...

1.5 GHz CPU core frequency, some old RISC-V cores while we're still waiting for cores with decent single-core performance to compete with modern desktop processors.

Sorry, but for me this board is dead in the water, unless you can't use ARM/x86 for political reasons.

It's a dev board. Reason to buy it: you need a desktop that has RISC-V cpu inside.

The problem is that it's a dev board that will likely be slower than QEMU, and is missing half of the Risc-V extensions that you want to test with. (and it supports a maximum of 8gb of ram, so good luck compiling LLVM on it)

If you want a desktop, the Pine64 Star64 is only $90 for the same spec. This is a laptop though.

> This JH7110 is from 2021.

First retail customer deliveries of mass-production JH7110 chip and board were February 2023. First laptops with it were at the end of 2023.

The CPU cores used (U74) were announced in October 2018. The first high-priced dev boards using essentially test chips (HiFive Unmatched $650, BeagleV Starlight unknown price, 300 were made and given away to developers) were mid 2021.

It is important to distinguish the dates of availability of RTL for a core, first tests chips of a complete SoC using it, and mass-production as there is usually several years between each stage.

You hear about all these dates in the RISC-V and Arm worlds where each thing (core, SoC, board) is done by different companies, each with a vendor-customer relationship with the previous stage company. You don't hear about them in the more vertically-integrated x86 and Apple worlds.

Milk-V Mars 8 GB is $68.99 at Arace.

>good luck compiling LLVM on it

4 cores, thus 2GB/core. Plenty.

An N100 running QEMU will be slower. A machine that is faster running QEMU will cost a lot more.

For example my 6 core Zen2 laptop runs my primes benchmark (small code, long-running, the best possible case for qemu-user) 10% slower than my VisionFive 2. If you want to run a whole emulated OS then qemu-system is a lot slower than qemu-user.

My i9-13900 laptop runs the same benchmark in qemu-user 2.6x faster than the VisionFive 2, but it also costs 30x more -- or about 2x more than the Frame laptop with the JH7110 mainboard. Or 5x more than the original DC Roma laptop with the JH7110 now costs ($299).

If you want a RISC-V laptop then Frame is a very expensive way to get one. It might be higher quality, and it will be upgradable to better specs later.

I regularly get OOMs at 16 GB/core doing debug builds. LLVM is practically a memory stress test.

That's true, you don't hear about these dates in vertically-integrated businesses, but it's a bit of a misdirection. Vertically-integrated manufacturers definitely don't take 6 years from RTL completion to mass production of the end product.

I can't remember if LLVM has this problem specifically, but the linker step with debug info can really explode the memory use.

And unfortunately, that's even without build parallelism.

That's because they are vertically-integrated and can overlap the different stages and have the board people give feedback to the SoC people, who can give feedback to the CPU core people.

With multiple vendor-customer relationships in the chain there is not only likely to be no overlap in stages, but even there may be 6, 12, 24 months of gap between the RTL for the core being available and someone even making a decision to make an SoC using those cores, and a similar gap from a chip being available to someone else deciding to buy it to design a motherboard around it.

make -j4 for LLVM requires about 36GB (I know because I tried with 32GB). 16 gb is almost enough to maybe build a debug build of LLVM without threading, but it will take a few hours on a chip that slow. With only 8gb, you are going to be absolutely trashing your swap (which at pcie gen 1x2 speeds will be pretty darn torturous). I'm guessing this system will take ~8 hours to build LLVM.

Those delays are very understandable but they don't make the chips less old, or counteract the problems caused by being old when RISC-V is racing to catch up.

The people who put out RTL for a core go right on to making a better core. The time they take to design a new core is not affected by how long people making SoCs or boards or consumer products do or don't take to make their own products.

Are you aware that major chip company Microchip just announced a new family of chips, the PIC64GX -- a big deal for them -- with a dev board that has just become available in the last month or so, which uses RISC-V cores first used in the HiFive Unleashed in early 2018 (and announced in Oct 2017, when they already had working test chips)?

https://www.microchip.com/en-us/development-tool/curiosity-p...

Are you aware that people still announce new chips based on the Arm A53, a core announced in 2012?

Or that 70% of Arm's revenue comes from CPU cores announced in 1994 (ARM7TDMI) - 2009 (Cortex-M0)?

"Old" is not relevant to anything. Only design features are relevant.

Fortunately the LLVM build framework allows you to specify how many link steps can be done in parallel separately from the number of other things done in parallel.

Also, linkers other than GNU `ld` (or `gold` which is faster but used more RAM) use a lot less RAM e.g. `mold`, or even better LLVM's own `lld`.

> The time they take to design a new core is not affected by how long people making SoCs or boards or consumer products do or don't take to make their own products.

I don't think anyone implied otherwise. But the product in my hand is still lacking.

> Are you aware that major chip company Microchip

I don't see how this affects my argument in any way?

> Are you aware that people still announce new chips based on the Arm A53, a core announced in 2012?

Not for the main cores of laptops they don't.

> "Old" is not relevant to anything. Only design features are relevant.

There is sufficient context here to tie the two together. These cores are slow because of relative lack of development time. These cores lack vector units specifically because of their age, because they were designed before there was a spec (which you brought up).

> will cost a lot more.

Presumably everyone buying this thing would already have (or need) a proper PC/Mac to use alongside it.

Maybe. Or they might only have a phone/tablet. Or an older but still totally useful machine such as that Zen 2 laptop I mentioned, which runs qemu slower than the VisionFive 2.

Also, a number of people have come unstuck by writing and testing things ONLY on qemu, and then had them fail on real hardware. For example, qemu was historically much more lenient with PMP settings than real hardware (if you didn't touch the PMU then qemu acted as if you didn't have one at all). Also anything that needs fences on real RISC-V (or Arm) hardware is likely to work even when it's incorrect on a PC that is jitting multiple instructions per RISC-V instruction and is TSO anyway. Qemu being lenient about setting up the UART (e.g. it doesn't care about baurd rate, start/stop bits etc) compared to real hardware is another example.

Only if you use FatLTO. I've compiled LLVM many times with less memory.

GCC on the other hand is another story. On a machine that I was able to compiled LLVM (thanks swap), I couldn't even extract GCC source code.