Showing posts with label fpga. Show all posts
Showing posts with label fpga. Show all posts

Friday, May 23, 2025

Microblaze

Bon, je vais pas faire comme si je m'étais mis au développement FPGA, mais je m'en approche de plus en plus. Assez en tous cas pour avoir commencer à programmer/débugger du code pour des soft cores, c'est à dire des processeurs réalisés à coups de LUTs et de flip/flops à l'intérieur d'un FPGA, qui a pour mission de piloter les différentes unités de traitement écrites en VHDL.

Et c'est l'occasion de découvrir quelques exotismes et autres vieilles connaissances en découvrant un peu l'architecture microblaze, chère à Xilinx. 

  • une instruction imm %%% qui permet de précharger la partie haute/basse d'un mot 32 bits qui devra servir de constante dans une des instructions *i, et ça malgré le fait que toutes les instructions font elles-même 32 bits. (ARM doit aussi jouer à ça, mais d'une façon moins sexy :)
  • un registre r0 qui vaut toujours 0
  • une variante addk en plus de l'instruction add, qui évite que le carry flag soit modifié par effet de bord de l'addition (le compilateur adore, même si ça a l'air un peu gadget la plupart du temps)
  • une variante brid en plus de l'instruction de saut bri, qui permet d'éxécuter malgré tout une instruction qui se trouve après le saut pour éviter de perdre le travail présent dans le pipeline (on avait ça sous le nom "deferred" sur le processeur IXP2400 de ma thèse ... ici, ça peut s'appliquer aussi aux sauts conditionnels (heureusement) et même aux appels de fonction !

the NIOS quest

I had learnt of Microblaze by my FPGA colleagues, of course. It felt a bit weird at first that you would use fully programmable silicium to remake a CPU because I was working on a design where there was a CPU onboard already. And yes, if I want my gates in the FPGA do what they have to (e.g. convert the proper video signal based on width and height), they need to be filled with proper values, and in many cases, a compact CPU fetching instructions from memory is more practical for the job than turning that into state machines that turn into FIFOs and LUTs. I still had to learn that not all of them are microblaze. There are actually so many soft cores!

In intel/altera technosystem, it seems that NIOS is the reference softcore. And readers, it is sure tricky to install. I finally got nios2eds/bin/gnu/*/bin/nios2-elf-addr2line and friends installed on my linux VM after I manually started QuartusSetup-23.1std.0.991-linux.run and manually checked the md5sum because the Intel Quartus Prime Installer was stuck in the "checking file integrity step" forever. Now that it is done, I should be able to close the installer, but it insists that it has a background task to complete. I don't see anything but the qinst processes ... I guess I'll have to kill them manually as well.

So much about not sending humans do machines' job.


Thu Apr 18 16:10:08 2024 INFO: Do download ...
Thu Apr 18 16:10:08 2024 INFO: Path: /tmp/intelFPGA_standard_23.1std
Thu Apr 18 16:10:08 2024 INFO: Total disk space: 21,83 GB
Thu Apr 18 16:10:08 2024 INFO: Free disk space: 4,44 GB
Thu Apr 18 16:10:08 2024 INFO: File: QuartusSetup-23.1std.0.991-linux.run resume position: 0

Thu Apr 18 16:10:08 2024 INFO: GET QuartusSetup-23.1std.0.991-linux.run
Thu Apr 18 16:11:30 2024 INFO: Downloaded /tmp/intelFPGA_standard_23.1std/QuartusSetup-23.1std.0.991-linux.run, 2671252465 bytes (status: 200)
Thu Apr 18 16:11:31 2024 INFO: File: max10-23.1std.0.991.qdz resume position: 0

Thu Apr 18 16:11:31 2024 INFO: GET max10-23.1std.0.991.qdz
Thu Apr 18 16:11:41 2024 INFO: Downloaded /tmp/intelFPGA_standard_23.1std/max10-23.1std.0.991.qdz, 300376601 bytes (status: 200)
Thu Apr 18 16:11:42 2024 INFO: Checking file integrity ...
Thu Apr 18 16:57:02 2024 INFO: Download stopped
Thu Apr 18 16:57:02 2024 INFO: Total download time: 46 mins 54 secs
A few tips about the machine code
  • uses the RISC-typical approach of OP dst, op1 [,op2] except for store instructions that follow STx data, target(offset)
  • movhi reg, 0xcafe ; addi reg, 0xbabe is the natural way to put 0xcafebabe in some register
  • arguments in function calls are put in r4, r5, r6, r7, ...
  • function calls can fit 1 32-bit word.
  • it is not unusual to see a bunch of ldbu reg, ...; stb reg, ... in place of a memcpy call (for small amount of data)

Thursday, September 02, 2010

Comment ça marche ...

Je suis un hacker. Voilà, c'est dit. Attention, pas cracker -- genre "je vais pirater votre ordi et voler votre numéro de carte bleue". Non. Hacker -- genre "passe moi un tournevis, on va regarder comment ça marche", au grand dam de mes copains d'enfance. Alors, voilà. Je code mon jeu sur la DS parce que j'adore la manière dont le hardware graphique se programme. Mais au fait, ça marche comment, le hardware graphique d'une DS? Si j'essayais de reproduire un chip graphique affichant 4 plans, des sprites et tout le tralala sur un FPGA, ça donnerait quoi ?

A friend of mine persistently repeats I've got a hacker's desktop. When hacker == "hand me the screwdriver and let's see how that thing works", I guess he's quite right. Need a proof ? Well, not only I'm coding homebrew games and apps on the nintendo DS (which is supposed to be a closed system), but I can't help thinking of "how could we reprogram an FPGA so that it mimmics the DS' (2D) graphic engine". I know that's pretty pointless: my experience of programmable chip is thin and obsolete (VHDL on PAL 22v10, anyone ?). But what if ... 

Je n'aurai peut-être pas la réponse (je ne suis pas un dieu des FPGA, loin de là) mais la question est posée. En guise d'amuse-gueule voilà déjà le genre de schéma de timing à respecter en sortie (source sur http://www.sharpsma.com/) Quelques lignes de contrôle pour prévenir qu'on commence une image, un temps de réaction de l'écran et c'est parti. Vous donnez une fréquence d'horloge, et sur chaque flanc montant, les lignes Rx Gx et Bx contiennent les composantes RVB d'un pixel. Point après point. ligne après ligne. Avec un temps de resynchronisation (HBLANK) de quelques pixels entre chaque ligne. Et en ayant laissé un temps t1 pour que les données se stabilisent avant lecture, et en les maintenant pendant un temps t2 pour que l'écran les exploite. 

Pour une matrice de 256x256 à 60 images/secondes, il faut quand même cavaler à ~4MHz, et donc pomper les données graphiques correspondantes hors de la VRAM à temps ... Choisir quelle couleur donner en fonction des différents sprites présents, calculer les compositions de couleur genre "alpha-blending", et tout ça. Je sens déjà se dessiner le "pipe-lining" entre les différents stades, tiens.

Digging back in the refs of the Jumbotron project I found the specs of a DS-alike LCD screen ... let's study that a bit to figure out what the problem actually is.