martoni a écrit 557 commentaires

  • [^] # Re: Certes, mais pour quels usages ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 10.

    L'utilisation en «émulateurs hardware» est loin d'être la première application des FPGA.
    On peut avoir par exemple :

    • Adaptation de périphériques «custom» dans un système embarqué. Certain composant ont des bus de communication non standard, ou nécessite un décodage d'adresse spécifique. Un fpga est parfait pour ça.
    • Ajout de périphérique supplémentaire. Toujours dans le cas de système embarqué, s'il est nécessaire d'avoir une vingtaine de bus série (uart) par exemple il est très difficile de trouver un processeur sur le marché permettant de faire ça. On peut par conséquent les ajouter dans un FPGA. Par exemple, les cartes d'armadeus munies d'un processeur i.MX sont couplées à des FPGA pour les rendre plus flexibles sur les périphériques.
    • génération de signaux, un fpga est tout indiqué quand il s'agit de générer des PWM par exemple au d'autres signaux plus ou moins périodique (pour les écran d'affichage par exemple)
    • Traitement vidéo/signal : beaucoup de FPGA possèdent des multiplieurs câblés ainsi que des blocs de ram intégré. Ce qui permet de faire du calcul/traitement massivement parallèle et reconfigurable à loisir en fonction de «filtres» que l'on souhaite appliqué. La plupart des caméras très haute résolution ou rapide possède des fpgas pour le traitement.
    • Les antennes relais GSM utilisent massivement des fpga pour adapter le décodage des modulations de fréquences.
    • simple décodage logique: les petits fpga (souvent des CPLD d'ailleurs) peuvent être utilisé en lieu et place de quelque portes logique soudées sur pcb. Si l'on a besoin de générer/décoder du manchester par exemple, ou pour faire une machine d'états pour gérer les modes d'un boutons/led.

    J'ai plus qu'une balle

  • [^] # Re: Le rêve

    Posté par  (site web personnel, Mastodon) . En réponse au journal Raspberry-Pi entre dans la fondation Risc-V. Évalué à 5.

    RISC-V et MIPS proviennent du même terreau de Berkley. Ce qui change c'est la date de conception, RISC-V est plus récent et a pu apprendre des erreurs de MIPS (ainsi que de ARM d'ailleurs).

    Je comprend pas vraiment l'argument de la sécurité, en quoi le RISC-V apporterait ou non de la sécurité ?
    Au contraire d'ailleurs le fait d'avoir une ISA ouverte ne peut-être qu'un plus au moins niveau logiciel.

    Avec RISC-V il y a vraiment une volonté de mettre le plus possible d'acteurs du processeur autour de la table pour optimiser l'isa au mieux (par le biais de la fondation). C'est d'ailleurs la raison pour laquelle tout le spectre de l'ISA n'est pas encore stabilisé (Les base RV32E, RV128, et une partie des extensions ne sont pas encore dans leurs version final).

    Et MIPS a été poussé à l'opensource par RISC-V justement.

    J'ai plus qu'une balle

  • [^] # Re: Projet "Libre Silicon" : LSA

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche 2018, l’année de la libération des processeurs ?. Évalué à 3.

    C'est le projet LSA, ils ont déjà fait une présentation à la conférence ORCONF2018 en Pologne. J'ai hâte de voir sur quoi ça débouche !

    J'ai plus qu'une balle

  • [^] # Re: étonnement

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche 2018, l’année de la libération des processeurs ?. Évalué à 10.

    Dire que Risc-V n'a pas la faille est discutable. La faille (meltdown et spectre) dépend de l'implémentation du jeux d'instructions et non du jeux d'instruction lui même.
    En gros ces deux failles sont liées à la capacité des processeurs moderne à pouvoir réordonner les instructions assembleurs «à la volée» pour accélérer l’exécution (out-of-order execution).

    C'est un peu comme dire que le C à des fuites mémoire et des erreurs de débordement de buffer !

    J'ai plus qu'une balle

  • [^] # Re: étonnement

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche 2018, l’année de la libération des processeurs ?. Évalué à 10.

    La campagne de dénigrement d'ARM n'as pas été un échec mais une bourde. Ils n'ont pas mis de temps à virer leurs site internet d'ailleurs, ils ont assez vite compris leur erreur.

    Dans ce genre de cas la «bonne» manière d'aborder le concurrent est de l'ignorer, surtout pas en parler, encore moins le dénigrer ! En tout cas pas quand on est déjà en position dominante.

    J'ai plus qu'une balle

  • [^] # Re: RISC-V

    Posté par  (site web personnel, Mastodon) . En réponse au journal Thales rejoint la fondation RISC-V pour participer à la sécurisation des uProcesseurs open source. Évalué à 8. Dernière modification le 28 novembre 2018 à 14:28.

    Attention, Risc-V n'est pas un processeur mais juste un standard pour le jeux d'instructions (le langage d'un processeur). Libre aux gens d'implémenter ensuite l'ISA (Instruction Set Architecture) comme il le veulent.

    On trouve déjà tout un tas de processeurs basés sur Risc-V, et pas seulement des «soft-core» :

    • E310, U540 de SiFive: Le E310 peut se commander sous la forme du board «arduino compatible». Le 540 est déjà un peu plus cher, mais permet de faire tourner linux sans problème.
    • K210 de Kendryte: un RV64 dual core permettant de faire du traitement vidéo ou du signal.
    • Shakti de la «NASA indienne».
    • GAP8 un proc 9 cœurs pour de l'IoT.
    • certainement plein d'autre qui ne sont pas publique/que je n'ai pas trouvé ;)

    Quand au softcore pour les FPGA il y en a une tripotté.

    J'ai plus qu'une balle

  • # Un nouveau standard ?

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

    Pourquoi est-que je ne peux pas m’empêcher de penser au strip de xkcd en lisant ça ?

    Titre de l'image

    J'ai plus qu'une balle

  • [^] # Re: Ouverture de la carte d'extension ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 5.

    Est-ce que la carte d'extension que tu présente ici est aussi ouverte que le CPU ?

    Nope …

    Par contre c'est un peu un petit nouveau qui arrive sur le marché du FPGA. Certe Microsemi faisait déjà des FPGA avant mais avec le PolarFire ils semblent chercher à venir titiller Altera (pardon Intel) et Xilinx sur leurs milieux de gamme et c'est déjà une bonne nouvelle je trouve.

    À l'heure actuelle il n'existe aucun FPGA avec une documentation ouverte pour les configurer (le bitstream). Il existe cependant des FPGA qui ont été reversés (voir icestorm et SymbiFlow).

    Je connais un seul FPGA libre et avec une chaine de développement complètement libre, mais tu vas être déçu : c'est juste un projet universitaire: Archipelago. Le FPGA en question n’existe pas en silicium.
    Le projet reste intéressant pour maitriser la chaîne de développement complète.

    J'ai plus qu'une balle

  • [^] # Re: Info intéressante, présentée avec du troll que j'aime

    Posté par  (site web personnel, Mastodon) . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 7. Dernière modification le 29 septembre 2018 à 10:18.

    Je trouve ça intéressant qu'on puisse se mettre au RISC-V prochainement. Vivement des cartes grand public, je ne compte pas spécialement me jeter sur 3000€ de matos là tout de suite. :-D

    Risc-V se veut un set d'instructions générique allant du petit micro-contrôleurs low-power au gros super calculateur avec set d'instructions vectorisé.

    Donc si tu veux faire du Risc-V à prix un peu plus raisonnable c'est déjà possible avec le E310 par exemple, et je ne parle pas de la myriade de cores disponible pour FPGA.

    Évidemment tu ne fera pas tourner Linux sur ces petits cores, pour ça il faut soit le silicium de SiFive soit un très gros FPGA pour y synthétiser un core avec MMU.

    J'ai plus qu'une balle

  • [^] # Re: Pourquoi seulement du Verilog synthétisable ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Verilator 4.002. Évalué à 4.

    J'ai rebooté le projet verilator VHDL et je serais curieux d'avoir des testeurs :)

    Cool, il faut que j'aille voir ça !

    J'ai plus qu'une balle

  • [^] # Re: Pourquoi seulement du Verilog synthétisable ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Verilator 4.002. Évalué à 4. Dernière modification le 24 septembre 2018 à 09:14.

    Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux langages ?

    Ça n'est pas vraiment comparable dans la mesure où GHDL est un simulateur «complet» qui simule toute la norme VHDL alors que Verilator se contente de la sous-partie «synthétisable».
    J'avais commencé à faire un comparatif verilator/icarus avec mon projet blp (blinking led project), il faudrait que j'ajoute GHDL au comparatif. Mais je suis certain que GHDL sera nettement plus lent que Verilator, le comparatif Icarus/GHDL serait plus pertinent.

    Il existe un projet d'adapter verilator (verilatorVHDL) pour supporter le VHDL, mais il n'est pas encore abouti à ma connaissance.

    Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il convertit ce code en un objet en C++ et/ou SystemC

    Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-nous limité à du code synthétisable ?

    La différence fondamentale entre un simulateur «normal» et verilator (au dela du fait qu'il ne fasse que convertir le modèle en un objet C++) est qu'il ne gère pas le temps !

    Pour faire tourner le simulateur, on écrit des valeurs sur les ports d'entrées de notre design, on appel la fonction «eval()» qui va évaluer les valeurs de sorties. Puis on recommence.
    C'est à nous de gérer le temps en appelant la fonction eval() à interval régulier. Tous les #xx sont ignorés.

    J'ai plus qu'une balle

  • # Et ORConf 2018 ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un peu d'Open Hardware pour la rentrée (et beaucoup de linuxboot). Évalué à 10.

    Je sais bien que c'est chez les polonais que ça se passe, mais en matière d'open-hardware la conférence ORConf est plutôt un truc important non ?

    Du 21 au 23 septembre à Gdansk.

    C'est là qu'on y découvre tout ce qui se fait en open-source en matière de langages de description Hardware ainsi que tout les outils libre liés aux FPGA/ASIC.
    Et je ne parle même pas des architectures libre (riscv tenant bien sûr le haut du pavé:).

    Pour ceux qui veulent faire de l'open-hardware jusqu'au bout de leurs ongles en silicium.

    https://orconf.org/

    J'ai plus qu'une balle

  • # Un scalaiste qui ne bluff pas ;)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un autre taptempo en Scala. Évalué à 6.

    Merci,

    Je vois qu'on a à faire à un expert en Scala qui ne bluff pas lui !

    J'avoue ne pas comprendre le quart des concepts que tu viens de décrire dans ton journal. De mon coté, TapTempo était mon premier réel programme en Scala.

    Je n'ai fait du scala que pour du HDL jusqu'ici (Chisel).
    Mais pour aller plus loin avec Chisel il est rapidement nécessaire d'apprivoiser les concepts fonctionnel de Scala.

    Voila un programme à décortiquer pour mes vacances.

    J'ai plus qu'une balle

  • [^] # Re: Régionalisation

    Posté par  (site web personnel, Mastodon) . En réponse au journal TapTempo en Scala. Évalué à 2.

    Je pense que c'est possible en effet. Déjà en intégrant les propositions de j_m on devrait pouvoir isoler les données (texte) du code.

    J'ai plus qu'une balle

  • [^] # Re: Faut se calmer, là !

    Posté par  (site web personnel, Mastodon) . En réponse au journal TapTempo en Scala. Évalué à 2.

    J'avoue que je me pose la même question ;)
    Ma fonction faisait 10 lignes, celle-ci en fait 12 !

    Après peut-être y a-t-il une «loi» de séparation du code fonctionnel et des données que je ne respecte pas en effet.

    J'ai plus qu'une balle

  • [^] # Re: Faut se calmer, là !

    Posté par  (site web personnel, Mastodon) . En réponse au journal TapTempo en Scala. Évalué à 2.

    Aucune chances, rien que l'affichage du help fait plus de 5 lignes. ;)

    J'ai plus qu'une balle

  • [^] # Re: Objet et Fonctionnel

    Posté par  (site web personnel, Mastodon) . En réponse au journal TapTempo en Scala. Évalué à 3. Dernière modification le 24 juillet 2018 à 10:03.

    La réponse est oui certainement ;)

    Il serait intéressant de transformer le programme pour qu'il soit plus fonctionnel/objet en effet.

    J'ai plus qu'une balle

  • [^] # Re: Point de vue pragmatique mais

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 1.

    On peut également faire du RUST sans os sur le kit hifive1.

    J'ai plus qu'une balle

  • # Clap de fin

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 8. Dernière modification le 13 juillet 2018 à 08:11.

    Bon le site en question ne sera resté qu'une seule journée en ligne. Arm ayant assez vite compris la bourde ;)
    Du coup le site «concurrent» va lui aussi fermer ses portes ce weekend comme l'indique l'auteur dans un message sur le github.

    C'est un clap de fin pour une histoire qui nous aura fait bien rire.

    On remercie la société Arm d'avoir mis un tel coup de projecteurs sur cette architecture de processeur promise à un bel avenir.

    J'ai plus qu'une balle

  • [^] # Re: Serveur inaccessible

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.

    Y a un responsable com' chez Arm qui a dû se faire virer …

    J'ai plus qu'une balle

  • [^] # Re: Point de vue pragmatique mais

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 8.

    Le Risc-V est déjà dans le kernel Linux mainline. Il existe un proc Risc-V fonctionnant sous Linux (quad-core 64bits + un core «realtime») produit par SiFive (la boite créée par les chercheurs de Berkley): HiFive Unleashed.

    J'ai plus qu'une balle

  • [^] # Re: petite remarque

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10.

    Au contraire, c'est une vrai reconnaissance pour Risc-V !

    J'ai plus qu'une balle

  • # arm-basics.com

    Posté par  (site web personnel, Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10.

    Et le plus beau dans tout ça, c'est qu'ils ont «oublié» d'enregistrer le nom de domaine arm-basics. Du coup il y a une version concurrente du site https://www.arm-basics.com/.

    ARM architecture : Understand the facts

    J'ai plus qu'une balle

  • [^] # Re: xkcdify ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Intégration de TapTempo-Chisel sur APF27. Évalué à 1.

    Tu l'as fait avec quel outil ton diagramme à la xkcd ?

    Comparer mon diagramme à xkcd est un grand honneur ! Mais je ne pense pas lui arriver à la cheville ;)

    Je débute avec ma tablette wacom et j'utilise MyPaint pour gribouiller.

    J'ai plus qu'une balle

  • [^] # Re: clic clac

    Posté par  (site web personnel, Mastodon) . En réponse au journal Intégration de TapTempo-Chisel sur APF27. Évalué à 1.

    Par contre je me suis vautré pour le lien de la vidéo. Le vrai lien vers la vidéo est celui-ci.

    J'ai plus qu'une balle