Archives de catégorie : Non classé

Mentor/PAD viewer sous Linux

Non classé, outils, , , , , , , ,

Contrairement aux apparences, le logiciel de visualisation de Schéma/routage de Mentor (Maintenant siemens) PAD peut fonctionner sous Linux sans (trop) de problème.

Mais pourtant, la seule archive à télécharger sur le site officiel est un exe ?! Tout le monde sait qu’un fichier exe est un binaire exécutable pour Windows voir même pour DOS !

De fait, sous Linux, il est possible d’exécuter des exe grâce au vénérable wine. Ce logiciel n’est pas un logiciel franchouillard combattant la loi Évin.

Non ! c’est un émulateur windows qui permet d’exécuter des logiciels windows sous Linux.

En règle générale ça ne fonctionnne pas … Car l’émulation est toujours imparfaite, mais dans le cas du viewer Mentor/PAD le résultat est plutôt honorable et permet de visualiser des schéma/routage qu’on vous envoit.

Pour créer des cartes électroniques et/ou en éditer on préférera bien sur Kicad qui lui est parfaitement compatible avec Linux en plus d’être un logiciel libre.

Comment ça marche ?

On suppose que vous avez wine installé sur votre machine et que vous avez téléchargé l’archive de PADviewer . Il vous suffira ensuite de taper wine suivi du nom de l’archive :

 $ wine PADSViewerVX.2.15_mib.exe

The most recent version of MIP is already installed in: c:\mentorgraphics\instal
l
MIP related file c:\mentorgraphics\install\tmp\FABIENM-TUXEDO-_32\ddinst32.exe w
as extracted successfully
MIP related file c:\mentorgraphics\install\tmp\FABIENM-TUXEDO-_32\vlhostid.exe w
as extracted successfully
MIP related file c:\mentorgraphics\install\tmp\FABIENM-TUXEDO-_32\ssidddp.sys wa
s extracted successfully
...
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (build 11.0.13+8, mixed mode)
053c:err:richedit:ReadStyleSheet skipping optional destination
053c:err:richedit:ReadStyleSheet skipping optional destination
053c:err:richedit:ReadStyleSheet skipping optional destination
053c:err:richedit:ReadStyleSheet skipping optional destination
061c:err:richedit:ReadStyleSheet skipping optional destination
061c:err:richedit:ReadStyleSheet skipping optional destination
061c:err:richedit:ReadStyleSheet skipping optional destination
061c:err:richedit:ReadStyleSheet skipping optional destination
0744:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
0744:err:ole:CoDisconnectObject apartment not initialised
075c:err:ole:CoDisconnectObject apartment not initialised
075c:err:ole:CoDisconnectObject apartment not initialised
Error getting install status ...

Cela va lancer l’installeur graphique qui va décompresser l’archive avec quelques erreurs plus ou moins compréhensible à la micro$oft.

Une fois l’installation terminée, même avec erreur le programme se retrouvera installé dans votre home ~/.wine/drive_c :

~/.wine/drive_c/SiemensEDA/PADSVX.2.15Viewer/SDD_HOME/Programs/powerpcbviewer.exe

Programme que l’on pourra lancer, toujours avec wine pour visualiser son fichier pcb :

$ wine /home/user/.wine/drive_c/SiemensEDA/PADSVX.2.15Viewer/SDD_HOME/Programs/powerpcbviewer.exe
Vue de la fenêtre PADpcbviewer lancée dans Linux avec Wine

Pour le schéma (fichier sch) on utilisera powerlogicviewer.exe de la même manière.

Le viewer fonctionne assez bien, on arrive également à connecter le schéma avec le routage. Il y a quelques problèmes de police de caractères et parfois le logiciel plante, mais c’est un logiciel windows à l’origine, il y a des traditions à respecter 😉

Couleur des log dans (neo)vim

Non classé, ,

