L'ingénieur FPGA conçoit la logique qui tourne dans le composant : traitement du signal, interfaces rapides, contrôle d'un capteur, accélération d'un calcul. Il écrit le RTL, le vérifie dans un testbench, l'implémente sous Vivado, Quartus Prime ou Libero, ferme le timing puis le met au point sur carte avec l'électronicien. Sur un SoC comme le Zynq, il travaille aussi avec l'équipe logicielle. Les annonces disent ingénieur FPGA, développeur FPGA, ingénieur VHDL ou concepteur RTL.
Un CV qui aligne VHDL, Vivado et Zynq ne dit pas grand-chose du niveau. Un profil expérimenté parle d'un franchissement de domaine d'horloge raté, d'un chemin qu'il a pipeliné pour gagner une demi-nanoseconde, d'un testbench qui vérifie seul ses résultats et d'une session à l'analyseur logique embarqué. Un jeune diplômé connaît souvent bien le langage et peu les contraintes.
Partez de situations réelles plutôt que de définitions : un rapport de timing en échec, un bus à faire passer d'une horloge à l'autre, un design qui marche en simulation et pas sur carte. Le PDF ajoute un cas de 20 minutes sur un bloc de filtrage entre un ADC et un Zynq.
Langages, outils et interfaces d'un ingénieur FPGA
VHDL, Verilog et SystemVerilog
Les langages de description du matériel. Le VHDL domine dans beaucoup d'équipes françaises, le Verilog et le SystemVerilog dans d'autres et pour la vérification. Écrire un programme et décrire un circuit sont deux choses différentes : chaque ligne devient des portes et des bascules.
Vivado, Quartus Prime, Libero
Les outils des fabricants : Vivado pour AMD (ex-Xilinx), Quartus Prime pour Altera (ex-Intel), Libero pour Microchip, Radiant pour Lattice. Ils font la synthèse, le placement, le routage et l'analyse de timing. Un candidat change d'outil sans trop de peine, mais il doit savoir les piloter par scripts Tcl.
Contraintes et analyse de timing (STA)
Les fichiers XDC ou SDC décrivent les horloges et les délais des entrées et sorties. L'analyse statique de timing vérifie que chaque chemin tient dans la période. C'est la partie la plus technique du métier, et le meilleur moyen de distinguer un profil confirmé.
Franchissement de domaines d'horloge (CDC)
Un design utilise souvent plusieurs horloges. Chaque signal qui passe de l'une à l'autre doit être synchronisé, sinon il produit des pannes rares et difficiles à reproduire. Synchroniseurs, poignées de main et FIFO asynchrones sont les réponses attendues.
Simulation et vérification
Questa ou ModelSim, GHDL, NVC, Verilator pour simuler ; UVM, OSVVM, UVVM ou cocotb pour structurer les tests. Un bon testbench compare seul les résultats à un modèle de référence et tourne dans une intégration continue.
Interfaces AXI, DDR et transceivers
AXI4, AXI4-Lite et AXI4-Stream relient les blocs entre eux et au processeur. La DDR passe par un contrôleur fourni par le fabricant. Les transceivers portent les liens rapides : PCIe, Ethernet, JESD204 pour les convertisseurs.
SoC FPGA : Zynq, Versal, Agilex SoC
Des composants qui associent processeurs Arm et logique programmable. L'ingénieur FPGA y définit les registres, les interruptions et les DMA que le logiciel utilise, et travaille avec l'équipe Linux embarqué sur le device tree et les pilotes.
Analyseurs logiques embarqués et HLS
ILA chez AMD et SignalTap chez Altera capturent des signaux internes sur la carte, en fonctionnement réel. Vitis HLS et ses équivalents génèrent du RTL à partir de C ou de C++ pour des blocs de calcul, sans remplacer la conception RTL classique.
L'ingénieur FPGA travaille entre l'électronicien qui conçoit la carte et l'équipe logicielle qui utilise le composant. Selon le poste, il conçoit des blocs de traitement, intègre des IP du fabricant, se consacre à la vérification ou prend en charge l'architecture du composant entier. Les outils varient avec le fabricant (AMD, Altera, Microchip, Lattice), mais les fondamentaux restent les mêmes : logique synchrone, contraintes, horloges, vérification. Certains postes imposent une démarche qualité stricte avec traçabilité des exigences et revue de chaque modification ; demandez au candidat comment il a documenté et justifié ses choix de conception.
Les points techniques qui séparent les profils FPGA
- Conception RTL synchrone en VHDL ou Verilog
- Contraintes et fermeture du timing
- Domaines d'horloge et reset
- Vérification et simulation automatisées
- Interfaces AXI, DDR et SoC FPGA
- Outils, build et mise au point sur carte
Horloges, timing, simulation : cinq questions commentées
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un signal d'un bit passe d'une horloge à 100 MHz vers une horloge à 156,25 MHz sans relation de phase. Comment le transférez-vous ? Et un bus de 32 bits ?
Une bonne réponsePour un bit de niveau, un synchroniseur à deux bascules (ou trois à haute fréquence) dans le domaine d'arrivée, sans logique combinatoire avant la première bascule, et un attribut qui garde les bascules proches (ASYNC_REG chez AMD). Pour une impulsion, une conversion en bascule de niveau (toggle) ou une poignée de main. Pour un bus de 32 bits, jamais un synchroniseur par bit : une FIFO asynchrone avec pointeurs en code Gray, ou une poignée de main qui ne valide la donnée qu'une fois stable. Dans les contraintes, les chemins entre ces horloges sont déclarés asynchrones ou bornés par set_max_delay.
Signal d'alerteDeux bascules sur chacun des 32 bits, ce qui laisse arriver des mots incohérents. Ou « les fréquences sont proches, ça passe ».
Question 2 · confirmé
Après placement et routage, l'outil annonce un WNS de -0,4 ns sur l'horloge à 250 MHz. Que faites-vous ?
Une bonne réponseIl ouvre le rapport de timing et regarde les pires chemins : départ, arrivée, part de logique et part de routage. Beaucoup de niveaux de logique : il ajoute un étage de pipeline ou simplifie la logique. Surtout du routage : fanout trop élevé à dupliquer, placement éclaté, ressources éloignées (DSP, BRAM). Il vérifie aussi que le chemin est réel : une contrainte manquante ou un chemin entre horloges asynchrones mal déclaré peut produire un faux échec. Il essaie ensuite les stratégies d'implémentation, en dernier recours.
Signal d'alerteRelancer la compilation avec une autre graine en espérant que ça passe, ou baisser la fréquence sans savoir quel chemin échoue.
Question 3 · confirmé
Le code simule parfaitement, mais sur la carte le comportement est différent. Quelles pistes suivez-vous ?
Une bonne réponseDes écarts entre simulation et synthèse : liste de sensibilité incomplète, latch déduit d'un process combinatoire qui n'affecte pas toutes les sorties, valeurs initiales supposées. Des contraintes manquantes ou fausses : horloge non déclarée, entrées et sorties sans set_input_delay ou set_output_delay. Un franchissement de domaine d'horloge non synchronisé. Un reset relâché de façon asynchrone. Il lit les avertissements de synthèse, le rapport de CDC et place un analyseur logique embarqué (ILA ou SignalTap) sur les signaux suspects.
Signal d'alerteAjouter des délais dans le code pour « laisser le temps aux signaux », ou incriminer la carte sans avoir lu les rapports de l'outil.
Question 4 · confirmé
Comment construisez-vous un testbench qui vérifie seul un bloc de traitement, sans regarder les chronogrammes ?
Une bonne réponseUn générateur de stimuli, un modèle de référence qui calcule le résultat attendu (souvent en Python ou en MATLAB, ou dans le testbench), un comparateur qui signale chaque écart, et un verdict final lisible par une CI. Il ajoute des stimuli aléatoires contraints et des assertions sur les protocoles, et mesure la couverture. Selon l'équipe : UVM en SystemVerilog, OSVVM ou UVVM en VHDL, ou cocotb en Python avec un simulateur comme Questa, GHDL, NVC ou Verilator.
Signal d'alerteUn testbench qui envoie trois valeurs et qu'on valide en regardant les courbes dans ModelSim.
Question 5 · confirmé
Un esclave AXI4-Stream de votre conception bloque le flux de temps en temps. Que vérifiez-vous dans le handshake ?
Une bonne réponseUn transfert n'a lieu que quand TVALID et TREADY sont hauts sur le même front. La source ne doit pas attendre TREADY pour lever TVALID, sinon les deux côtés s'attendent. Une fois TVALID levé, la donnée reste stable jusqu'au transfert. Côté esclave, TREADY calculé en combinatoire à partir de l'aval crée de longs chemins : il insère un skid buffer ou une petite FIFO. Il vérifie aussi TLAST et la gestion de la contre-pression en simulation.
Signal d'alerteIgnorer TREADY et supposer que l'aval accepte toujours, ou une source qui baisse TVALID avant que la donnée soit prise.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un ingénieur FPGA, les points qui reviennent
VHDL ou Verilog : faut-il exiger le langage du projet ?
Pour un junior, oui, ou au moins une bonne pratique d'un des deux. Pour un profil confirmé, le changement de langage prend quelques semaines : la logique synchrone, les contraintes et la gestion des horloges se transposent. SystemVerilog est un cas à part quand le poste demande de la vérification UVM, qui demande une vraie expérience. Demandez sur quels projets la personne a utilisé chaque langage et avec quel simulateur.
Comment évaluer un jeune diplômé en FPGA ?
Sur les bases qui ne s'apprennent pas en une semaine : différence entre logique combinatoire et séquentielle, setup et hold, machine d'états, testbench, franchissement d'horloge simple. Faites-lui raconter son projet d'école ou de stage : quel composant, quelle fréquence, quels problèmes de timing, comment il a vérifié. Un candidat qui a déjà chargé un design sur une carte réelle et l'a mis au point part avec un avantage net.
Quel test technique proposer à un ingénieur FPGA ?
Un petit bloc à écrire en VHDL ou en Verilog, un compteur avec enable ou une FIFO, avec son testbench, en une heure, puis une discussion sur un rapport de timing réel. Un code fourni avec deux erreurs volontaires (un latch, un franchissement d'horloge non synchronisé) fonctionne aussi. Évitez les questions de syntaxe pure : elles se vérifient en deux minutes dans la documentation et ne montrent pas le niveau.
Quelle différence entre un ingénieur FPGA et un ingénieur ASIC ?
Les deux écrivent du RTL et le vérifient. L'ingénieur ASIC conçoit un circuit fabriqué une seule fois, avec une vérification beaucoup plus poussée et des étapes physiques (bibliothèques de cellules, test de fabrication) absentes en FPGA. L'ingénieur FPGA travaille sur un composant reprogrammable, avec les primitives, les IP et les outils du fabricant, et passe plus de temps sur carte. Un profil ASIC apporte souvent une culture de vérification solide.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
