Salut,
J'ai récemment acquis une carte de développement Sifive Hifive 1 rev B, dont la principale motivation était de faire joujou avec la fameuse architecture de jeu d'instructions libres RISC-V. \O/
J'ai pris cette carte car c'était celle dans les premiers prix à 80 €, bien plus abordable que la carte Sifive HiFive Unleashed.
Alors qu'est ce qu'on a dessus :
- un microcontrôleur (FE310-G002) avec son coeur E31 utilisant l'architecture de jeu d'instructions RISC-V
- du Wifi (ESP32-SOLO-1)
- du Bluetooth (ESP32-SOLO-1)
- de la flash de capacité 32 Mbits (IS25LP032D)
- une LED RGB
- un connecteur USB de type Micro-B (le câble n'est pas fourni avec)
- un connecteur d'alimentation de type jack
- les boutons reset et wake
Premier contact avec la documentation de la carte tout en Anglais fallait si attendre.
Cependant la documentation est fournis et relativement simple à comprendre du moins sur la partie de présentation de la carte Sifive Hifive 1 rev B.
On a le droit à de nombreuses documentations comme le schéma de la carte électronique, du microprocesseur, du coeur et bien sur du jeu d'instructions.
Coté environnement de développement on est invitée à utiliser le logiciel Sifive Freedom Studio, basée sur l'IDE Eclipse, qui est plus complexe a utiliser que l'IDE d'Arduino.
Le langage utilisé pour développer sur la carte est le C
Je ferais sans doute d'autres journaux pour parler du développement sur cette carte.
# À suivre
Posté par Anonyme . Évalué à 6.
Perso, je reste sceptique à la fois sur le tarif (un "bluepill" STM32 F103 c'est plus de 50 fois moins cher pour des perfs acceptables) et sur l'intérêt de manipuler une ISA qui va certainement évoluer, se spécialiser et se refermer (l'intérêt du libre ici n'est pas vraiment pour l'utilisateur mais pour le fabricant).
Sans compter que Sifive ne fait pas dans l'open-source, du moins pas complètement, donc la portée éducative reste relativement limitée par rapport à d'autres designs RISC-V.
Pour un concepteur de matériel amené à devenir client de Sifive, pourquoi pas. Pour découvrir le dev de microcontroleurs de manière moins limitée que Arduino-IDE ou pour découvrir RISC-V et ses entrailles il y a sans doute de meilleures alternatives.
On dirait que Eclipse a le vent en poupe, STMicro l'utilise aussi dans sa suite.
Sinon le journal est un peu court, on dirait un unboxing de youtuber. Il manque un premier essai de blinky.hex :-)
[^] # Re: À suivre
Posté par martoni (site web personnel, Mastodon) . Évalué à 7.
Gigadevice fait également des RISCV (clone STM32 ;) pour 50fois moins cher. Mais au moins c'est du RISCV.
Sur quel élément bases tu cette affirmation gratuite ? Il faut lire la spec RISCV et pas la campagne get the fact de ARM. Cette spec dit bien que l'ISA est considérée comme stable et ne sera pas changée. Il va y être cependant ajouté des extensions qui elles ne sont pas forcément encore stabilisées.
Pour les sources (hardware) de l'E310 dont il est question ici c'est par là.
J'ai plus qu'une balle
[^] # Re: À suivre
Posté par reno . Évalué à 4.
Il y a quand même un point qui me choque particulièrement sur le RISC-V: la possibilité d'avoir des instructions 32bit non-alignées avec l'extension C.
C'est un RISC ça?? Bonjour la complexité de l'extension..
J'aurais bien aimé avoir un compte rendu de la discussion sur ce point car je trouve la décision vraiment surprenante.
[^] # Re: À suivre
Posté par martoni (site web personnel, Mastodon) . Évalué à 4.
Les instructions sont alignées … sur 16 bits ;) pour une question de densité du code l'alignement sur 32bits a été viré dans le cas d'utilisation de cette extension.
Perso le truc qui me choque encore plus c'est la possibilité de faire des lectures/écritures non alignées (enfin, aligné sur 8bits quoi) sur le bus de données.
J'ai plus qu'une balle
[^] # Re: À suivre
Posté par Ronan BARZIC . Évalué à 3.
D'après la spec il est possible pour le matériel de ne supporter que des lectures/écritures alignées - c'est dans ce cas le logiciel qui devra implémenter les accès non-alignés
We do not mandate atomicity for misaligned accesses so simple implementations can just
use a machine trap and software handler to handle misaligned accesses. If hardware misaligned
support is provided, software can exploit this by simply using regular load and store instructions.
Hardware can then automatically optimize accesses depending on whether runtime addresses are
aligned
[^] # Re: À suivre
Posté par reno . Évalué à 2.
Merci, je sais pourquoi ça a été fait, mais pour moi c'est privilégié les microcontrôleurs qui ont très peu de RAM au dépend de CPU 'normal' après c'est clair que le RISC V va être cantonné au monde des microcontrôleurs pendant une longue période..
[^] # Re: À suivre
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Ça ne me semblait pas un truc très original, on retrouve la même extension chez ARM avec le thumb par exemple. Et ça reste une extension que l'on peut choisir d'intégrer ou non.
J'ai plus qu'une balle
[^] # Re: À suivre
Posté par reno . Évalué à 4.
Je suis quasiment sur que dans les extensions 16bit de ARM ou MIPS, les instructions 32 bits sont alignées sur 32bits pas sur 16bits comme le RISC V.
Et ça n'est pas une petite différence, sur le RISC Vl peut y avoir un défaut de page pour accéder à la moitié d'une instruction, le prefetching est + compliqué aussi, après l'icache est + efficace..
[^] # Re: À suivre
Posté par cedric . Évalué à 4.
Perso, c'est l'inverse qui me choque. 32 bits pour des instructions simples? Ils sont au courant que la latence et bande passante mémoire, ca ne suit pas la loi de Moore? L'existence de l'extension c, c'est plus tôt, un oops, on n'avait pas fait attention au perf. C'est pas comme si on avait quelques décennies de connaissance sur le sujet.
L'autre point problématique c'est la licence et les brevets sur la spec. Il n'y a rien qui garantit que qui que ce soit qui contribue à la spec n'a pas un brevet sur le sujet dans un coin (et rien qui les forces à fournir une implémentent libre de brevet pour une implémentation libre). Comme projet, pour un gros constructeur, c'est une bonne option vu qu'ils ont probablement de quoi se défendre, mais pour les plus petit et le logiciel libre, c'est pas garantit.
Après toutes les start-up autour de risc v ont réussi à lever pas mal de fond, donc ca va continuer d'avancer et l'écosystème est probablement robuste, suffisamment pour faire stresser arm.
[^] # Re: À suivre
Posté par Tonton Th (Mastodon) . Évalué à 1.
Parse error, redo from start[^] # Re: À suivre
Posté par Anonyme . Évalué à 3.
J'ai bien dit « plus de 50 fois ». Si tu vas regarder les prix, c'est même parfois moins de 2€.
Le Longan Nano, bien que plus abordable que la devboard de Sifive, reste cher comparé à un blue pill et rien ne garantit le même niveau de performance malgré la nomenclature similaire à celle de STMicro.
L'ISA RISC-V est toujours un surcoût.
Je ne suis pas aussi enthousiaste que toi, ça ne t'autorise pas à insulter mon intelligence.
Parce que tu crois vraiment que les fabricants vont respecter l'ISA à 100% dans leurs produits privateurs?
Le but de RISC-V pour les industriels c'est de ne plus avoir de royalties à payer tout en ayant une architecture modulaire qu'ils peuvent rendre confidentielle.
Et comme pour chaque itération précédente de RISC, les acteurs vont rapidement s'isoler et créer une miriade d'ISA proprio incompatibles entre elles.
[^] # Re: À suivre
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
En même temps on compare un peu des choux et des carottes. La Blue Pill c'est une carte assez «sèche» avec juste le microcontrôleur sans aucun périphérique. La Longan Nano a beaucoup plus de périphériques. Et la Hifive encore plus. Mais il est vrai que la Hifive est cher, d'autant que le E310 est surtout destiné à des entreprise qui voudrait le dériver avec leur propre composant.
Le concept du RISCV est de respecter une base ouverte et d'ajouter des extensions. Ces extensions peuvent être ouverte ou non. Mais s'ils veulent afficher une base RISCV, oui il la respecterons.
On ne parle ici que du jeux d'instructions hein, après l'implémentation n'a aucune obligation d'être ouverte.
J'ai quand même un doute là dessus, l’intérêt de rester dans le standard c'est de garder toute la base logiciels compatible. Quel est l’intérêt de se rendre incompatible dans ce cas ?
J'ai plus qu'une balle
[^] # Re: À suivre
Posté par Anonyme . Évalué à 3.
Complétement. Mais ça fait aussi partie de la gamme des devboards que d'avoir le quasi-minimum et c'est certainement moins compliqué à obtenir pour l'étudiant, le hacker ou le hobbyiste qui a déjà accès à divers périphériques à piloter par le MCU ou qui n'a aucun besoin des fioritures fournies (ou voudrait les déporter sur un projet). C'est un produit qui manque encore au panel.
Perso pour mes protos ou mes POC, les features du Longan Nano sont inutiles, voire même encombrantes pour l'implémentation. J'ai jamais eu besoin de microSD sur un MCU pourtant j'ai un "hat" Teensy depuis près de 10 ans et j'ai le matériel pour en bidouiller un avec des fils et un adaptateur passif SD vers micro. Pareil, j'ai rarement la nécessité d'un écran. Puis quand je vois les problèmes d'usure sur la techno oled encore à l'heure actuelle et les grandes variations de qualité de ces écrans chinois, je reste suspicieux face à l'effet de mode et suis partisan des LCD.
Sans compter que si on en croit le pinout de la carte, le MCU ne semble pas avoir la flexibilité d'attribution des ports que possède un STM32F103 (mais peut-être que c'est une question de firmware, j'ai pas vraiment gratté).
Par exemple, pour s'assurer une rente quand on est leader d'un marché, protéger un brevet, ou pour faire de la sécurité par obscurité. Les raisons sont nombreuses.
ARM, Sun, HP, IBM, DEC, Atmel et bien d'autres l'ont fait avec les itérations précédentes des travaux de Berkeley. On peut imaginer aisément qu'un acteur comme Western Digital, Nvidia, voire un mastodonte chinois comme Huawei ou le plus discret Padauk le fassent aussi avec cette version cinq.
Je n'ai pas de boule de cristal mais en regardant le passé on peut se demander si une implémentation standard de l'ISA sera encore disponible d'ici quelques années. Il suffit parfois d'une grosse boite ou d'un gros succès d'une déviation pour qu'une inertie technologique se mette en place et occulte le standard.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.