Posts by Bruce Hoult

Post-IPO, Arm to push purpose-built almost-processors

RISC-V behind but catching up

The initial version of the RISC-V ISA with just basic integer and IEEE floating point instructions was ratified (frozen, formally published) in July 2019, almost eight years after the ARMv8-A spec was published (and which Arm had presumably been working on in secret for some years -- I suspect from around the time amd64 entered the market in 2003).

Ratification was the starting gun for serious RISC-V players.

A handful of chips existed before that -- a few made by students at Berkeley, generally with instruction sets quite different to the final version, the FE310 and FU540 made in quantities of a few hundred ("shuttle run") by some of those Berkeley students at their SiFive startup, and one commercial microcontroller, the Kendryte K210 made by Chinese company Canaan which specialises in BItcoin mining ASICs. Canaan checked out the then current snapshot of Berkeley's "Rocket" RISC-V core and built an SoC around it.

A couple of reasonably high performance RISC-V cores, the SiFive U74 and the THead C910 were announced right around RISC-V ratification in 2019. The C910 is similar to Arm's A72, as found in e.g. the Raspberry Pi 4. The U74 is similar to ARM's A55, simpler cores that can approach A72/C910 performance (and significantly better than A53) but with much lower silicon area and energy usage.

Multiple low cost RISC-V SBCs have come out this year using the U74 (JH7110 SoC) and C910 (TH1520), plus there is a 64 core C910 SoC (SG2042) that will be on boards shipping to retail customers before the end of the year (vendors have had EVBs since March).

So that's basically four years behind the Raspberry Pi 4, both for announcement of the cores (2015 vs 2019) and SBCs shipping (2019 vs 2023).

The Milk-V Mars (JH7110) is available starting from $39, with a Pi CM4-compatible board starting from $34. The Milk-V Meles (TH1520) is faster and starts from $99. Other companies including Sipeed, Pine64, and BeagleBoard are also shipping SBCs (and a tablet from Pine64) using one or the other of these chips, but so far Milk-V have the keenest pricing.

2024 is going to see RISC-V boards competitive with the RK3588 Arm A76 boards such as Radxa Rock 5 and Orange Pi 5 [Plus]. Those will be about two years behind the similar Arm boards.

Multiple companies ranging from SiFive to MIPS to Jim Keller's Tenstorrent to Ventana have RISC-V cores formally announced (or very close to it) that are in the Neoverse to Apple M1 range.

Enter Tinker: Asus pulls out RISC-V board it hopes trumps Raspberry PI

Re: where some high speed SRAM is located

> Err, is it the same memory that shows up in every virtual address space? wouldn't that be a huge security/stability risk?

