Journal De retour du 4e workshop RISC-V

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
45
14
juil.
2016

Bonsoir à tous, (désolé désolé je suis sur un clavier qwerty (NdM.: corrigé))

Il m'a pris l'envie il y a quelques mois de suivre le développement de RISC-V. Après tout, je fais de l'Open Hardware et même si j'aime bien Intel, AMD et ARM, faire des machines "open" avec des processeurs "fermés" c'est un peu bébête. Du coup j'ai pris un billet d'avion et direction Boston lundi soir pour le 4e workshop RISC-V au MIT. S'en sont suivis 2 jours studieux de conférences techniques avec des personnes ultra motivées, des démos fonctionnelles (sur FPGA) et un projet ambitieux qui me semble devenir de plus en plus prometteur et fiable.

Alors qu'ai-je retenu:

  • Le projet est piloté par Berkeley et le MIT, au travers d'une fondation à but non lucratif (mais dont l'inscription est payante 99$ par an en membre individuel).

  • Les outils de développement se basent sur chisel un langage de description matériel qui franchement vaut le détour (bon après c'est un peu technique, mais quel progrès par rapport à mes débuts dans la micro architecture chez Digital)

  • Il existe aussi bluespec (mais là ça coûte une blinde, et nécessite une phase d'apprentissage non négligeable notamment sur la gestion des preuves formelles)

  • Actuellement deux cœurs sont disponibles en chisel, le cœur Rocket (CPU superscalaire in order avec cache et MMU, dédié plutôt aux environnements fortement contraints et sur des consommations de l'ordre de la centaine de mW), et accrochez-vous le truc est disponible sur github. Le second cœur est BOOM. Ce cœur m'intéresse déjà plus, il est out of order, et à la capacité d'émettre 3 instructions par cycle là où Rocket est limité à une.

  • Sifive une startup issue de Berkeley démontrait un FPGA avec un cœur Boom sous Linux avec support PCIe etc … Il prévoit de sortir un chip complet aux alentours de 1,6 Ghz pas si mal pour une première passe.

  • Debian a démarré un portage sur l'architecture RISC-V et la motivation est là !

Alors sommes-nous à la naissance d'une nouvelle architecture, je pense que oui, en 2 ans le travail accompli est énorme, la complexité d'ARM, et le monopole d'Intel commence à énerver un certain nombre de personnes, mais comme je l'ai toujours pensé la clef réside dans les outils et franchement chisel est un sacré pas en avant dans la conception de chips.

Conclusion de cette histoire, je suis retombé dans ma jeunesse, lorsque je travaillais sur le chip Alpha, et ça me donne sévèrement envie de faire un chip (ok vous avez le droit de penser que je suis un peu cintré). La plus grosse difficulté maintenant c'est de financer tout ça, on va chercher des solutions et peut-être en trouver si les ventes d'Horizon décollent.

Le seul hic c'est que je vais finir par avoir vraiment beaucoup de boulot après être passé du côté obscur de la force sur FreeCAD, mais franchement l'idée d'avoir un chip totalement ouvert et libre me tente vraiment, et en plus je pense qu'on peut le faire vraiment performant, l'ISA est bien née. Alors y a plus qu'à, ressortez vos cours d'architecture et let's go. Et on se croisera en novembre chez Google à Mountain View pour le 5e workshop RISC-V !

Ah si, dernier truc pour ceux qui sont intéressés, je suis rentré avec une carte FPGA flashée avec un chip Rocket ;)

vejmarie

  • # Bluespec

    Posté par  . Évalué à 2.

    Je connais (« de loin ») l'un des chercheurs du MIT derrière Bluespec. La courbe d'apprentissage est peut-être un peu raide, mais les principes sur lesquels elle se base permettent de créer des conceptions correctes pour du matériel (et techniquement, du logiciel aussi, mais il y a des environnements plus simples à utiliser dans ce cas).

    Comme tu le dis dans le journal, avoir des notions de preuves formelles n'est pas un luxe. En retour, Bluespec promet (mais je ne sais franchement pas à quel point c'est vrai) qu'avec un langage relativement haut-niveau, on peut générer un bitstream ou autre description matérielle/bas-niveau optimisés, corrects, et qu'on peut repérer les erreurs bien plus tôt qu'avec des outils standard (genre : ta simulation VHDL te dit que tout va bien, mais tu n'as pas remarqué que tu as affecté deux signaux à un unique pin parce que c'est définit dans deux modules).

    Je n'ai jamais utilisé le truc, et la seule raison qui fait que je connais un peu, c'est parce que Bluespec se base sur des concepts que j'utilise au boulot.

    • [^] # Re: Bluespec

      Posté par  (site web personnel) . Évalué à 2.

      En fait sur le principe Bluespec a l'air vraiment bien, les demos faites etaient tres interessantes et ca m'aurait sauve plus d'une fois il y a qqs annees. Mais la licence proprietaire a 100 000$ par an, le rend quasiment inutilisable sur des projets "open". C'est un peu les limites du systeme universitaire americain.

  • # excuse du qwerty

    Posté par  . Évalué à 0.

    (desole desole je suis sur un clavier qwerty)

    Désolé de faire mon vieux con, mais lire ton journal — au demeurant fort intéressant au niveau du contenu — est très pénible et l'excuse du qwerty me convainc de moins en moins. Ne peux-tu pas changer facilement la disposition ? Est-ce parce que tu as encore besoin de regarder ton clavier quand tu tapes ? As-tu regardé du côté d'outils alternatifs du genre http://marin.jb.free.fr/qwerty-fr/ ?

    • [^] # Re: excuse du qwerty

      Posté par  . Évalué à 6.

      Perso j'utilise la disposition US-International : ça a tous les avantages d'un qwerty pour le code, mais l'on peut quand même écrire du français correct avec des diacritiques de façon simple.

  • # Interressant

    Posté par  . Évalué à 2.

    Je n'ai pas eu le temps de regarder en detail l'ISA, mais a premiere vu, ca manquait de calcul vectoriel et flottant. Je trouve ca assez domage au final surtout aujourd'hui avec le support de l'auto-vectorisation dans les compilateurs et l'utilisation des flottants dans quasiment tous les languages de script. Je me trompe peut etre, mais c'est probablement du fait de leur volonte de faire le grand ecart entre Rocket et BOOM. Du coup, pour les avoir rencontre et avoir regarde le sujet de plus pres, tu en penses quoi ? C'est vraiment necessaire l'approche Rocket quand des projets comme j-core addresse deja ce marche ?

    Par curiosite, j'ai juste regarde les exemples sur la premiere page de chisel, et ce n'est pas evident la difference avec VHDL. Tu pourrais un peu elabore ce que tu as appris sur le sujet ? Ou donner des pointeurs sur les morceaux que tu trouves interressant.

    Sinon je n'avais pas vu pour le 5eme workshop. Vu que c'est a cote de chez moi, je viendrais bien. Tu as une date plus precise et une annonce pour s'enregistrer ?

    • [^] # Re: Interressant

      Posté par  (site web personnel) . Évalué à 2.

      l'ISA va avoir des extensions vectorielles et FPU ;). L'ISA est jeune et au depart developpee a usage educatif. Rocket est le premier chip, je ne connais pas trop l'interet de ce chip d'un point de vu marche, je pense que l'IoT va etre envahie d'archi divers et variees et a mon avis ca va etre complexe de savoir qui "gagnera".

      Chisel est pour le moment plus efficace dans la detection d'erreurs de design par rapport a VHDL. Il est en fait moins permissif ou te renvoie plus de message de Warning ou erreurs, style affectation de deux signaux differents sur une meme pin (le nombre de fois ou je me suis fais "avoir"). Je vais t'envoyer qqs exemples durant le week-end.

      Pour la date du workshop, je ne l'ai pas encore, car j'ai oublie de la note (elle etait sur le second slide), des que je recupere les presentations je la posterai, mais a mon avis la fondation va rapidement le faire aussi !

    • [^] # Re: Interressant

      Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 18 juillet 2016 à 10:36.

      Chisel est un langage synthétisable et synchrone. Cela signifie que si ton code est correcte en chisel, il synthétisera !
      Ce qui n'est pas le cas des HDL comme VHDL ou Verilog, qui eux sont des langages de simulation à l'origine. Prévu pour décrire le comportement d'un composant.
      De plus Chisel est un langage synchrone. Écrire quelque chose d'asynchrone génèrera une erreur à la «compilation» contrairement au VHDL/Verilog. (Mais il existe des moyens d'avoir plusieurs domaines d'horloges tout de même).

      C'est un langage beaucoup plus moderne que VHDL/Verilog qui est nettement moins verbeux et plus facile à factoriser (langage objet, fonctions plus facile à écrire, …).
      Par contre c'est basé sur le scala, qui n'est pas un langage très courant dans le monde de l'embarqué. La courbe d'apprentissage du scala n'est pas forcément très douce pour qui est habitué au C/Python/…

      J'ai plus qu'une balle

    • [^] # Re: Interressant

      Posté par  . Évalué à 2.

      Le concept qu'implémente Chisel est clairement un pas en avant. Après y avoir goûter, il m'est devenu impossible de refaire du VHDL/Verilog tellement ces 2 langages sont primitif et, désolé du terme, "abrutissant".

      Mais Chisel a quand même de gros défaut de conception :
      - Typage faible pour de la conception hardware (auto cast, auto resize), ce qui reporte la découverte de beaucoup d'erreurs de codage à la simulation.
      - Syntax pas top (la déclaration des IO, et d'autres limitation dans l'utilisation de la DSL internes)
      - Support des clock domain pas terrible
      - Pas de réel support pour les énumerations
      - Pas de support pour les attributs Verilogs
      - Impossibilités d'assigner partiellement des signaux combinatoire
      - Affichage des erreurs indéchiffrable (surtout quand on commence a exploiter pleinement les possibilités du langage)
      - Et plain d'autre soucis

      D'un coter Chisel est quel que chose de super enthousiasment, mais d'un autres, c'est dommage de passé du VHDL/Verilog à Chisel, alors que l'idée derrière Chisel aurai clairement pu être bien mieux implémentée.

      Et quand a leur capacités de corriger la plupart de ces problèmes je doute, malgré une troisième itération (Chisel 3.0) la grande majorité des soucis que j'ai eu avec Chisel 2.0 ont persisté.

      Désolé pour tout se pessimisme XD

  • # ARM Bientôt racheté par SoftBank (Japon)

    Posté par  . Évalué à 1.

    Je viens d'apprendre via MacG.co que le japonais SoftBank allait racheter ARM en cash pour $32Mds (!!).
    Son indépendance de fonctionnement est censée être garantie, (et à ce prix là, ils ont intérêt à leur laisser faire leur business!), mais si j'étais client d'ARM comme Apple, Qualcomm ou Broadcom, je ne mettrais pas tous mes oeufs dans le même panier…

    L'émergence d'une nouvelle architecture RISC libre est donc particulièrement intéressante pour le futur de cette famille d'architecture, même si ça lui prendra du temps pour être au niveau des Cortex actuels.

    Pour un SoC complètement libre, il faudrait un GPU libre aussi. Qui connait une initiative comparable?
    Je sais que Broadcom a libéré le blob du GPU du RaspberryPi, mais existe-t-il d'autres initiatives comparable? Ce GPU pourrait d'ailleurs être un bon point de départ non?

    Un SoC entièrement libre serait parfait dans un Raspberry Pi !

  • # Note du workshop

    Posté par  . Évalué à 2.

    Je viens de voir passer les notes prises par lowRISC lors du workshop: http://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/ . Une bonne lecture pour qui veut plus de detail et probablement assez de matiere pour qui aurait envie de faire une news sur le sujet.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.