La taille en bits

Comment calculer la taille d’un registre permettant de représenter un nombre N

Chisel3 : log2Ceil()

import chisel3.util.log2Ceil
val Nsize = log2Ceil(N + 1)

Verilog : $clog2()

parameter NSIZE = $clog2(N + 1);

VHDL : ceil(log2()

use IEEE.math_real."ceil";
use IEEE.math_real."log2";

Nsize := integer(ceil(log2(real(N + 1))));

Python: math.ceil(math.log(N+1, 2))

import math
Nsize = math.ceil(math.log(N + 1, 2))

CλaSH: ?

Le point Gowin

Oui je sais c’est nul 😉

Arrivée dans un énorme carton, la carte électronique se trouve dans le tout petit «tube» blanc.

Je viens donc de recevoir ma carte petite abeille (littlebee) munie d’un FPGA du chinois GOWIN.

La carte «LittleBee» munie d’un FPGA de chez Gowin

La carte produite et vendue par la société allemande Trenz Electronic permet de se faire la main avec le composant pour moins de 40€ (un peu plus avec les frais de ports UPS …).

Branchement

Au branchement à la sortie du carton les huit leds rouge s’allument ainsi qu’une led verte que je suppose de «power».

Les messages noyau nous donnent deux ports séries ttyUSBx :

$ dmesg
[630417.919258] usb 3-1: new high-speed USB device number 35 using xhci_hcd
[630418.059577] usb 3-1: New USB device found, idVendor=0403, idProduct=6010
[630418.059581] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[630418.059583] usb 3-1: Product: Dual RS232-HS
[630418.059584] usb 3-1: Manufacturer: FTDI
[630418.060116] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
[630418.060155] usb 3-1: Detected FT2232H
[630418.060352] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
[630418.060499] ftdi_sio 3-1:1.1: FTDI USB Serial Device converter detected
[630418.060528] usb 3-1: Detected FT2232H
[630418.060648] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB1

Si on se connecte au port série ttyUSB1 on obtient un affichage de la résolution du problème des philosophes.

Philosopher 0 [P: 3] THINKING [ 750 ms ]
Philosopher 1 [P: 2] HOLDING ONE FORK
Philosopher 2 [P: 1] EATING [ 450 ms ]
Philosopher 3 [P: 0] STARVING nabled
Philosopher 4 [C:-1] HOLDING ONE FORK get back,
Philosopher 5 [C:-2] EATING [ 375 ms ]

Il est probable que nous ayons ici un RISC-V dans le tiroir.

La connexion d’un terminal sur le port ttyUSB0 ne donne rien par contre.

IDE

Voila pour le déballage, maintenant il va falloir installer les outils pour faire clignoter ces leds !

[To Be Edited …]

Digital Design with Chisel

«Digital Design with Chisel» n’est pas un manuel d’utilisation des ciseaux à bois.

Le livre de Martin Schoerberl «Digital Design with Chisel» est à ma connaissance le premier livre papier concernant le langage de description matériel Chisel.

Le livre — en anglais mais on s’en doute — est une excellente introduction au langage de description matériel Chisel. Avec lui il est même possible de commencer la conception numérique (digital design) en Chisel sans avoir à mettre les mains dans le VHDL ou le Verilog.

Ce manuel se veut un guide pratique de démarrage, on commence avec la description de l’installation des outils pour faire tourner Chisel tout en faisant une (très) rapide introduction à Scala. Scala est le langage utilisé pour Chisel.

Après avoir décrit les composants de bases du langage, l’auteur s’attaque à la description d’un projet Chisel avec l’architecture des sources, testbench et autres makefile et built.sbt . On attaque ensuite les différentes structures un peu plus avancées de la construction numérique comme les machines d’états, les FIFO, ports séries pour aller jusqu’à la conception d’un processeur simple.

Le livre se termine par un chapitre expliquant comment contribuer au projet initié à Berkeley.

C’est un excellent manuel pour mettre le pied à l’étrier de la conception numérique avec un langage moderne (SSHDL). Bien sûr ça n’est pas en 130 pages que l’on fera le tour du langage, ça n’est pas non plus un manuel de référence exhaustif. Pour le manuel de référence on se référera au site officiel, et pour se souvenir des mots clefs on ira télécharger la «cheat sheet».

Le livre est disponible en impression amazon pour ~10$. Comme c’est un livre «libre» il est également disponible avec ses sources sur le github de l’auteur.

Lancement de l’OpenHW group

L’OpenHW group a été lancé en juin dans la foulée du workshop RISC-V qui se tenait à Zurich.

L’OpenHW group est une organisation à but non lucratif ayant pour objectif de promouvoir le développement de composants électroniques libres (ASIC, FPGA, …).

C’est dans cette optique de l’OpenHW développe une série de microprocesseurs RISC-V nommés sobrement Core-V.

On en saura certainement plus sur cette organisation cet automne à l’occasion du forum OSDForum qui se tiendra à Ottawa.

  • Présentation de l’OpenHW à Zurich (slide/vidéo)
  • Présentation de l’OpenHW sur HPCWire.

FireAnt: Un petit nouveau dans le monde du FPGA à bas coût

FireAnt est un kit de développement «de la taille d’un pouce» permettant de se faire la main sur le FPGA Trion T8 de la société Efinix.

Le kit est en crowdsourcing sur la plate-forme crowdsupply pour $30.

Vue du kit FireAnt muni d’un Trion T8 de chez Efinix

Pour ce prix on a le droit à :

  • Un Trion T8F81C2 (dispo chez digikey) muni de
    • 7384 Éléments logiques (LE)
    • 123kb de RAM
    • 8 multi-plieurs 18×18 bits
  • Un FTDI pour piloter le kit en USB
  • Une mémoire flash SPI à 104Mhz de 8Mo
  • Et bien sûr un LDO pour l’alimentation 3v3 à partir de l’USB

Efinix est une toute nouvelle société qui propose des petits FPGA gravés en 40nm. Pour les tout petits FPGA de leur gamme, la société propose ce qu’elle appelle un MPM pour «Mask Programmable Memory» -> la possibilité de figer le design en usine et de ne plus avoir à configurer le FPGA à chaque démarrage.

Un IDE permettant de faire la synthèse, le placement-routage et le bitstream est fourni «gratuitement». À condition de posséder un kit de développement (J’ai beau négocier, ils ne veulent pas me le donner tant que je n’aurais pas reçu le kit 😉 ).

Bref, il n’est pas encore question d’outils libres pour ces FPGA pour l’instant. Cependant, ça fait du bien de voir de nouveaux acteurs dans le domaine des FPGA «physique».

Un hack pour intégrer Wavedrom dans LibreOffice

Wavedrom est un outils magique pour générer de très beaux chronogrammes à partir d’une base texte (JSON). Il existe un outils en ligne de commande pour générer des rendu en SVG ou PNG. Cependant, Wavedrom reste très lié au web, pas facile de l’intégrer dans un document wysiwyg comme libreoffice.

On peut bien sûr générer l’image puis l’intégrer à son document, mais cela éparpille très vite le nombre de fichiers source à gérer. Or, un des intérêt d’un document libreoffice est d’inclure toute les sources permettant de générer et modifier le document.

L’idéal serait d’avoir un plugin Libreoffice pour wavedrom, mais pour l’instant cela n’existe pas.

Krispy propose une solution/hack sur la mailing list de wavedrom.

Cette solution nécessite d’avoir un accès web et de faire son chronograme avec l’éditeur en ligne de wavedrom. Cet éditeur permet de «stocker» la description du chronograme dans l’URL. Il suffit pour cela de cliquer sur le menu sandwich en bas à droite et de sélectionner «expand url» pour avoir le contenu du chronogramme dans l’url comme ceci.

Il n’est pas utile de comprendre ce qui est écrit dans l’url, il suffit de cliquer dessus pour avoir le texte «lisible».

Pour l’intégrer à son document libreoffice il suffit de:

  • générer l’image dans le format de son choix avec l’éditeur en ligne
  • de l’intégrer à son document libreoffice
  • Puis de faire un lien web sur l’image avec l’url complète contenant le source du chronograme.

De cette manière, le source du chronogramme est bien embarqué dans le document. Il faudra certe refaire une manip légèrement fastidieuse à chaque modification, mais nous avons tout de même une solution viable.


C’est évident quand on y pense, mais très piégeux :

        if(state == OPU_RSC || (state == OPU_WSTR))
            if(timetick_pulse) begin
                pwr_counter <= pwr_counter + 1;
            end
        else
            pwr_counter <= 0;

On pense que le else se rapporte au premier if … et bien non !

Il faut écrire :

        if(state == OPU_RSC || (state == OPU_WSTR)) begin
            if(timetick_pulse) begin
                pwr_counter <= pwr_counter + 1;
            end
        end else
            pwr_counter <= 0;

Voila voila, si on peut vous éviter des heures de déverminage inutiles c’est cadeaux 😉

Un ASIC conçu intégralement avec des logiciels libres

Les FPGA sont très liés aux ASIC. En effet, la plupart des outils utilisés en FPGA pour la synthèse HDL, la preuve formel, le placement routage ou l’analyse des timings sont les même que ceux à destination des ASIC. Seuls les librairies et les configurations changent. La grosse différence (de taille) avec les FPGA c’est que l’ASIC n’est pas reconfigurable, et les «frais d’initialisations» sont très élevés. Les délais de productions sont très long également (on parle en trimestre voir en semestre de délais).

Avec de telles contraintes, on comprend pourquoi les développeurs ne se mouillent pas trop avec des logiciels exotiques et restent sur ceux qu’ils connaissent. Vu les tarif de production, le coût des licences des logiciels est assez négligeable. Pourquoi «grenouiller» avec des outils open-source dans ce cas ?

Vue «silicium» du Raven, un microcontrôleur Risc-V conçu avec des outils open-sources

Toutes ces contraintes n’ont pas découragé Tim Edwards de se lancer dans la conception et la fabrication d’un microcontrôleurs intégralement avec des outils open-sources.

Synoptique du Raven avec ses différents périphériques

C’est comme cela qu’est né le Raven, un microcontrôleur basé sur un cœur picoRV32 (conçu par Clifford Wolf) et réalisé principalement avec les outils qflow d’opencircuitdesign.com :

Grande surprise quand on se plonge dans ces outils open-source : Beaucoup sont très vieux. Les pages web de ses outils sont encore codé en web95 avec des frames et autre fonds hideux datant de l’époque frontpage.

Pourtant à y regarder de plus prêt, ces outils semblent toujours activement maintenus.

Mais alors pourquoi aucun fondeur FPGA ne les proposent dans leurs IDE ?

Une première série du microcontrôleur gravé en 180nm a été produite en mai 2018. Le composant est désormais fonctionnel avec les caractéristiques suivantes:

  • Cadencé à 100 MHz
  • 16 GPIO
  • 2 ADCs
  • 1 DAC
  • 1 Comparateur
  • Alarme de température
  • Oscillateur RC de 100 kHz
  • Fonction configurables pour les sorties GPIO
  • Interruptions configurable sur les entrées GPIO

Il n’est pas possible d’acheter le composant pour se faire un montage chez soit pour le moment. Par contre l’«IP» est disponible dans la bibliothèque du fondeur efabless et peut être utilisé comme base pour réaliser son propre composant selon les besoins.

Les traces VCD se compressent bien

La simulation HDL génère assez vite des traces (waves) de plusieurs centaines de méga-octets, voir des dizaines de giga.

Ces traces sont le plus souvent au format VCD, qui n’est qu’un fichier texte répétant les même schéma au court du temps. Ces fichiers ayant énormément de redondance, ils se compressent très bien.

Si je prend par exemple un fichier vcd messignaux.vcd faisant ~500Mo :

$ ls messignaux.vcd
-rw-r--r-- 1 fabien fabien 504M avril 3 10:17 messignaux.vcd

Je compresse avec zip en environ 30 secondes:

$ zip -c messignaux.zip messignaux.vcd
adding: messignaux.vcd (deflated 89%)
$ ls -lha messignaux.zip
-rw-r--r-- 1 fabien fabien 56M avril  5 14:16 messignaux.zip

Et je réduis mon fichier à 56Mo soit un rapport de presque 10.

Avec gzip on gagne la même chose à une queue de vache près :

$ gzip messignaux.vcd
$ ls -lha messignaux.gz
-rw-r--r-- 1 fabien fabien 57M avril  3 10:17 messignaux.vcd.gz

Et avec xz alors là on réduit environs à 20 fois plus petit, … mais il faut plus de 5 minutes à xz pour faire la compression:

$ xz -z messignaux.vcd
$ ls -lha messignaux.vcd.xz
-rw-r--r-- 1 fabien fabien 27M avril  3 10:17 messignaux.vcd.xz

Bref, si vos traces de simulation prennent trop de place sur votre pc, n’hésitez pas à les compresser.

Designing Video Game Hardware in Verilog

Stephen Hugg est l’auteur d’un vieux jeux en shareware tournant sur Win95 nommé comet buster. C’est surtout un grand fan de rétro-gaming.

Or, à une époque les consoles de jeux fonctionnaient avec de la logique discrète à base de puces que l’on soudait sur un PCB pour réaliser le jeux. La seule horloge utilisée était l’horloge «pixel» de l’écran CRT qui servait à piloter le balayage du faisceau d’électrons sur le téléviseur.

Dans ce livre, l’auteur revisite l’architecture de ces vieilles consoles avec du Verilog. À l’époque ce langage n’existait pas, mais il est tout de même bien indiqué pour décrire les circuits de logique numérique qui étaient utilisés dans ces vieilles consoles de jeux.

L’ouvrage commence donc par un cours de Verilog avec les bases du langage. Puis il enchaîne sur les circuits de base utilisé à l’époque pour piloter un écran CRT. Avec les technique comme le slipping counter qui permettait d’économiser des portes logiques en jouant sur le compteur de ligne et de colonnes de l’écran pour déplacer une balle.

Le livre enchaîne ensuite sur l’architecture d’un processeur 8 bits puis d’un processeur 16bits.

Et pour que l’on puisse mettre la main à la pâte, un site internet permet de simuler les «programmes» décrit en verilog.

On peut donc tester en live tout les codes proposé dans le livre sur le site 8bitsworkshop.

Stephen Hugg n’en est pas à son coup d’essais en matière de livre sur les vieux jeux vidéo puisque ce livre est le troisième. Mais c’est le premier livre à parler d’architecture «électronique», les deux précédent parlaient surtout de programmation de jeux vidéo sur de vieille architecture.

C’est un excellent petit livre pour se mettre au Verilog de manière ludique. Et cela permet de se replonger dans l’histoire des vieux jeux vidéos.