J’avais parlé il y a quelque temps de GHDL, un simulateur VHDL pour GNU.

Aujourd’hui, je vais vous parler de son équivalent pour le Verilog : Icarus Verilog.

Il ressemble à GHDL dans son fonctionnement :

• on lance une compilation (au sens traditionnelle du terme, pas une synthèse) du code et de son test,
• on lance le programme (comme un binaire)
• on lit le fichier vcd ainsi généré avec GTKWave

Comme un exemple vaut souvent mieux qu’un long discours, voici le code, les commandes à lancer et le résultat obtenu dans le cas de la simulation d’une mémoire RAM :

Code de la RAM (RAM.v) :

module RAM( clk, dataIn, address, wren, dataOut );
  // Parametres
  parameter DATA_LENGTH    = 4;
  parameter ADDRESS_LENGTH = 3;
  
  // Entrees / Sorties
  input                            clk; // Horloge
  input [ DATA_LENGTH - 1 : 0 ]    dataIn; // Donnees entrantes
  input [ ADDRESS_LENGTH - 1 : 0 ] address; // Adresse
  input                            wren; // Write Enable
  output [ DATA_LENGTH - 1 : 0 ]   dataOut; // Donnees sortantes
  
  reg [ DATA_LENGTH - 1 : 0 ] dataOut;
  
  // Tableau pour stocker les donnees (c'est le coeur de la RAM)
  reg [ DATA_LENGTH - 1 : 0 ] data [ 2 ** ADDRESS_LENGTH - 1 : 0 ];
  
  always @( posedge clk )
  begin  
    if( wren == 1 )
    begin
      data[ address ] <= dataIn;
    end
    
    dataOut <= data[ address ];
  end
endmodule 

Code du TestBench (RAM_TB.v) :