La synthèse et le placement routage génère de grande quantité de texte de «log». Dans ces logs, les problèmes s’étagent avec 3 niveaux de «danger» :

  • INFO: juste une information
  • WARNING: Un problème qu’il faut lire mais qui peut souvent être ignoré
  • ERROR: Je ne dirais pas que c’est un échec, mais ça n’a pas marché

Si on utilise Vim (ou neovim) pour lire les logs on aimerait avoir de la surbrillance de couleurs différentes en fonction de la gravité du message.

Un truc comme ça :

Saisie d'écran de vim avec un fichier de log fictif ouvert. On y voit le texte INFO en blanc sur bleu, le texte Warning en blanc sur jaune et le texte ERROR en blanc sur rouge

C’est quelques chose qui est relativement facile à mettre en place dans neovim. Il faut tout d’abord créer un fichier de syntaxe dans le répertoire ~/.config/nvim/syntax que l’on nommera log.vim et qui contiendra ceci :

" my highlight rules for fpga logs
syntax match fpgaloginfo /INFO\c/
syntax match fpgalogwarn /WARNING\c/
syntax match fpgalogerr  /ERROR\c/
highlight fpgaloginfo  ctermbg=blue guibg=blue
highlight fpgalogwarn  ctermbg=3 guibg=orange
highlight fpgalogerr   ctermbg=red guibg=red

Puis il faut dire à vim que les fichiers terminant par .log sont de type log en ajoutant la ligne suivante dans son fichier de configuration ~/.config/nvim/init.vim :

autocmd! BufRead,BufNewFile *.log     set syntax=log
autocmd! BufRead,BufNewFile *.rpt     set syntax=log

De cette manière, à chaque fois que nvim ouvrira un fichier nommé monfichier.log, il chargera la coloration syntaxique que nous avons configuré.

Comment générer du SystemVerilog et/ou du Verilog avec Chisel 6

Non classé, , , , ,

Avec les dernières version de chisel le «backend» de génération du verilog a changé.

SystemVerilog

Avec circt on peut générer en systemVerilog avec la méthode emitSystemVerilogFile() inclue dans le package: 

import circt.stage.ChiselStage

//...

class MonModule extends Module {
 //...
}

object MonModule extends App {
    ChiselStage.emitSystemVerilogFile( new MonModule(),
      firtoolOpts = Array("-disable-all-randomization",
                          "--lowering-options=disallowLocalVariables",
                          "-strip-debug-info"))

}

Le fichier généré se nommera MonModule.sv

Verilog

Pour générer du Verilog il faut utiliser l’ancienne méthode que l’on trouve dans le package chisel3.

object MonModule extends App {
    val filename = "MonModule.v"
    println("Generate verilog source for ChisNesPad Module")
    val verilog_src = chisel3.emitVerilog(new MonModule)
    val filepath = os.pwd / filename
    if (os.exists(file)) os.remove(file)
    os.write(filepath, verilog_src)
}

Le choix

Et l’on peut s’ajouter une option à la ligne de commande si l’on veut avoir le choix.

import circt.stage.ChiselStage

//...

class MonModule extends Module {
 //...
}

object MonModule extends App {
  if (args.length == 0) {
  } else if (args(0) == "--systemVerilog") {
    ChiselStage.emitSystemVerilogFile( new MonModule(),
      firtoolOpts = Array("-disable-all-randomization",
                          "--lowering-options=disallowLocalVariables",
                          "-strip-debug-info"))
  }
}

On lancera les commandes suivantes pour générer l’un ou l’autre :

# générer le verilog
sbt "runMain MonModule"
# générer le systemVerilog
sbt "runMain MonModule --systemVerilog"

Quickfeather eos s3 logic cell (pp3)

Non classé, , ,

Quand on utilise la suite symbiflow pour synthétiser un projet sur le eFPGA (pp3) de la quickfeather on tombe sur des nom étranges de cellule logique.

Circuit Statistics:
  Blocks: 65
    .output   :       3
    ASSP      :       1
    BIDIR_CELL:       3
    C_FRAG    :       7
    F_FRAG    :       1
    GND       :       1
    Q_FRAG    :      22
    T_FRAG    :      26
    VCC       :       1

