Merci pour cette belle introduction à la longan nano. Juste pour préciser, avec 5€ (en fait $4.90) on a aussi l'écran (RGB), c'est pas en option !
Et l'usb est dans le microcontrôleur contrairement à beaucoup de kit de ce type, il n'y a pas de «ftdi» à côté pour faire de la conversion usb-uart ou usb-gpio.
L'histoire du SysTick est visiblement une histoire de copier/coller de ARM. En fait le GD32VF103CBT6 de Gigadevice est un copier-coller de leur microcontrôleur GD32E103CBT6 dont ils ont juste changé le cœur pour mettre un processeur de type Risc-V (Bumblebee).
Et ils ont fait pareil pour leurs base de code !
Tout le code fourni initialement en tant que librairie était en fait le code de leur microcontrôleur ARM. À la lecture de l'article il semble que ce code se soit amélioré, mais à l'époque faire fonctionner l'USB (pour en faire un périphérique afficheur de stats pour mon pc) n'était pas une mince affaire.
À l'origine, le SysTick est du pur standard ARM, qui ne peut être présent dans un processeur Risc-V. Comme la doc était du copié collé, c'est resté (du moins au début).
En fait, le standard Risc-V décrit des registres mstatus, mtimecmp, … qui sont accessibles via le CSR (Control Status Register). On ne peut pas lire/écrire ces registres via les instruction classiques load/store. Il faut utiliser les instructions spécifiques riscv csrrx.
Il est donc impossible que le code ARM soit le même que le code RISC-V puisque se sont des instructions assembleur différentes, et il à donc fallu retoucher leur base de code.
D'après ce que j'ai pu regarder ce matin c'est plutôt facile à faire en fait.
Pour les photos et vidéos, comme l'a dit mihkeulbody, elles se trouvent déjà dans la mémoire du téléphone. De plus comme je n'avais pas assez de mémoire sur mon téléphone j'avais déjà transféré le stockage sur une carte microSD.
Pour la partie discussions il est possible de simplement se les envoyer par mail grâce à la fonction exporter dans l'appli téléphone (visiblement l'appli web n'a pas l'option par contre).
La discussion est envoyée au format texte brute et parfaitement lisible avec n'importe quel éditeur.
Ok, je vais améliorer le dépots et essayer d'être un peu plus concis. Si on peut limiter la verbosité c'est toujours mieux. Déjà pour le «top» arrêté de déclarer les modules avant de les instancier en utilisant «work.*» ce qui allège grandement le code.
Pour les constantes dans les packages il est possible que j'ai lu de travers, je vais essayer de retrouver le post.
C'est malin, à cause de toi j'ai commandé une ColorLight au père noël!
Hé hé, bienvenu au club alors ;)
Je dirais aussi qu'il serait sans doute mieux de remplacer le bloc debounce par une capa sur l'entrée (avec une petite résistance en plus), mais bon quand on se permet de remplir 3% du FPGA à toi tout seul, ça donne pas envie d'enlever des morceaux.
Oui le FPGA de la colorlight est absolument monstrueux pour le prix (15$). On peux même y fourrer 55 cores RISC-V (Bon un SERV, qui est un processeur très spéciale car sérialisé).
Bon sinon, pour continuer le troll la discussion démarré dans la rédaction, j'ai remplacé pour les signaux divisor, remainder et quotient le type en unsigned et le code est un peu plus simple (non le VHDL n'est par verbeux. Bon enfin si, mais moins), et chez moi ça marche™ (enfin ça compile et synthétise).
J'avoue qu'il faut que je me décrasse un peu plus du VHDL, visiblement y a plus simple que mes vieux std_logic_vector. J'ai testé les unsigned suite à ta remarque mais j'ai du faire un truc de travers, je regarderais à nouveau. Si on peut rendre le VHDL moins verbeux il faut pas hésiter.
Il ne faut pas hésiter, à me faire des pull-request pour améliorer le projet.
J'avais également l'intention d'écrire un tap-tempo en VHDL afin de le proposer en exercice à mes étudiants.
Il y a d'ENSTAB qui vient de «sortir» un kit virtuel utilisant l'interface vpi de GHDL. Je ne l'ai pas testé mais TapTempo en vhdl sur ce kit pourrait être un défi rigolo ;)
Même si les kits de développement sont de moins en moins cher, ça permet de se faire la main rapidement sans attendre son colis.
je préciserais qu'on est tout à fait libre de choisir la structuration de son circuit.
Je voulais surtout parler de la structuration en blocs connectés entre eux que l'on retrouve très fréquemment en VHDL (mais en Verilog aussi)
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.
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).
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 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'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à.
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» ?
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*/regbtn_old,btn_s;always@(posedgeclk_iorposedgerst)beginif(rst)beginbtn_old<=1'b0;btn_s<=1'b0;endelsebeginbtn_old<=btn_i;btn_s<=btn_old;endend
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_oldbtn_old<=btn_i;// btn_old a ici la valeur de btn_i à l'instant t-1btn_s<=btn_old;
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.
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 ?
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.
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 ;)
Ç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 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 ?
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.
# La vérité sur le SysTick
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Prise en main de la carte Longan Nano RISC-V de Sipeed. Évalué à 2.
Merci pour cette belle introduction à la longan nano. Juste pour préciser, avec 5€ (en fait $4.90) on a aussi l'écran (RGB), c'est pas en option !
Et l'usb est dans le microcontrôleur contrairement à beaucoup de kit de ce type, il n'y a pas de «ftdi» à côté pour faire de la conversion usb-uart ou usb-gpio.
L'histoire du SysTick est visiblement une histoire de copier/coller de ARM. En fait le GD32VF103CBT6 de Gigadevice est un copier-coller de leur microcontrôleur GD32E103CBT6 dont ils ont juste changé le cœur pour mettre un processeur de type Risc-V (Bumblebee).
Et ils ont fait pareil pour leurs base de code !
Tout le code fourni initialement en tant que librairie était en fait le code de leur microcontrôleur ARM. À la lecture de l'article il semble que ce code se soit amélioré, mais à l'époque faire fonctionner l'USB (pour en faire un périphérique afficheur de stats pour mon pc) n'était pas une mince affaire.
À l'origine, le SysTick est du pur standard ARM, qui ne peut être présent dans un processeur Risc-V. Comme la doc était du copié collé, c'est resté (du moins au début).
En fait, le standard Risc-V décrit des registres
mstatus,mtimecmp, … qui sont accessibles via le CSR (Control Status Register). On ne peut pas lire/écrire ces registres via les instruction classiquesload/store. Il faut utiliser les instructions spécifiques riscvcsrrx.Il est donc impossible que le code ARM soit le même que le code RISC-V puisque se sont des instructions assembleur différentes, et il à donc fallu retoucher leur base de code.
J'ai plus qu'une balle
# c'est relativement simple en fait
Posté par martoni (site web personnel, Mastodon) . En réponse au message Récupérer l'intégralité de ses données (discussions, image, vidéos, ...) Whatsapp sous Linux. Évalué à 3. Dernière modification le 09 janvier 2021 à 15:53.
D'après ce que j'ai pu regarder ce matin c'est plutôt facile à faire en fait.
Pour les photos et vidéos, comme l'a dit mihkeulbody, elles se trouvent déjà dans la mémoire du téléphone. De plus comme je n'avais pas assez de mémoire sur mon téléphone j'avais déjà transféré le stockage sur une carte microSD.
Pour la partie discussions il est possible de simplement se les envoyer par mail grâce à la fonction exporter dans l'appli téléphone (visiblement l'appli web n'a pas l'option par contre).
La discussion est envoyée au format texte brute et parfaitement lisible avec n'importe quel éditeur.
J'ai plus qu'une balle
# Un beau défis en perspective
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 2.
J'aime beaucoup se genre d'idée :) Je trouve ça presque poétique.
J'ai plus qu'une balle
[^] # Re: direction
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Un ami a la carte. Évalué à 3.
Pareil !
Je suppose qu'une des deux roues est libre par rapport à l'axe ?
J'ai plus qu'une balle
[^] # Re: Rhaaaaaaaaaaa! Honte à toi!
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 2.
Merci, ça fonctionne bien. Je ne sais pas ce que j'avais bidouillé pour que ça déconne.
C'est commité.
J'ai plus qu'une balle
[^] # Re: Rhaaaaaaaaaaa! Honte à toi!
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 3.
Bon évidemment il faut ajouter les frais de port, mais sur aliexpress on est même à un peu moins de 15$. La mienne était bien à 15$.
Il faut une sonde jtag. Perso j'en ait une à environ 10$, mais il est visiblement possible de faire la même chose avec la bluepills qui est à environ 2$.
Il y a déjà celui de Hackable 35.
J'ai plus qu'une balle
[^] # Re: Valeurs des constantes dans les packages
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 2.
Ok, je vais améliorer le dépots et essayer d'être un peu plus concis. Si on peut limiter la verbosité c'est toujours mieux. Déjà pour le «top» arrêté de déclarer les modules avant de les instancier en utilisant «work.*» ce qui allège grandement le code.
Pour les constantes dans les packages il est possible que j'ai lu de travers, je vais essayer de retrouver le post.
J'ai plus qu'une balle
[^] # Re: Rhaaaaaaaaaaa! Honte à toi!
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 3. Dernière modification le 18 décembre 2020 à 20:49.
Hé hé, bienvenu au club alors ;)
Oui le FPGA de la colorlight est absolument monstrueux pour le prix (15$). On peux même y fourrer 55 cores RISC-V (Bon un SERV, qui est un processeur très spéciale car sérialisé).
J'avoue qu'il faut que je me décrasse un peu plus du VHDL, visiblement y a plus simple que mes vieux
std_logic_vector. J'ai testé les unsigned suite à ta remarque mais j'ai du faire un truc de travers, je regarderais à nouveau. Si on peut rendre le VHDL moins verbeux il faut pas hésiter.Il ne faut pas hésiter, à me faire des pull-request pour améliorer le projet.
J'ai plus qu'une balle
[^] # Re: Quelques remarques sur VHDL
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 2. Dernière modification le 18 décembre 2020 à 19:39.
Il y a d'ENSTAB qui vient de «sortir» un kit virtuel utilisant l'interface vpi de GHDL. Je ne l'ai pas testé mais TapTempo en vhdl sur ce kit pourrait être un défi rigolo ;)
Même si les kits de développement sont de moins en moins cher, ça permet de se faire la main rapidement sans attendre son colis.
Je voulais surtout parler de la structuration en blocs connectés entre eux que l'on retrouve très fréquemment en VHDL (mais en Verilog aussi)
J'ai plus qu'une balle
[^] # Re: Valeurs des constantes dans les packages
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Portage de TapTempo en VHDL. Évalué à 3.
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 martoni (site web personnel, Mastodon) . En réponse au journal framework de jeu vidéo. Évalué à 2.
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 martoni (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 martoni (site web personnel, Mastodon) . En réponse au journal Une histoire d'encodage de caractères. Évalué à 5.
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 martoni (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 :
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
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 martoni (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 martoni (site web personnel, Mastodon) . En réponse au journal Le retour du RiscPC ?. Évalué à 3.
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 martoni (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 martoni (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.
Tu veux sans doute parler de ce code :
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 :
J'ai plus qu'une balle
[^] # Re: j'ai quelques questions msieur !
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 6.
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.
btn_per_i compte le nombre de période de timepulse TP_NS. Une autre manière d'écrire l'équation serait :
Tout à fait, les liens entre les modules se font par les ports que l'on connecte dans le composant «TOP»
Dans le top qui s'appelle taptempo.
La connexions du module debounce est donné par le code suivant :
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».
Ç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 martoni (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 5.
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.
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 martoni (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 6.
Tout à fait ;)
J'ai plus qu'une balle
[^] # Re: À suivre
Posté par martoni (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 martoni (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. É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: Petite erreur de jugement ?
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Petite histoire de debug. Évalué à 3.
Ç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 martoni (site web personnel, Mastodon) . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. É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