Fabrice Mousset a écrit 63 commentaires

  • # VHDL vs Verilog pour les FPGA

    Posté par  (site web personnel) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 5.

    VHDL ou Verilog, en ce qui concerne les FPGA c'est bonnet blanc et blanc bonnet ;)

    Les deux sont des langages créés pour décrire des circuits électroniques pour permettre la simulation par un outil informatique.
    Ils ont ensuite été utilisés de façon détournée pour faire de la synthèse pour concevoir des configurations pour des composants programmables tels que les CPLD et FPGA. Ceci en remplacement de divers langages propriétaires (en gros, chaque fabricant de circuit programmable avait son propre langage!).

    Pourquoi les deux existent? C'est en partie à cause du département de la défense américaine (les mêmes qui ont conçu ARPANET, la base de notre Internet actuel).
    A la base seul Verilog existait, ce un langage de description de circuit électronique (HDL) propriétaire a été développé par Cadence, qui vendu des licences (très onéreuse) aux sociétés et ou universités américaines en priorité.
    L'US Army arrivait à un moment où ces crédits commençaient à fondre comme neige au soleil et avait besoin d'un outil pour faire le trie dans les différents projets électroniques qui étaient en sous-traitance.
    Comme Verilog était très cher et qu'ils ne pouvaient pas vraiment l'imposer à leur sous-traitant, ils ont préféré faire appel à leur service d'ingénierie interne pour concevoir cet outil, et c'est là que le VHDL a été conçu (sur la base du langage ADA qui était en vogue à ce moment là).
    Et comme tout ceci c'est fait sur des crédits publiques, l'ensemble des spécifications de ce langage ont été publiés pour normalisés. Et les sous-traitants n'avaient pas d'excuse pour le pas fournir de description VHDL de leur produit pour permettre leur évaluation.

    Dans l'intervalle, les grosse sociétés américaines d'électronique ainsi que les grosse université ont déjà massivement investi dans les licences Verilog de Cadence pour pouvoir faire de la simulation de circuits électronique. Par contre Cadence avait plus de mal pour vendre ces licenses sur le "vieux continent".
    Et l'apparition du langage VHDL a été vue comme une bonne opportunité pour entrer dans le domaine de la simulation des circuits électronique avec un ticket d'entré moins onéreux.

    Cadence voyant le vent tourner pour son langage c'est empressé de faire également certifié sont langage par IEEE (comme le VHDL).

    Et voilà comment on se retrouve avec 2 langages pour faire en gros la même chose ;)

    Et comme aux US Verilog était déjà bien implanté, il est resté le langage de prédilection alors qu'en Europe c'est le VHDL qui avait déjà un train d'avance.

    Bref, cela n'a rien à voir avec les possibilités ou les performances supposés de chaque langage… C'est comme toujours, juste une histoire de gros sous :D

  • [^] # Re: Avantages de l'ASIC

    Posté par  (site web personnel) . En réponse à la dépêche Un ASIC conçu intégralement avec des logiciels libres. Évalué à 8.

    En fait un ASIC n'a rien a voir avec un FPGA.
    Pour faire une analogie informaticienne, cela revient à comparer de la ROM (ASIC) avec de la RAM (FPGA).

    Un ASIC c'est un design de logique programmable qui est défini et figé une fois pour toute. Tous les éléments de logique sont placés une fois pour toute avant de partir en gravure. On a ainsi un composant beaucoup plus rapide et avec une consommation énergétique beaucoup moindre qu'avec un FPGA.
    Par contre, une fois le design gravé… et bien il est ce qu'il est… pas moyen de changer quoi que ce soit. En cas de bug, il va falloir créer un nouvel ASIC… Bref c'est reparti pour quelques k€ !

    Un FPGA, pour faire simple (attention c'est vraiment très grossier), c'est une matrice de plusieurs millier d'éléments logiques identiques ainsi qu'un ensemble "routes" qui quadrillent les éléments logiques. Lorsque l'on créer une design FPGA, on ne fait que définir les interconnexions entre les éléments logiques. Bref, le chemin entre les éléments pourra être plus ou moins long… et donc plus ou moins rapide. De plus tous les éléments logiques sont tjrs présent… Donc ils consomment de l'énergie même s'ils ne sont pas utiles pour le design.
    L'avantage, c'est que l'on peut changer le design plus ou moins à volonté.

    Ceux sont vraiment 2 mondes différents, qui ne font que partager un certain nombre d'outils.

  • [^] # Re: installation

    Posté par  (site web personnel) . En réponse à la dépêche Collaboration laborieuse ? Si les symptômes persistent, installez Tracim 2.1 !. Évalué à 7.

    Je pense que cela ne concerne que le dépôt Git.
    La branche "develop" est, comme son nom l'indique, la partie active qui reçoit toutes les modifications avant la création d'une version stable.

    Les versions stables se trouvent sous "releases" ==> https://github.com/tracim/tracim/releases

  • [^] # Re: Un nouveau standard ?

    Posté par  (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3. Dernière modification le 08 octobre 2018 à 16:47.

    On est d'accord ;)

    Mais ça c'est la liberté de chacun de choisir l'environnement et les outils de développement qui lui conviennent le mieux.
    Mais ça c'est un autre débat!

    Si meson ou CMake s'imposent tout doucement comme outils de développement pour les projets d'envergures, c'est parce qu'ils répondent à un besoin de performance de compilation.
    Et si cela se poursuit, l'utilisation des autotools ne sera plus qu'un lointain souvenir… tout comme CVS et d'autres outils de dev.

  • [^] # Re: Un nouveau standard ?

    Posté par  (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à -2.

    Si on compile à partir des sources (ce qui est le cas ici) avec ./configure && make && make install, les autotools doivent être installés sur la machine…
    sinon ./configure ne fonctionnera pas!

    Où alors j'ai rien compris :(

  • [^] # Re: Un nouveau standard ?

    Posté par  (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 1.

    Tu trouves "normal" d'utiliser ./configure && make && sudo make install pour installer un logiciel que tu compiles à partir de ces sources… mais avant de pouvoir faire cela, il t'a bien fallut installer un tas d'outils (en particulier les autotools, make, gcc, etc.)
    ET que le dit projet utilise les autotools.

    Pour compiler un projet qui utilise meson (ou CMake), et il te faudra installer meson (ou CMake) ainsi que ninja et python3.
    Et puis faire quelque chose dans le genre meson /sources /builddir && ninja -C /builddir -jxx && sudo ninja -C /builddir install

    Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.

    Le but, c'est de faire gagner du temps aux personnes qui sont obligées de faire plusieurs itérations (packaging, tests, etc.).
    Le but de Meson n'est pas forcément de faire autrement que autotools + make, mais de le faire le plus rapidement possible. Pour simplifier la vie des intégrateurs/testeurs/développeurs.

  • [^] # Re: Un nouveau standard ?

    Posté par  (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 6. Dernière modification le 08 octobre 2018 à 10:44.

    Hmmm, pas vraiment d'accord.

    Meson ne prétends pas être un nouveau standard mais réponds à un besoin qui est de rendre la compilation de gros projets plus rapide en évitant/supprimant les outils devenu trop lourds de part l'historique qu'ils sont obligés de traîner avec eux.

    Comme tout nouvel outil, il n'est pas parfait et ne répondra sans doute jamais à tous les besoins. Mais il a le mérite d'apporter une réponse à ce problème (tout comme CMake).

    Pour le commun des mortels, ce n'est qu'anecdotique, mais quand on travail sur un projet avec beaucoup de dépendances et options, gagner quelques minutes par compilation ce n'est pas négligeable quand on est obliger de faire plusieurs compilations par jour

  • [^] # Re: Pour Wayland

    Posté par  (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 4.

    Je pense que tu fais référence au problème de plantage récurrent de Gnome Shell qui sous Wayland se termine en clôture de la session parce que Gnome Shell est un composeur. Il me semble que des travaux sont en cours sur Wayland pour prendre en charge ce type de problème, et ainsi ne pas perdre la session complète lors d'un plantage du composeur. Je suis désolé, mais je n'arrive pas à trouver un lien potable :(

  • # Petit boulette sur le dernier lien

    Posté par  (site web personnel) . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés du mois d’octobre 2017. Évalué à 3.

    un petit message pour le modérateur, le lien de l'article d'Adrien (Une carte des caméras de surveillance basée sur OpenStreetMap) n'est pas valide.
    Il y a une virgule qui traine…

  • [^] # Re: 4.11

    Posté par  (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.10. Évalué à 10.

    Moi, ce que je trouve navrant, c'est ce genre de commentaire qui prends les contributeurs de haut.

    Ces personnes ont sacrifié de leur temps libre pour rédiger avec soin cette news très technique sur un sujet relativement complexe.

    Certes, il est dommage que la parution de la news tombe alors qu'une nouvelle version du noyau est déjà publié, mais cela ne retire en rien la qualité du travail fourni.

    D'ailleurs une news pour le noyau 4.11 est encours de rédaction, je suis certains que les rédacteurs de celle-ci seraient très content de toute aide pour la finir avant la publication des sources du prochain noyau!

    http://linuxfr.org/redaction/news/sortie-du-noyau-linux-4-11

  • [^] # Re: Je ne suis pas sur de comprendre

    Posté par  (site web personnel) . En réponse à la dépêche PikoPixel, éditeur de « pixel art ». Évalué à 2.

    Hmm j'ai un peu de mal à y croire
    selon element14

    • RPI 1: 2 BogoMips
    • RPI 2: 57 BogoMips
    • RPI 3: 76 BogoMips
  • [^] # Re: Tout l'inverse du soft !

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Chisel 3, un langage de description matériel basé sur Scala. Évalué à 8.

    Les concepts synchrone/asynchrone dans le monde hardware n'ont rien à voir avec le monde du software.
    On est ici dans le monde HW et il faut donc penser en terme de HW et non SW.
    Je vais essayer de donner quelques clés sans entrer trop dans les détails.

    Quand on parle de systèmes synchrones en HDL, on parle de design qui sont "sensibles" à une (ou plusieurs) horloges. Cela veut dire que l'état des sorties du système vont changer après un front (en général montant) de l'horloge. Le reste du temps les sorties sont stables (sinon on a un problème ;-) ).
    Ceci est très vrai pour les circuits programmables type FPGA. Les FPGA sont des circuits avec une structure bien particulière, basée sur des blocs élémentaires très simples composés: d'une LUT (Look-Up Table => table de vérité), d'un inverseur, d'un multiplexeur et d'une bascule D (mémoire synchrone 1 bit). Cette structure très simple est la force des FPGA parce qu'il est plus facile de produire un circuit intégrer graver très finement (28nm pour les CycloneV Alera) avec une structure répétitive qu'un circuit avec une structure plus complexe (tels que les CPLD).

    La conception d'un design FPGA passe par plusieurs phases:
    1. la description du design à l'aide d'un langage HDL
    2. la synthèse du design qui consiste à extraire de la description une "netlist" qui correspond à l'interconnexion des éléments HW (bascules, inverseurs, multiplieurs, etc.)
    3. Le placement/routage ou l'on va tenter de placer les éléments de la netlist dans le FPGA
    4. L'analyse de timing, qui est une étape essentielle qui consiste à s'assurer que les contraintes de temps seront respectées par le design générer.

    Le point dur d'un design est en général l'étape 4, en effet pour que le design soit stable, il faut que les bascules D soit toutes bien utilisées. Il faut que le signal soit présent à l'entré de la bascule un certain temps avant le front actif de l'horloge (setup time) et reste stable un certain temps après le front actif (hold time). Et ceci pour toutes les bascules D utilisées par le design.

    J'espère ne pas avoir été trop brouillon dans mes tentatives d'explication.

  • [^] # Re: HTML5 n'est que le rendu, il te faut le calcul et les interactions

    Posté par  (site web personnel) . En réponse au message Cherche alternative crédible à Adobe Flash. Évalué à 1.

    Je ne vois pas où tu veux en venir.
    Mais si c'est là ta question, oui c'est moi qui fait le développement.

    Et pour être honnête, le problème n'est pas là, mais qu'elle alternative "crédible" y a-t-il à Adobe Flash pour faire quelque chose de semblable.

    C'est là ma question. Je cherche à remplacer la technologie Flash par autre chose pour gagner en pérennité parce que du fond de ma grotte, je vois bien que Flash n'a pas/plus d'avenir.

  • [^] # Re: HTML5 n'est que le rendu, il te faut le calcul et les interactions

    Posté par  (site web personnel) . En réponse au message Cherche alternative crédible à Adobe Flash. Évalué à 1. Dernière modification le 29 octobre 2016 à 11:56.

    Non, les apprenants utilisent le matériel pédagogique pour "apprendre", en l’occurrence des langues (anglais, allemand, etc.)

    Mais comme le matériel pédagogique se trouve en ligne, il faut l'outil informatique pour y accéder. Et cet accès se doit d'être simple pour ne pas être un frein à l'apprentissage.

    Pourquoi utiliser scratch? Si j'ai bien compris le projet, il se base sur Adobe Flash (https://scratch.mit.edu/help/faq/)!

    Donc, retour à la case départ avec Adobe Flash…

  • [^] # Re: Flash est en effet mort, en tous cas sur le web.

    Posté par  (site web personnel) . En réponse au message Cherche alternative crédible à Adobe Flash. Évalué à 1.

    Merci pour le retour très complet!

    Pour commencer, oui je suis développeur dans l'âme… et professionnel, mais pas vraiment dans les "technologies WEB".

    Je suis plus orienter C/C++ et logiciels embarqués (de WinCE à Linux, en passant par Android). Et depuis quelques années avec des zestes de Qt5.

    Bref, le développement "Bureau" pourquoi pas, mais ça engendre en général plus de problèmes que de solutions… Le premier étant l'installation et la mise à jour.
    C'est pour cela que je cherche quelque chose d'accessible "en ligne".
    Qui est plus dans l'air du temps, de nos jour, on est plus branché smartphone/tablette que PC.

    C'est aussi pour cela que je voudrai m'orienter vers le HTML5. Mais je suis conscient que cela veut tout et rien dire à la fois.

    Ce que je veux réussir à faire, c'est des modules thématiques avec des animations intégrées (pour l'autocorrection d'exercices), de jolies images avec des textes et des contenus audio synchronisés avec les textes correspondants.

    Bref, tout ce que je fais déjà avec Flash/ActionScript mais en mieux… Si possible sans avoir à réinventer la roue et passer 1 mois pour construire un exercice!
    Après il faut pouvoir faire un "package" pour lequel je puisse affecter un accès sécurisé parce que ce que je cherche à produire c'est à but commercial.
    Tous les contenus ont été créés de toute pièce par ma femmes, avec enregistrement des textes par un studio professionnel, illustration, etc.
    Bref ça a coûter un bras, et c'est très orienté "business" et clientèle professionnel.

  • [^] # Re: HTML5 n'est que le rendu, il te faut le calcul et les interactions

    Posté par  (site web personnel) . En réponse au message Cherche alternative crédible à Adobe Flash. Évalué à 1.

    Merci pour le retour,

    bien évidement c'est la partie "mise à disposition" qui m'inquiète le plus.

    Les apprenants qui vont devoir utiliser le matériel pédagogique ne sont pas des geeks, encore moins des pros "logiciel libre"/"open source".
    Ce qu'ils veulent c'est travailler avec, un point c'est tout.
    La partie technique n'intéresse personne. Le seul critère est fonctionne/fonctionne pas!

    C'est dur, mais c'est comme ça.

    Bref, il faut quelque chose que tout le monde peut accéder/utiliser sans se prendre la tête.
    Et pour ça, Flash c'était vachement pratique. Même si techniquement ce n'est/était la panacée (je reste poli).

  • [^] # Re: Libre ?

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de la version 0.4 de Drone. Évalué à 1.

    Les sources sont sur github ==> cf. le 3ième lien de l'article

  • [^] # Re: Supports accessibles?

    Posté par  (site web personnel) . En réponse à la dépêche Meetup sur la gestion des flashs NAND dans Linux le 23 juin 2015 à Toulouse. Évalué à 1.

    Merci pour l'info, je vais voir ça tout de suite :)

    PS: Il y en a de la doc chez Free Electron! Merci pour cette mine d'informations.

  • # Supports accessibles?

    Posté par  (site web personnel) . En réponse à la dépêche Meetup sur la gestion des flashs NAND dans Linux le 23 juin 2015 à Toulouse. Évalué à 3.

    Le sujet de la conférence m'intéresse fortement mais Toulouse est trop loin de chez moi pour que je puisse y participer :(

    Est-ce qu'il est prévu de mettre en ligne le(s) support(s) de cette conférence, ou peut-être même un flux vidéo?

  • # Merci

    Posté par  (site web personnel) . En réponse à la dépêche Publication de supports de formation sur Buildroot. Évalué à 6.

    Merci pour ce support complémentaire au manuel de Buildroot.
    Et merci également pour la mise à disposition de celui-ci et pour votre travail sur BuildRoot.

    Buildroot un merveilleux outil qui mérite à être plus connu. Il est certainement moins "eye candy" que Yocto mais permet de construire un système clé en main de taille réduite sans trop se prendre la tête.

    Je suis fan!

  • # Un peu réducteur comme raisonnement...

    Posté par  (site web personnel) . En réponse au journal Enfin une chaîne de développement complètement open source pour un FPGA. Évalué à 5.

    Bon, je ne vais pas me faire des amis… Mais tampis, je me lance.
    Ayant travaillé pendant plusieurs années avec des FPGA de divers sortes, surtout ceux de chez Altera, je me doit de réagir sur cette news.

    Tout d'abord je suis heureux d'apprendre qu'un logiciel libre de ce genre existe et je félicite les auteurs pour leur travail et leur engagement. Ce n'est pas un travail simple.

    Après, je ne suis pas du tout de l'avis de l'auteur de la news pour dire que les logiciels privateurs fournis par les fondeurs sont mauvais, bourrés de bug, etc. Je suis même plutôt de l'avis inverse. Xilinx a longtemps eu la réputation de fournir une suite logicielle pas trop terrible mais à pris un assez bon virage depuis ces 5 dernières années. Pour ce qui est d'Altera, je n'ai jamais hésité avant d'installer une mise à jour de leur suite de développement, c'est dire ce que je pense de la qualité de leur logiciels ;-) Après les autres, qui ne ramassent que les miettes et son dans des secteurs de niche, il n'est pas évident d'avoir une suite de bonne qualité.

    Et il ne faut confondre logiciel libre et qualité/stabilité. L'un ne vient pas forcément avec l'autre! Ca serait trop simple.

    Après, il faut comprendre pourquoi tout est aussi cloisonné. Quoi qu'on en dise, le secteur des FPGA/CPLD est un secteur très réduit et les coûts de développement (R&D+production) sont énormes. Les FPGA sont souvent précurseurs dans divers procédés de fabrication. Avoir un retour sur investissement n'est pas une chose simple.
    Le nerf de la guerre se situe au niveau des outils de placement routage et d'analyse de timing qui nécessitent une parfaite connaissance de la structure même du FPGA et des temps de propagation des signaux entre les différents blocs du FPGA. Caractériser un FPGA pour ces outils là, demande beaucoup de temps et de travail et donc d'argent. Donc donné cela en libre accès, c'est donné également beaucoup d'informations sensibles aux concurrents, et donc un peu joué avec la santé de l'entreprise.

    Après que cela soit frustrant pour un libriste convaincu je le conçoit aussi ;-)

  • [^] # Re: Du bon usage de la langue (laissé en exercice au lecteur)

    Posté par  (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.0. Évalué à 10.

    Sans vouloir jeter de l'huile sur le feu ou blesser qui que ce soit, la langue française a piqué bcp de mots du grec et du latin, dont certains sont entrés dans l'usage "courant".

    Même si incipit et prologue semblent sémantiquement identiques, le second est beaucoup plus usuel et donc moins perturbant et n'aurait pas obligé l'ajout un lien Wikipedia pour tenter d'en expliquer le sens.

    C'est un peu dommage de complexifié la lecture d'un article déjà hautement technique par une sémantique un peu trop "élitiste".

    Mes 2cts d'Euro.

  • [^] # Re: Du bon usage de la langue (laissé en exercice au lecteur)

    Posté par  (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.0. Évalué à 3.

    Moi je doit avoué que j'ai également beaucoup de mal avec certaines expressions qui sont passées dans l'air du temps… La pire pour moi c'est expérience utilisateur et toutes ses dérivées.

    Mais je dois avouer que incipit c'est pas mal non plus… Prologue ça doit faire trop vieux ;-)

  • [^] # Re: Merci beaucoup

    Posté par  (site web personnel) . En réponse à la dépêche Publication de supports de formation Yocto Project et OpenEmbedded. Évalué à 1.

    Oui, je suis à 100% d'accord.
    Yocto/OE c'est super si on veut faire une sorte de distribution Linux avec paquets pour permettre l'installation/désinstallation "facile" par l'utilisateur final.
    Comme sur une distribution PC "classique". Bref, cela n'a plus grand chose à voir avec de l'embarqué à mes yeux… Mais je suis certainement trop sectaire/strict.
    C'est sans aucun doute un superbe outil pour des projets de cartes "grand public" comme la RaspberryPi, BeagleBone, etc.
    Lorsque l'on cherche à faire un système "industriel", Buildroot est plus adapté

    Pour le troll, ça peut se faire, mais il faudrait sans doute attendre jusqu'à vendredi pour ne pas bousculer les habitudes ;-)

  • # Merci beaucoup

    Posté par  (site web personnel) . En réponse à la dépêche Publication de supports de formation Yocto Project et OpenEmbedded. Évalué à 3.

    J'ai moi-même suivi une formation Free Electrons / "Embedded Linux" à Lyon avec Grégory Clément (qui était sur le point de devenir papa). J'en garde un très bon souvenir. Ces 3 jours de formation m'ont beaucoup apporté sur la compréhension de la mise en oeuvre de Linux dans le monde embarqué.

    Le support est une chose, et il est de qualité, mais c'est surtout les échanges avec les formateurs et leurs réactivités qui font la force d'une formation (oui le dernier jour a été assuré par un autre formateur, le bébé ne voulait plus attendre ;-) ). Sur ce point chapeau bas, je n'ai pas été déçu!

    Merci pour ces slides sur Yocto, je vais y jeter un oeil à l'occasion, mais je doit avouer que je suis plus fan de Builroot qui, à mes yeux, est plus simple à mettre en oeuvre et moins gourmand en ressources (niveau machine de "build") que Yocto.

    Fabrice