Cette page est la cinquième et dernière d'une série de pages consacrée au métier de concepteur FPGA. Contrairement aux précédentes, elle ne parle pas de technique. L'accent est mis sur nous, êtres humains, et sur les caractéristiques qui rendent la vie d'un concepteur FPGA plus facile et plus agréable.
Cela compte vraiment
Cela peut sembler étrange de parler de la personnalité et de l'attitude des concepteurs FPGA, en particulier sur un site axé sur des sujets techniques. Cependant, dans un guide destiné à un futur concepteur FPGA, je trouve approprié d'aborder aussi les qualités et comportements humains qui font la différence entre avoir tout sous contrôle et travailler dans un chaos complet.
Il y a une personnalité adaptée à pratiquement chaque métier : il est difficile d'être vendeur de voitures si on est mal à l'aise avec les gens, et on ne sera pas un bon enseignant si on n'aime pas les enfants. De même, certains traits de personnalité vous aident en tant qu'ingénieur FPGA, et d'autres non.
Je ne fais pas la morale et je ne cherche pas à décourager qui que ce soit. Je n'arrive pas non plus avec un « il faut travailler dur ». Au contraire : l'intention est de faire les choses correctement, et d'atteindre ses objectifs avec moins d'effort.
Sur cette page, je vais tenter de décrire ce qu'il faut pour être un concepteur FPGA qui réussit, en plus d'avoir telle ou telle connaissance professionnelle, afin de vivre en paix avec ce métier. Cette page porte sur la personnalité de l'ingénieur. Cela ne surprendra personne qu'il vaut mieux avoir de l'autodiscipline et de la maîtrise de soi, et être du genre méticuleux. Une légère obsession du détail ne fait pas de mal non plus.
Mais ne confondez pas cela avec une idée de souffrance dans la vie ou de travail jusqu'à l'épuisement. C'est l'inverse : si vous avez la capacité de travailler d'une certaine manière, vous terminerez plus vite et plus facilement. Ce sera amusant et gratifiant. Réussir du premier coup est l'idéal, et c'est atteignable.
En revanche, si vous sentez que vous ne correspondez pas à mes descriptions du concepteur FPGA idéal ci-dessous, même de loin, hmmm, comment dire ? Genre, réfléchissez encore une fois à toute cette idée ?
« Ça marche » ne suffit pas
Dans le monde du logiciel, en particulier les sites web et les applis, la pratique courante consiste à griffonner quelque chose, à l'essayer, à corriger ce qui ne va pas et à réessayer. Avec l'IA, même la phase de griffonnage du code est sautée, et une machine fait à la fois le codage et les tests, puis finit par valider le résultat dans le dépôt Git.
L'idée sous-jacente est : si le code passe les tests, le travail est fait. S'il reste un bug, l'assurance qualité le trouvera ou la plainte d'un utilisateur arrivera bientôt. Dans ce cas, une demande de correction sera émise selon la procédure standard. Puis on corrige le bug. Tout un tas d'équipes logicielles sont structurées pour travailler exactement comme ça.
Que cette pratique convienne ou non au développement logiciel est une autre discussion. Ce que je veux affirmer clairement, c'est qu'elle est profondément fausse pour la conception FPGA professionnelle. « Ça marche » est de loin insuffisant pour un projet FPGA. Peut-être pour les amateurs, mais certainement pas pour un projet qui part en production réelle. Il est tentant de tomber dans ce piège, surtout quand on est content que quelque chose fonctionne enfin après une longue session de débogage, et qu'on s'arrête là.
Cela peut sembler une prédication puriste, mais c'est la simple vérité : le seul moyen d'obtenir une conception FPGA fiable est de vous prouver à vous-même, une fois pour toutes, que ce que vous avez conçu est garanti de fonctionner. On ne termine pas une tâche quand la conception passe tous les tests, mais seulement quand on peut se convaincre qu'elle ne peut pas échouer.
Je comparerai cela à un théorème mathématique : vous ne dites pas qu'il est correct parce que vous l'avez essayé quelques fois avec des nombres, et que ça s'est révélé correct à chaque fois. Vous considérez l'équation comme correcte quand vous en avez une preuve mathématique.
En pratique, cela signifie que chaque ligne d'un fichier Verilog est traitée comme une équation dans une démonstration mathématique, et il en va de même pour les contraintes temporelles (timing constraints) et les autres fichiers sources associés. Cela peut sembler un peu extrême, mais être aussi méticuleux paie à long terme.
Il en va de même pour les connexions du FPGA aux autres composants électroniques : vous ne supposez pas que l'interface électrique est bonne simplement parce qu'elle fonctionne. Vous vous prouvez à vous-même que les exigences des fiches techniques sont respectées : celles de la fiche technique du FPGA comme celles des autres composants. Les niveaux de tension sont-ils corrects ? La conception FPGA garantit-elle que toutes les exigences temporelles des deux côtés sont satisfaites ?
Est-ce que cela signifie que mes conceptions sont toujours exemptes de bugs ? Bien sûr que non. Je suis humain, et je fais des erreurs. Tout comme il m'arrive de ne pas rendre une preuve mathématique parfaitement correcte, même en essayant. Je peux oublier de vérifier des cas limites, remplacer un plus par un moins et tout gâcher en général.
Mais ce qui est agréable avec cette approche rigoureuse, c'est que les quelques bugs qui me restent sont généralement évidents, et relativement faciles à corriger. Et une fois qu'ils sont corrigés, la conception fonctionne, tout simplement. Pas de bugs, pas de mystères, pas de sorcellerie. Un morceau d'électronique qui fonctionne solidement.
C'est le chemin lent pour atteindre rapidement son objectif.
Les gens travaillent-ils vraiment avec cette rigueur ?
Réponse courte : certainement pas. Je le sais en particulier de mon époque de freelance. Ma première tâche, chez chaque nouveau client, était de stabiliser le projet FPGA. C'était un peu comme les médecins qui stabilisent un patient aux urgences. Et les ingénieurs responsables du projet semblaient souvent avoir besoin, eux aussi, d'une sorte de stabilisation, après une longue période de stress et de frustration.
L'attitude du « griffonne puis débogue » est malheureusement courante dans l'industrie du FPGA également. Pas étonnant, puisque le simulateur est souvent présenté dans les cours de Verilog dans le même esprit qu'un débogueur dans le monde du logiciel. La suggestion sous-jacente est souvent d'atteindre le résultat voulu par tâtonnement. Simulez jusqu'à ce que ça marche sur l'ordinateur, puis synthétisez et corrigez jusqu'à ce que ça marche aussi sur le matériel.
Pour empirer les choses, il y a des managers qui encouragent ce genre de méthode de travail. Ils sont impatients de voir des résultats, et dès qu'ils voient quelque chose qui semble aller, ils attendent de vous que vous passiez à la tâche suivante. Le planning est serré, et « on corrigera les bugs plus tard ».
Comme résultat de cette approche, il est difficile, et parfois impossible, d'obtenir une conception FPGA vraiment fiable. Cela est compensé par de vastes tests de régression en simulation ainsi que par de vastes tests sur le matériel. Certaines entreprises font subir des tests de température à chaque carte fabriquée avant qu'elle ne quitte la ligne de production, si elle contient un FPGA. Tester le matériel avant livraison devient son propre département, avec son propre matériel et ses propres logiciels, qui n'a qu'un seul but : s'assurer que le FPGA fait vraiment ce qu'il devrait.
Derrière tout cela, il y a des ingénieurs FPGA très stressés, qui sont en retard sur le planning alors qu'ils chassent frénétiquement des bugs qui apparaissent et disparaissent mystérieusement.
Ce n'est pas toujours aussi grave. Quand le FPGA fonctionne à une fréquence relativement basse, quand les exigences sont simples et quand les défaillances sporadiques ne sont pas si graves, l'attitude du tâtonnement peut assez bien fonctionner.
D'ailleurs, en réalité, la plupart des gens qui travaillent avec des FPGA sont quelque part au milieu de l'échelle : pas à l'extrême de considérer le Verilog comme des équations mathématiques, mais avec un niveau élevé de patience, d'autodiscipline et de respect de la précision. C'est ainsi qu'ils arrivent à faire le travail dans ce domaine.
Savoir ce que l'on fait
Si je vous ai convaincu que le tâtonnement n'est pas la bonne voie avec les FPGA, il est clair qu'un chemin plus rigoureux et précis est nécessaire. Mais cela ne suffit pas en soi. Une attitude rigoureuse ne sert à rien si vous ne comprenez pas exactement ce que vous faites.
Par exemple, il est assez courant de voir des réinitialisations asynchrones (asynchronous resets) dans du code Verilog (je l'ai mentionné aussi sur les pages précédentes). C'est une méthode légitime pour réinitialiser de la logique, mais seulement si elle est appliquée correctement. Dans la grande majorité des cas, cette réinitialisation est utilisée de manière incorrecte, et ne garantit donc pas que la logique se comporte comme prévu. Mais en réalité, tout fonctionne bien. Habituellement. Il y a une page séparée sur ce sujet.
La raison de cette utilisation incorrecte de la réinitialisation asynchrone (asynchronous reset) est probablement que les gens copient-collent du code Verilog d'autres sources dans le leur. Le schéma de codage est si familier et évident que les gens ne s'arrêtent pas pour réfléchir à ce qu'il signifie réellement. Et dans ce cas, à ce qu'il ne signifie ni ne garantit.
Savoir ce que l'on fait est un prérequis pour pouvoir se prouver à soi-même que sa conception est garantie de fonctionner. Cela signifie comprendre exactement ce que chaque expression Verilog signifie, et comment le synthétiseur (synthesizer) pourrait l'interpréter. Le même principe s'applique aux contraintes temporelles (timing constraints) et aux autres informations que les outils de développement consomment en relation avec la conception FPGA.
Mais comme je l'ai déjà admis, la plupart des concepteurs FPGA ne sont pas assez rigoureux pour prouver que la conception fonctionne. Connaître le sens exact de ce qu'on tape est néanmoins un pas dans la bonne direction.
Penser de manière abstraite
Si vous avez suivi un cours universitaire en informatique, vous avez peut-être vu comment on invente des créatures abstraites pour décrire du logiciel. Par exemple, des structures de données toujours organisées d'une manière spécifique, des classes et des objets, des flux de données, et des invariants maintenus après chaque itération d'une boucle, etc. En informatique, on invente des créatures imaginaires tout le temps, pour que nous, humains, puissions regarder au-delà des petits détails internes et nous rapporter à une représentation plus simple. Cela réduit la charge sur notre cerveau, et rend possible la compréhension de conceptions logicielles compliquées. C'est ce qu'on appelle l'abstraction.
À l'opposé de l'abstraction, nous avons la façon de penser concrète. Ou dois-je l'appeler « narration » ? Avec cette attitude, un programme informatique est traité comme une histoire. D'abord on fait ceci, puis on fait cela, et si ceci est vrai on fait ceci, sinon cela. Il suffit de suivre la séquence des événements avec le doigt qui parcourt le code, et on comprend tout.
La narration fonctionne bien pour développer des scripts simples, des sites web, des applis mobiles et d'autres logiciels simples. Si l'utilisateur appuie sur ce bouton, allez à cet écran ou à cette page web, et continuez à partir de là. Le logiciel progresse dans un seul fil d'exécution simple, et peut être compris dans un seul fil de pensée.
J'aimerais démontrer la différence entre ces deux façons de penser avec un exemple. Regardons cette fonction, écrite en C, qui calcule n !, la factorielle de n :
unsigned int factorial(unsigned int n) {
if (n == 0)
return 1;
return n * factorial(n - 1);
}
C'est l'exemple classique de la récursion. Comment comprenez-vous le code ci-dessus ?
La façon « narration » consiste à « essayer ». Cela ressemble à quelque chose comme : « Supposons que la fonction soit appelée avec n=3. Elle s'appellera elle-même avec n=2, puis n=1, puis n=0. Maintenant, déroulons : donc elle renvoie 1 pour l'appel avec n=0, puis 1*1, puis elle renvoie 2*1, et enfin 3*2, ce qui fait 6, et c'est la bonne réponse. Super, ça marche. » Ce raisonnement se fait peut-être avec un débogueur, en exécution pas à pas.
L'autre façon est similaire à une démonstration par récurrence mathématique. Nous supposons que la fonction renvoie bien la factorielle de n et confirmons que si elle fonctionne pour n-1, elle fonctionne aussi pour n. Enfin, nous confirmons qu'elle donne la valeur correcte pour n=0, et que la récursion se termine toujours à n=0. La séquence d'exécution n'a aucune importance, car la fonction est traitée comme une créature abstraite qui ne fait que remplir son rôle.
Et vous pouvez demander : pourquoi compliquer les choses ? La narration l'expliquait très bien. À cela je réponds : oui, mais elle ne fonctionnait que parce que l'exemple est simple.
Et maintenant, j'arrive enfin au point : si vous êtes limité à la narration pour comprendre du logiciel, cela va être un obstacle pour vous en tant que concepteur FPGA. La première raison, évidente, est que dans un FPGA, tout se passe en même temps. Peu de choses dans un FPGA peuvent être décrites par « d'abord ceci, puis cela ».
La deuxième raison, plus importante, est que les conceptions FPGA sont souvent complexes. L'abstraction est souvent nécessaire pour que vous soyez mentalement capable de saisir ce qui se passe. Par exemple, c'est une bonne habitude de définir un module Verilog de sorte que sa fonctionnalité puisse être décrite en quelques phrases et sans trop de détails. Les interfaces vers ses ports devraient aussi être simples à décrire. Quand il est possible de réduire un bloc logique compliqué à quelques idées simples, il y a moins de chances d'erreur humaine. Ce principe s'applique aussi au logiciel, mais il n'est pas toujours aussi crucial.
La troisième raison de penser de manière abstraite concerne la capacité de se prouver à soi-même la correction. Avec la narration, vous ne couvrez que les scénarios auxquels vous êtes capable de penser. Une vraie preuve couvre tout.
Lorsqu'on s'attaque à des tâches compliquées, il peut être nécessaire d'inventer de nouvelles créatures théoriques avant d'écrire une seule ligne de Verilog. Par exemple, si vous avez besoin d'un module qui reçoit et émet des paquets de données, il peut être utile de définir N comme le nombre de paquets actuellement stockés dans son tampon mémoire. Avec cela, vous pouvez prouver que le tampon ne devient jamais plein. Cela peut sembler peu de chose, mais faire ce pas vers la pensée mathématique peut beaucoup aider. Il se peut très bien que toute la logique du module soit en quelque sorte liée au maintien de ce N dans les bonnes limites.
L'astuce est de trouver les bonnes créatures abstraites qui aident vraiment à bien concevoir la logique. Cela peut signifier ne pas écrire une seule ligne de Verilog pendant quelques jours, puis tout à coup avoir un court module Verilog écrit très rapidement. Le code conçu de cette manière est souvent court, élégant, facile à comprendre et fonctionne du premier coup et pour toujours.
Cela peut toutefois ne pas très bien fonctionner si votre patron vous demande ce que vous faites chaque jour : pendant quelques jours il n'y a rien à montrer, et quand vous finissez par trouver quelque chose, la réaction peut être « tout ce que tu as, c'est ce module trivial ? »
Donc, une fois de plus, être purement mathématique dans la conception FPGA n'est pas nécessairement la voie pour tout le monde. Mais je suggère quand même de vous débarrasser de l'habitude de la narration, si vous l'avez.
Ne faites pas confiance aux outils
Ou plus précisément : les outils de développement ne vous empêcheront pas de faire des erreurs horribles. Ils ne vous avertiront peut-être même pas.
Aucun compilateur logiciel au monde ne produira jamais du code exécutable qui fait quelque chose de différent de ce que demande le code source. Si c'est le cas, signalez un bug. Un synthétiseur (synthesizer), en revanche, peut très bien générer une logique qui ne remplit pas le comportement demandé par le code Verilog. Avec un peu de chance, il y aura un avertissement à ce sujet. Avec encore plus de chance, vous remarquerez cet avertissement parmi les centaines d'autres messages et avertissements innocents que le synthétiseur (synthesizer) crache.
Les autres parties de la suite de développement FPGA peuvent aussi jouer de sales tours. Le plus évident est que la plupart d'entre elles créeront un flux de configuration (bitstream) que vous pouvez charger dans le FPGA, même si les contraintes temporelles (timing constraints) ne sont pas respectées. Cela signifie que le FPGA peut fonctionner comme le synthétiseur (synthesizer) l'entendait, ou pas. Ou peut-être qu'il fonctionnera un peu puis ne fonctionnera plus. Vous obtiendrez un avertissement, ou même un avertissement critique (critical warning). Mais un compilateur logiciel terminerait-il une compilation et donnerait-il un exécutable qui pourrait ne pas fonctionner ?
Il y a une infinité d'autres façons de gâcher une conception FPGA sans que les outils ne vous arrêtent. C'est un peu une question de culture. C'est comme si quelqu'un voulait intentionnellement qu'il soit difficile de travailler avec les FPGA.
J'ai travaillé avec plusieurs fournisseurs de FPGA différents, et pas mal d'outils de développement pour FPGA. Il est assez intrigant qu'ils aient tous cette même tendance à compliquer les choses, et que les filets de sécurité soient quelque chose à souhaiter. Ce n'est pas un fournisseur de FPGA spécifique, bon marché et maléfique. C'est tous.
En plus de tout cela, il n'est pas rare que les outils de développement FPGA aient des bugs. Avec un peu de chance, ils plantent en tentant de construire le projet, donc au moins ce n'est pas un bug qui fait dysfonctionner votre conception. Cependant, des bugs qui aboutissent à un défaut dans le flux de configuration (bitstream) arrivent, même si ce n'est pas si fréquent. C'est pire quand une nouvelle suite de développement est publiée. Dans le monde du FPGA, le dernier sorti ne signifie pas nécessairement le meilleur, c'est le moins qu'on puisse dire.
Cela dit, ne suspectez pas les outils si votre conception ne fonctionne pas, surtout pas quand vous êtes nouveau dans ce domaine. Et si vous pensez que les outils vous ont trahi, trouvez la preuve irréfutable. Trouvez la cellule logique dans le FPGA où il aurait dû y avoir une chose mais où il y en a une autre. Convainquez-vous que c'est vraiment la faute des outils que cela se soit terminé ainsi. Il ne suffit pas que vous ayez le sentiment que les outils sont fous. Il y a presque toujours une explication plus simple à ce qui ressemble à cela.
Et en particulier, si vous changez quelque chose sans rapport dans votre code Verilog et qu'un bug disparaît, cela ne signifie pas qu'il y a un bug dans les outils. Ce comportement est plus typique de contraintes temporelles (timing constraints) mal définies et d'autres erreurs similaires.
La clé pour aborder ce problème avec les outils de développement est, au risque de me répéter, de savoir ce que l'on fait. Spécifiquement pour ce sujet, de lire les avertissements et messages que les outils émettent, et de comprendre ce qu'ils signifient, ou au moins à quoi ils se rapportent approximativement. C'est une question d'expérience d'apprendre quels avertissements sont inoffensifs, apparaissent toujours, et peuvent et doivent être ignorés. Quant à savoir pourquoi les outils continuent d'émettre de nombreux avertissements inutiles, version après version — ai-je mentionné la culture ?
C'est donc une bonne habitude de parcourir tous les avertissements de temps en temps, et de voir si quelque chose ressort. Faites-le même, et en particulier, quand tout fonctionne parfaitement bien. Non seulement parce que « ça marche » ne suffit pas, mais aussi comme moyen d'apprendre quels avertissements sont inoffensifs.
Et en fait, certains avertissements indiquent que vous avez bien fait les choses. Par exemple, si un avertissement dit qu'un registre a été retiré de la conception parce qu'il a une valeur constante ou est équivalent à un autre registre. C'est l'occasion de s'arrêter une seconde et de réfléchir à si cela a du sens dans le contexte. Assez souvent, de tels avertissements vous aident à réaliser des choses intéressantes sur votre propre code.
De l'exigence à la conception
Quand on écrit du logiciel, il y a généralement une ligne assez directe entre l'exigence et ce qu'on doit écrire. C'est particulièrement vrai pour le logiciel simple (les sites web et les applis mobiles, par exemple).
Avec la conception FPGA, ce n'est pas forcément aussi simple. L'exigence pour un FPGA ressemble souvent plutôt à « voici les composants, on veut que ça se comporte comme ceci ».
Par exemple, la configuration peut être une carte avec un capteur de caméra, un FPGA et des fils qui vont vers une autre unité. La tâche consiste à récupérer l'image du capteur de caméra, effectuer un traitement de signal de base sur les pixels, et envoyer la sortie à l'autre unité, selon le format spécifique de votre employeur pour transmettre des données vidéo.
Vous savez tout sur les FIFO, les machines d'état (state machines), les pipelines (pipelines) et la conception RTL. Comment créez-vous ce qu'on vous demande ? Personne ne vous dit « écris une machine d'état (state machine) ». On attend de vous que vous créiez quelque chose qui fonctionne.
Si vous avez de la chance, les exigences sont similaires à beaucoup de projets précédents. Copiez le schéma-bloc, imitez la logique, et peut-être copiez quelques parties. Mais assez souvent, il y a quelque chose dans les exigences de votre projet qui rend une telle imitation déraisonnable.
C'est alors que vous devenez aussi l'architecte FPGA. Vous décidez comment la tâche est divisée en unités fonctionnelles, ce que chacune d'elles fait, et comment elles interagissent entre elles. Mieux vous faites cela au tout début du projet, plus il sera facile d'écrire et de maintenir le projet. Trop souvent, le schéma-bloc d'un projet existant est imposé à un nouveau projet en l'absence de quelque chose de mieux. Ce raccourci a un coût.
Alors, comment devenir un bon architecte ? Cela vient en grande partie de l'expérience, et aussi de l'observation des solutions choisies dans d'autres projets. J'ai mentionné l'abstraction plus tôt : comprendre une conception, que ce soit la sienne ou celle d'un autre, en termes abstraits vous aide à mieux construire le projet suivant. Si vous voyez les modules Verilog comme des blocs fonctionnels accomplissant une tâche pour laquelle vous avez un nom court, vous avez une palette à utiliser pour votre propre projet. Si vous voyez comment plusieurs fils connectent deux modules, et que vous pouvez nommer la façon dont les modules interagissent à travers ces fils, vous êtes mieux placé pour décider comment les différentes parties de votre nouveau projet interagissent. Mieux vous savez reconnaître les créatures théoriques dans une conception existante, mieux vous saurez en construire une nouvelle.
Si la partie « architecte FPGA » vous semble difficile, laissez-moi partager un petit secret : elle l'est vraiment. Je l'ai fait quelques fois, et cela demande énormément de temps et de regrets. Chaque petite erreur à ce stade initial a des conséquences importantes.
Mais rappelez-vous que vous n'aurez probablement pas besoin de concevoir un projet à partir de zéro, et sûrement pas en tant que nouveau venu dans les FPGA. Cette tâche est généralement confiée à l'ingénieur FPGA le plus expérimenté de l'équipe. Vous avez donc probablement un peu de temps avant d'endosser le chapeau d'architecte système. Et même si vous êtes embauché comme seul ingénieur FPGA de l'équipe, il y a de fortes chances que vous mainteniez du code existant, ou que vous développiez un nouveau projet basé sur un projet existant.
Mais il n'est jamais trop tôt pour commencer à se préparer à cette tâche.
Résumé
À bien des égards, le sujet principal de cette page a été l'autodiscipline sous différentes formes. C'est la capacité de surmonter ce qui est souvent considéré comme un comportement humain : faire les choses de manière imprécise et sans y réfléchir d'abord (écrire du code Verilog et des contraintes temporelles (timing constraints) en particulier), puis corriger les erreurs (simulation et débogage sur le matériel). Être content que quelque chose fonctionne et être pressé de passer à la tâche suivante (« ça marche » ne suffit pas). S'expliquer les choses de manière simple et naturelle (la narration), au lieu de chercher les idées abstraites derrière elles. Sauter les petits détails ennuyeux, comme les avertissements que les outils émettent.
Notre nature humaine est malheureusement une ennemie pour nous en tant que concepteurs FPGA. Mais notez que je n'ai rien dit sur le fait de travailler dur. Viser moins de travail n'est pas de la paresse si le travail est fait. L'objectif est en fait de travailler moins, et pourtant d'obtenir un meilleur résultat. Et c'est possible si vous vous y prenez correctement.
Il ne s'agit pas non plus de devenir un robot. Il s'agit d'avoir de la maîtrise de soi et de la précision dans sa vie professionnelle, mais certainement pas de travailler comme une machine. Nous avons besoin de notre cerveau humain. Un robot peut travailler de nombreuses heures, mais notre cerveau se fatigue. La maîtrise de soi signifie parfois quitter le bureau et se reposer après une longue et pénible journée. Même quand ce bug est encore là.
Et pour résumer toute cette série de pages — comme cela devrait être évident maintenant, la conception FPGA n'est pas le plus simple des métiers, et j'ai listé pas mal de raisons à cela. Si vous n'aimez pas apprendre sans cesse de nouvelles choses sur l'électronique, ce n'est peut-être pas pour vous. Si vous pensez ne pas avoir l'autodiscipline nécessaire pour faire les choses à fond et avec précision, c'est une autre raison de repenser votre choix.
Et si je n'ai pas réussi à vous faire peur jusqu'ici, je vous souhaite la bienvenue au club, et je vous souhaite la meilleure des chances et des compétences. Et plus que tout, j'espère que vous apprécierez ce choix autant que moi.