Comment empêcher les projets basés sur FPGA de s'égarer

Au cours de ma carrière, j'ai été impliqué dans le développement d'un certain nombre de conceptions de FPGA pour des projets vraiment intéressants. Malheureusement, j'ai également participé au sauvetage de plusieurs conceptions de FPGA qui se sont gravement égarées. Alors que je travaillais sur ces conceptions à problèmes, il est devenu évident que, bien que les applications cibles et les membres des équipes de développement soient différents, les conceptions partageaient des points communs qui les vouaient à l'échec avant même que le premier ingénieur ne se mette à écrire la première ligne. du code HDL.

Dans cet esprit, j'ai pensé que je passerais en revue cinq problèmes courants que j'ai observés dans le cadre du sauvetage de ces projets. Ces problèmes sont les suivants :

#1 : La première préoccupation ne concerne pas seulement le développement basé sur FPGA, mais l'ingénierie en général. Le problème n'est pas d'avoir une base d'exigences stable au démarrage. Il y a toujours un désir de commencer le projet alors que les exigences sont encore en train de mûrir sur la base que des progrès doivent être démontrés. Cependant, si nous nous lançons et commençons à développer sans bien comprendre les exigences, alors, trop souvent, tout progrès initial s'avère faux, et les corrections en aval entraînent des retards et des coûts supplémentaires. En fait, commencer trop tôt introduit un risque dans le développement, et ce risque doit être atténué. Je comprends que, selon l'application à portée de main, la profondeur et le détail des exigences peuvent évoluer. Je m'attendrais à beaucoup plus d'exigences, et plus détaillées, pour un système SIL4 que pour un système commercial. Cependant, en fin de compte, si les exigences ne sont pas convenues et définies dès le début, il y aura une dérive de la portée. Bien que la conception ait commencé avec une architecture sensible aux exigences telles qu'elles sont comprises, elle deviendra de plus en plus compliquée lorsque les développeurs tenteront d'intégrer de nouvelles fonctionnalités à mesure que la ligne de base mûrit. Avant longtemps, quelque chose va se casser.

#2 : Après avoir compris la situation des exigences, chaque membre de l'équipe doit comprendre le plan de développement du FPGA. Par conséquent, c'est une bonne idée d'avoir un plan définissant l'approche qui sera suivie du lancement à la livraison, en identifiant les principales étapes impliquées et les portes d'examen technique qui seront appliquées au cours du processus de développement. Parallèlement au plan, nous devons également documenter l'architecture et la conception, identifier chacune des fonctions principales, décider quelles fonctions doivent être nouvellement développées et lesquelles utiliser pour tirer parti de l'IP de tiers ou réutiliser l'IP existante (plus d'informations à ce sujet plus tard). Cette documentation combinée du plan, de l'architecture et de la description de la conception permettra à l'équipe d'ingénierie de comprendre clairement la tâche à accomplir. Nous pouvons également retracer toutes les fonctions jusqu'à l'ensemble d'exigences pour garantir que l'approche proposée répond à toutes les exigences de haut niveau.

#3 : La conception des modules et du FPGA global prendra du temps ; ce qui prendra plus de temps, cependant, c'est de vérifier la conception et de s'assurer qu'elle répond à ses exigences. Cette vérification doit englober non seulement la logique fonctionnelle, mais doit également être effectuée dans toutes les conditions de fonctionnement possibles de l'appareil. À son tour, cela signifie qu'il est nécessaire de développer une stratégie de vérification claire pour la conception ; il ne s'agit plus simplement d'écrire le code, d'effectuer quelques simulations, puis de lancer la conception sur le matériel.

#4 : Parfois, nous nous rapprochons tous si près des choses et sommes tellement ancrés dans nos pensées qu'il devient difficile de voir quand nous avons raté quelque chose. C'est pour cela que les revues de conception technique ont été inventées. En organisant ces examens, nous pouvons nous assurer que nous suivons les bonnes pratiques d'ingénierie et que nous nous conformons aux normes de développement internes. De manière significative, ils offrent également la possibilité aux ingénieurs indépendants d'examiner la conception - son architecture et sa mise en œuvre - pour s'assurer qu'elle fournira les fonctionnalités requises. Si nous ne révisons pas la conception au fur et à mesure de sa progression, nous ne parviendrons pas à intégrer la qualité et nous augmenterons les problèmes d'intégration en aval.

#5 : Jusqu'à présent, vous avez peut-être remarqué que la plupart des points que j'ai soulevés sont liés aux processus et aux aspects d'ingénierie plus larges, par opposition au codage de la conception elle-même. Bien sûr, le développement du code est important, mais il est également important de s'assurer que nous tirons parti de l'IP de tiers et de la réutilisation de l'IP interne. Idéalement, nous devrions réutiliser autant de blocs IP existants de notre bibliothèque que possible. Lorsque cela n'est pas possible, nous devrons, bien sûr, développer de nouveaux modules. Dans ce cas, créer ces nouveaux modules de manière à ce qu'ils puissent être réutilisés dans de futurs projets devrait être une priorité pour nous. Pour nous aider à créer ces nouveaux blocs, nous devrions envisager l'utilisation d'outils de synthèse de haut niveau (HLS). En nous permettant de travailler à un niveau d'abstraction plus élevé, ces outils offrent la possibilité d'explorer plus facilement l'espace des solutions et de réduire les risques, le temps de développement et les coûts.

Les points présentés ci-dessus ne sont que quelques-unes des choses que j'ai remarquées lors du sauvetage de conceptions de FPGA. Je serais très intéressé d'entendre vos réflexions sur les projets qui se sont égarés.