The RISC-V based Hazard3 core featured in RP2350 was designed by Luke Wren, an engineer at Raspberry Pi. Hazard3 is completely his own design, licensed to Raspberry Pi. Luke started designing processors based on 7400-series logic in his free time when he was 16, and has progressed to working with the RISC-V ISA, inspired by the ability to experiment and extend on top of a clean, industry standard architecture. The momentum and ecosystem of RISC-V means that his work is supported by mature tools like GCC and LLVM, making it easy to develop for.
Hazard3 is a fork of one of Luke’s previous designs, Hazard5, with a focus on best possible performance at MCU clock frequencies inside a small silicon footprint. The process of development for the first instance of Hazard3 took less than a week from forking Hazard5! Luke is excited for the educational possibilities enabled by Hazard3 and has made it available on his GitHub page under an Apache Licence Version 2.0 for anyone to use, and to learn from. Future processor designers can view the unedited commit history for Hazard3 and learn from Luke’s development process, including his mistakes and how he corrected them. Students studying processor design can develop and test software workloads on RP2350, then look at the Hazard3 source, modify the processor to include their own custom instructions, then test their new version on an FPGA.
Ça pourrait être cool de faire tourner les deux architectures en même temps comme le Cell avec son cœur PPC et ses SPEs en effet, mais d’après l’article de franboise314 ce serait soit les cœurs Arm, soit les cœurs RIRSC-V, mais pas les deux architectures en même temps:
Le choix s’effectue au démarrage, les deux cœurs activés sont ensuite utilisés par le programme.
En tout cas ça semble être un moyen intéressant de diffuser en masse une architecture en laissant le client prendre le risque de tester autre chose… sans perdre ce qu’il connaît déjà et sur lequel il peut se rabattre si besoin. Un dual boot mais pour l’archi, en somme.
ce commentaire est sous licence cc by 4 et précédentes
Il y a un gros intérêt par à 2 cartes plus simples ? Construire une offre commerciale avec l'un des existants et un nouveau PI risc-v, me paraît plus simple et évite d'avoir cette partie spécifique qui peut toujours être sujet aux bugs et rendre toujours plus spécifique le matériel.
On peut voir ça aussi comme un gros gâchis de silicium, vu qu'une fois le dév terminé, l'application sera sur l'un ou l'autre, et on aura 2 cores inutiles.
Il existe des applications qui demandent précisement de pouvoir tourner sur des architectures différentes : environnement ionisés, exposition aux radiations etc. Avoir deux cpus différents faisant tourner le meme code permet de mettre en place des points de contrôle dans l'exécution et vérifier que le code tourne correctement.
Ici le fait d'avoir seulement à dupliquer la carte pour passer en mode redondance est un grand avantage.
Avoir deux cpus différents faisant tourner le meme code permet de mettre en place des points de contrôle dans l'exécution et vérifier que le code tourne correctement.
Ici il n'y a qu'une architecture activé à la fois.
Généralement dans ce genre de cas j'ai toujours entendu 3 CPU pour pouvoir décider le quel accepter en cas de problème.
Je ne suis pas sûr que ce soit faisable avec des architectures différentes parce que ça me paraît compliqué de savoir quand vérifier et comment comparer les résultats
Je ne suis pas professionnel de ce milieu, je me base sur une conférence à laquelle j’avais assisté qui expliquait ce problème. Le présentateur expliquait comment il avait réussi à résoudre ce problème sans trop de frais en compilant le même code avec deux compilateurs différents (llvm et gcc), et en mettant un bus de communication entre les deux programmes.
Après chaque opération, chaque composant envoyait sur le bus les résultats de son calcul et attendait confirmation de l’autre unité. Si les deux différaient, les deux unités recommençaient le traitement depuis le précédent point de contrôle.
Avoir deux compilateurs semble être suffisant pour qu’une perturbation sur un composant n’affecte pas le second de manière identique, mais j’imagine que mettre deux architectures doit augmenter encore davantage la sûreté de l’ensemble.
Posté par barmic 🦦 .
Évalué à 2 (+0/-0).
Dernière modification le 10 août 2024 à 22:03.
Le cell est souvent tenu pour responsable de l'échec de la PS3, il semble que c'était un enfer d'en tirer partie.
À terme il y aura une version sans doute 100 % RISC-V..
Raison de plus supporter des architectures exotiques prend du temps pourquoi investir du temps là dessus si 3 ans après elle est surclassé par quelque chose de plus simple
J'ai le même avis mais je pense qu'il y a un truc qui nous echappe. Peut être que cela permet de tester quelle architecture est la plus efficace suivant les scénarii? Une utilité pour des développeurs/testeurs ?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Je sais pas si c'est dur à concevoir, mais à développer non : comme indiqué il y un choix à faite au démarrage puis soit l'un (jeu ARM) soit l'autre (jeu RISC) est actif donc ça change rien
Ben soit je suis idiot soit c'est eux? Tu achète un CPU qui a 4 cœurs, 2 ARM et 2 RISC-V et tu dis qu'au boot tu choisis si tu utilise ARM ou RISC-V ça veut dire que tu va utiliser 50% des processeurs… et comme tu l'utilise avec un OS ou un seul programme c'est à chaque boot le même choix. Donc on fabrique 4 processeurs pour en utiliser 2. A moins que tu fasse un double boot, l'un en OS Risc-V l'autre en ARM?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Et un lien vers la datasheet
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Toujours en Anglais : https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Et un lien vers la datasheet
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 1 (+0/-0).
C'est mieux qu'en chinois, non ?
;-)
# Et sur framboise314.fr (en français donc)
Posté par Jona . Évalué à 6 (+4/-0).
https://www.framboise314.fr/sortie-du-nouveau-raspberry-pi-pico-2-avec-le-rp2350-arm-ou-risc-v/
# Génial
Posté par antistress (site web personnel) . Évalué à 8 (+5/-0).
# Architecture exotique
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Une architecture exotique qui j'ai bien compris avec des unités de calculs ARM et RISC-V, ça va pas être un enfer pour en tirer pleinement partie ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Architecture exotique
Posté par YBoy360 (site web personnel) . Évalué à 2 (+1/-0).
Ils peuvent avoir des jeux d'instruction distinct mais avoir une compatibilité binaire pour les données (comme le sell de la PS3).
Par exemple, on peut imaginer les fpu identiques, elles donnent donc les mêmes résultats.
Je trouve ça génial perso. À terme il y aura une version sans doute 100 % RISC-V..
[^] # Re: Architecture exotique
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
Ça pourrait être cool de faire tourner les deux architectures en même temps comme le Cell avec son cœur PPC et ses SPEs en effet, mais d’après l’article de franboise314 ce serait soit les cœurs Arm, soit les cœurs RIRSC-V, mais pas les deux architectures en même temps:
En tout cas ça semble être un moyen intéressant de diffuser en masse une architecture en laissant le client prendre le risque de tester autre chose… sans perdre ce qu’il connaît déjà et sur lequel il peut se rabattre si besoin. Un dual boot mais pour l’archi, en somme.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Architecture exotique
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Bien vu pour le choix au démarrage
Il y a un gros intérêt par à 2 cartes plus simples ? Construire une offre commerciale avec l'un des existants et un nouveau PI risc-v, me paraît plus simple et évite d'avoir cette partie spécifique qui peut toujours être sujet aux bugs et rendre toujours plus spécifique le matériel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Architecture exotique
Posté par Maclag . Évalué à 5 (+2/-0).
On peut voir ça aussi comme un gros gâchis de silicium, vu qu'une fois le dév terminé, l'application sera sur l'un ou l'autre, et on aura 2 cores inutiles.
[^] # Re: Architecture exotique
Posté par chimrod (site web personnel) . Évalué à 3 (+1/-0).
Il existe des applications qui demandent précisement de pouvoir tourner sur des architectures différentes : environnement ionisés, exposition aux radiations etc. Avoir deux cpus différents faisant tourner le meme code permet de mettre en place des points de contrôle dans l'exécution et vérifier que le code tourne correctement.
Ici le fait d'avoir seulement à dupliquer la carte pour passer en mode redondance est un grand avantage.
[^] # Re: Architecture exotique
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Ici il n'y a qu'une architecture activé à la fois.
Généralement dans ce genre de cas j'ai toujours entendu 3 CPU pour pouvoir décider le quel accepter en cas de problème.
Je ne suis pas sûr que ce soit faisable avec des architectures différentes parce que ça me paraît compliqué de savoir quand vérifier et comment comparer les résultats
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Architecture exotique
Posté par chimrod (site web personnel) . Évalué à 3 (+1/-0).
Je ne suis pas professionnel de ce milieu, je me base sur une conférence à laquelle j’avais assisté qui expliquait ce problème. Le présentateur expliquait comment il avait réussi à résoudre ce problème sans trop de frais en compilant le même code avec deux compilateurs différents (llvm et gcc), et en mettant un bus de communication entre les deux programmes.
Après chaque opération, chaque composant envoyait sur le bus les résultats de son calcul et attendait confirmation de l’autre unité. Si les deux différaient, les deux unités recommençaient le traitement depuis le précédent point de contrôle.
Avoir deux compilateurs semble être suffisant pour qu’une perturbation sur un composant n’affecte pas le second de manière identique, mais j’imagine que mettre deux architectures doit augmenter encore davantage la sûreté de l’ensemble.
[^] # Re: Architecture exotique
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Ah oui c'est logique
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Architecture exotique
Posté par vpinon . Évalué à 3 (+2/-0).
Un coeur c'est pas forcément gros dans un MCU/CPU : les mémoires et les périphériques peuvent être très majoritaires en surface…
[^] # Re: Architecture exotique
Posté par barmic 🦦 . Évalué à 2 (+0/-0). Dernière modification le 10 août 2024 à 22:03.
Le cell est souvent tenu pour responsable de l'échec de la PS3, il semble que c'était un enfer d'en tirer partie.
Raison de plus supporter des architectures exotiques prend du temps pourquoi investir du temps là dessus si 3 ans après elle est surclassé par quelque chose de plus simple
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Architecture exotique
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
J'ai le même avis mais je pense qu'il y a un truc qui nous echappe. Peut être que cela permet de tester quelle architecture est la plus efficace suivant les scénarii? Une utilité pour des développeurs/testeurs ?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Architecture exotique
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 10 août 2024 à 21:01.
Je sais pas si c'est dur à concevoir, mais à développer non : comme indiqué il y un choix à faite au démarrage puis soit l'un (jeu ARM) soit l'autre (jeu RISC) est actif donc ça change rien
[^] # Re: Architecture exotique
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Ben soit je suis idiot soit c'est eux? Tu achète un CPU qui a 4 cœurs, 2 ARM et 2 RISC-V et tu dis qu'au boot tu choisis si tu utilise ARM ou RISC-V ça veut dire que tu va utiliser 50% des processeurs… et comme tu l'utilise avec un OS ou un seul programme c'est à chaque boot le même choix. Donc on fabrique 4 processeurs pour en utiliser 2. A moins que tu fasse un double boot, l'un en OS Risc-V l'autre en ARM?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Architecture exotique
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 1 (+0/-0).
On peut même mélanger : 1 coeur ARM et 1 coeur RISC-V dans l'ordre qu'on veut !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.