Préparer un entretien technique embarqué avec un mini fpga : checklist de tests et script de démonstration

Lorsque l’on me demande de préparer un entretien technique autour d’un mini FPGA, j’ai appris à ne rien laisser au hasard : l’entretien doit montrer à la fois vos compétences techniques, votre méthode de travail et votre capacité à expliquer clairement vos choix. Sur Nouvelingenieur.fr je partage ici une checklist pratique de tests à réaliser sur votre carte, et un script de démonstration que vous pourrez adapter selon la carte (TinyFPGA, iCEBreaker, Digilent Arty, etc.) et le langage que vous maîtrisez (Verilog, VHDL, Migen, LiteX).

Objectifs de l’entretien et de la démo

Avant de préparer les fichiers et le câblage, posez-vous ces questions simples : qu’est-ce que je veux prouver en 10–20 minutes ? Souvent, l’employeur cherche :

• La compréhension des contraintes matérielles (IO, horloges, contraintes de timing)
• La capacité à synthétiser et à déboguer un design simple
• La maîtrise des outils de chaîne (synthèse, placement-route, programmation)
• La clarté dans l’explication du design et des choix d’implémentation

Mon but est donc de préparer une démo courte, robuste et compréhensible. Mieux vaut une démo simple mais qui fonctionne à tous les coups que vingt fonctions qui bugguent.

Checklist matérielle avant l’entretien

Je vérifie systématiquement le matériel la veille et le matin de l’entretien :

• Carte FPGA (tester plusieurs fois le boot/program si la carte a tendance à perdre la config)
• Câbles USB (au moins un câble de rechange) et adaptateurs d’alimentation si nécessaire
• Ordinateur avec environnement de développement installé (quartus/vivado/nextpnr/icestorm selon la cible)
• Désignation des pins IO utilisés et un petit schéma papier si le board n’a pas de breakout
• Oscilloscope ou logique analyzer USB (Saleae ou clone) si vous comptez montrer des signaux
• LEDs, switches, boutons et éventuellement une petite breadboard pour prototypes externes
• Fichiers sources, bitstream/bin prêts et sauvegardés sur clé USB et cloud (GitHub privé, Google Drive)
• Un adaptateur série/USB (FTDI) si vous utilisez une UART

Checklist logicielle et design

Sur le plan logiciel je m’assure :

• Que le projet se synthétise et se place sans erreurs (warnings ok, erreurs non)
• D’avoir un top propre avec les contraintes de pin (.xdc, .qsf ou .pcf selon l’outil)
• D’un script de build (Makefile ou script shell) pour recompiler rapidement si nécessaire
• Que la fréquence d’horloge est réaliste et que les contraintes timing passent ou que j’explique les limites
• De versions pré-compilées du bitstream prêtes à flasher pour éviter les problèmes réseau
• D’avoir des tests unitaires ou simulations de base (iverilog, ghdl ou testbench) pour montrer la validation
• Des commentaires clairs et un README expliquant comment lancer la démo

Tests à exécuter avant l’entretien (préparation)

Voici la liste des tests que je fais tourner sur la carte pour m’assurer que tout est opérationnel :

• Test 1 — Blink LED : simple, rapide, prouve que le bitstream se télécharge et que la carte fonctionne.
• Test 2 — Lecture des boutons et affichage sur LEDs : vérifie les IO en entrée/sortie.
• Test 3 — UART loopback : envoyer/recevoir via UART pour prouver les échanges série (utile pour debug log).
• Test 4 — Génération d’une horloge et vérification au scope : s’assurer que PLL/PLL-less fonctionne et que les fréquences sont correctes.
• Test 5 — Simple périphérique SPI ou I2C : montre l’intégration d’un protocole série (peut être simulé via loopback).
• Test 6 — Démo d’un petit filtre ou of FSM : un bloc logique simple (machine d’états) pour montrer l’architecture
• Test 7 — Mesure de consommation (optionnel) : donner une idée de la consommation si pertinent pour l’application embarquée.

Script de démonstration (10–15 minutes)

Je structure la démo en étapes claires, avec des phrases types pour guider l’échange. Adaptez selon la carte et la techno :

Script détaillé (exemples de phrases) :

• "Je vais commencer par télécharger un bitstream simple nommé blink.bin pour valider la programmation de la carte."
• "Ici, j’utilise une horloge interne à 12 MHz et un compteur pour piloter une LED. C’est volontairement simple pour garantir la robustesse."
• "Maintenant je vais appuyer sur le bouton 1 — vous voyez la LED correspondante s’allumer. Le schéma logique est une bascule synchronisée sur l’horloge."
• "J’ouvre le terminal série : je vous montre un message de boot. J’utilise 115200 8N1. L’UART me sert à logguer l’état de la FSM et à envoyer des commandes."
• "Ensuite, je vais montrer la FSM qui gère un petit protocole : état IDLE, RX, PROCESS, TX. Voici le code Verilog/VHDL et l’explication des transitions."
• "Enfin, si on devait industrialiser cela, je proposerais d’ajouter un PLL pour générer des fréquences plus stables et d’utiliser un interface AXI/bridge si on connecte un CPU soft."

Points techniques à maîtriser pendant la démo

Préparez des réponses courtes pour ces questions courantes :

• Pourquoi tel pin en particulier ? (réponse : contrainte mécanique, multiplexage, facilité d’accès)
• Comment gérez-vous le timing ? (constraints, analyses de timing, marges)
• Que se passe-t-il si l’horloge est trop élevée ? (métastabilité, violations tpd)
• Comment déboguez-vous ? (log via UART, toggling LEDs, probe logique, simulation)
• Quelles alternatives à l’implémentation actuelle ? (optimisation area vs timing, utilisation d’IP)

Trucs et astuces que j’utilise

Quelques petites astuces qui sauvent souvent la mise :

• Toujours avoir un bitstream "fallback" très simple (blink + UART) prêt à flasher.
• Documenter le pinout critique dans un petit PNG ou PDF que vous pouvez partager rapidement.
• Utiliser un script pour flasher automatiquement et afficher des logs, ainsi vous ne perdez pas de temps à taper des commandes pendant l’entretien.
• Si vous montrez un code Verilog/VHDL, mettez en avant l’architecture et commentez les blocs clés au lieu de lire le code ligne à ligne.
• Anticiper les questions sur la licence des IP utilisées (open-source vs licences commerciales).

Ces éléments mènent généralement à une démo claire, courte et efficace. L’important est de montrer que vous savez prioriser : faire fonctionner quelque chose de simple et l’expliquer bien vaut mieux que d’avoir une démo complexe qui plante. Si vous voulez, je peux vous fournir un template de repository (Makefile + bitstreams) adapté à quelques cartes populaires pour vous entraîner.