À quoi correspondent les blocks C_FRAG, T_FRAG, ASSP, … ?

Et il est assez compliqué de trouver la documentation correspondante. On retrouve une description en Verilog de ces blocs dans le répertoire suivant du SDK :

$ ls qorc-sdk/fpga_toolchain_install/v1.3.1/quicklogic-arch-defs/share/techmaps/quicklogic/pp3/techmap/
cells_map.v  cells_sim.v  lut2tomux2.v  lut2tomux4.v  lut3tomux2.v  mux4tomux2.v  mux8tomux2.v

Et plus particulièrement dans le fichier source cells_map.v qui semble décrire au moyen de plusieurs «FRAG»ment de module le schéma de la figure 36 de la datasheet (page 60).

Le schéma d’une «Logic Cell Block» trouvé dans la datasheet

En lisant le code du fichier cells_sim.v on trouve les relations suivantes dans le schéma.

Annotation du schéma de cellule logique à partir du fichier cells_sim.v

Les nom de signaux QDI et QDS ne se trouvent pas dans le fichier source, ils sont liés au multiplexeur situé devant la bascule D Q_FRAG et semble correspondre aux constantes CONST0 et CONST1 que l’on trouve dans les sources.

Pour les fragments T_FRAG et B_FRAG c’est moins clair en se servant du nom des signaux mais ils semblent liés à des bits de configuration que l’on trouve à gauche du schéma (BAS, BBS, TAS, …)

On imagine aisément que le FRAG correspond à Fragment mais les lettres préfixes sont moins claires.

Si on fait la liste des noms de block donnés au début on a

  • ASSP: celui là est plus clair. C’est le bloc qui assure la communication avec le microcontrolleur, avec les différents signaux de bus (Wishbone, SPI, …) ainsi que l’horloge, et autres signaux de contrôles.
  • BIDIR_CELL: Ça c’est un buffer d’entrée sortie `iopad`
  • C_FRAG: Cet enchevêtrement de multiplexeurs ressemble fort à une LUT avec une sortie retenue (C pour Carry).
  • F_FRAG: Là on a affaire à un simple multiplexeur deux entrées, pour faciliter le routage (routage rapide ?)
  • GND: bon bin … la masse quoi (mais qu’est-ce que ça vient faire là ?)
  • Q_FRAG: Q pour la sortie de la bascule D Flip flop.
  • T_FRAG: ?
  • VCC: L’alim, …
  • B_FRAG: celui là n’est pas dans le rapport de routage mais se trouve dans le code verilog, il ressemble à T_FRAG.

Tout cela n’est pas parfaitement claire.

Et surtout on aurait aimé avoir un schéma d’architecture du eFPGA comme on peut le voir dans les datasheet des autres constructeur. Avec l’alignement des différentes cellule et une description graphique des entrées sorties.

C’était juste une prise de note (susceptible d’évoluer comme d’habitude) pour tenter de comprendre ce FPGA à la documentation pas très claire.

[Edit 2024/01/19]

J’ai eu des réponses sur le site officiel \o/ Il y a plus de détails du coup. Je vais pouvoir continuer mes investigations.

Getting started with FPGAS

Non classé, , , ,

Russell Merrick est un ingénieur en électronique qui travail sur des FPGA depuis plus de 15 ans. C’est l’auteur du site internet Nandland qui propose toute une série de tutoriels pour débuter et s’amuser avec des FPGA.

Russell vient de sortir un livre chez No Starch Press pour débuter avec un FPGA.

En seulement 280 pages, on peut dire que l’auteur couvre bien le sujet. Les deux langages HDL du «marché» sont décrits et tous les exemples sont donnés en Verilog ainsi qu’en VHDL.