Exactly! If this is actually correct (and it's being discussed on the Linux mailing list) then it's just an awful blunder on the part of Andes.

https://lore.kernel.org/all/[e-mail]/

They want to change the address for statically-linked binaries, to start above this address hole.

OK, sure, that will work with things they compile themselves, or on their board, but not for any binary copied from another RISC-V system WHICH SHOULD WORK.

To solve this you'd need to have the OS copy that 128 KB of RAM in and out on every process switch (or address space switch), at least if either the from or the to process has that memory range in their page table. Slow, slow, slow.

Just an awful bug in that Andes CPU core, if this is all true and not some misunderstanding.

Re: where some high speed SRAM is located

It is completely normal to have a few KB of ITIM and/or DTIM on both ARM and RISC-V chips. Often (e.g. on all current SiFive cores) you can programatically decrease the size of the L1 cache and use the rest of it as scratchpad.

That's in physical address space.

What is wrong here on this Andes core is that this shows up in EVERY virtual address space too. That just completely breaks what a virtual address space is supposed to be. You're supposed to be able to map any virtual address to whatever physical address the OS wants. Not to have part of it (128K) mapped directly to physical.

On a normal ARM or RISC-V or x86 chip (or any other), you can always choose to map a certain part of multiple (or all) virtual address spaces to the same physical addresses. It's normal for this to be done for the OS kernel's RAM, for example. It is mapped the same in every process, but protected so only OS code can read/write it.

But that's a CHOICE.

This Andes core doesn't give you a choice, and furthermore, puts that area in a commonly-used address range.

Re: Look up StarFive 2

> Someone dug deep into the source code commits for the JH7110 and found that they could possibly do 1.75GHz, but you would probably need proper cooling.

As it does 1.5 GHz without a heatsink of any kind, and a lot cooler than a Pi 4 -- I haven't been able to get mine over 68 C with a heavy make -j4 build taking over two hours -- it can probably do a good bit more than 1.75 GHz with "proper cooling".

Re: Look up StarFive 2

> I don't see how a single core 1 GHz CPU can get close to 80% of the 4 core 1.5 GHz Raspberry Pi 4 CPU. Can you expand on how this is done?

It doesn't, obviously. That post is very badly phrased.

The Asus Tinker V has a 1 GHz single-issue core.

The StarFive VisionFive 2 has a 1.5 GHz quad core dual-issue in-order CPU, similar to an ARM A55 at 1.5 GHz, and about 80% of an A72 at 1.5 GHz -- except for lacking the NEON SIMD found in the ARM chips.

Re: Look up StarFive 2

> Said to have the performance of a top flight 2016 smartphone - sufficient processing power to do lightweight computing.

The better comparison would be an SBC with RK3566 with quad A55.

Re: Yikes.

> The closest board on there is the BeagleV StarLight JH7100

300 of those were made and distributed for free to developers in April 2021. I was lucky enough to get one. No more have ever been made.

They were supposed to go into mass-production with a different SoC, the JH7110, in September 2021, but that didn't happen. Instead, a very very similar board, still with the JH7100, has been sold as the VisionFive v1 since December 2021, and the VisionFive 2 with JH7110 started to be delivered to people in January and February 2023.

Re: Wrong

>Starfive are upstreaming all their work for the VisionFive 2 to the 6.3 kernel. Looks to me like they planning future support.

Indeed so, but StarFive with their SiFive core based SoC are completely different to Asus with their Andes CPU core.

Also, I just yesterday learned that this Andes core has a major major flaw in not correctly implementing the RISC-V spec. It appears that virtual addresses between 0x30000 and 0x4FFFF do not (unlike all others) get mapped to physical addresses via the page table and TLB etc, but directly access the same PHYSICAL addresses, where some high speed SRAM is located.

This completely screws any OS which puts anything in those virtual addresses. Such as ... oh I don't know ... statically linked Linux binaries. I just checked a HelloWorld kind of program on my VisionFive 2 and the code starts at 0x103e0 and ends at 0x49bab ... so smack through that unmapped region.

Could RISC-V become a force in high performance computing?

Re: RISC-V is inherently high performance

The problem is that branch delay slots and load delay slots only made sense for a single micro-architecture -- the first single-dispatch in-order one, generally with 5 pipeline stages.

As soon as you did anything else ... dual or triple issue in-order, or OoO, the delay slots not only didn't help any more but also actively made implementations harder because of the screwed-up semantics.

Re: A mixed blessing?

RISC-V SBCs with draft 0.7.1 of the Vector ISA are currently available starting from $17 (Lichee RV 1 GHz 512 MB RAM https://www.aliexpress.us/item/3256803408560538.html)

That's the in-development spec as at the middle of 2019.

The final 1.0 Vector spec is incompatible in detail but about 90% or 95% the same binary opcodes and the same semantics. Close enough that 0.7.1 hardware gives a good head start. Many useful algorithms such as memcpy(), memcmp(), strlen(), strcpy(), strcmp() and so forth are binary compatible between 0.7.1 and 1.0.

There is no reason that in time RVV 1.0 implementations won't be available at similar price-points. It's not any harder to implement, just a few minor details were changed sue to feedback, experience using 0.7 and 0.8 and 0.9 and 0.10. (NO one has commercially produced anything except 0.7.1, but intermediate versions were implemented in the Spike emulator and in GNU binutils etc and programming experience gained with them.

If RVV eventually makes its way into supercomputers (and it seems that it will), then you're going to be able to test your supercomputer code on a $10 or $100 SBC or $1000 laptop.

Re: Only if China pushes hard

“That said, RISC-V CPU performance is still far behind x64 and arm64.”

Obviously, because RISC-V started much later.

Currently off-the-shelf RISC-V SBCs are 3-4 years behind ARM. When the Intel/SiFive Horse Creek product ships in around six months, it will be a little over 1 year behind the RK3588 ARM boards. Ventana and MIPS have announced chips near current x86 and Apple chips, so I guess they’ll be shipping in around 2 years.

RISC-V is several years (not decades) behind, but catching quickly.

Re: RISC-V is inherently high performance

“AAarch64 is probably the best ISA going since it was conceived so recently - more recently than RISC-V.”

The ARMv8.0-A ISA was published in finished form in October 2012. The RISC-V ISA was ratified and published in frozen form in July 2019, with important additions to bring it to parity with ARMv8 in November 2021.

People usually give RISC-V’s newness as a disadvantage, so this is a weird argument from you, especially given the facts are the opposite.

Design of RISC-V started in 2010, a couple of years before ARMv8 was published. The *design* of ARMv8 clearly started much earlier. I don’t think anyone has really said how much earlier, but I suspect around 2003-2004 when amd64 made it clear it wasn’t going to be an Itanic-only future.

Twitter tweaks third-party app rules to ban third-party apps

Is Twitter's own app still crap? The web site is for suer utterly unusable for me. I've been using Tweetbot forever -- I don't even know how long. Ten, twelve years? For me, Tweetbot IS Twitter.

My needs are very simple. I want to read every tweet made by anyone I follow (or at least original tweets and replies to people I also follow), in chronological order. I want the app to remember what I have read and what I haven't read. I don't want to see tweets by people I don't follow, or tweets "I might be interested in", or sorted in some way other than chronological.

I don't need something to "manage" my experience on the assumption I can't read all the tweets from people I follow. I can. I trim my following list as needed to ensure I can.

Biden wants SpaceX to beam internet to Iran amid uprising

Are the companies supplying rifles and HIMARS and HARM and Hummers to Ukraine expected to simply donate them? I don’t think so. So why is Musk expected to?

An individual or private company shouldn’t get directly involved in wars. That’s very dangerous to them. If the US or EU governments buy stuff from SpaceX then donate it, that’s very different from SpaceX doing it themselves.

The terminals and service sent to Ukraine cost twice as much as regular home terminals because they are the equivalent of business accounts, which provide a higher level of service.

SpaceX is at very real risk of going broke at the moment. They need to expand Starlink hugely to get cash coming in, but they can’t do that until they get the Starship/Superheavy rocket flying. They have literally warehouses full of satellites that have been built but can’t be launched because they don’t fit inside Falcon 9.

Also, as noted, Starlink can now operate in Ukraine because the Ukrainian government gave (begged) them a license to. That’s not the situation in Iran.

China has recently been demanding assurances from SpaceX that they will NOT enable Starlink in China. I’ll bet Russia doesn’t want it either.

If Musk goes against those kinds of people then he’s going to need Putin-level personal security.

China may prove Arm wrong about RISC-V's role in the datacenter

Re: Poor article

>The article then goes on to say that both CPUs are possible but there's currently no indication that there's anything remotely as powerful as ARM or x86 out there or on the horizon.

That's just not correct.

It is well known in the industry that RISC-V startup Rivos, for example, has been founded by some of the same people who founded PA Semi, which as bought by Apple in 2008, and created Apple's A-series chips and the M1/M2. A number of other engineers who worked on the M1 have also gone to Rivos. Apple is suing them for taking "too much" information with them.

Interestingly, Apple is not asking for an injunction to stop Rivos from working, or even fixed damages, but for a ROYALTY on sales. That means Apple expects them to be successful. They have the people, they have the funding.

The way these things go with Rivos being founded in May 2021, an M1-class (maybe better) RISC-V will emerge from them probably around 2024-2025.

There are others too, but that's the slam-dunk example.

Arm execs: We respect RISC-V but it's not a rival in the datacenter

Re: Toast

ARM's "every instruction is predicated"?

Looked great in a couple of hand-picked examples in 1985: GCD, software emulation of missing multiply and divide hardware instructions. But not so much in general code.

They didn't include predication at all in Thumb, just traditional conditional branches.

Thumb2 (ARMv7) added back a limited form -- maximum 4 instructions in a row predicated by the same condition or its inverse, controlled by an extra instruction preceding them.

Predication is entirely absent from 64 bit ARM.

Re: More bad news for Intel

Every simple foundry customer project isn't going to be given an Intel platform name like "Horse Creek". This is something more.

Intel bags deal to make chips for MediaTek, that other Android processor designer

When a company such as MediaTek does a "tape-out" and sends the resulting physical design files to the chip maker, there is absolutely no easy way to tell what the data on the "tape" represents, whether it has x86 cores, ARM cores, RISC-V cores, or just a lot of random logic.

Airbus flies new passenger airplane aimed at 'long, thin' routes

Re: Long and thin eh?

Yes, A380 is the best, but you can't always get one.

I would much rather travel in an A320 for 11 hours than in a B777 with 3-4-3 seating. I absolutely hate those things.

I love the 16 hour Dubai-Auckland A380 flights (17 the other way). Far far better than having a stopover and getting back on the same plane.

Sadly it seems this stretched A320 won't even make Perth from Dubai, let alone Melbourne or Sydney. But either Singapore or Bali would serve as a reasonable halfway point to NZ.

It also isn't going to manage Auckland to LAX or SFO. Other than the 747-400 (which have long gone from the route) the best time I've had between NZ and the US was with Air Fiji with their A330s (with a stop in Fiji of course).

I haven't yet had a chance to fly in a 787 so I'll reserve judgement on those.

Just someone kill the 777, please. Or at least make the airlines use 3-3-3 seating as they were designed for.

Will this be one of the world's first RISC-V laptops?

Re: Some serious questions.

Just about everything in your post is wrong.

RISC-V was not introduced 12 years ago, some students and their professor had a crazy idea in a pub to START it 12 years ago. It was essentially introduced to the world a little under 7 years ago.

Dave Patterson invented the term "RISC" and the first RISC I CPU around 1980-1981, not 1990. I can only assume you weren't born at those times and consider them prehistoric.

ARM does NOT allow you to add or remove things from their CPU core or the instruction set. Of course you can add whatever you like else in the SoC, as you don't license that from ARM and ARM doesn't make such IP.

The Raspberry Pi is very far from standard. There are simply a lot of them. (Compared to other SBCs, not compared to phones or tablets)

Re: Cool...

Look up "binfmt_misc". I've been using it for many years to run x86, ARM, RISC-V (and others) binaries transparently on whatever board I'm currently using.

Slower than native, of course, but much faster than Python.

Re: Some serious questions.

I don't know why you think it appropriate to look at what is clearly a personal project of a handful of people and extrapolate that to OoO RISC-V cores from companies such as SiFive, Alibaba, Andes employing experienced CPU designers who have previously worked at ARM, Intel, AMD, Apple ...

It's been known for quite a few years now how to avoid Spectre/Meltdown and that it's pretty easy if you incorporate that into your design from the outset.

Here's something from four years ago: https://www.youtube.com/watch?v=yvaFpNNLkzw

The presenter designed OoO BOOM as a student, later ET-Maxion at Esperanto, and now works as a core designer at Intel.

The ‘substantial contributions’ Intel has promised to boost RISC-V adoption

Re: "vowed to do what it can to make the open-source RISC-V ISA worthy"

It's not like Intel has a choice in that. The best they can do is try to have a cut of it.

Someone -- possibly several someones -- will have RISC-V competitive with x86 and Apple M in 3-5 years. Quite likely including Rivos who Apple are suing for taking too many of their M1 engineers with too much knowledge about how it works. Interestingly Apple isn't trying to stop them -- they're not asking for an injunction or damages, but for royalties.

RISC-V CEO seeks 'world domination' by winning over the likes of Intel

Re: That RISC-V TRS-80 M100....

The DevTerm is an existing product that uses a Raspberry Pi Compute Module as the CPU. They've just substituted a CM3-compatible board with a RISC-V module, which they also sell separately for $28 for if you already have an ARM-based DevTerm or want to use the RISC-V module on another CM-compatible motherboard.

Alibaba Cloud gets more of Android working on RISC-V silicon

Re: Open source hardware (and consequently software) will be the future

There is already a laptop of sorts:

https://www.clockworkpi.com/product-page/devterm-kit-r01

If you already have the ARM version (or any Pi CM3 compatible board) then you can buy just the RISC-V compute module from the same site for $29:

https://www.clockworkpi.com/product-page/copy-of-clockworkpi-core-r-01

Note that this is roughly Pi Zero equivalent.

The board that runs Android (that Android is being developed on) is available here:

https://www.aliexpress.com/item/1005003395978459.html

The C910 cores are roughly Pi 4 speed, though it's got fewer cores than a Pi 4.

>The Xuantie C906 uses Alibaba-designed cores

That's very confused.

Firstly, the Xuantie C906 *is* a core. The AllWinner D1 (external DRAM) and D1s (DRAM in the package) also sometimes called "Nezha" are chips or SoCs that use the C906 core.

The Sipeed "Lichee RV", the AWOL "D1 EVB" (which many called "Nezha" until we learned that refers to the Soc), the MangoPi "Nezha MQ" and "MQ Pro", the ClockworkPi "Core R-01" (a $29 Pi CM3 compatible board designed for the DevTerm laptop) are variously boards with versions of the D1 chip on them.

Similarly the Xuantie C910 is a (much higher performance) core from Alibaba T-Head, roughly comparable to the A72 in the Pi 4. The C910 is available in the "ICE" SoC, used on the "ICE EVB" (Evaluation Board), which is what the RISC-V Android port has been shown on. I have one, incidentally.

> that are – as required for RISC-V users – available on GitHub.

Incorrect. There is no requirement for RISC-V cores to be put on Github. There are a number of companies with commercially-developed RISC-V cores for which the source code is not available. Alibaba put the C906 and C910 on github entirely voluntarily.

We take Asahi Linux alpha for a spin on an M1 Mac Mini

Re: 53GB

>i assume you can also run it in a VM using Parallels or similar which for many might be the preferable option?

Mate.

I've been running arm64 Ubuntu in a VM on the M1 Mac Mini since ... checks ... 22 November 2020. That's 16 months. They ere only released on November 17, 2020, so it took all of 5 days to get mine and get Ubuntu working...

Performs *really* nice. But I want it native, so as to not waste 4 GB of RAM on the host OS.

https://twitter.com/BruceHoult/status/1330236899546591235

More benchmarks at...

https://hoult.org/arm64_mini.html

114 billion transistors, one big meh. Apple's M1 Ultra wake-up call

Re: I was there

And I programmed PDP-11s and VAXes and other similar machines ... PR1ME, Data General Eclipse.

>This high performance Apple computer is nice, but, it doesn't run FoldingAtHome, which would possibly take advantage of those GPUs.

It certainly does. I just downloaded and tried FoldingAtHome on my original M1 Mac Mini. It runs. The performance stats seem to be 800 points per day, 3.00 days ETA for a work unit. I have no idea whether that is good or bad, but it runs.

>You can't run 64bit Intel code on this machine.

Of course you can. I do it every single day. Apple includes an x86_64 emulator which runs x86 code and about as fast as the Intel machines they previously sold.

Here's one benchmark I wrote many years ago and run on everything:

https://hoult.org/primes.txt

Note that the Rosetta (x86 emulation) result is faster than a ThreadRipper, a Ryzen 5, or a Xeon Platinum.

You appear to be misinformed.

RISC-V keeps its head down amid global chip war

Re: Genuine question RISC-V / ARM

RISC-V just defines an API right ? Presumably there aren't too many innovative new Assembly Language instructions, especially in RISC, they are supposed to be simple right? (This is based on my doing a few weeks of ARM2 assembler after having learned 6502 as a kid)

Right.

There is deliberately nothing innovative in the base RISC-V instruction set. It set out to learn lessons from 30 years experience with RISC and use the best parts from RISC-I and -II, SPARC, MIPS, ARM, POWER, Alpha and others. Not from Aarch64, which was developed largely in parallel, with the basic RISC-V design being already in place when the Aarch64 ISA was published in late 2012. They *both* took many of the same lessons from experience, though Aarch64 is a bit constrained by having to run (at least up until very recent designs) on the same CPU pipeline as Aarch32, and also ARM don't seem to intend it to ever be used in the smallest devices.

The most innovative part of RISC-V so far is the just ratified Vector extension. Again, it's similar in a lot of ways to ARM's SVE. They may have both had the same influences, though it seems quite likely that SVE was influenced by the Berkeley research into vector processing. RISC-V was actually initially wanted as the scalar control processor for vector processors already in development.

So what's the massive lead of ARM over RISC-V? Obviously the silicon design of an Apple M1 is incredible, but you get this by being Apple+TSMC, not by buying an ARM license. Presumably Apple could have done the same design around a RISC-V instruction set?

Indeed Apple could have. RISC-V didn't yet have all the standardised ISA parts Apple needed at the time they started development of the M1 -- and of course not back when they made their first Aarch64 chip for the iPhone 5s released back in 2013 (and 1.5 years before ARM and their partners had 64 bit CPUs ready for the Android market e.g. Samsung Galaxy S6).

Apple wanted to get Macs on to the same ISA as iPhones and iPads, and for the moment that meant Aarch64.

Personally I think that within five years Apple will switch *everything* to an ISA they have greater control over. I don't know whether that would be RISC-V or something they design themselves.

The lead of ARM over RISC-V is mostly that they started earlier. In the case of the M1, Apple has a lot more money to spend than ARM does.

Currently shipping RISC-V cores that you can buy on an SBC (e.g. SiFive HIFive Unmatched, Starfive VisionFive v1, T-Head ICE RVB) are about 5-6 years behind ARM (e.g. Pi 3).

If you are starting to design a chip today then the RISC-V cores you can license for it e.g. SiFive P650 are about three years behind comparable ARM designs (Cortex A76).

Does ARM supply all the super-scaler / out of order pipeline / branch prediction magic we all rely on - as part of the licence design? Or is it just that there are more optomised ARM core designs out there, more people familiar with them, more tooling, more compilers etc etc ?

ARM supplies the pipeline and branch prediction if you license one of their cores. They don't if you simply license the ISA and implement your own core, as Apple does.

There is no significant difference today between the quality of gcc or LLVM compilers for ARM and RISC-V.

Re: Sorry, what was the problem again?

You apparently aren't aware that the Berkeley RISC-V effort open-sourced in 2015 included not only the ISA itself but also a competent traditional 5-stage pipeline processor design, "Rocket", complete with good MMU, branch prediction, L1 cache, and FPU.

The design was picked up wholesale in commercial productions such as the SiFive FE310 (which competes well with ARM Cortex M3 and M4) and FU540 (which is close to ARM Cortex A53, despite being only single-issue). It is also used directly in the Kendryte K210, and influenced many others. The FPU design is probably used in a lot more -- fully IEEE 2008 compliant, and with full-speed handling of denorms (which is pretty unusual)

Rocket and its components has since formed the basis for dual-issue in-order and wider out-of-order CPU cores.

Assuming for the moment it's true that open source systhesis and layout pays a 20-30% area and clock penalty -- which I"m not convinced is true of yosys/nextpnr -- that's a MINOR price to pay for having an open source system. Especially when RISC-V cores are consistently 1/3 to 1/2 the size and 1/3 the energy use of otherwise comparable ARM cores.

The instruction set is a very big technical pinch-point because the entire software stack depends on it, and porting all the world's useful important software to a new ISA is a far bigger and more expensive and longer task than designing an SoC.

Re: Sorry, what was the problem again?

Well, no David Patterson didn't invent RISC-V.

He was there in a kind of supervisory role, but in fact the main supervisor was Englishman Krste Asanovic (who, as you might imagine from his name, has recent roots in Eastern Europe), with most of the grunt work done by American Andrew Waterman, and Korean Yunsup Lee (I think Yunsup was born in the US but he speaks Korean fluently and has grandparents there).

That was the initial specification for the basic integer and floating point instructions corresponding to C's built in operators, between 2010 and 2015.

Since 2015 the ISA has been extended in a number of directions by international working groups with participation by experts from every part of the globe.

Geomagnetic storm takes out 40 of 49 brand new Starlink satellites

Re: No loss

I signed up to rent a house that had no internet service possible on January 3 2022, went to the STARLINK site and paid my money, and had the equipment (shipped from California to New Zealand) on January 14, a full week before I actually moved in.

RISC-V CTO: We won't dictate chip design like Arm and x86

There are RISC-V boards similar in performance to Pi Zero through to Pi 4. At the moment they cost more, but that's a market size and mass production problem not a technology problem.

For example the $17 Sipeed LicheeRV is similar to a Pi Zero compute module, and docks giving a good set of I/O connectors start from $5.

https://www.aliexpress.com/item/1005003594875290.html

https://www.aliexpress.com/item/1005003741287162.html

The ICE RVB has similar performance to a Pi 4, though with fewer cores and a much higher price (just as the "Nezha" EVB has the same SoC as the LicheeRV but at a much higher price). Expect to see the same SoC appear on much cheaper boards in the next few months -- I suspect BeagleBoard will be one of the vendors.

https://www.aliexpress.com/item/1005003395978459.html

Re: Viable alternative

That "very basic RISC-V common subset" includes 32 bit and 64 bit ISAs, FPU, SVE-like vectors, cache control, hypervisor, crypto (e.g. SHA, AES, TRNG).

Anyone wishing to use the trademark "RISC-V" with their products must pass conformance tests for the standard parts of the ISA, and therefore correctly run any code from standard compilers such as gcc and LLVM.

If someone adds extensions then all standard software will continue to run correctly. Of course programs using the extensions won't run elsewhere but that's the point -- custom extensions are by nature usually very specialised.

Re: what was wrong with MIPS ?

RISC-V is similar in philosophy to MIPS. The RISC-V assembly language uses many of the same mnemonics as MIPS, but with different semantics and binary encoding. Many of the instructions are completely different, especially around function call and return and conditional branching (though neither uses condition codes). The most recent MIPS specifications (MIPS R6 and NanoMIPS) adopted some of RISC-V's ideas.

RISC-V and MIPS are also both very similar to DEC Alpha, and to a slightly lesser extent ARM Aarch64.

Re: what was wrong with MIPS ?

It's not free to implement your own MIPS core.

MIPS wanting about $5 million for *just* the rights to use the ISA (not even supplying a core) was the reason Berkeley university developed RISC-V instead.

MIPS announced an "open source" program in April 2019. It had pretty awful terms. You had to apply for entry to the program, giving details of what you intended to use the MIPS ISA for, your business plans etc. You were only allowed to do things within very narrow parameters. You had to have your core certified by MIPS. You were not allowed to distribute the design of your core to others.

And then in November 2019 -- just seven months later -- MIPS cancelled the program entirely, long before anyone could have had a chance to ship anything.

Now MIPS has announced they are dumping their own ISA and switching to RISC-V.

RISC-V was never about licensing costs. It's about flexibility and freedom, and the ability to move fast.

Forget the cost, reliable sources say that it typically takes one or two years for the lawyers to simply negotiate the contract with ARM. And that's for an off-the-shelf standard core.

Only a few few of ARM's licensees ("Architecture License") have the right to modify ARM's microarchitecture, or to design their own core. Until the last year NO ONE had the right to add or subtract any instructions from the ARM Instruction Set.

RISC-V core vendors such as SiFive or Andes also change licensing fees. They might or night not be less than ARMs, but they are not zero. If you don't want to pay them (or others) you are free to design your own core -- *everyone* in the world effectively has a free Architecture License -- but you're going to have to hire some expensive people to do that and it will cost you more than licensing a commercial core.

But you get flexibility.

Do you want a very small core like a Cortex M0, but you want it to run faster than 48 MHz? Sorry, ARM won't do that. SiFive will license you an E20 that will run at 1 GHz on 7 nm if you want to - and Andes has something similar. Do you want a very small core like a Cortex M0, but you want it to have 64 bit registers and addresses instead of 32 bit? You can't do that with ARM -- their smallest 64 bit core is much bigger. Do you want to get something like a Cortex M0 but with an FPU, or with a vector processing unit? You can't do that with ARM, but SiFive or Andes will be very happy to license you one.

The same applies up and down the line. RISC-V vendors give you much more flexibility than ARM does -- up to their current upper limit on core performance, which is currently in Cortex A73 to A76 range depending on which vendor. Or if you have a lot of money and think you can do a better job yourself then you are free to -- while still getting the benefit of standard gcc, LLVM, Linux, FreeRTOS, Zephyr etc etc.

Enthusiasts dash for RISC-V computer with GPU

It's not sub Pi 3. The C910 cores are roughly Pi 4 class -- claimed ARM A73 class vs A72 in the Pi 4.

The U54 cores in the 3.5 year old HiFive Unleashed were a little slower than Pi 3. The U74 cores in the HiFive Unmatched (and the now cancelled BeagleV "Starlight") are ARM A55 class, which is significantly better than the A53 in the Pi 3. Benchmarks bare this out -- other than ones that depend on SIMD or crypto instructions, obviously, as that's something coming in RISC-V next year.

Proposed RISC-V vector instructions crank up computing power on small devices

I really like this RISC-V Vector extension. It is one of two "vector length agnostic" vector instruction sets currently on the way between specification and machines normal people buy and use.

The other is ARM's SVE (Scalable Vector Extension). ARM also has more recently announced MVE (M-profile Vector Extension) for microcontrollers.

SVE and RISC-V V extension both give the programmer 32 registers of size that varies from machine to machine. Code is written in a way that doesn't have to know the actual register size, so one machine might have 128 bit registers, another 512 bit registers, and another (in future) 4096 bit registers and the same programs and libraries run efficiently on them all, without rewriting.

SVE allows for vector register sizes between 128 and 4096 bits. ARM's MVE gives the programmer 8 registers of always 128 bits each -- apparently SVE wasn't scalable enough.

RISC-V V (RVV) allows for register sizes between 1 element of the largest size handled (often 32 bits) and 2^31 bits. Version 1.0 of the vector profile for application processors (i.e. something that can run binary distros of Linux or similar) restricts the vector register size to be between 128 bits and 65536 bits. Those who are making embedded processors or supercomputers can choose register sizes outside that range if they wish.

RVV has a feature called "LMUL" that allows the programmer to trade addressable registers for register size. For example if your program loop only need 16 vector variables not 32, then you can use LMUL=2, use only the even numbered registers, and use pairs of registers as if they were a longer register. Similarly if your loop only needs 4 or fewer vector variables then you can use LMUL=8 and use only registers 0, 8, 16, and 24 but they are 8 times bigger than usual.

So a microcontroller with RVV might implement only 32 bit nominal registers, but if the programmer uses LMUL=4 then they get 8 registers of 128 bits each -- the same as MVE.

Both RVV and SVE are going to eliminate that awful situation where you have to rewrite all your SIMD code every few years when your CPUs move from MMX to SSE to AVX to AVX512 -- or a similar but shorter progression for ARM.

Deep neural networks... IN SPAAACE: Vector-enhanced RISC-V chips could give satellites onboard AI

Re: Speed vs. Size

Not really correct, as FPGAs typically have a lot of ALUs in them (referred to as “DSP blocks”) and using them to implement a vector processor makes perfect sense. You’ll usually only get 50-100 million instructions per second from a soft core in an FPGA, but if you have long vectors this doesn’t matter. The RISC-V vector extension lets the exact same code run on machines with vector registers of any length. There are rad-hard FPGAs available off the shelf.

I’d expect to see a scalable open source FPGA implementation of the RISC-V vector extension within the next 12 months.

Intel to put SiFive's latest CPU cores into 7nm dev system to woo customers to RISC-V

I've been running Linux on a quad core 64 bit 1.5 GHz RISC-V board with 8 GB DDR4 RAM for more than three years already. That board only had an SD card to boot off and no video or USB so access was via ssh over gig ethernet.

I now have a board with roughly late Pentium 3 performance CPU but quad core with 16 GB DDR4 RAM, a 500 GB M.2 SSD for storage, and a PCIe video card so in general use it's considerably better than Pentium 3 machines. https://www.youtube.com/watch?v=3o411cQ7XG0

This new P550 core will bring RISC-V to approximately the late Core 2 era in CPU performance. That's a very usable level, especially with more modern peripherals than Core 2 systems had.

Next year Nehalem or Sandy Bridge performance? I wouldn't rule it out -- or even better -- especially if a company with deep pockets such as Intel decides to go for it.

SiFive has gotten to this point on $190 million of funding.

Intel, AMD, and Apple are spending probably several billion dollars on each new CPU generation now.

Docker Desktop for Apple Silicon is here, but probe a little deeper and you'll find Rosetta 2 staring back

One of us is confused.

Aarch64 containers is exactly what Docker for M1 Mac runs, since aarch64 is the M1's native (and only) instruction set.

64 bit OSes and binaries compiled for Raspberry Pi 3/4, Amazon Graviton instances (A1, M6g, M6gd, T4g, 6g, C6gd, C6gn, R6g, R6gd, X2gd) run perfectly under virtualisation, including Docker, on the M1 Macs.

Just a lot faster than they do on their usual hosts.

Beagleboard peeps tease dual-core 64-bit RISC-V computer with GPU, AI acceleration, more for $119

Re: I can understand the ISA

ARM has deprecated conditional execution on 32 bit and never had it on 64 bit ISA.

The U74 core treats a conditional branch over a single instruction, and the following instruction, as a kind of predicated execution with no pipeline flush no matter which way the branch works out.

Re: RPi4 vs Beagle V

We’re still six weeks from the first device with U74 cores shipping to paying customers.

I doubt that the FU740 will be significantly different to the FU540+expansion board in peripherals and drivers.

After ten years, the Google vs Oracle API copyright mega-battle finally hit the Supreme Court – and we listened in

An analogy

Let’s liken an operating system to a house.

A house provides electrical sockets with a certain pin layout and voltage e.g. type A or B at 120 V . Phone sockets RJ11. Internet RJ45. Clothes washer water connections of certain diameter and thread.

It is convenient for an occupier to move their appliances (code) from one house to another if both houses have the same connectors.

Moving your appliances to a house with type G sockets at 230 volts, BT phone sockets, different water connections is inconvenient. You may need to get new appliances, or at the least add some kind of adaptor.

Google wanted to build houses on a newly discovered uninhabited island (or on the Moon) where people could move to with their existing appliances.

What did they do – twist his Arm? Ex-Qualcomm senior veep joins SiFive as CEO, RISC-V PC for devs teased

Re: RISC-V Raspberry Pi

You say you're happy to ssh in to the board and run things automated from your standard PC. Me too, and that's exactly how I use my Pi 3 and Pi 4 and Odroids.

It's also exactly how I've been using my HiFive Unleashed RISC-V board for 2.5 years now. Quad 64 bit CPUs running at 1.4 GHz, 8 GB DDR4-2400, gigE, USB serial console, SD card to boot from, then NFS mount big stuff from the PC, run a RISC-V desktop using the PC as an X server or VNC. It all works great and my $999 got me a (so far) 2.5 year headstart.

However I think that's probably not most people.

I've actually been running a poll on this for the last few days (it ends in 12 hours). More than 50% of people say they want to plug an HDMI monitor, kb&mouse in to the board itself -- as most people do with a Pi.

https://www.reddit.com/r/RISCV/comments/irwumi/if_you_say_you_want_a_riscv_board_that_runs_linux/

Re: Comparison

I'm expecting something definitely faster than the Raspberry Pi 3 or 3+ (the 2.5 year old FU-540 roughly matches the 3+), but probably not *quite* the raw performance of a Pi 4. The MHz will be higher, but the architecture is like the CPU in the Pi 3+. It's also likely be surrounded by higher spec memory, cooling and other bits like that to let the CPU shine.

Something around the last Pentium 3s or PowerPC G4s would be about right.

No problems with the graphics. It will have PCIe. If you add the expansion board to that 2.5 year old HiFive Unleashed then you just plug in a Radeon graphics card and run the open source driver (which is written in C) and accelerated graphics works fine. I've played with a HiFive Unleashed set up with this..

This chip jut brings all that onboard and hopefully sells for a lot less. It should be in the $250 to $500 range I'd think.

Chips that pass in the night: How risky is RISC-V to Arm, Intel and the others? Very

Re: Power ISA?

"Not to mention you can get entire desktops and servers with Power from Raptor Computing Systems. I can't recall seeing an equivalent for RISC-V."

Of course not. It's too new. It's not even five years since the RISC-V Foundation was set up and everything open-sourced. It's only a year and a half since the base instruction set, initial extensions (MAFDC), and privileged architecture were formally ratified and set in stone.

POWER has been going for thirty years.

RISC-V vendors have started with small embedded cores, with only a couple recently starting to get more into CPUs suitable for mobile applications processors let alone desktop or server. The most sophisticated RISC-V core so far -- SiFive's U-84 -- was announced at the end of October and the way these things progress will probably see first silicon around this time next year, and get into products six to twelve months later. The U-84 is competitive with ARM's Cortex A72 which was in the hot phones in 2016 and just found its way into the Raspberry Pi in June/July last year.

"For the 10 years it's been heralded as the saviour of open computing it's still very marginal, sadly."

That's what exponential growth looks like -- not worthy of notice for a long time, and then suddenly it's everywhere.

Look at the number of hospitals recently saying "we'll worry about coronavirus when we see a case" and then one or two weeks later they're "Our ICU is filled to overflowing and we're having to decide who we just let die, we're running out of beds with oxygen, 10% of our doctors have caught it and the rest are working 18 hour days and aren't allowed to see their families".

If you haven't noticed:

- Samsung has said the new Galaxy S20 has one RISC-V core controlling the camera and another controlling the 5G radio.

- Qualcomm has said every SoC they ship from now will have RISC-V in it somewhere.

- Espressif have said the new version of the ubiquitous ESP32 wifi/Bluetooth chip with main CPU core still Xtensa but an ultra low power RISC-V management core has gone to volume production.

- Microchip / MicroSemi has said the version of their avionics / military-qualified FPGA with embedded penta-core RISC-V FU540 is available to qualified customers for development now, available in volume Q3.

- Western Digital / Sandisk should be shipping their first disks and flash drives with RISC-V in them later this year.

It takes companies like these four or five years to go from "Hey, that looks interesting" to volume production. All those companies started working on RISC-V products years ago -- and it wasn't really available to people outside Berkeley until 2015 -- and you can be sure many many others have started the process in the last couple of years.

As for extensibility. The vast majority of custom instructions I've seen proposed don't affect the rest of the software in the system, don't even require changing compilers. These instructions are usually used in two or three places in a software library to speed up some specialized thing by a factor of five or twenty or whatever. Often it's not even worth modifying the assembler to know about them -- it woudl be easier overall to just encode them in hex with a .word directive where you need them.

But in fact the RISC-V GNU assembler has a special ".insn" directive that lets the user's program source define a new instruction using any of a number of standard instruction encoding formats and then immediately use it -- no modifications to the assembler.

For details see https://embarc.org/man-pages/as/RISC_002dV_002dFormats.html

That covers small, secret, extensions anyone can make.

Larger RISC-V extensions that will be standardized and made available for everyone go through a review process where experts from *many* companies and universities and research organisations look at them, try experimental implementations of them, suggest improvements etc. This process slows things down, but it's quite likely that the end result will be of *better* quality than any one company would do.

A little product renaming here, a little RISC-V magic there, some extra performance, and voila – Imagination's 10th-gen PowerVR is born

RISC-V management core

It's just the system management core, the same as Nvidia are doing, not the actual GPU cores like Think Silicon announced

https://think-silicon.com/2019/12/02/think-silicon-demonstrates-early-preview-of-industrys-first-risc-v-isa-based-3d-gpu-at-the-risc-v-summit/

Still, good to see, and there will be more and more things like this.