SiFive ne cache pas son plaisir d’avoir été sélectionné par l’Agence spatiale américaine « pour fournir les cœurs CPU du processeur HPSC (High-Performance Spaceflight Computing) de nouvelle génération de la NASA ».
Ce processeur « devrait être utilisé dans pratiquement toutes les futures missions spatiales, de l'exploration planétaire aux missions de surface lunaire et martienne ». HPSC exploitera huit cœurs SiFive Intelligence X280 RISC-V avec quatre cœurs RISC-V supplémentaires, pour « offrir cent fois la capacité de calcul des ordinateurs spatiaux actuels ».
Commentaires (23)
#1
Ce surprenant, j’ai lu la même info à propos de Microchip.
https://www.tomshardware.fr/la-nasa-veut-un-processeur-hpsc-100-fois-plus-performant-que-les-solutions-actuelles/
#1.1
SiFive dévelope l’architecture RISC-V, là ou Microship est un fondeur. il faut les 2 pour faire un produit final :)
C’est comme ça que je le comprend en tout cas.
#1.2
MicroChip n’est pas un fondeur, mais un concepteur de microcontroleurs, FPGA et SoC. Apparemment, la puce HPSC est conçue conjointement par SiFive et MicroChip.
#2
RISC-V semble avec cette annonce devenir un candidat sérieux pour reprendre le flambeau du PowerPC dans les applications spatiales/avioniques ou ARM/Intel sont exclus (pour des raisons différentes).
Mais si on veut que cela fonctionne, il est impératif que ce coup de pouce débouche sur une utilisation plus large en amont car ce n’est pas les volumes du spatial qui vont tirer l’affaire: Le PowerPC a dû son succès dans les applications critiques à des caractéristiques propres favorables (pas de cachotteries dans le ME et autres firmwares + grande variabilité de latence y compris dans des applications “machine à laver” hors OS, non pétri d’états indéfinis par souci de simplification/moindre conso) mais également au fait que l’industrie télécom a généré en amont des volumes suffisants et un gros boulot de déverminage des SoC ayant ensuite connu une seconde vie ailleurs et qui seront encore là pour des décennies.
#3
Tu pourrais détailer les raisons stp ? J’imagine que ce n’est pas une uniquement une question de blindage et de contrôle d’intégrité.
#3.1
Les raisons m’intéressent aussi. La NASA est bien allée sur la lune avec des processeurs intel 8066, qu’est-ce qui a changé depuis ?
#4
Intel 8066, ça n’existe pas. Et d’ailleurs, à la date des mission Apollo, Intel n’avait pas encore conçu son tout premier microprocesseur (le 4004, en 1971). L’AGC était issu du MIT. Tu confonds avec le 8086 dans la navette spatiale qui, elle, n’est pas allée sur la lune.
Sinon, il me semblait que c’est le Z80 qui a été utilisé longtemps dans le spatial : simple, fiable, assez ancien pour penser raisonnablement que 100% de ses bugs étaient connus. Mais peut-être que je confonds, et qu’en réalité c’est plutôt en aéronautique.
#4.1
Oui, petite faute de frappe avec le 8086. Et effectivement, j’ai confondu le processeur utilisé pour les missions Apollo et celui utilisé dans la navette spatiale américaine (en même temps, le 8086 est sorti alors que le programme Apollo était déjà arrêté, j’aurai dû réfléchir 😅)
#5
La 4K. Ce serait plus difficile de faire croire qu’on est allés sur la lune. Cette fois-ci il faudra vraiment y aller et c’est compliqué.
#5.1
On n’est pas encore trolldi…
#5.2
Trop gros, ça ne passera pas.
#6
double post
#7
En même temps, les CGI ont bien progressé aussi.
#8
Et puis Michael Bay est né entre temps.
Plus sérieusement, n’ayant pas connu la première arrivée sur la Lune, je regarderai sûrement celle-là (si on est pas tout mort de déshydratation
)
#9
Je l’évoquais un peu plus loin: ARM est pétri d’états indéfinis faute d’implémenter toute la logique permettant d’éviter, autant que possible, qu’un code puisse dérailler de manière incontrôlée.
Intel manque désormais totalement de déterminisme et impose dans les faits de ne pas maîtriser certains aspects comme le démarrage.
Pour commencer, pas facile de se faire fournir les firmwares non signés, dont le ME indispensable au démarrage, qui le sont à la première exécution en utilisant l’ID unique du processeur qui les utilise (au moins pour leurs SoC basés Xeon ou Atom ciblant l’embarqué: On a tôt fait de remarquer qu’un dump de boot flash d’une carte collé sur une autre ne permet pas de démarrer! Impossible dans ces conditions de générer une boot flash générique donc d’industrialiser un produit).
Limitations des blob binaires nécessaires à une alternative type coreboot, qui sont en réalité une version compilée de leurs reference-code (RC pour la partie plateforme et MRC pour la partie init DDR) avec qq limites d’API bloquantes pour des usages embarqués, imposant de sous traiter cet élément clef à un vendeur de BIOS (eux ont accès aux RC que l’on refuse aux clients finaux et aux FW non signés, qu’on avait eu après pas mal de palabres avant de lâcher l’affaire en raison de la non fourniture des RC qui n’avait même pas été discutable!).
Et quand tu as signé un contrat avec un vendeur de BIOS, incluant la fourniture du source et environnements de développement… bin tu te rends compte de l’affreux patchwork qui (si cela ne venait pas de dehors, donc hors scope) ne passerait aucune revue de code interne dans l’industrie! Alors aller certifier un tas de merde pareil pour de l’avionique, même pas en rêve!
#9.1
Merci pour ce retour technique intéressant. J’ignorais ces évolutions, mais je suis pas surprit.
#9.2
Je comprends un peu mieux. Merci !
#10
Un Z80 est tellement simple (surtout par rapport à ce qui a suivi) qu’il comporte encore des bugs après les premiers mois (voire années) ?
#11
Des bugs connus de tous et dont le contournement est aisé donc ce n’est pas un vrai problème.
#12
Par curiosité, tu as un exemple particulier en tête concernant le Z80 ou un des processeurs de l’époque (le 6502 qui a également été beaucoup utilisé, dont Commodore 64 et Apple II) ?
#12.1
Il y en a un dans la page Wikipédia (en).
Suivre le lien de la note pourra aussi t’intéresser.
#12.2
Merci.
Étonnant que ce bug n’ait pas été corrigé au bout d’un moment (évidemment ça ne vaut que pour les puces gravées après la correction des masques).
#12.3
Les programmes contournant le bug risquaient de ne plus fonctionner, à une époque où les patches n’existaient pas (ou avec des vecteurs d’information et de distribution très lent) Donc on préférait garder un bug connu et documenté, plutôt que de risquer de rendre les nouvelles séries de processeurs incompatibles avec la base de logiciels existante.