C’est la première fois que, dans un livre, je vois un vrai comparatif des deux HDL. En effet, l’un est souvent balayé au profit de l’autre avec un «si vous connaissez l’un vous saurez vous servir de l’autre». Même si l’accent est mis sur le ICE40 de Lattice (Célèbre FPGA lowcost reversé dans le projet icestorm), on sent bien qu’il existe d’autres constructeurs et que l’auteur a travaillé avec.

Le livre n’est pas si gros et pourtant il traite vraiment de tout ce qu’il faut savoir pour bien commencer (et avancer) dans le FPGA.

Un chapitre entier est consacré aux bascule D (FlipFlop) et à la problématique de conception synchrone. La notion de domaines d’horloge et son franchissement, les machines d’états, les macro classique (RAM, PLL, DSP) ne sont pas en reste.

Et avant d’aborder les entrées sorties (I/O, LVDS, SerDes) un chapitre particulièrement intéressant sur l’arithmétique est abordé. Tout est dit pour additionner, soustraire, multiplier et diviser (enfin surtout les méthodes de contournement de la division) des entiers mais également des nombres en virgules fixe (Qn.m) dans un FPGA.

C’est un livre que j’aurais adoré avoir pour débuter en FPGA, mais qui fera tout de même un très bon livre de référence au besoin.

Cartes Gatemate

Non classé, , ,

Nous avons déjà parlé du Gatemate dans les colonnes du FLF. Mais jusqu’à présent, seul le kit de développement officiel de CologneChip était disponible. Le tarif du kit officiel étant assez élevé on attendait avec impatience d’avoir des cartes développées par des tiers pour pouvoir investir.

Ce qui est chose faite avec les kits suivant. La note reste éditable au grès des sorties de kit muni du FPGA.

Evaluation board officielle par CologneChip

À tout seigneur tout honneur, citons d’abord du kit officiel qui est proposé à un prix de 226€ sur digikey.

Le kit officiel du GateMateA1 proposé par CologneChip dans sa belle boite en carton

Olimex GateMate-A1

Annoncé en décembre 2023 par Olimex, le kit GateMateA1 devrait être proposé au tarif de 50€.

La carte GateMate A1 annoncée par Olimex

TrenzMicro TEG2000-01-P001

Le SoM de TrenzMicro TEG2000-01-P001 est dans les même ordre de grandeur au niveau tarif (69€) mais nécessitera une carte d’accueil pour s’en servir.

Le SoM (System on Module) de Trenz micro avec le GatemateA1

Identification des bitstreams de la série 7 avec usr_access2

Non classé, , ,

Le processus de synthèse/placement/routage/bitstream prenant beaucoup de temps, on est amené à faire d’autres activité pendant le traitement. Ce «switch» de tâche nous amène à faire des erreurs fréquentes de version de bitstream au moment de la configuration du FPGA.

Il est fréquent de passer des heures voir des jours sur un bug qui n’en était finalement pas un puisque nous n’avions pas mis à jour la version du bitstream.

Pour éviter ce problème il faut pouvoir lire la version du bitstream généré de manière à s’assurer qu’on travail bien avec la bonne.

C’est exactement l’objet de la macro «usr_access» des FPGA de la série 7 de Xilinx.

Cette macro est appelée de la manière suivante en VHDL :

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;

Entity usr_accesse2 is
port
(
  CFGCLK : out std_logic;
  DATA : out std_logic_vector(31 downto 0);
  DATAVALID : out std_logic
);
end entity;

Architecture usr_accesse2_1 of usr_accesse2 is

begin

  CFGCLK <= '1';
  DATA <= x"00000E0F";
  DATAVALID <= '1';

end architecture usr_accesse2_1;

Et la valeurs de la sortie «DATA» est ré-inscriptible jusqu’à la génération du bitstream avec l’option -g USR_ACCESS.

Pour y mettre la date et l’heure on utilisera l’option timestamp dans le menu tools->edit device property.

Cette action à pour effet d’ajouter la commande suivante dans le xdc :

set_property BITSTREAM.CONFIG.USR_ACCESS TIMESTAMP [current_design]

Mais elle ne met pas la date chez moi pour le moment 🙁