One of the first RISC-V laptops may ship in September, has an NFT hook It seems promoters of RISC-V weren't bluffing when they hinted a laptop using the open instruction set architecture would arrive this year. Pre-orders opened Friday for Roma, the "industry's first native RISC-V development laptop," which is being built in Shenzen, China, by two companies called DeepComputing and Xcalibyte. And …
Ports? Screen resolution? Audio capabilities? Battery size? Average/max run time? Etc, etc, etc.
I tried to visit the preorder page to get more info, but there was a blatant void in that department. They're happy to collect all your details, you have to register that you're interested with full name, email, mailing address, business, whom referred you, etc, and all those fields are marked *Required*, but not a jot about product specs, pricing, or even when/if you can expect to get one.
It's like KickStarter, but with less oversight or product details. =-/
I would be interested myself, but the way this is being done is a bit unnerving. I expect it will be US keyboard layout only.
I have a RISC V SBC and it’s fun to mess with but the Linux support is all a bit ropey, qemu on my existing laptop could have provided for my requirements just as well.
I’m way, I’ll keep watching for more information.
There is hope that RISC-V get on the list of sanctions for supporting Russian terrorist state.
SoC Design Challenge: the first engineering hackathon for students in Russia
Organisations supporting terrorism should not have a place in our society.
So, we’ll start with:
The 12nm CPU must be the StarFive Dubhe, which makes it (and don’t all rush at once) “up to” 2GHz and 64-bit
https://riscv.org/news/2021/12/starfive-dubhe-64-bit-risc-v-core-to-be-found-in-12nm-2-ghz-processors-jean-luc-aufranc-cnx-software/
Coming out in “late 2022 or 2023”, which from long experience of such announcements means “late 2023, early silicon with errata”
Out of curiosity, on the high end RISC side, how much are the licensing fees for arrm CPUs?
I thought the fees were relatively trivial. Is it literally just because the Americans are being difficult and restricting sales to China and Russia, is it the nature of open source coders, CompSci PhD students, or just the nicety of having CPUs with confirmed lack of patent worries??
Licensing fees for something high end might be a million. Royalties typically might be 1-2% per chip. But all this misses the point:
Manufacturers buy wafers, not chips. Yield adds directly proportionately on costs, and just dominates over any royalty in practice.
When you just drop in an ARM Cortex A53 (say) into your SoC, and get it fabbed on TSMC 7nm, they’ve made the exact same thing before. They will guarantee you 95% yield contractually, and pay any shortfall on that. It’s reputational and core risk: if they have low yield on that, they need to fix it - for everyone, not just you, otherwise they don’t have a business.
If you DIY a RISCV, even if it’s identical source, unless it’s been through *traceably* identical toolset, synthesis, clock and power tools, drive strengths, etc. There is enough “black art” in the fab process that you will be lucky to get 80% yield. And TSMC won’t guarantee it. That 15% shortfall is 15% higher effective chip price for *you*. 2% royalty overhead totally misses the point.
The point is that the restrictions of the ARM licenses are excessive, and the fact that it costs more than $0.
If you want to make modifications to ARM chips, you aren't allowed to. If you just need a low end processor for a controller board, why would you want to pay for it unnecessarily?
“If you want to make modifications of ARM chips you’re not allowed to”.
A) Rubbish. Of course it’s allowed, there’s a license available to add your own special instructions on ARM core.
B) As ASIC designer, and leader, and manager, I’ve been involved in dozens of tech tradeoffs. There’s always some bright young thing who thinks they are the first to consider a custom instruction to accelerate a tight loop. And we always consider it. But after careful tradeoff, it’s just always more optimal to hang it as a memory-mapped IP block.
Multiple reasons:
1 Cost of re-optimising and re-verifying the CPU core.
2 Risk of yield problems on the modified CPU core (big one this).
3 Hanging extra logic onto the fan out of CPU registers, increases required drive strengths, which means extra power dissipation all the time (not just when executing the tight loop).
4 It also messes around the whole floor planning, which tends to drop the clock frequency. Have you ever wondered what an amazing coincidence it is that all the CPU dies you’ve seen are rectangular? There’s no a priori reason for the gates to pack nicely like that. Add just ten gates in the wrong place, and *everything* has to move to the other side, which completely alters the critical paths, as they are dominated by routing delay in many cases.
5 Most tight loops iterate around a block of data, possibly larger than L1 cache. The *last* thing you want is to waste memory bus cycles pulling all that data into and out of registers, with cache misses. Better to provide dedicated on-chip scratchpad SRAM that never gets swapped, and operate on it without involving memory bus.
6 When you’re not executing the tight loop, you can power down an IP block. You can’t separately power down a tightly coupled execution unit within the CPU core.
Academics and “researchers” often think it’s cool, and makes it more “flexible” in software. It really isn’t, and actually it isn’t more flexible either than a well-designed and parameterised memory-mapped IP.
Anyone who falls for this train-wreck deserves exactly what they are going to get---absolutely guaranteed. Everywhere one looks and no matter which way one turns in trying to get a rational handle on this so-called product, a red flag pops up.
Oh...my Driver's License confirmed the fact that I wasn't born yesterday. If you are even remotely considering this device or its <charitable>perpetrators</charitable>, you need to check your Driver's License.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
