NASA selects SiFive and makes RISC-V the go-to ecosystem for future missions
sifive.com
sifive.com
There is no existing compulsion for missions to use HPSC. This is a technology development program seeking to meet the requirements of missions. It's great news they converged on an architecture!
As part of their development, HPSC folks will seek mission partners for tech demos. Then, missions will voluntarily (or with some light compulsion) adopt the technology based on the growing heritage and mission need.
RISC-V is a respectable enough architecture, but not better than recent POWER designs, equally open. NASA has an enormous amount of experience with POWER.
I suppose it comes down to what bidders are offering to build for them.
Take for example a low level programming task with the following choices: Ada and Rust (excluding other options for sake of argument), with Ada being the better fit. It may still make more sense to choose Rust because the Rust community is more vibrant and the projection for the ecosystem is also up even if it might be a worse fit for the project.
Choices are not always technical and as a technical person I might disagree with the choice but I can still respect it if it is well argued.
I honestly do not see it.
I've been following POWER at a distance, and while I'm sure the ISA itself is good enough, I'm not really convinced about the vitality of the ecosystem. The only place where serious money is being invested is in the high-end CPU's which IBM keeps developing enough to prevent their high-end captive customers from defecting. But at the lower end and embedded, it's crickets. Beyond some token efforts like the microwatt for FPGA's and an old supercomputer core design they open sourced, the whole OpenPOWER effort seems to be little more than a couple of guys producing the occasional powerpoint and press releases.
The POWER ISA is only partially open. All you get is the old version.
Momentary "vitality of the ecosystem" just seems like a poor basis to choose the underpinnings for decades of future work. But we seem to do that every time.
Well, to an extent. If one looks at GCC at least (presumably LLVM as well, although I don't follow it as much), POWER-specific patches seem to amount to enabling and optimizing the latest POWER server CPU's. I can't offhand actually recall much if any work on other POWER CPU's. So all that work won't really benefit an embedded POWER core. And further, which core would that be? I haven't seen anything new in the embedded POWER market for a very long time, but maybe I'm missing something? You're certainly not going to put a POWER10 on a space probe and call it a day.
So if NASA was really wedded to POWER, would they have to foot the bill to develop a new POWER core, and maintain the compiler backend for that one? Sounds a lot more expensive than picking an existing core developed by someone else, and compiler backend maintenance done by someone else as well, and rad-hardening it.
> Momentary "vitality of the ecosystem" just seems like a poor basis to choose the underpinnings for decades of future work.
Well, AFAICS it's not momentary but terminal decline. Now of course it might be that RISC-V dies away as well after the current excitement, but at least to me that looks much less likely than POWER reversing its fortunes in the embedded market.
As to why not ARM then, I'm not sure. Might have to do with such government contracts requiring working with US companies, and both Microchip and SiFive are US, whereas ARM is British/Japanese?
> But we seem to do that every time.
Sure. I do think that if IBM had done the OpenPOWER thing 15 years ago and put serious money behind it, POWER could have been a worthy competitor to ARM in the embedded market, and RISC-V might never have seen the light of day. But, they didn't, and here we are.
[1] The only people who have any incentive to invest in it going forward are those who already have significant investments in it.
It is easiest to pretend there is such a thing, because we are socially attuned for that. But it is not a technical observation, but a sociological one. And, that was my point.
We have maybe learned a few things about ISA design since POWER was cast. But we have also forgotten things. It is far from clear we are ahead. Most of what we learned feeds into stuff like vector units that have little to do with whatever they are bolted onto.
One example is the popcount instruction, omitted from the base RISC-V, and from all chips when last I checked. It has been added to every architecture ever mainstreamed, always at great expense, but it seems hard for ISA designers to contemplate. There is a special extension just for it so it could be put into a standard "profile" without importing the entire B thing.
Looking at the problem long term RISC-V makes more sense. RV has a lot of steam building behind it and we have really neat things like the Polarfire SoC and many more in the works. New tools, compilers and software support are being added every day (hell, there is a plan 9 Risc-v compiler already...) RV is the future from the look of things.
Power has an EoL set of chips from NXP which were former Freescale/Motorola designs and costly server chips from IBM. Arm ate their lunch in the embedded sector and Intel in the desktop/server sector. No one is looking to build new Power chips. No one is porting to Power unless its a Raptor Computing Talos workstation or IBM box, essentially an expensive toy or big iron, niche stuff.
https://www.gaisler.com/index.php/products/processors/noel-v
If I were designing an open source processing for a laptop or cell phone I'd use the POWER ISA. But for a space probe I'd certainly go with RISC-V.
Sure, you can license a fast POWER from IBM today.
But if you were to design your own, why would you ever pick POWER?
I'm currently using a dual-core 90 MHz processor that is relatively advanced and has good performance for many applications. It has error-correcting memories (SDRAM, cache, registers) and a lot of integrated peripherals (spacewire, serial, ethernet, 1553, CCSDS) that help reduce board complexity.
Next up in the pipeline is an 8-core 1 GHz monster: https://www.gaisler.com/index.php/products/components/gr765
Worst price I can remember off hand was $15 grand USD for a radiation hardened microcontroller, pretty sure it was an Arduino mega family chip I could have gotten the industrial quality version of for $25 bucks from Digi-Key… if I didn’t want it radiation hardened.
I'm slightly surprised you could even buy a rad-hardened microcontroller, but maybe microcontrollers are considered simple enough that they are exempt?
Get that from the USA and your basically in for a polite colonoscopy before they even tell you their prices (only slightly exaggerating)
The NavSpark Mini is still $36 for a 6-pack, making it one of the cheapest uCs with a floating-point unit. (The ESP32 technically has one, but its performance is inexplicably poor.)
I'm not clear on whether SkyTraq's chips have all the error-correcting goodies that're in other LEON implementations; would those be baked in by default?
While LEON isn't going away any time soon (especially given the recent release of the new LEON-5), I very much get the impression that the long-term plan is to replace it with RISC-V based solutions such as NOEL-V. Nobody can throw out working systems, but if you are starting something brand new, does it really make sense to base it on an ISA which the rest of the industry has essentially abandoned? Even its originator (or successor thereto) has basically walked away from it. Aerospace stuff is as expensive enough as it is already, getting stuck on a niche legacy ISA seems like a recipe to only make it even more expensive.
Still good SiFive have convinced NASA otherwise, they must have a pretty strong verification story behind the scenes.
If NASA is supposed to be a multi-state grant to the sciences, I'd much rather they focus the funding where it will deliver results that benefit the public commons. The jobs program for obsolete and finicky space tech is a dis-service to the public and even the workers who's skills are in questionably useful specialties.
0. https://arstechnica.com/science/2022/09/nasa-will-pay-boeing...
1. https://en.wikipedia.org/wiki/Exploration_Ground_Systems#Lau...
Not to mention a national security nightmare. Imagine a world without the COTS program, where we would most likely still be waiting for whatever version of Starliner that we finally got. We would right now be reliant on Russia to return our astronauts to earth from the ISS. Can you even imagine what we’d have to give up for their safety?
With its impending first launch, a lot of discussion is popping up again about it arguably being way too slow to develop, overly expensive, and not fit for the intended mission profile.
They were supposed to build a 130 to LEO rocket that should launch the first time in 2016 (min 70t) and use existing contractors. That is kind of insane.
So NASA basically allow their internal teams to come up with Block upgrades based systems and that's where the whole SLS Block 1a, 1b, 1c comes from.
The problem with this was (and is) that they had no reason to rush to a quick block 1 as there were really no missions for it.
Had they been given until 2020 developing a single core modern Saturn V would have been a much better design (this is clearly evident in their internal design evaluation documents). The had already put a lot of work into J-2x and modern F-1 version was attainable. My alternative would have been to use a whole bunch of SpaceX Merlin 1D instead but they never considered that. This version would also have been much closer to the 130 tons in the first version.
And it could have been evolved to be reusable unlike the current SLS.
What people from the outside don't really see is the NASA internal competition. Johnson Space Center clearly wanted the Shuttle derived version, Kennedy Space Center really wanted to Saturn V style rocket. Some at NASA HQ wanted to give it as a contract to SpaceX/ULA.
You're implying a degree of coordination which organizations the size of NASA just don't have. Artemis has had two scrubbed launches, they didn't put out this announcement to distract from it. I doubt someone went over to SiFive and said, "Hey, help us distract from the Artemis I launch problems and we'll give you a nice contract."
> Seeing meh PR and thinking, “hey maybe we should step up the advanced technology press releases” is enough. As for NASA contracts, it’s almost harder to name someone who doesn’t have even a tiny one, even cranks.
Except no one cares about the instruction set of space computers, except a small cadre of computer geeks.
A story no one cares about is a bad thing to use as a distraction.
SpaceX is similar while they are very successful it also encourages competition in a space that really needed it and now there are so many other companies doing smaller launches that don’t make business sense to SpaceX.
It's RISC-V itself that has a permissive license, allowing anyone to make an implementation open or closed source.
That's a huge limitation. It's unfortunate that RISC-V allows for closed implementations (IP) and also closed ISA extensions.
Someone, somewhere may eventually form a coalition to pay TSMC or Samsung to generate an in-house spec for a high-performance RISC-V processor with an open-source license on the hardware design, too. Some places use RISC-V in products where the processor is another line item in the BOM and not the centerpiece of a SOC or dev board, like Western Digital using it in storage products. A group of companies and institutions could very conceivably get things where we'd wish now that the open ISA has set the stage.
Supporting a system that centralized designs of critical semiconductors in the hands of few companies and manufacturing in the hands of TSMC is not very pragmatic. If anything it's very ideological.
You are implying that socioeconomical systems are "the real world" and somehow they just happen to exist independently from our "hopes and dreams".
It's the complete opposite. Unlike solar flares and ocean tides, socioeconomical systems are entirely the product of human decisions.
It is rather fortunate. Else, it couldn't possibly aspire to be the standard ISA for absolutely everything.
The Cost-plus contracts have made them fat and lazy and somewhat remind me of that Bugs Bunny cartoon where the cats don't mind the mice emptying the fridge.
NASA is taking a small risk, but the rewards can, as SpaceX has demonstrated, be HUGE.
If the latter, that seems (to a layperson) quite exciting, since more local processing capabilities will hopefully lead to more efficient use of the very limited radio bandwidth these missions have available at such vast distances.
What?! I'd like to know more about this. Does it have GC? I just can't fathom that being the case...
[1] https://www.theverge.com/2022/8/18/23206110/james-webb-space...
[2] https://news.ycombinator.com/item?id=32519918
[3] https://www.jwst.nasa.gov/resources/ISIMmanuscript.pdf#page=...
So they decided on Javascript back in 2006 and it uses an interpreter/runtime written in C++. Which runtime is this?
It's far too easy with malloc/free to make errors such as replacing a pointer with a pointer to another object and forgetting to free the original, freeing something that is still referred to somewhere else and then the other place using it and corrupting any new object allocated in that space, or freeing something that has already been freed, again potentially corrupting a new object reusing that memory.
None of those is possible with GC.
The only problem GC is subject to is allocating more data than you have physical memory for, and that is equally as much a problem with malloc/free so GC is no worse for that error, and better for the others.
On the contrary, the big issue with the GC is what happens when the actual collection happens. There's an apocryphal story about a research team that was making a table-tennis playing robot; but every 5 minutes the robot would randomly pause; in then end they discovered it was the Java garbage collector pausing the entire thing to run. Much less apocryphal, and more recently, Discord rewrote one of their services from Golang to Rust specifically because of the garbage collector [1].
Yes, misusing pointers is a potential problem; but when you're talking about situations where precise timing of maneuvering thrusters or stepper motors can make or break your mission, a garbage collector is arguably a much bigger problem if you don't have a way to make it predictable.
[1] https://discord.com/blog/why-discord-is-switching-from-go-to...
And there were really quite good GC developed in the 90s. GC systems with predictable pause times (if you know the load) very much exist.
So if you are not loading arbitrary code you can do a lot with a memory safe GC system.
However I do think more could have been done in that space in the last 20 years instead of having so much C code everywhere.
I imagine it is an interesting balancing act.
The Perseverance rover uses the VxWorks real time OS from Wind River Systems and the same RAD750 PowerPC processor that NASA has been using for the last 20 years. The rover is designed to last and operate a long time.
The Ingenuity drone helicopter uses an off the shelf Qualcomm Snapdragon 801 and Linux. While NASA wants it to last a long time that was not part of its main design.
https://www.pcmag.com/news/linux-is-now-on-mars-thanks-to-na...
https://www.nasa.gov/press-release/nasa-awards-next-generati...
https://www.electronicdesign.com/technologies/embedded-revol...
https://www.microchip.com/en-us/products/microcontrollers-an...
https://www.eenewseurope.com/en/microchip-to-develop-next-ge...
"NASA’s Jet Propulsion Laboratory has selected Microchip to develop the High-Performance Spaceflight Computing (HPSC) processor that will provide at least 100 times the computational capacity of current spaceflight computers for all types of future space missions, from planetary exploration to lunar and Mars surface missions.
The radiation hardened, fault tolerant processor will be based on 12 instantiations of the X280 RISC-V core from SiFive and will be used in a series of ruggedised radiation tolerant single board computers."
Microsemi (acquired by Microchip) has built RISC-V hardware in the past:
https://www.electronicdesign.com/technologies/iot/article/21...
0. https://www.microchip.com/en-us/about/news-releases/products...
How hard would it be for SiFive to take one of their existing designs, which lacks those countermeasures, and add them?
IIRC, all internal logic will require triple mode redundancy and all type of memory will need ECC plus scrubbing.
That seems to say it’s for a radiation-hardened design:
“In 2021, NASA solicited proposals for a trade study for an advanced radiation-hardened computing chip with the intention of selecting one vendor for development. This contract is part of NASA’s High-Performance Space Computing project”
They also say:
“The processor will enable spacecraft computers to perform calculations up to 100 times faster than today’s state-of-the-art space computers”
and
“Our current spaceflight computers were developed almost 30 years ago,”
That, for me, also points towards a radiation-hardened design. If it isn’t, 100 times faster than 30 years ago is an incredibly low hurdle to clear.
Also, it’s a $50 million firm-fixed-price contract. I have no idea whether that’s a sharp price for this, so can’t judge how much risk SiFive takes on with this.
It's physically impossible to produce RAD-hard semiconductors at the small scale we're currently producing high-end CPU's with.
I read this in an article somewhere but don't have the link.
In any case, I found this[2] article interesting and illuminating, which goes into different aspects of radiation hardening, including how the "old = safe" isn't strictly true.
"today’s state-of-the-art space computers" is not the same computer as "Our current spaceflight computers were developed almost 30 years ago".
this was developed for the HPSC program whose goal was to develop a replacement for the RAD750, and the "100 times performance" requirement is wrt that.
> If the latter, that seems (to a layperson) quite exciting, since more local processing capabilities will hopefully lead to more efficient use of the very limited radio bandwidth these missions have available at such vast distances.
Is that either/or, though? I could imagine building a probe with a radiation hardened central processor (or two), plus a non-radiation hardened "accelerator" CPU that's not considered mission critical. The "accelerator" could be tasked with things like pre-transmission data analysis/triage, and if it fails the mission could continue without feature (like Galileo continued without its high-gain antenna).
Though the value of that might be less than it seems at first look: New Horizons had literal years of time to transmit its data back to Earth.
Stuff on the outside to absorb? Different band gaps in the silicon?
Larger node, different substrate, shielding, and other things.
"Analysis of the Intel 386 and i486 microprocessors for the Space Station Freedom Data Management System" Yuan-Kwai Liu NASA May, 1991 RTOP 488-51-01 ISBN 9781729173374 https://www.libreriauniversitaria.it/analysis-intel-386-and-...
As for why Freedom/ISS went with 386s for the MDMs, I don't personally know. I'd guess that of the rad hard chips various defense companies shipped, a 386 was one of the more powerful. AFAIK the likes of the hardened RCA 1802 and some other 8-bit CPUs were pretty popular in the defense space. The RCA 1802 was used on a lot of the NASA's New Frontiers program probes.
The MDM design on Freedom/ISS was meant to have a standardized component that was easily replaceable and use software to define the role of the device. An MDM plugged into a pump actuator today could have its EEPROM flashed and be plugged into a pressure sensor tomorrow. A useful feature in a system humans live in.
That doesn't change the fact NASA's been RISC-y with their probes for the past three decades. The added power of the CPU (whatever the architecture) in today's probes means fewer specialized chips like were needed in older probes. That means more of the mass budget can go to science instruments and software can do the jobs that used to require dedicated chips.
For anyone interested you can get the paper from NASA here[0]. It's pretty interesting. Thanks for pointing it out.
Also excited to see RISC V gaining some acceptance in space.
So I understand that RISC-V does not immediately impose licensing fees, but how does that translate into portability and speed of development? I'd think that tools and toolchains do not especially benefit from there not being licensing fees, and do benefit from somebody paying cool kernel/compiler hackers. Tools hardware designers use as well as the designs themselves will stay closed. What am I missing?
I hope NASA and others using RISC-V also take the opportunity, of a bit of a fresh start, to push for more of an open hardware platform around the CPUs (chipsets, devices, etc.).
https://www.nasa.gov/feature/goddard/2022/nasa-s-davinci-mis...
> “The probe will touch-down in the Alpha Regio mountains but is not required to operate once it lands, as all of the required science data will be taken before reaching the surface.” said Stephanie Getty, deputy principal investigator from Goddard. “If we survive the touchdown at about 25 miles per hour (12 meters/second), we could have up to 17-18 minutes of operations on the surface under ideal conditions.”
There will be a companion orbiter, as well, called VERITAS:
You can experience SiFive's product in the real world.
[1]: https://www.kickstarter.com/projects/starfive/visionfive-2
Antmicro also teased their low-density SoM board [2] last year, but I have not heard any news about that since, which is a shame because you could put a ton of those in a server rack.
[1]: https://www.cnx-software.com/2022/08/29/pine64-star64-sbc-st...
[2]: https://www.cnx-software.com/2021/04/30/antmicro-arvsom-offe...
From the article:
> The HPSC processor and X280 compute subsystem is expected to be useful to other government agencies in a variety of applications including industrial automation, edge computing, ratification intelligence, and aerospace applications.
I couldn't find a good answer online.
Thank you!
Event the venerable behemoth x86(_64) has a front-end which translates CISC instructions into RISC-like micro-ops.
The distinction is pretty meaningless today.
Ever since the RISC paper, every new architecture of any remaining significance today has been RISC. Today, it makes more sense than ever[0].
The only CISC that remains in large-scale use is x86, which I expect to finally be deprecated during this decade.
0. https://itnext.io/risc-vs-cisc-microprocessor-philosophy-in-...
Ok CISC ISAs are out of favor today, although I suspect as some of these RISC ISAs age, they'll accrete instructions. The ARM ISA sure is a lot chonkier than it used to be. Modern ARM CPUs have a massive micro-op cache just like x86 CPUs do. I wouldn't be surprised if we wake up one day and it's half way to x86.
In my opinion ISA isn't relevant or interesting. [1]
I echo the sentiments in this article:
> In short, there’s no meaningful difference between RISC/ARM and CISC/x86 as far as performance is concerned. What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks like predicting whether a load can execute before a store to an unknown address.
So to your point that:
> Today, [RISC] makes more sense than ever.
I would respond, today, it makes less difference than ever.
What actually happens under the hood of a modern performance-optimized CPU is so far removed from the ISA that the ISA is just a design curiosity.
'RISC architecture' isn't going to 'change everything' - how it's implemented: advances in branch prediction, prefetching, etc - that's going to continue to iteratively improve processors. The number of instructions is truly not a factor of note.
Does it never matter? Probably sometimes. Once in a while in some very specific applications - like pico-amp scale microcontrollers - it might? But for anything you’re thinking of it’s super irrelevant.
[1] https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
It isn't. Instead, it is a way to compare ISAs. And RISC is the way to go, because we've known for some 40+ years that CISC is bad.
>In my opinion ISA isn't relevant or interesting.
Except when it is.
One example: x86 is too complex to be reasoned with, so it's not an option where high assurance (and thus formal proofs) is a necessity.
>What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks...
Another example: ARMv8 and v9 have horrendous code density. As a result, L1 needs to be larger to fit the same amount of code. Which means lower frequency. larger area and higher power usage. Similarly, a microcontroller's ROM would have to be larger to fit the same program, also bad.
>RISC CPUs (like the RISC-V) fuse instructions into macro-ops.
Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].
>I would respond, today, it (RISC) makes less difference than ever.
For most applications, end users don't know or care what ISA is in there.
But, for anyone actually designing systems, it does matter. Complexity breeds bugs. Most bugs are security bugs. x86's (the one CISC that still sees chips fabbed, large scale) complexity is insane. And security thus impossible; a losing proposition.
In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.
x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.
> And RISC is the way to go, because we've known for some 40+ years that CISC is bad.
Quantify 'bad'. Again these are all opinions.
Nobody will argue with you x86 is terrible. What I'm saying, backed by the article I linked, is that the fact the x86 ISA is terrible really doesn't hold it back. And once you start optimizing a RISC architecture, over time, for performance, it quickly approaches the same thing.
> Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].
It doesn't depend on fusion but since 2016 it's pretty clear it'll be an optimization. A big one! Which means that complexity is coming whether or not any market cores implement it today or not, which is part of the argument I'm making haha. Once you take the path of these optimizations, the cores start to look pretty familiar. Read the reply to the comment you linked.
Nobody is going to leave performance on the table to satisfy some niche opinions on complexity being bad.
> But, for anyone actually designing systems, it does matter.
What is "actually designing systems" today? There's complexity in everything (especially anything performant) and frankly, that complexity is abstracted effectively by compilers and operating systems.
> In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.
Citation needed?
> x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.
Fine, but not relevant to CISC vs RISC.
https://github.com/riscv/riscv-isa-manual/releases/download/...
Plus recently ratified extensions:
https://wiki.riscv.org/display/HOME/Recently+Ratified+Extens...
The ISA being open source means that if SiFive goes out of business or changes its product lineup, or starts to make buggy stuff, or charge too much ... no matter what happens, the customer is free to find another vendor to make software-compatible chips.
As we've found out with ARM this week, even if one company with ARM's highest and most expensive form of license, the Architecture License Agreement (ALA), makes a CPU design they are not allowed to transfer or sell that design to another company that also has an ALA without ARM's explicit permission. Or so ARM claims. Let's see what the courts decide about that.
Per my understanding RISC-V has nothing even close performance-wise to Arm's high-end stuff. So isn't it apples to oranges?
Cortex-A77 isn't ARM's fastest anymore, but it was in 2019. Meaning SiFive was, in 2021, not even 2 years behind. If tracing back to prior generations, you'll see SiFive has been quickly closing the gap.
To the point that it wouldn't surprise me if at the next iteration from both companies, SiFive and ARM highest performance cores were on par.
What's even more amazing is that SiFive's cores are consistently smaller area and lower power to the ARM cores they have comparable performance to.
[0] https://www.sifive.com/cores/performance-p650
[1] https://www.phoronix.com/image-viewer.php?id=2021&image=sifi...
Open ISA is huge. It may not mean open hardware on its own, but it sure as hell opens the door to open hardware in the future. I think there is a chinese CPU in development that is claiming to aim to be the linux of CPUs. Can't remember the name but they were at one of the risc-v conferences recently.
I swear, this place's appetite for empty lowbrow armchair dismissal is very disappointing.
“Launch aborted, whenever we access the pressurization control we’re getting an ‘ISA not implemented in this version of the core’ error from the controller that arrived overnight. They must have received the wrong version of the chip and didn’t catch it in the test rig we gave them 6 years ago.” #roflmao