Un truc qui est sympa aussi avec les LED. C'est qu'on peu s'en servir comme capteur de luminosité !
En effet branché «à l'envers» une led se comporte comme un condensateur dont la capacité varie en fonction de la luminosité.
Bravo pour ce journal qui nous éclairent sur un successeur (encore un ;-)) du couple fameux VHDL/Verilog.
Je ne trouve pas qu'il y en ait tant que ça perso. Mais c'est vrai que depuis 2 ou 3 ans ça commence à bouger. À ma plus grande joie ;)
Par contre, je suis surpris que ce langage prenne pour parti pris un tout-synchrone. J'ai certes arrêté la conception HW il y a quelques années, mais pour les designs complexe (au-delà de la dizaine de millions de portes), on parlait beaucoup de GALS (Globally Asynchronous Locally Synchronous). Comment un tel langage peut-il être compatible de ce paradigme ?
C'est bien l'esprit du langage en fait. On est bien «localement synchrone» avec le concept de domaines d'horloges. Il est tout à fait possible de changer de domaines d'horloges d'un module à l'autre. Mais c'est au développeur de bien soigner ses traversées de domaines d'horloge. C'est encore un point noir de Chisel à mon avis, même s'il existe quelques fonctions comme la fifo asynchrone ou le registres à décalage pour faciliter ça.
Il n'est pas possible de garantir le temps de propagation entre deux portes logique dans un FPGA à cause du placement routage.
En effet pour connecter la sortie d'une porte logique sur une autre il est nécessaire de passer par un nombre aléatoire de connexions qui seront différente à chaque synthèse/placement routage.
Si nos signaux d'entrées d'une porte logique «ET» par exemple n'arrive pas exactement en même temps, le résultat de sortie va passer par plusieurs valeurs fausses avant de se stabiliser.
Pour éviter de propager ces erreurs on va mémoriser le résultat à un moment précis − la plupart du temps sur le front montant d'une horloge principale − au moyen d'une Bascule D.
Ces la valeurs de sorties de la bascule D qui seront prisent comme résultat pour être propagées dans d'autre calculs. On parle de système synchrone quand toutes les Bascules D se déclenchent sur la même horloge.
L'analyse des timings consistera alors a s'assurer qu'entre deux bascules les signaux se propagent plus rapidement qu'une période de l'horloge.
Et effectivement c'est pas une présentation trop violente (limite j'ai dû chercher où était le message. C'est peut-être même pas assez visible pour le coup) donc c'est cool.
Faudrait peut-être que j'améliore un peu en effet. Peut-être le mettre au moins dans un cadre rouge. Mais je suis pas un dieux du HTML/Css donc il me faut toujours du temps pour faire les trucs web.
Edit: dommage qu'on puisse pas mettre de commentaires sur ton blog sans être inscrit. Je comptais laisser en commentaire là-bas et me suis rabattu sur le forum linuxfr par dépit. :-/
Il faut que j'améliore ça aussi ;). À la base c'était permis pour tout le monde mais je me tapait trop de spam. Du coup j'ai régulé de manière assez violente. Peut-être qu'avec une simple captcha je peu éviter le spam mais permettre les commentaire «publique» quand même.
silverlankaiz, il y a eu quelques tentatives de libération de gros FPGA par le passé. Je pense surtout au projet «debit» et son papier «from the bitstream to the netlist» qui s'était attaqué à la rétro-ingénierie du Spartan3. Mais il y a aussi, dans une certaine mesure, le projet Torc, mais développé par une université qui est financé par les gros du FPGA, du coup tout n'est pas reversé pour pas les froisser.
J’essaie de les recenser sur une page du front de libération des FPGA.
De tout les projets que je scrute depuis quelques années maintenant, le projet Icestorm est de très loin le projet le plus abouti. Le projet inclue même l'analyse des timings maintenant, ce qui était son gros point noir au début.
Merci pour tous les conseils jehan, bon le but n'est pas non plus de trop dégrader l'expérience utilisateur avec une popup dégueulasse qui encombre la vue.
L'idée est plutôt de faire un bandeau en haut de la page, ou un encart sur le coté donnant le message.
Juste histoire de contrer les messages qui me traitent de voleur à tout bout de champs quand je surf sur le web ;)
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/…
Pour moi «brute-forcer» signifie : tester toutes les combinaison possibles bêtement une par une jusqu’à obtenir la bonne.
Après pour faire moins brute on peut réduire l'espace des combinaison possible en faisant des «attaques au dictionnaire» ou autre.
Mais le «brute-force» n'a rien de violent, c'est juste du calcul bête et long ;)
Tu peux tout à fait financer un projet libre et maintenir un fork pour ton compte. C'est un peu ce que font Ubuntu, Android et consort (pas sûr qu'ils financent beaucoup Debian et Linux en fait).
S'adosser à un projet libre énormément utilisé te donne une certaine pérennité. Tu n'as plus qu'a te concentrer sur les détails que tu veux spécialiser.
Perso je serais moins hostile à installer un système sachant qu'il est basé sur un truc connu et très utilisé plutôt que de me lancer sur un truc totalement nouveau développé par une petite équipe (quelque soit les millions engloutis dans un OS souverain, l'équipe sera nécessairement plus petite que celle développant Linux ou Debian).
C'est ouvert aux rédacteurs si tu veux soutenir la lutte n'hésites pas ;)
Pour MyHDL c'est vrai que je l'ai oublié, mais il est légèrement différent des trois cités. Les trois que j'ai cité se concentrent sur la conception de design synchrones, alors que MyHDL se veut un simple remplaçant de VHDL/Verilog en python. Ce qui est aussi très intéressant !
Si le projet à 12 ans et qu'il a été débuté en Europe il n'y a rien d'étonnant à le voir écrit en VHDL. Il est vrai que GHDL est un très bon outil pour simuler du VHDL (je l'utilise tout les jours), mais il est lent. Tout comme icarus est lent pour le Verilog.
VHDL et Verilog ne sont pas des langages conçues à l'origine pour faire de la synthèse FPGA, se ne sont que des langages de simulation.
Quitte à reprendre tout de zéro, pourquoi ne pas passer sur les nouveaux langages de synthèse comme Clash, Migen ou surtout Chisel ?
Ces langages sont conçues pour la synthèse (synchrone) et permettent de développer des «IP» de manière beaucoup moins verbeuses en limitant les copier/coller. Et il n'est plus nécessaire de se taper du VHDL/Verilog pour les testbench.
Avec Chisel par exemple il est possible de générer
- soit un code synthétisable en verilog pour les outils privateurs habituels (ISE, Quartus, …)
- soit un modèle C++ pour la simulation. Le modèle C++ pour la simulation est nettement plus rapide que les simulateurs GHDL ou Icarus. On peut même envisager de «faire tourner» un programme sur le modèle en simulation (à quelques centaines de kilohertz au lieu des MégaHertz certes, mais c'est tout de même pas mal pour de la simulation).
Les outils du FPGA sont vieux. ils s'encroûtent. il faut faire la révolution et libérer les FPGA avec de nouveaux outils/langages !
Armadeus Project est spécialisée depuis longtemps aussi dans les cartes à base d'arm.
Ils sortent en ce moment l'apf6 à base d'i.MX6.
Le support d'un bsp à base de buildroot est dispo sur sourceforge.
Ce qui est spécifique avec ces cartes, c'est qu'il y a toujours (hormis apf28) une version disponible avec un FPGA. Cela permet d'étendre la possibilité des périphériques déjà disponibles dans le processeur freescale.
La question n'est pas de savoir lequel est le meilleurs, mais plutôt dans lequel s'engager si on veut utiliser des logiciels libres pour développer avec.
En tout cas pas avec des logiciels libre. La base de cette lib n'est pas si libre que ça d'ailleurs, il faut s'identifier sur le site pour avoir accès au code.
Tout à fait d'accord avec toi, l'avenir n'est pas dans le Verilog ou le VHDL.
Mais quand je regarde les projets libres générant du langage HDL pour la synthèse, la plupart se basent sur le Verilog.
Comme souvent ces projets ne sont pas «terminés» il faut souvent mettre les mains dans le code généré, du coup si on veut utiliser des outils libres pour le faire du FPGA c'est au Verilog qu'il faut se mettre.
Le VHDL appris à l'école réduit le champs des possible dans le libre.
Je connaissais myhdl, mais quand j'avais regardé il était encore embryonnaire. Visiblement c'est un projet qui avance bien, je vais me pencher dessus à nouveau.
C'est assez ambitieux de pouvoir générer à la fois du VHDL et du Verilog pour la synthèse.
Pour OpenCL, les outils de conversions ne semblent pas spécialement libre par contre.
# Led comme capteur de luminosité
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Les diodes ne sont pas toutes des lumières. Évalué à 10.
Un truc qui est sympa aussi avec les LED. C'est qu'on peu s'en servir comme capteur de luminosité !
En effet branché «à l'envers» une led se comporte comme un condensateur dont la capacité varie en fonction de la luminosité.
On trouve quelque montage sur le web pour exploiter cette propriété.
https://duckduckgo.com/?q=led+as+light+sensor&t=ffnt&ia=web
J'ai plus qu'une balle
[^] # Re: Langage synchrone
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Chisel 3, un langage de description matériel basé sur Scala. Évalué à 2.
Je ne trouve pas qu'il y en ait tant que ça perso. Mais c'est vrai que depuis 2 ou 3 ans ça commence à bouger. À ma plus grande joie ;)
C'est bien l'esprit du langage en fait. On est bien «localement synchrone» avec le concept de domaines d'horloges. Il est tout à fait possible de changer de domaines d'horloges d'un module à l'autre. Mais c'est au développeur de bien soigner ses traversées de domaines d'horloge. C'est encore un point noir de Chisel à mon avis, même s'il existe quelques fonctions comme la fifo asynchrone ou le registres à décalage pour faciliter ça.
J'ai plus qu'une balle
[^] # Re: Tout l'inverse du soft !
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Chisel 3, un langage de description matériel basé sur Scala. Évalué à 10.
Il n'est pas possible de garantir le temps de propagation entre deux portes logique dans un FPGA à cause du placement routage.
En effet pour connecter la sortie d'une porte logique sur une autre il est nécessaire de passer par un nombre aléatoire de connexions qui seront différente à chaque synthèse/placement routage.
Si nos signaux d'entrées d'une porte logique «ET» par exemple n'arrive pas exactement en même temps, le résultat de sortie va passer par plusieurs valeurs fausses avant de se stabiliser.
Pour éviter de propager ces erreurs on va mémoriser le résultat à un moment précis − la plupart du temps sur le front montant d'une horloge principale − au moyen d'une Bascule D.
Ces la valeurs de sorties de la bascule D qui seront prisent comme résultat pour être propagées dans d'autre calculs. On parle de système synchrone quand toutes les Bascules D se déclenchent sur la même horloge.
L'analyse des timings consistera alors a s'assurer qu'entre deux bascules les signaux se propagent plus rapidement qu'une période de l'horloge.
J'ai plus qu'une balle
[^] # Re: Emulation d'un CPU 32-bits sur MCU 8-bits
Posté par martoni (site web personnel, Mastodon) . En réponse au journal [Bookmark] Faire tourner Linux sur un micro-contrôleur 8-bit. Évalué à 2.
Visiblement oui, mais le résultat reste un Linux qui tourne sur un microcontrôleur 8bits.
J'aime beaucoup le temps de boot de 4h !
J'ai plus qu'une balle
[^] # Re: Gâteau d'anniversaire
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Le noyau Linux a 25 ans. Évalué à 2.
Manque les bougies !
J'ai plus qu'une balle
[^] # Re: Il suffit d'inverser les codes de détection d'adblock
Posté par martoni (site web personnel, Mastodon) . En réponse au message Nous avons remarqué que vous n'utilisez pas de bloqueur de publicité .... Évalué à 1.
Faudrait peut-être que j'améliore un peu en effet. Peut-être le mettre au moins dans un cadre rouge. Mais je suis pas un dieux du HTML/Css donc il me faut toujours du temps pour faire les trucs web.
Il faut que j'améliore ça aussi ;). À la base c'était permis pour tout le monde mais je me tapait trop de spam. Du coup j'ai régulé de manière assez violente. Peut-être qu'avec une simple captcha je peu éviter le spam mais permettre les commentaire «publique» quand même.
J'ai plus qu'une balle
[^] # Re: Il suffit d'inverser les codes de détection d'adblock
Posté par martoni (site web personnel, Mastodon) . En réponse au message Nous avons remarqué que vous n'utilisez pas de bloqueur de publicité .... Évalué à 1.
Voici :
http://www.fabienm.eu/wordpress/?p=901
;)
J'ai plus qu'une balle
[^] # Re: le logiciel permet de dessiner son projet au moyen de blocs reliés...
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Icestudio 0.2, du schéma au verilog. Évalué à 4.
Dans un journal non c'est systématique ;) Par contre dans une dépêche c'est la première fois vu que c'est ma première dépêche.
J'ai plus qu'une balle
[^] # Re: Il suffit d'inverser les codes de détection d'adblock
Posté par martoni (site web personnel, Mastodon) . En réponse au message Nous avons remarqué que vous n'utilisez pas de bloqueur de publicité .... Évalué à 1.
Je n'y manquerais pas ;)
J'ai plus qu'une balle
[^] # Re: La "libération" de ce FPGA est une excellente chose
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Icestudio 0.2, du schéma au verilog. Évalué à 3.
silverlankaiz, il y a eu quelques tentatives de libération de gros FPGA par le passé. Je pense surtout au projet «debit» et son papier «from the bitstream to the netlist» qui s'était attaqué à la rétro-ingénierie du Spartan3. Mais il y a aussi, dans une certaine mesure, le projet Torc, mais développé par une université qui est financé par les gros du FPGA, du coup tout n'est pas reversé pour pas les froisser.
J’essaie de les recenser sur une page du front de libération des FPGA.
De tout les projets que je scrute depuis quelques années maintenant, le projet Icestorm est de très loin le projet le plus abouti. Le projet inclue même l'analyse des timings maintenant, ce qui était son gros point noir au début.
Il y a une vieille présentation de Sébastien Bourdeauducq sur comment s'y prendre pour faire le reverse engineering d'un fpga aussi.
J'ai plus qu'une balle
[^] # Re: Il suffit d'inverser les codes de détection d'adblock
Posté par martoni (site web personnel, Mastodon) . En réponse au message Nous avons remarqué que vous n'utilisez pas de bloqueur de publicité .... Évalué à 1.
Merci pour tous les conseils jehan, bon le but n'est pas non plus de trop dégrader l'expérience utilisateur avec une popup dégueulasse qui encombre la vue.
L'idée est plutôt de faire un bandeau en haut de la page, ou un encart sur le coté donnant le message.
Juste histoire de contrer les messages qui me traitent de voleur à tout bout de champs quand je surf sur le web ;)
J'ai plus qu'une balle
[^] # Re: Interressant
Posté par martoni (site web personnel, Mastodon) . En réponse au journal De retour du 4e workshop RISC-V. É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:
Posté par martoni (site web personnel, Mastodon) . En réponse au journal testmysite.thinkwithgoogle.com. Évalué à 1.
Pas si arbitraire que ça, ça permet de savoir comment google référence le site aussi.
J'ai plus qu'une balle
[^] # Re: bruter-forcer...
Posté par martoni (site web personnel, Mastodon) . En réponse au journal miniurl ki pu. Évalué à 4.
Pour moi «brute-forcer» signifie : tester toutes les combinaison possibles bêtement une par une jusqu’à obtenir la bonne.
Après pour faire moins brute on peut réduire l'espace des combinaison possible en faisant des «attaques au dictionnaire» ou autre.
Mais le «brute-force» n'a rien de violent, c'est juste du calcul bête et long ;)
J'ai plus qu'une balle
[^] # Re: Oui, il est bon
Posté par martoni (site web personnel, Mastodon) . En réponse au journal le retour du Virus Informatique [presse]. Évalué à 9.
Bon la conception de cette tablette était financé par elf d'après l'article …
J'ai plus qu'une balle
[^] # Re: Supaire
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Un système d’exploitation français pour la souveraineté numérique. Évalué à 3.
Tu peux tout à fait financer un projet libre et maintenir un fork pour ton compte. C'est un peu ce que font Ubuntu, Android et consort (pas sûr qu'ils financent beaucoup Debian et Linux en fait).
S'adosser à un projet libre énormément utilisé te donne une certaine pérennité. Tu n'as plus qu'a te concentrer sur les détails que tu veux spécialiser.
Perso je serais moins hostile à installer un système sachant qu'il est basé sur un truc connu et très utilisé plutôt que de me lancer sur un truc totalement nouveau développé par une petite équipe (quelque soit les millions engloutis dans un OS souverain, l'équipe sera nécessairement plus petite que celle développant Linux ou Debian).
J'ai plus qu'une balle
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 1.
Ça me fait penser à un gag dans Kid paddle cherchant à faire un mot au scrabble ;)
J'ai plus qu'une balle
[^] # Re: VHDL ?
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 2. Dernière modification le 20 avril 2015 à 11:47.
C'est ouvert aux rédacteurs si tu veux soutenir la lutte n'hésites pas ;)
Pour MyHDL c'est vrai que je l'ai oublié, mais il est légèrement différent des trois cités. Les trois que j'ai cité se concentrent sur la conception de design synchrones, alors que MyHDL se veut un simple remplaçant de VHDL/Verilog en python. Ce qui est aussi très intéressant !
J'ai plus qu'une balle
# VHDL ?
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 7. Dernière modification le 20 avril 2015 à 08:53.
Si le projet à 12 ans et qu'il a été débuté en Europe il n'y a rien d'étonnant à le voir écrit en VHDL. Il est vrai que GHDL est un très bon outil pour simuler du VHDL (je l'utilise tout les jours), mais il est lent. Tout comme icarus est lent pour le Verilog.
VHDL et Verilog ne sont pas des langages conçues à l'origine pour faire de la synthèse FPGA, se ne sont que des langages de simulation.
Quitte à reprendre tout de zéro, pourquoi ne pas passer sur les nouveaux langages de synthèse comme Clash, Migen ou surtout Chisel ?
Ces langages sont conçues pour la synthèse (synchrone) et permettent de développer des «IP» de manière beaucoup moins verbeuses en limitant les copier/coller. Et il n'est plus nécessaire de se taper du VHDL/Verilog pour les testbench.
Avec Chisel par exemple il est possible de générer
- soit un code synthétisable en verilog pour les outils privateurs habituels (ISE, Quartus, …)
- soit un modèle C++ pour la simulation. Le modèle C++ pour la simulation est nettement plus rapide que les simulateurs GHDL ou Icarus. On peut même envisager de «faire tourner» un programme sur le modèle en simulation (à quelques centaines de kilohertz au lieu des MégaHertz certes, mais c'est tout de même pas mal pour de la simulation).
Les outils du FPGA sont vieux. ils s'encroûtent. il faut faire la révolution et libérer les FPGA avec de nouveaux outils/langages !
J'ai plus qu'une balle
# Armadeus
Posté par martoni (site web personnel, Mastodon) . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 2.
Armadeus Project est spécialisée depuis longtemps aussi dans les cartes à base d'arm.
Ils sortent en ce moment l'apf6 à base d'i.MX6.
Le support d'un bsp à base de buildroot est dispo sur sourceforge.
Ce qui est spécifique avec ces cartes, c'est qu'il y a toujours (hormis apf28) une version disponible avec un FPGA. Cela permet d'étendre la possibilité des périphériques déjà disponibles dans le processeur freescale.
J'ai plus qu'une balle
[^] # Re: Logiciels de HLS
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Le VHDL prend-il l'eau ?. Évalué à 1.
La question n'est pas de savoir lequel est le meilleurs, mais plutôt dans lequel s'engager si on veut utiliser des logiciels libres pour développer avec.
J'ai plus qu'une balle
[^] # Re: Et System C?
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Le VHDL prend-il l'eau ?. Évalué à 1.
En tout cas pas avec des logiciels libre. La base de cette lib n'est pas si libre que ça d'ailleurs, il faut s'identifier sur le site pour avoir accès au code.
J'ai plus qu'une balle
[^] # Re: Logiciels de HLS
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Le VHDL prend-il l'eau ?. Évalué à 2.
Tout à fait d'accord avec toi, l'avenir n'est pas dans le Verilog ou le VHDL.
Mais quand je regarde les projets libres générant du langage HDL pour la synthèse, la plupart se basent sur le Verilog.
Comme souvent ces projets ne sont pas «terminés» il faut souvent mettre les mains dans le code généré, du coup si on veut utiliser des outils libres pour le faire du FPGA c'est au Verilog qu'il faut se mettre.
Le VHDL appris à l'école réduit le champs des possible dans le libre.
J'ai plus qu'une balle
[^] # Re: myHDL et OpenCL
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Le VHDL prend-il l'eau ?. Évalué à 2.
Je connaissais myhdl, mais quand j'avais regardé il était encore embryonnaire. Visiblement c'est un projet qui avance bien, je vais me pencher dessus à nouveau.
C'est assez ambitieux de pouvoir générer à la fois du VHDL et du Verilog pour la synthèse.
Pour OpenCL, les outils de conversions ne semblent pas spécialement libre par contre.
J'ai plus qu'une balle
# Liens
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 3.
Un petit lien ?
le blog : http://slo-ist.fr/ada4autom
la doc : http://slo-ist.fr/A4A/Documentation/A4A-Book-fr.html
Ou le code : https://gitorious.org/ada-for-automation
J'ai plus qu'une balle