Mission Principale - IPXact Tool - Part 1

sascha salles project

Posted on July 16, 2020, 5:10 p.m.

Presentation du contexte

Mon stage se déroule au sein de l'équipe FPGA/ASIC au sein du département Hardware. Les ingénieurs FPGA conceptualisent et développent l'architecture de leurs puces. Les  FPGA pour Field-Programmable Gate Arrays ou réseaux logiques programmables sont des composants entièrement reconfigurables ce qui permet de les reprogrammer à volonté afin d'accélérer notablement certaines phases de calculs. 

On programme un FPGA grâce à un langage de description Hardware. Attention aux lecteurs plutôt orientés software, il s'agit bien ici de programmation hardware qui ont de véritables effets physiques. Parmis les langages de description Hardware, nous pouvons nommer le VHDL pour VHSIC Hardware Description Language, plutôt utilisé en France, et le Verilog plutôt utilisé à l'étranger. Une fois la conception d'un FPGA terminée, le service transmet une sorte de documentation technique aux ingénieurs logiciels, cette documentation comporte le descriptif du FPGA. 

La problématique émise ici est que la documentation que les ingénieurs FPGA transmettent aux ingénieurs logiciel n'est pas normée. Les ingénieurs logiciels se retrouvent donc avec des documentations de différentes formes plus ou moins soignés et lisibles. C'est ici qu'intervient la norme IPXACT.

La norme IPXACT 

Lorsque que les ingénieurs Hardware conceptualisent leurs FPGA, ils utilisent un IDE capable de générer un fichier XML conforme à la norme IPXACT. Voici ci-dessous une brève représentation de ce fichier.

sascha salles project

Pour démystifier le sujet il faut retenir que la norme IPXACT permet de définir et de décrire les conceptions de circuits électroniques individuels et réutilisables. L'IPXACT a été créé par le consortium SPIRIT en tant que norme pour permettre une configuration et une intégration automatisée via des outils. 

Les objectifs de la norme sont : assurer la livraison de descriptions de composants compatibles de plusieurs fournisseurs de composants, permettre l'échange de bibliothèques de composants complexes entre des outils d'automatisation de conception électronique (EDA) pour la conception de SoC, décrire les composants configurables à l'aide de métadonnées, permettre la fourniture de scripts EDA indépendants du fournisseur pour la création et la configuration des composants.

J'interviens sur le fait que l'IPXACT a été créee pour être intégrée dans des outils. 

Thales IPXact Tool

A la demande de Benjamin, ma mission principale est de créer une IHM prenant en entrée le fichier IPXACT.xml et permettant de modifier se dernier sans devoir écrire une ligne de XML. En effet, la saisie de XML se révèle fastidieuse, et fait perdre du temps aux équipe d'ingénieurs.

Benjamin à donc codé un petit parser de XML au format IPXACT que je dois intégrer dans l'IHM. Ce parser permettait à mon arrivée de lire le XML d'entrée et de générer des objets Python correspondants à ce qu'il se passe dans le FPGA (Registres, Blocks d'addresses, Champs, Enumerated Values). Nous verrons par la suite comment je l'ai adapté pour qu'il puisse lire certaines valeurs supplémentaires. 

Technologies Utilisées

Toujours dans l'optique que mon code doit pouvoir être réutilisé par le service, Benjamin m'a orienté vers Python. Concernant les bibliothèques graphiques, il en existe plusieurs mais une prédomine : Qt. Au départ Qt permet de faire des GUI en C++, mais depuis maintenant une dizaine d'années des développeurs l'adaptent en Python. La dernière version Python de Qt, se nomme PySide2 et est supporté par l'équipe Qt officielle. Un des grands avantages de Qt est qu'il permet de faire applications cross-platform. Concrétement cela signifie que Qt permet d'utiliser un seul code pour faire des applications compatibles avec les 3 plus grands OS (macOS, Linux et Windows). Ce détail à son importance, les bureaux de Thales sont équipés de Windows et Linux, cela aurait fastidieux d'écrire plusieurs programmes natifs et très dur à maintenir. 

Ce logiciel n'ayant pas besoin de persistance des données, il n'y a donc pas besoin de base de données.

Un point sur la compilation

Python est un langage interprété, ce qui signifie que lorsque nous lançons le code en utilisant la commande "python mon_code.py", ce fichier ne va pas directement être traduit en langage machine comme on le ferait en C++ avec le compilateur, mais il va plutôt passer par un interpréteur qui va convertir les données instructions par instructions de manière plus ou moins dynamique. 

Ce détail pose un léger problème, un utilisateur lambda ne sait pas forcement lancer un interpreteur python, pire encore, cela signifie que l'utilisateur doit forcement avoir python installé sur sa machine. Afin de rendre l'utilisation de l'IHM la plus ergonomique possible, j'utilise cx_Freeze, un outil très puissant qui permet de Freezer (geler) le code python et de générer un executable (.exe sur windows par exemple) avec les dépendances associés (dll pour windows). Cx_Freeze est aussi cross-platform, à l'instar de Qt.

La gestion du projet

Une des difficultés majeures de la mission à été l'ajout de fonctionnalités à la volée. Le besoin de départ qui était d'éviter de saisir du XML à la main à été maintenu mais à fortement évolué, un export vers un template World s'est ajouté, puis un export vers un template complet Excel, puis la génération de code VHDL à partir du fichier IPXACT est apparue, puis celle du code C, etc...

Une autre difficulté à été la refonte du code à 0. Cette mission m'a été confiée à mon arrivée sur le site, et les logiciels de conception graphiques (Qt Creator et Qt Designer) n'étaient pas installés sur mon poste. Pour faire une installation de logiciel chez Thales, il faut faire une demande à un service dédié : le service Desk. Ma demande d'installation de Qt à pris plus d'un mois, et je ne souhaitais pas perdre de temps, j'ai donc décidé de coder l'IHM sans interface builder tel que Qt Creator/Designer.

Le soucis que l'on obtient lorsque nous nous passons d'interface-builder, c'est que la masse de code front-end "sans-logique" est mélée au code logique. C'est un problème très ennuyant, l'architecture logicielle des projets Qt ne se fait pas de la même manière en fonction de tel ou tel widget. Un widget peux suivre l'architecture MVVM de Qt, et un autre peux suivre une architecture plus classique (item based) et presque empirique. 

Ma première solution pour pallier ce problème à été de séparer au maximum les données de l'interface, en créant des Models, et des Views. La logique du parser IPXACT (et des Exporters excel, world) est quant à elle, contenue dans des Helpers.

Hélas malgré tout cela, le projet se révelait dur à maintenir, le fait d'avoir un mixing trop important de code lié aux Views et aux Models donnait des énormes fichiers. A ce moment là du stage je venais d'avoir l'outil d'interface-builder (Qt Designer) installé, et nous avons, d'un commun accord avec Benjamin, décidé de reprendre l'IHM avec la bonne structure. Le code "logique" n'était pas complétement à réecrire, il fallait juste l'adapter à la nouvelle architecture.

A ce moment là, nous avons aussi décidé de passer en conception agile, en lançant des sprints et en utilisant un logiciel similaire à Trello nommé Jira. La correction de bug et l'ajout de features se fait désormais à distance, tout est bien plus pratique.

 

Voir la suite : Mission Principale - IPXact Tool - Part 2