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.
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.
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.
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...
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...
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.
> 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.