// Periode de temps a 10 ns
`timescale 10 ns / 100 ps
module RAM_TB;
  
  // Entrees / Sorties
  reg            clk, wren;
  reg [ 3 : 0 ]  dataIn;
  reg [ 2 : 0 ]  address;
  wire [ 3 : 0 ] dataOut;
  
  // Instanciation de la RAM
  RAM ram_inst( clk, dataIn, address, wren, dataOut );
  
  // Sauvegarde du resultat dans un fichier
  initial
  begin
    $dumpfile( "RAM_TB.vcd" );
    $dumpvars; // On sauvegarde toutes les variables
  end
  
  // Horloge a 100 Mhz
  initial
    clk = 0;
  always
  begin
    #0.5;
    clk = ~clk;
  end

  // Stimulis
  initial
  begin
    address = 0;
    dataIn  = 0;
    wren    = 0;
    
    #1;
    
    address = 0;
    dataIn  = 7;
    wren    = 1;
    
    #1;
    
    address = 1;
    dataIn  = 5;
    wren    = 1;
        
    #1;
    
    wren    = 0;  
    
    #3;
    
    address = 1;
    dataIn  = 9;
    wren    = 1;
        
    #1;
    
    address = 0;
    
    #3;
    
    address = 1;    

    #3;
    
    $finish;
  end

endmodule

On lance ensuite les commandes qui vont bien (on remarquera la syntaxe semblable a celle de GCC) :

iverilog RAM_TB.v RAM.v -o RAMSimu
./RAMSimu
gtkwave RAM_TB.vcd

Et on obtient finalement le chronogramme suivant :

Références et liens :

• Site d’Icarius Verilog (en)
• Cours sur langage Verilog + liste de simulateurs libres (fr)

J’avais il y a une semaine posté un article sur le filtrage des commentaires WordPress avec Math Comment Spam Protection.
En commentaires, plusieurs personnes ont mentionné Akismet : il analyse les commentaires et décide s’il s’agit ou non de spam.

Comme Akismet est gratuit (mais demande quand même une clef) et payant pour un usage professionnel, je me suis demandé comment faire un plugin qui soit également capable de filtrer intelligemment les commentaires.

Je me suis donc mis en quête de statiques sur les mots les plus couramment utilisés, mais n’ayant rien trouvé de bien concluant, j’ai décidé d’analyser les 300 dernières pages du Planet, ce qui représente 3000 articles repartis sur environ 1 an.
Les résultats permettent d’extraire les mots les plus utilisés de la langue française et du jargon informatique (du moins, pour nous blogeur).
On pourrait ensuite choisir un certain nombre de ces mots et décider qu’au-dessus d’un pourcentage de mots présents dans le commentaire, celui-ci est valide.

Voyons rapidement, les résultats obtenus.

10 mots les plus utilisés :

de
le
la
et
à
les
un
des
en
pour

En utilisant ses mots clefs du français, on doit sans doute pouvoir détecter assez facilement si le commentaire est bien en français (et pas en anglais comme la majorité du spam).

On peut également regarder les mots en lien avec l’informatique.

20 mots les plus utilisés en rapport avec l’informatique :

version
libre
fichier
logiciel
serveur
Ubuntu
logiciels
système
site
source
fichiers
Linux
commande
données
configuration
libres
réseau
utilisateurs
sudo
web
code
Google
basé
machine
Firefox
Windows
distribution
licence
développement
installer

On pourrait alors éventuellement, mais cela risque d’être assez délicat, utiliser ce type de mots pour savoir si le commentaire parle bien d’informatique.
Les défenseurs du « GNU/Linux, ce n’est pas que Ubuntu ! » pourront noter qu’on retrouve plus souvent le mot Ubuntu que le mot Linux…

Pour finir, on peut regarder par simple curiosité les mots les moins utilisés.

Parmi les mots les moins utilisés, on trouve :

Dannois
Irrlicht
Lithium
Guadalajara
auvergnates
sociopathe
…

Pour ceux que ça intéresse, voici le dump de la liste, sous la forme (mot, nombre d’occurrences) qui contient les résultats.

Vous pouvez facilement la lire en Python avec le code suivant :

#!/usr/bin/env python
# -*- coding:Utf-8 -*-

#################
#### Modules ####
#################

import pickle

# On charge le fichier
fichier = open( ‘ListeOki.dat’ ,’rb’ )
listeMots = pickle.load( fichier )
fichier.close()

# On affiche les 20 iers éléments
print listeMots[ :20 ]

Aujourd’hui j’ai décidé de vous parler de matériel et pas de logiciel.
Rassurez vous, pas un nième article sur l’iPad, mais plutôt sur la création de circuits numériques, et bien sûr de libre.

Nous allons aborder les points suivants :

• Intérêt et utilisation des langages de description matérielle (VHDL et Verilog)
• Logiciels propriétaires
• Les IP’s
• Exemple de solution libre : GHDL et GTKWave
• Quelques composants de base
• Site qui référence de code libre

Intérêt et utilisation des langages de description matérielle (VHDL et Verilog)

Les langages de description matérielle comme le VHDL ou le Verilog sont utilisés pour créer la plupart des composants d’électronique numérique (qui manipulent des 0 et des 1 ie des valeurs quantifiées, par opposition à l’électronique analogique qui manipule des valeurs continues comme des tensions ou des courants).

Ainsi, vos processeurs, les puces qui décodent matériellement les vidéos dans vos téléphones portables ou les puces de vos routeurs ou de vos switchs sont développées avec du code comme si c’était un programme (avec quand même des différences, rassurez-vous !).

Si pour l’industriel la création de composants s’avère très coûteuse, c’est essentiellement car les temps de développement sont assez longs et doivent être accompagnés de temps de tests très très longs : en effet lors de l’envoi en fabrication, les premières réalisations coûtent très cher (j’ai entendu parler de 1 million d’euros) et si un bug a été oublié lors de l’étape de simulation, il va falloir recommencer (et donc payer de nouveau).
Si tout se passe bien, la production en masse pourra être lancée et en vendant beaucoup, l’entreprise pourra être bénéficiaire.
Les forts coûts de développement associés à la concurrence expliquent peut-être pourquoi aucun code issu d’industrie n’est sous licence libre ; je serais curieux et surpris de voir Intel diffuser le code de ses derniers processeurs !

Pour le particulier, qui n’a pas le budget d’une entreprise ni la nécessité de produire ses circuits à grande échelle, des composants programmables (CPLD/FPGA), abordables (environ 60€ pour un petit kit de développement disposant de 100 000 portes logiques, de boutons poussoirs, de switchs, de LED’s, d’afficheurs 7 segments, port PS2, …) permettent d’implémenter son code de façon assez simple.
On pourra par exemple utiliser un FPGA pour de la robotique ou de la domotique.

Les solutions privatrices

Logiciels propriétaires

Les FPGA’s qu’on peut trouver dans le commerce sont toujours fournis avec un logiciel permettant de simuler, de synthétiser (transformer le code en portes logiques, bascules, …) puis d’implémenter (placement + routage) le circuit sur le FPGA. C’est d’ailleurs souvent la qualité de ce logiciel qui aide à vendre le composant (ce qui est souvent le cas avec le matériel).

Si ces logiciels sont souvent multi plate-forme (Windows, Mac OS, GNU/Linux), ils sont cependant toujours propriétaires.

Il existe bien un simulateur libre, GHDL, dont je parle un peu plus bas, mais pour ce qui concerne la synthèse et l’implémentation du circuit, il faudra utiliser les logiciels propriétaires fournis.

C’est forcement, pour nous libristes, une mauvais chose de devoir utiliser ces logiciels. Mais il y a selon moi, une chose bien plus mauvaise que de devoir utiliser ces logiciels pour implémenter son code : c’est que les codes des composants eux-mêmes ne sont jamais libres !

Les IP’s

Dans le domaine des circuits, on parle souvent d’IP’s. Rien à voir ici avec les adresses IP ; on parle ici d’Intellectual property qui sont en réalité des bouts de circuit (donc de code) qui réalisent des fonctions spécifiques (mémoire FIFO, module Ethernet, …).
Ces IP’s, en plus d’avoir un code fermé, sont vendues très cher.

Utilisées dans des composants dont vous n’avez pas non plus le code source, il en résulte qu’il est impossible de savoir comment sont réalisés les composants que nous utilisons ni même ce qu’ils font. Pourquoi alors les défenseurs du logiciel libre ne parlent pas plus souvent de matériel ?

Les 4 libertés fondamentales du logiciel libre ne devraient-elles pas également s’adapter au matériel que nous utilisons ? Parce que justement c’est du matériel et pas du logiciel ? Eh bien non : après tout, il y a quand même un code source derrière, pourquoi n’aurions-nous pas le droit de l’étudier comme on peut le faire pour le code source d’un logiciel libre ?

Je trouve qu’il est assez paradoxal de vouloir des logiciels libres alors que le code du matériel que l’on utilise ne l’est même pas !

Espérant en avoir alerté quelques-uns sur le sujet (un seul serait déjà bien !), nous allons maintenant voir les solutions libres qui existent (même si elles ne sont pas nombreuses…).

Les solutions libres

Exemple de solution libre : GHDL et GTKWave

GHDL est un simulateur VHDL qui utilise GCC.
Il permet entre autres d’analyser son code VHDL, de le compiler (en un binaire, pas de le synthétiser en portes logiques) puis enfin de le simuler pour en vérifier le comportement.
Contrairement aux outils propriétaires, il ne permet vraiment que de tester le code.

Vous devriez l’avoir dans les dépôts de votre distribution.
À noter que si vous devez le compiler, il vous faudra gcc-ada.

Nous allons voir comment avec un petit exemple (compteur 3 bits) simuler le composant pour voir ensuite comment visualiser le résultat sous forme de chronogramme sous GTKWave.

On va utiliser les fichiers suivant :

• countern_en.vhd qui contient l’entité, l’architecture et la configuration du compteur
• countern_en_tb.vhd qui contient les paramètres de la simulation (test bench)

À noter que j’ai eu des problèmes en utilisant des majuscules dans mes noms d’entités…
Je vous conseille donc de les écrire en minuscule.

Ensuite il suffit de faire les commandes suivantes :

• Analyse des fichiers (production des fichiers objets .o) :
  

  ghdl -a countern_en.vhd
  ghdl -a countern_en_tb.vhd
      

• Élaboration (création du programme) :
  

  ghdl -e countern_en_tb
      

• Lancement de la simulation (qui produit en sortie le fichier countern_en_tb.vcd et qui s’arrête après 100 ns) :
  

  ghdl -r countern_en_tb --vcd=countern_en_tb.vcd --stop-time=100ns
      

On notera que ces étapes ressemblent très fortement à la compilation d’un programme classique.
C’est effectivement le cas, car comme dis précédemment, on crée un programme pour la simulation mais on ne fait pas la traduction code – portes logiques.

Ensuite, pour pouvoir visualiser graphiquement les résultats de la simulation, on va utiliser GTKWave.
Il suffit de le lancer avec comme paramètre le fichier de sortie de la simulation :

gtkwave countern_en_tb.vcd 

Ensuite, on sélectionne les signaux que l’on veut visualiser, on les ajoute (append), on clique sur Zoom Fit pour ajuster le zoom et la :

Il peut donc assez facilement utiliser une solution libre pour simuler le code que l’on est en train de développer (il faudra encore cependant passer par un logiciel propriétaire si on veut implémenter ce code sur FPGA…)

Quelques composants de base

J’ai eu l’occasion de faire quelques composants de base en VHDL, je vous les mets à disposition (sous licence GPL), en espérant qu’ils serviront à quelqu’un.

On trouvera :

• Convertisseur little endian/big endian
• Accumulateur
• Mémoire RAM
• Mémoire de type FIFO
• Mémoire CAM
• Calcul de checksum

Site de référence de code libre

Même si on ne trouve pas énormément de code sous licences libres, on trouve notamment des projets sur le web (le plus souvent développés lors de thèses ou projets de fin d’études) et il y a surtout un site (le plus gros) qui regroupe du code libre : OpenCores.org

On y trouve notamment plein de choses utiles comme des cores Ethernet, des contrôleurs I2C et SPI, des fonctions de hachage (MD5, SHA1, …) ; enfin, ce qui vous facilitera la vie lors de la création de projets libres.

Références et liens :

• Article Wikipedia sur le VHDL (fr)
• OpenCores (en)
• Fichiers de test pour GHDL (fr)
• Composants perso (fr)

Il est toujours agréable d’avoir des miniatures pour ses vidéos.
En tant normal, dans GNOME, c’est Totem qui se charge de ça (enfin, la dernière fois que je m’en suis inquiété, c’était le cas !).
Mais pour les gens qui n’utilisent pas Totem (car ils ne l’aiment pas ou utilisent SMPlayer, VLC, …), c’est embêtant de le désinstaller car on perd les miniatures dans Nautilus…

Une solution pour remédier à ça est d’utiliser un script appelé Mplayer-video-thumbnailer qui charge mplayer de s’occuper de la génération des miniatures.
La dernière version (1.4-1) est écrite en Python mais va moins vite (enfin il me semble) que l’ancienne version (1.3-3) écrite, elle, en Shell.

Je vais donc rapidement vous expliquer comment l’installer :

Il suffit de

• Décompresser l’archive
• Lancer en root le script setup.sh qui va s’occuper en autre de copier le script dans /usr/bin/
• Lancer en utilisateur (donc pas en root) le script gconf.sh qui va configurer GNOME pour qu’il utilise le script précédemment installé pour générer les miniatures des vidéos.

A noter que le type des fichier supportés se trouvent dans le fichier video_ext de l’archive.
J’ai moi même ajouté :

/desktop/gnome/thumbnailers/video@x-matroska
/desktop/gnome/thumbnailers/video@x-flv

Références :

• Site officiel du projet (en)
• Version 1.3-3 du script

Pour reprendre les préceptes d’un bon ami à moi : autant mettre de l’eau dans son vin, c’est un sacrilège, autant mettre du vin dans son eau, c’est une bonne chose puisque que cela améliore l’eau !
Nous allons donc voir aujourd’hui comment améliorer son Windows en y mettant du GNU/Linux ! (je vois déjà la tête de tous les déçus qui croyaient qu’un vin opensource existait… :p)

Introduction :

andLinux, car c’est bien de lui que nous allons parler aujourd’hui permet d’utiliser les programmes GNU (terminal, compilateur, amarok, …) tout en étant sur Windows et ce, sans utiliser d’émulateur (comme Wine) ou de virtualisation : le noyau Linux (coLinux ici) tourne en parallèle avec Windows ce qui procure un gain de performance assez appréciable !

Configuration requise :

Pour peu que vous ayez le matériel requis :

- Windows 2000, XP, 2003 ou Vista en 32 bits

- Minimum 512 Mo de ram pour que ça tourne pas trop mal

- 5 Go d’espace disque minimum

- Votre partition Windows qui est en NTFS

alors vous pouvez tenter l’aventure !

J’ai utilisé la version KDE que l’on peut trouver ICI.

Installation :

On lance le fichier .exe, quelques messages classiques et c’est partis :

Choisissez la quantité de RAM que andLinux aura à disposition

Voulez vous activer le son pour andLinux (gérer par PulseAudio)

Démarrer andLinux automatiquement

Utiliser Samba pour le partage de fichiers

Nom du répertoire pour le partage de fichiers (il faut au préalable créer le répertoire et demander (gentiment) à Windows de le partager).

Choix de quelques réglages (très bien par défaut)

Et voilà, on se retrouve avec un beau répertoire de 4.3 Go !!!

Utilisation :

Un petit reboot, une petite crise de pare feu plus tard puis après un srvstop et un srvstart, tout fonctionne !

On se retrouve avec une petite liste de programmes par défaut :

Ensuite après une petite mise à jour du système assez utile :

On peut facilement ajouter les programmes que l’on veut via Synaptic :

puis les lancer via un terminal (exemple avec Amarok) :

Conclusion :

Même si je n’y vois personnellement aucun intérêt, je pense que ce genre de programme peut intéresser les programmeurs (c’est pas mal de pouvoir compiler/exécuter ses programme sur du GNU/Linux) et ceux qui veulent utiliser certains programmes sans pour autant utiliser la virtualisation car elle est beaucoup moins performante que andLinux !

De retour en cours après quelques agréables mois de vacances , je commence enfin des études dans l’informatique !
Première semaine agréable puisqu’elle était destinée à une initiation UNIX et plus particulièrement aux commandes UNIX !

Je vais essayer de vous faire une petite liste de celles que j’ai découverte ; rien de transcendant mais cela peut toujours servir !
Spécialistes passez votre chemin, vous n’allez pas apprendre grand chose…

Imprimer un fichier :

lpr -P nomDeImprimante -h fichier

Les liens :

–> Les liens symboliques :

On les crée avec la commande

ln -s

et ils se comportent comme les raccourcis Windows.

–> Les liens physiques :

A la différence des liens symboliques, il crée une sorte de copie du fichier avec les propriétés suivantes :

- Si l’on modifie le lien physique, on modifie le fichier de départ ET vice versa
- Le fichier ne prend qu’une place sur le disque dur (et non pas 2)
- Si l’on supprime l’un ou l’autre des fichiers, il en reste toujours un

On fait cela grâce à la commande

ln

Tuer un processus :

Repérer le PID du processus grâce à la commande

ps aux

et tuer le processus avec

kill -9 PID

Bon, je sais qu’un

pkill nomDeApplication*

marche aussi mais c’est quand même beaucoup moins bourrin si on connaît le PID…

Redirections :

-> Récupérer la sortie d’une commande dans un fichier :

commande > fichier.txt

-> Récupérer les erreurs d’une commande dans un fichier :

commande 2> fichier.txt

-> Ne pas afficher à l’écran les messages d’erreur :

commande 2> /dev/null

Envoyer un mail :

mail -s sujetDuMail adresseDestinataire < fichierContenantLeTexteDuMail

Commande qui devient vraiment intéressante lorsqu’on veut envoyer beaucoup de mail à la fois :

- On crée un fichier listeMails qui contient les mails des destinataires

toto@mail.com
tutu@mail.com
tata@mail.com
…

- On écrit le mail dans un fichier texte mail

- On utilise un petit programme pour l’envoi des mails :

for i in `cat listeMails`
do
mail -s sujetDuMail $i < mail
sleep 1
done

On peut encore modifier un peu la chose pour faire des mails personnalisés du genre :

Chers Monsieur Toto,
…

Il reste bien une commande

date

pour voir l’heure en toute discrétion (sans regarder sa montre :p ) !

Aujourd’hui, il n’est pas question de religion (non, non, non !) mais juste des quelques guides, manuels, tutoriaux, … (appelez ça comme vous voudrez !) qui selon moi valent le coup !

J’ai personnellement utiliser ces documents et j’ai beaucoup appris grâce à eux, j’espère que certains pourront vous aider !

GNU/Linux :

• Installation, configuration et utilisation de Ubuntu : Simple comme Ubuntu (sources en LaTeX disponibles)
• Installation, configuration et utilisation de Debian : Formation Debian GNU/Linux
• Bien configurer son source.list pour Debian : Debian Testing : comment l’utiliser efficacement ?
• Installation de Archlinux : Installation d’Archlinux 0.8

Logiciels Libres :

• Utilisation de Thunderbird : Utilisez Thunderbird 2.0 !
• Utilisation de OpenOffice : Changer pour OpenOffice.org

Formats :

• Audio – Ogg/Vorbis : Ogg Vorbis
• Photo – HDR : Le HDR sous GNU/Linux (v.2)

Programmation :

• Bash : Guide avancé d’écriture des scripts Bash
• LaTeX : Apprends LaTeX !
• Python : Apprendre à programmer avec Python

Divers :

• Typographie française : Petites leçons de typographie

Mise en situation :

Vous avez sur votre ordinateur une belle bibliothèque musicale ; elle est parfaite : bien rangée, bien triée et bien taguée mais le seule problème, c’est que vous n’avez pas les pochettes et vu le nombres d’albums que vous avez, impossible de les chercher une par une sur Internet ou même de scanner la pochette d’origine…

Heureusement, le couple Amarok/CopyCover se charge de tout !

Amarok :

On va d’abord commencer par récupérer toutes les pochettes grâce à Amarok (il récupère pour cela les pochettes disponibles sur Amazon).

Allez donc dans Outils > Gestionnaire de jaquettes > Télécharger les jaquettes manquantes.
Là, Amarok se charge de récupérer toutes les jaquettes qu’il vous manque automatiquement. Vérifier quand même que ce sont les bonnes rapidement, à vu d’œil (un bon 80% réussite chez moi).

Maintenant, Amarok a « en mémoire » les pochettes d’album, mais nous, on aimerai bien les avoir dans le dossier de l’album en question !

CopyCover :

Commencez par télécharger le script.

Ensuite, décompressez le dans un dossier puis :

cd copycover

pour vous placer dans le dossier du script, et enfin, un petit

python copycover-offline.py -c Cover.png

et vous voilà avec un fichier Cover.png dans chacun de vos album qui contient la pochette de l’album en question !

Trop facile !