martoni a écrit 557 commentaires

  • [^] # Re: Valeurs des constantes dans les packages

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

    En réalité, on peut très bien indiquer les valeurs des constantes directement dans le package.

    Faudrait que je retrouve l’info, mais j'étais tombé sur un post qui disait que non. Peut-être une histoire de version du standard, Je vais tester ça tiens.

    J'ai plus qu'une balle

  • [^] # Re: gdevelp et Löve ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal framework de jeu vidéo. Évalué à 2.

    Ce que j'ai trouvé de mieux jusqu'à aujourd'hui c'est un outil (en partie open source, voir totalement j'ai pas vérifié) de Microsoft qui est spécialement conçu pour faire des jeux que l'on peut ensuite mettre sur une mini console de jeu.
    Je l'ai pas pratiqué avec des jeunes, mais en gros c'est un scratch (ça utilise Blockly, la même lib que Scratch) mais avec une lib spécial JV et, cerise sur le gateau, y a moyen de passer en mode éditeur de code. Le langage est un subset de TypeScript et c'est très bien pensé.
    https://arcade.makecode.com/#

    Merci pour cette belle découverte, le principe de pouvoir passer sur une vraie console portable est génial. C'est un truc que je recherche depuis des années (après ça reste à tester bien sûr).

    Ces consoles sont sans doute décrite dans le livre de TkPx «Construisez et programmez votre console de jeux open source» ?

    J'ai plus qu'une balle

  • # TapTempo en raku ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Raku en 2020. Évalué à 5.

    D'après la page du wiki LinuxFr il n'y a pas de TapTempo en Raku.

    Peut-on considérer Raku comme un langage viable s'il n'a pas son TapTempo ? Soyons sérieux.

    J'ai plus qu'une balle.

    J'ai plus qu'une balle

  • [^] # Re: Contexte

    Posté par  (site web personnel, Mastodon) . En réponse au journal Une histoire d'encodage de caractères. Évalué à 5.

    (par contre, titre du journal un peu limite. Ca ne parle pas d'encodage du tout)

    Je me suis dit la même chose. Par contre on parle bien d'un problème de majuscules accentuées ;)

    J'ai plus qu'une balle

  • [^] # Re: le commentaire que Martoni me force à écrire

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un RISC-V sous Linux pour $12.50. Évalué à 5.

    J'ai pris pour habitude de ne plus répondre à chaud aux commentaires un peu trop impulsif comme celui là. D'où mon délai avant de répondre, comme pour le journal précédent. Comme dirait maître Éolas PPPTDT.

    Voici donc l'objet de mon crime :

    «PC de bureau ;) »

    Message qui, je le confesse bien volontiers, est un clin d'œil au débat enflammé sur la définition d'un «PC de bureau» que nous avions eu auparavant. Débats auquel j'ai répondu, (avec retard donc) par un clin d'œil à un précédent message (encore) sur l’intérêt du jeux d'instructions RISC-V. Et j'avoue avoir cherché a chatouiller ton égo, que je ne pensais pas si démesuré !

    Ceux qui écrivent des Journaux ou des dépêches sur LinuxFR le savent bien : il est impossible de les éditer une fois publiées, il faut négocier avec les modérateurs. Modérateurs que je salue et remercie au passage pour le travail formidable qu'ils abattent depuis toutes ces années.

    Donc, étant donné que :
    - je me contre-fiche de la définition d'un «PC de bureau»
    - que je ne tiens pas à déclencher une fatwa contre ma personne.
    - Mon pseudo n'est absolument pas anonyme.

    Serait-il possible à la modération de «caviarder» cette phrase ? Ça doit pouvoir se faire avec des caractères UTF-8 genre comme ça :
    «⬛⬛⬛⬛⬛⬛⬛⬛⬛⬛⬛»

    Mais si ça n'est pas possible je ne leurs en voudrais pas non plus :)

    Et je veux un hélicoptère dans les 10 minutes sinon paf pastèque !

    J'ai plus qu'une balle

  • [^] # Re: Et pendant ce temps à Vera Cruz...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un RISC-V sous Linux pour $12.50. Évalué à 2.

    J'avais bricolé un firmware pour s'interfacer avec le projet LCDProc qui permet d'afficher des informations de monitoring de son PC sur l'écran de la Longan. Si ça t'intéresse le projet est là.

    J'ai plus qu'une balle

  • [^] # Re: quel forceur ce Martoni

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le retour du RiscPC ?. Évalué à 3.

    SiFive a décidé de produire un processeur aux performances compatible avec les performances d'un ordinateur de bureau d'aujourd'hui le U740.
    

    Les perfs d'un processeur AMD ou Intel actuel pour desktop sont quand même bien au-delà. Si tu avais parlé des perfs d'un laptop x86 d'entrée de gamme j'aurais moins sourcillé (même si cette année il y a eu d'énormes progrès) mais là c'est vraiment trop gros comme affirmation.

    Sans vouloir insulter ton intelligence bien sûr. Ne penses tu pas qu'un ordinateur avec un écran, un clavier et une souris permettant de faire de la BUREAUtique, de «surfer» sur le web et regarder des vidéos peut être considéré comme un «ordinateur de bureau» ?

    J'ai plus qu'une balle

  • # git pull -r

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un pull Open Source ?. Évalué à 10.

    Suis-je le seul à avoir lu pull dans le sens git en première lecture du titre ?

    ;)

    J'ai plus qu'une balle

  • [^] # Re: j'ai quelques questions msieur !

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 5. Dernière modification le 26 septembre 2020 à 07:48.

    Néanmoins l'implémentation des bascules m'étonne car on passe dans la même itération le signal dans deux valeurs. Il y a une notion basique que j'ignore.

    Tu veux sans doute parler de ce code :

    /* Synchronize btn_i to avoid metastability*/
    reg btn_old, btn_s;
    always@(posedge clk_i or posedge rst)
    begin
        if(rst) begin
            btn_old <= 1'b0;
            btn_s <= 1'b0;
        end else begin
            btn_old <= btn_i;
            btn_s <= btn_old;
        end
    end

    Toute l'explication se trouve dans l'opérateur d'affectation non bloquante <=. Cet opérateur signifie que l'affectation ne sera effective qu'à la sortie du processus (always@).

    Donc si l'on regarde les deux lignes suivantes :

            // La valeur btn_i n'est pas encore affecté à btn_old
            btn_old <= btn_i;
            // btn_old a ici la valeur de btn_i à l'instant t-1
            btn_s <= btn_old;

    J'ai plus qu'une balle

  • [^] # Re: j'ai quelques questions msieur !

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 6.

    Métastabilité :
    J'ai consulté 'rapidement' l'article et j'ai compris le problème de propagation du signal sur des bascules avec plusieurs clocks dans le système.
    Mais est-ce c'est notre cas ? Tous les signaux clock et pulse ont la même base non ? Ou considères-tu qu'ils peuvent dériver suffisamment pour créer le phénomène ?

    Le signal provenant du bouton n'est pas synchronisé avec l'horloge du FPGA. Il est donc possible qu'un front (montant ou descendant) survienne en même temps que le front montant de l'horloge.

    Or, si cela arrive on viole les temps de setup/hold et le comportement du registre d'entré devient analogique. La valeur de sortie de la bascule va rester dans un état «entre-deux» pendant un temps plus ou moins aléatoire puis elle va basculer vers 0 ou 1. Mais ce temps peut devenir suffisamment long pour que la bascule suivante récupère cette valeurs analogique-instable et la transmette elle même dans tout le design. Cette instabilité sera d'autant plus amplifiée qu'il y aura de la logique entre les deux bascules.

    C'est la raison pour laquelle il est recommandé de mettre deux bascules D en série d'un signal d'entrée qui n'est pas synchronisé avec l'horloge du système. Cela diminue la probabilité de métastabilité, mais ça peut tout de même arriver. Par contre si cette double bascule n'est pas mise, il est à peu prêt certain que l'on aura des problèmes de métastabilité, et le comportement du système sera vraiment bizarre.

    Ma référence sur la métastabilité et le franchissement de domaine d'horloge.

    Calcul bpm : pas suivi le calcul
    MIN_NS 6e10 (1 minute en nanoseconde)
    TP_NS = ??
    Peut-être aussi que btn_per_i est aussi divisé par TP_NS mais cela ne m'a pas paru évident.

    btn_per_i compte le nombre de période de timepulse TP_NS. Une autre manière d'écrire l'équation serait :

    Entrée/sortie de module
    L'entrée de per_count c'est btn_i (qui existait déjà mais est-ce le même), mais la sortie de debounce c'est btn_o.
    J'imagine donc que ces variables sont locales au module.

    Tout à fait, les liens entre les modules se font par les ports que l'on connecte dans le composant «TOP»

    A quel moment se fait le lien entre les Entrées/Sortie des modules ?

    Dans le top qui s'appelle taptempo.

    La connexions du module debounce est donné par le code suivant :

    wire btn_d;
    debounce #(
        .PULSE_PER_NS(TP_CYCLE),
        .DEBOUNCE_PER_NS(20_971_520) // 20ms
        ) inst_debounce (
        .clk_i(clk_i),
        .rst_i(rst),
        .tp_i(tp),
        .btn_i(btn_s),
        .btn_o(btn_d));

    Division :
    Est-ce que tu as essayé de voir ce que ça donnait avec le logiciel de synthèse, ou tu es certains que cela n'en vaut pas la peine et qu'il ne faut jamais compter dessus ?

    J'avoue ne pas avoir essayé, mais je ne suis pas sûr que Yosys aurait suivi. C'est fondamentalement une mauvaise idée de toute manière. Le verilog n'est pas un langage de description «de haut niveau», il faut le voir un peut comme le «langage assembleur» des FPGA. Mais même avec des langages générateurs comme Migen/Chisel/SpinalHDL/Clash/… tu ne fait qu'instancier un «module» de division explicitement. Si l'on veut juste décrire l'algoritme ou le calcul et laisser le logiciel trouver comment l'architecturer il faut passer à la «synthèse de haut niveau».

    Quelque part tu l'as posé le calcul, le logiciel ne peut pas le reproduire ?

    Ça n'est pas le rôle d'un logiciel de synthèse, c'est par contre le rôle d'un logiciel de synthèse de haut niveau dit «HLS» pour High Level Synthesis. Mais dans ce cas on prend carrément un programme en C, C++, Matlab, Python que le logiciel va tenter de convertir en une architecture logiciel+hardware.

    J'ai plus qu'une balle

  • [^] # Re: bon article

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 5.

    Cependant j'ai eu l'impression que les détails et le contexte sont inversés, par exemple tu expliques comment trouver la carte utilisée après avoir donnés des listing de code (je sais on appelle pas ça comme ça en vérilog mais j'ai oublié).
    Et je crois que les explications et exemples de taptempo sont données après ces listings. Perso j'ai pas réfléchi de suite à ce que ça pouvait être et j'ai cherché dans ton article de quoi il en retournait.

    Je parle de la colorlight dans l'introduction. Et l'étape de synthèse vient à la fin dans le développement FPGA. Même si c'est une bonne pratique de tester la synthèse régulièrement sur chaque module, pour être sur que ce que l'on écrit est synthétisable.

    Aussi pour le matériel de brocante que tout le monde n'a pas, on peut très bien le remplacer par un petit bouton poussoir et un simple multimètre numérique, voir couplé avec une capacité pour lisser un peu la pwm, n'est-ce pas ?

    C'est une idée le multimètre numérique en effet, il faudra que j'essaie ;)

    J'ai plus qu'une balle

  • [^] # Re: Chouette article

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 6.

    (un article détaillé sur la colorlight est disponible dans le Hackable 35)

    est sera disponible: teasing sur le sommaire du prochain numéro à paraître?

    Tout à fait ;)

    J'ai plus qu'une balle

  • [^] # Re: À suivre

    Posté par  (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. É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  (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. É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.

    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.

    Parce que tu crois vraiment que les fabricants vont respecter l'ISA à 100% dans leurs produits privateurs?

    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.

    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.

    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: Petite erreur de jugement ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Petite histoire de debug. Évalué à 3.

    Juste au cas où, si quelqu'un a un débuggeur de cerveau, je serais très intéressé pour acheter une licence.

    Ça me fait penser à un bouquin – que je n'ai pas lu – qui est sorti il n'y a pas longtemps : Le bug humain

    J'ai plus qu'une balle

  • [^] # Re: À suivre

    Posté par  (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. Évalué à 4.

    la possibilité d'avoir des instructions 32bit non-alignées avec l'extension C.

    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  (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. Évalué à 7.

    (un "bluepill" STM32 F103 c'est plus de 50 fois moins cher pour des perfs acceptables)

    Gigadevice fait également des RISCV (clone STM32 ;) pour 50fois moins cher. Mais au moins c'est du RISCV.

    et sur l'intérêt de manipuler une ISA qui va certainement évoluer, se spécialiser et se refermer

    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.

    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 les sources (hardware) de l'E310 dont il est question ici c'est par là.

    J'ai plus qu'une balle

  • # Défenseure des droits

    Posté par  (site web personnel, Mastodon) . En réponse au journal J’ai testé pour vous : se faire usurper son identité. Évalué à 9. Dernière modification le 26 juillet 2020 à 11:06.

    Le fait de ne pas pouvoir déposer plainte est clairement une entrave à un droit. Ne faut-il pas saisir la défenseure* des droits pour ça ?

    (* Depuis 4 jours c'est une femme, il parait qu'il faut l'écrire comme ça, mais je suis pas sûr)

    J'ai plus qu'une balle

  • [^] # Re: centre de cout...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 7.

    cout << "Je doit vraiment être drogué! " << endl;
    cout << "La lecture du titre sans l'accent  " << endl;
    cout << "sur le û, m'a d'abord fait penser au" << endl;
    cout << " C++ ..." << endl;
    

    ;)

    J'ai plus qu'une balle

  • [^] # Re: CocoTB + tkinter pour rendre les simulations plus vivantes

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche CocoTB 1.4.0, la maturité. Évalué à 4. Dernière modification le 18 juillet 2020 à 22:43.

    Super, merci pour ce retour d'expérience.
    En ce qui concerne la rapidité d’exécution du simulateur, pour avoir du «temps presque réel» il faut se tourner vers Verilator. C'est du Verilog mais avec l'avancée du plugin yosys-ghdl il doit même être possible d'écrire son composant en VHDL et de le convertir en Verilog.

    Même si pour le moment mes expérimentations de verilator avec cocotb ne sont pas super concluantes niveau temps d'exécution. Je pense que j'ai des configurations à revoir.

    Dans tout les cas, verilator avec un banc de test en C++ est ce qu'il y a de plus rapide sur le «marché».

    J'ai plus qu'une balle

  • [^] # Re: La taille ça compte (ou pas)

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Google libère les ASIC avec un PDK open source en 130 nm. Évalué à 3.

    Martoni a bluffé en faisant une conversion.

    Je n'avais plus qu'une balle ;)

    Merci pour toutes ces précisions. Après si AMD fait appel à TSMC en 7nm, dire qu'AMD «grave en 7nm» n'est pas non plus totalement du bluff (pour intel j'ai fait un raccourci un peu rapide). Sachant que si l'on réuni TSMC et GlobalFoundry on obtient à peu près la totalité de la production de semiconducteurs mondiale.

    Si j'ai bien tout suivi d'ailleurs, efabless fait fabriquer chez GlobalFoundry.

    J'ai plus qu'une balle

  • [^] # Re: La taille ça compte (ou pas)

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Google libère les ASIC avec un PDK open source en 130 nm. Évalué à 3.

    C'est AMD qui produit en 7 nm

    Bien vu, si un des modérateurs peux amender la dépêche je veux bien ;)

    Mais l'idée reste là : le 130nm c'est quand même beaucoup plus gros que les processeurs du marché aujourd'hui.

    J'ai plus qu'une balle

  • [^] # Re: Un pt'it beurre des touyou ...

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Vingt‑deux ans de LinuxFr.org. Évalué à 5.

    Bon anniversaire LinuxFR.
    Et je ne bluff pas.

    J'ai plus qu'une balle

  • # Le bébé de Antmicro et Quicklogic aidé par Google

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche EOS S3, le bitstream libéré !. Évalué à 4. Dernière modification le 17 juin 2020 à 09:26.

    Je ne l'ai pas dit dans la dépêche, mais l'entreprise qui est derrière ce nouveau produit est Antmicro. Une entreprise qui fait de la conception FPGA/ASIC à base de logiciel libre.
    Il semble également qu'ils aient été aidé par google.

    Le communiqué de Antmicro.

    Et en plus du EOS S3, Quicklogic lance une gamme de FPGA «discret» : le PolarPro 3E. Également basé sur une chaîne de développement libre \o/

    J'ai plus qu'une balle

  • [^] # Re: Nouveauté ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche EOS S3, le bitstream libéré !. Évalué à 4.

    Oui ça existe depuis un certain temps maintenant.
    Il y a la série des PSoC de cypress qui a son petit succès dans le genre. Mais évidemment c'est du soft proprio (et que sous windows il me semble).

    J'ai plus qu'une balle