Aujourd’hui, je vais vous expliquer comment utiliser SCIM pour taper facilement les caractères chinois ou japonais sous GNU/Linux.

SCIM

SCIM, pour Smart Common Input Method, est un logiciel conçu pour faciliter la saisie des caractères complexes et des symboles (tels que les caractères chinois, coréens, japonais ou d’origine Indienne (Sanskrit, Tamoul, Tibétain…), à l’aide d’un clavier occidental classique.

Installation et configuration de SCIM pour le chinois

Sous Archlinux, rien de plus simple, tout est dans les dépôts !
Il faut alors installer :

• scim : le logiciel de base,
• scim-pinyin : le module qui gérera l’écriture en pinyin,
• ttf-arphic-uming : font (police) pour OpenOffice.org par exemple (facultatif).

Ensuite, il faut un peu configurer tout ça :

• Ajouter bashrc ou xinitrc ou … pour que les variables d’environnement soient prises en compte :
  

  export XMODIFIERS=@im=SCIM
  export GTK_IM_MODULE="scim"
  export QT_IM_MODULE="scim"

• Modifier le fichier ~/.scim/global pour qu’il prenne en compte le clavier français et les locales fr :
  

  /DefaultKeyboardLayout = French
  /SupportedUnicodeLocales = en_US.UTF-8,fr_FR.UTF-8

• Ajouter enfin zh_CN.UTF-8 UTF-8 a vos locales.
• Si vous souhaitez que le logiciel soit toujours lancé, lancer scim -d

Relancer enfin votre session pour que tout soit pris en compte.

Utilisation

Lorsque le logiciel est lancé, il ne reste plus alors qu’à activer la saisie avec CTRL + espace (valeur pas défaut) et commencer à taper en pinyin.
Lorsque vous aurez fini votre mot, il s’affichera une petite fenêtre pour que vous puissiez choisir le bon idéogramme avec les flèches Haut et Bas de votre clavier.


J’ai aussi eu l’occasion de tester cela avec le japonais, et cela marche également très bien !

Références et liens :

• Wiki Archlinux sur SCIM (en)
• Article Wikipédia sur SCIM (fr)

Le 15 Novembre, Mike Galbraith a proposé un petit patch de 200 et quelques lignes pour le kernel Linux qui à beaucoup fait parler de lui. Ce patch touche au scheduler du kernel et permettrai d’améliorer de manière assez hallucinante la réactivité du système lorsqu’il est soumis à une forte charge. Donc après avoir lu de nombreuses petites choses contradictoires, dans des articles, et surtout dans les commentaires des articles, à propos du patch, et parce que les tests de Phoronix sur un core i7 ne sont pas du tout représentatifs de mon matériel, j’ai voulu le tester.

Patchage du kernel

Donc pour tester, j’ai patché un kernel gentoo 2.6.36-r1, il m’a fallu modifier 2 bouts de code du kernel à la main parce que le patch n’arrivait pas à les modifier, visiblement parce que les patchs de gentoo sont aussi allé gratter autour de la zone à patcher, donc entraient en conflit. Une fois patché, j’ai rajouté l’option « General Setup –> Automatic process group scheduling » dans menuconfig qui a pris soin de rajouter les dépendances tout seul. Et après compilation et installation plus qu’à rebooter

Environnement de test

Pour les tests, j’ai une machine avec un CPU Pentium-m (en gros un Pentium 3 légèrement plus évolué) avec un Gentoo Linux. J’ai généré la charge du système en compilant un kernel sur 20 processus avec make -j 20. Résultat, avec le patch mon système reste aussi réactif que quand il est idle, je peux scroller de manière très fluide dans Firefox, changer d’onglet sans que ça ram, passer d’un bureau à l’autre et faire bouger les fenêtes sans problème. J’ai fait les même tests sans le patch, et là on sent vraiment l’impacte de la compilation, il faut une seconde pour changer d’onglet ou scroller dans Firefox, même passer d’une ligne à l’autre avec la flèche du clavier dans htop ram beaucoup, le système peine à changer de bureau et tout. On sent vraiment la différence.

Test de Phoronix

Pour voir un autre test, Phoronix à fait une petite vidéo, mais à base de Core i7, que tout le monde a bien évidemment dans son garage Ils ont chargés un peu plus le système, mais je trouvais pas ça représentatif des machines que j’ai l’habitude d’utiliser. Le test avec vidéo comparatives est disponible ici.

Conclusion

Donc ce patch est vraiment très efficace pour améliorer la fluidité du système lorsqu’il est soumis à une charge importante. On comprend vite le buzz qu’il y a autour quand on le test. Même si je pense que l’amélioration va paraître assez faible dans une utilisation quotidienne, vu qu’on lance assez rarement plus de 2 ou 3 grosses tâches réclamant chacune 100% du CPU en même temps. Et c’est surtout sur les systèmes lents, et mono-processeur qu’on va voir une amélioration, vu qu’avant de voir le gros des avantages du patch, il faut avoir monté tous ses processeurs à 100%. Et attention aux idées qu’on peut se faire en lisant certains articles et commentaires à propos de ce patch, il n’augmente pas la vitesse du système, le système n’a pas amélioré sa vitesse de boot non plus Et cette amélioration n’est pas destinée uniquement aux systèmes multi-cœurs.

Pour ceux qui vont attendre qu’il soit mis dans la branche principale du Kernel, il faudra attendre la 2.6.38 vu que les modifications sont maintenant bloquées pour la 2.6.37. Sinon il est toujours possible d’appliquer le patch soit même

Références

La discussion entre l’auteur du patch et Linus Torvalds où on peu trouver le patch : ici

Édit : à la suite de quelques commentaire, j’ai reformulé l’article pour mieux mettre en évidence les motivations qui m’ont amenées à utiliser cette solution.

Parce que y’en a marre de jamais avoir les mêmes alias du compte utilisateur au compte root, je viens de faire en sorte de partager un bout du bashrc entre ces différents comptes, sans pour autant affecter les autres utilisateurs de la machine. Comme je ne veux pas que mes modifications affectent d’autres utilisateurs, il n’est pas possible d’utiliser le ficher /etc/bashrc.

Sécurité

Nous allons donc créer un fichier qui contient la partie commune du bashrc. Dans mon cas, je partage le bashrc entre mon utilisateur et le compte root, or le bashrc contient des commandes qui sont exécutées à chaque fois qu’on ouvre le terminal, ou qu’on passe en root avec la commande su. Il est donc important que l’utilisateur ne puisse pas rajouter de commandes qui seront ensuite exécutées en root, donc ce fichier doit être possédé par root, disponible en lecture par tout le monde, et en écriture uniquement par root. Les permissions doivent donc être :

$ ls -l /home/ezaeza/.bashrc-common
-rw-r–r– 1 root root 272 11 nov 23:37 /home/ezaeza/.bashrc-common

Mise en place

Voilà pour les mises en garde de sécurité. Donc en root, créer le fichier nommé par exemple .bashrc-common dans un endroit visible par tous les utilisateurs qui vont le partager (donc pas dans /root/), dans mon cas je l’ai mis dans /home/ezaeza/. Il est ensuite possible d’y mettre toutes les commandes et alias à partager avec les autres utilisateurs.

Dans le .bashrc de chaque utilisateur il faut ensuite faire importer le fichier common, par exemple dans mon cas, le bashrc de root et ezaeza commence par :

. /home/ezaeza/.bashrc-common

(point espace /le/chemin/le-fichier-common)

Il est ensuite possible de rajouter n’importe quelle commande propre à l’utilisateur à la suite du bashrc.

Installation des pilotes d’impression lexmark-08z-series-driver-1.0-1 sur Gentoo ou ArchLinux, et probablement de nombreuses autres distributions Linux. (Ce package contient des pilotes pour de nombreuses imprimantes Lexmark, notamment les modèles : Lexmark Z2420, Lexmark Z2490, Lexmark X3650, Lexmark X3690, Lexmark X4630, Lexmark X4650, Lexmark X4690, Lexmark X4950, Lexmark X4975ve, Lexmark X4975, Lexmark X5070, Lexmark X5075, Lexmark X5650, Lexmark X5690, Lexmark X6650, Lexmark X6675, Lexmark X6690, Lexmark X7675).

J’ai acheté une imprimante Lexmark X4650 car j’avais vu que Lexmark fournissait des pilotes (seulement pour USB, pas WiFi) pour RedHat et Debian. Je me suis dit que ça devrait donc marcher facilement sur les autres distributions. Il n’a pas fallu longtemps pour que je m’aperçoive qu’il n’y avait aucune documentation, et que personne ne semblait y être arrivé. Donc voilà, après 10 heures à essayer de tout décortiquer le fichier en .i386.rpm.sh.tar.gz tout fucké, le pilote fonctionne sur Gentoo et ArchLinux, et avec en prime la compatibilité du WiFi (qui n’est pas assurée d’après le site de Lexmark).

Sur ArchLinux, avant de démarrer cups, il faut démarrer le service /etc/rc.d/avahi-daemon.

Toujours avec ArchLinux, il y a encore un soucis de permission visiblement avec cups pour l’installation par USB (pas réseau qui fonctionne). L’impression par USB échoue sur une erreur « Job stopped due to filter errors », il faut peut être regarder du côté de apparmor pour résoudre ce problème. Pour ceux qui veulent tester par USB, pensez à blackliser le module usblp comme l’indique la doc, c’est avec ça que je suis arrivé la plus loin. Mais l’utilisation de l’imprimante par réseau WiFi étant moins contraignante que par USB dans la plupart des cas, je n’ai pas trop cherché comment la faire fonctionner en USB.

Téléchargement

Donc après avoir passé 3 heures à sortir le rpm du fichier ignoble fourni par Lexmark et l’avoir converti en tar, vous pouvez le télécharger ici : lexmark-08z-series-driver-1.0-1.i386.tar.gz

À noter que cette version retire toute la partie interface graphique, notamment l’endroit ou vous devrez accepter la licence Lexmark. Il s’agit juste du rmp original contenu dans le fichier fourni par lexmark que j’ai extrait et converti en tar.

Installation

Tous les fichiers contenus dans ce tar sont dans usr/local/lexmark/, donc en root :

# tar xvf lexmark-08z-series-driver-1.0-1.i386.tar.gz -C /

# cd /usr/local/lexmark

Il faut ensuite créer tous les liens symboliques des librairies et tout

# ./08z-series-driver.link /usr/local/lexmark

Voilà l’installation est normalement terminée.

Notez l’existence du fichier 08z-series-driver.unlink, pour désinstaller les pilotes, il suffira donc de l’exécuter (sans arguments) et de supprimer les dossiers /usr/lexinkjet et /usr/local/lexmark

Configuration de cups

Maintenant que les pilotes sont installés, il faut configurer cups.

Commencez par démarrer cups si c’est pas déjà fait (sous ArchLinux c’est dans le /etc/rc.d)

# /etc/init.d/cupsd start

Il faut ensuite aller dans l’interface de cups avec un navigateur web à l’adresse http://localhost:631 aller dans la partie administration, et quand il faut s’identifier, rentrer les identifiant root avec le mot de passe root. Cliquez sur ajouter une imprimante.

Note : L’imprimante à déjà été utilisée et mise en service avec les outils fourni par Lexmark pour windows, il y a peut être des opérations qui ont été effectués à la mise en service de l’imprimante qui ne le seraient pas avec ma méthode d’installation (j’ai extrais le paquet de tous les scripts de Lexmark, qui ne sont donc pas exécutés). Si tel est le cas, il est toujours possible de la mettre en service avec un liveCD Ubuntu en utilisant les pilotes Ubuntu fournis par Lexmark, et ensuite reprendre l’installation pour votre distribution favorite.

Pour les utilisateurs Gentoo, pensez à faire un tour sur la doc Gentoo d’ajout d’une imprimante, il faut quelques options dans le kernel.

Pour les utilisateurs ArchLinux, cups est plus récent sur ArchLinux, la démarche est semblable à celle décrite mais pas dans le même ordre.

Installation de l’imprimante en USB

Si ce n’est pas déjà fait, branchez l’imprimante.

La première partie de l’ajout d’imprimante vous demande d’indiquer un nom, une description et une location, faites comme vous le souhaitez, ça n’a pas d’importance.

Ensuite, dans la partie matériel, l’imprimante devrait être détectée, par exemple pour une X4650, il faut sélectionner quelque chose de semblable à « Lexmark 3600-4600 Series USB #1″ et valider

Ensuite, il y a plein de modèles affichés, mais cliquez en bas sur parcourir pour indiquer un fichier ppd manuellement, allez chercher ce fichier dans /usr/local/lexmark/08zero/etc/ et sélectionnez celui qui correspond à votre imprimante, pour une x4650, c’est le fichier lx36-46.ppd. Vous pouvez ensuite cliquer sur ajouter une imprimante, et normalement l’imprimante devrait être fonctionnelle

Installation de l’imprimante sur le Réseau

Vous êtes normalement dans la partie où on vous demande de préciser un nom, un lieu et une description, indiquez ce que vous voulez, ça n’a pas d’importance.

Dans la partie matériel, sélectionner AppSocket/HP JetDirect

Dans l’uri du matériel, indiquez : socket://ip_de_l_imprimante:9100

Cliquez sur parcourir pour ajouter un fichier ppd manuellement, allez chercher ce fichier dans /usr/local/lexmark/08zero/etc/ et sélectionnez celui qui correspond à votre imprimante, pour une x4650, c’est le fichier lx36-46.ppd. Vous pouvez ensuite cliquer sur ajouter une imprimante, et normalement l’imprimante devrait être fonctionnelle

Conclusion

Même quand Lexmark fourni des drivers « Linux » c’est sur quelques distributions, mais pas toutes, donc Lexmark est toujours une marque d’imprimante à boycotter pour utiliser sous Linux. Il m’a fallu plus de 10 heures pour trifouiller dans le truc ignoble qu’ils donnent pour en extraire les pilotes, et comprendre comment installer tout ça sans aucune documentation. Et juste pour l’imprimante, j’ai pas encore regardé le scanner.

Cet article est sous licence GNU/FDL, n’hésitez pas à l’améliorer et à le propager sur les sites de documentation GNU-Linux en tout genre.

Références

• les pilotes fournis par Lexmark : lexmark-08z-series-driver-1.0-1.i386.rpm.sh.tar.gz (avec l’extension qui fait rêver, mais oui c’est bien un joyeux mélange de tout ça en un seul fichier)
• le forum Ubuntu qui en parle, et qui fourni l’idée pour l’utilisation réseau : ici
• la documentation Gentoo pour installer une imprimante : ici
• la documentation ArchLinux pour installer une imprimante : ici
• openprinting.org, le site qui vous permettra de trouver des imprimantes autre qu’une Lexmark qui fonctionne vraiment sous Linux, et pas juste sur 2 distributions.

J’ai acheté mon nouveau serveur hier (un Pentium 3), j’y croyais pas trop mais j’ai quand même espéré pouvoir faire mon installation d’Archlinux par USB. Forcément il n’a pas fallu longtemps pour que je m’aperçoive que le boot par USB n’était pas encore supporté sur ce genre de machine.

Donc je me suis retrouvé sans graveur CD, sans CD vierge, mais avec un liveCD Gentoo i386. Et au bout de 5 minutes je me suis souvenu qu’il était possible d’installer Archlinux par chroot à partir d’une autre distribution, et ça a été la libération Et en plus c’est plus écologique de pas avoir à graver d’autre CD

L’installation est très simple, il m’a suffi de booter le liveCD Gentoo, de connecter la tour au réseau avec dhcpcd. Pour plus de confort j’ai lancé le serveur ssh du liveCD, j’ai changé le mot de passe root avec passwd pour pouvoir me connecter avec ssh depuis mon portable. Ensuite, il n’y a plus qu’à suivre la documentation d’installation par chroot. C’est assez simple, il m’a fallu modifier quelques petites choses pour tout faire fonctionner, mais l’installation s’est passée en moins d’une heure (si on compte pas l’heure que j’ai perdu parce que j’arrivais pas à formater le disque dur comme il faut, honte à moi)

J’ai aussi eu un petit souci avec l’installation de grub, la commande grub-install /dev/sda faisait une erreur, en regardant la doc anglaise ils proposent de faire ça à la main avec la commande grub, et ensuite c’est la procédure habituelle.

Donc il n’est pas nécessaire d’avoir une grosse collection de liveCD, on peut vraiment tout faire avec un seul liveCD, même installer un kernel sur un système où un boulet d’amin les a tous désinstallés

Références

• Guide d’installation par chroot d’Archlinux (français) : wiki.archlinux.fr
• Guide d’installation par chroot d’Archlinux (anglais, mais plus compet) : wiki.archlinux.org

Voici une petite optimisation que je viens de découvrir en parcourant rapidement un bout de doc de Gentoo. Il est possible d’activer une option pour que Portage télécharge les paquets suivants pendant qu’il en installe ou met un à jours un autre. La manipulation est toute simple, il suffit d’éditer le fichier /etc/make.conf, et soit rajouter la variable FEATURES, soit de rajouter dans cette variable à la suite la valeur parallel-fetch, par exemple :

FEATURES="prelink ccache parallel-fetch"

Ceci peut permettre de gagner pas mal de temps dans le cas des gros programmes, vu que la compilation pourra démarrer sans avoir à attendre plusieurs dizaines de secondes que le programme soit téléchargé (enfin plusieurs minutes pour ceux qui habitent en Ardèche ^^)

Références

• Bout de doc sur les fonctionnalités de Portage : http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=2&chap=3

En tant qu’utilisateur gentoo, j’ai très souvent recours à la compilation, et avec un Pentium-M 1,4GHz, 1Go de ram, et un disque dur 4200RPM, ça prend très longtemps de tout compiler (sauf open office ou je prends les binaires, je ne suis pas suicidaire non plus ^^). Il y a déjà un moment j’avais regardé comment diminuer les temps de compilation. Et ce n’est pas la documentation qui manque à ce sujet sur Gentoo. J’utilise donc ccache depuis un bon moment.

Distcc

Mais c’est probablement distcc qui offre le plus gros potentiel de gain. Cependant il y a plusieurs contraintes non négligeables qui m’ont fait abandonner à la première tentative : la cross-compilation pas très user friendly à mettre en place (compilation pour une architecture 32bit sur une architecture 64bit) et gcc assez pénible à mettre à la même version sur toutes les machines.

Mise en place du test

Ayant dans le cadre de mes cours un accès sur des machines avec 2 processeurs Intel Xeon E5405 2.00GHz (ça fait 2 processeurs quad core), 8Go de ram, etc, j’ai voulu retenter l’expérience, mais depuis mon appartement, avec un accès ssh sur une connexion internet avec environ 120Kio/s en émission, et 1Mio/s en réception, du portable (:le proc 1.4GHz) vers le serveur (: la machine avec les 8 coeurs), et dans l’autre sens, une connexion plus grosse que la première qui n’est pas le facteur limitant.

Ne disposant pas des droits d’administation sur le serveur, j’ai téléchargé et compilé à la main distcc sans l’installer. Après un petit moment de bidouillage, dont le passage par un tunnel ssh pour contourner le firewall, je suis arrivé à partager ma compilation.

Résultats

Avec une telle puissance de calcul sur le serveur, j’espérais des résultats assez intéressants. Mais la connexion internet a été le facteur limitant Voici quelques résultats de la compilation d’un vieux kernel linux-2.6.30-gentoo-r8 dont les sources et la configuration perso traînaient encore dans un coin de mon disque dur :

• Compilation distante uniquement : j’en ai eu marre, ça avançait pas j’ai tout coupé
• Compilation distante + local en même temps sur la charge CPU restante du portable, lancé avec la commande make CC=distcc -j10 : 21 minutes 28 secondes en utilisant assez peu le PC pour autre chose pendant la compilation
• Compilation locale uniquement, 2 essais, lors du premier j’ai pas mal tiré sur le CPU avec firefox en supprimant les 6500 spams qui traînaient sur ce blog, j’ai donc relancé une 2ème fois sans trop tirer sur la machine pour essayer d’avoir des conditions semblables à l’essai partagé : 22 minutes 29 secondes, et 18 minutes 57 secondes

Les résultats seraient peut être un peu différents avec la compilation d’autres programmes, et dans de meilleurs conditions de tests, mais je suis pas sûr qu’il seraient bien différents en remplaçant la super machine de compète qu’on utilise au final presque pas, par une game boy tant qu’on a pas la bande passante suffisante.

Sur le site de distcc ils proposent le scénario de lancer des compilations depuis son jardin en WiFi avec un petit portable, mais vu qu’on peut s’estimer heureux quand on a le mega par seconde en WiFi (avec la norme g) je suis pas sûr qu’on ne passe pas plus de temps à configurer distcc et mettre tous les compilateurs à la même version, que ce qu’on peut gagner avec distcc. Mais donc pour en avoir le cœur net, si j’ai la motivation, et surtout le temps, je testerai tout ça à l’école avec le réseau WiFi local, et si j’ai encore plus la motivation, pourquoi pas en ethernet 100Mbit/s avec les 24 machines de la salle 192 CPU de 2GHz, ça laisse rêveur … Mais déjà exploiter 100% du potentielle d’une seul de ces bestioles serait magnifique.

À noter que dans cet article on peut avoir l’impression que je dis que distcc sert à rien, mais attention, le problème vient clairement de la connexion internet. Sur un réseau local, le site de distcc annonce un gain de vitesse de 2.6 fois en rajoutant 2 machines pentium 4 avec distcc à une compilation d’un kernel sur une machine en Pentium 4.

Références

• Site de distcc : http://distcc.samba.org
• Documentation Gentoo sur distcc : http://www.gentoo.org/doc/fr/distcc.xml
• Documentation Gentoo sur l’optimisation de portage : http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=2&chap=3

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)