En route vers Embedded World 2021 : épisode 5

Note de l'éditeur : Dans l'Épisode 1 de cette série de cinq blogs précédant le salon Embedded World 2021, nous avons présenté cet événement. Dans l'Épisode 2, Randall s'est replongé dans le langage de programmation C. L'Épisode 3 a expliqué comment l'utilisation de la programmation orientée objets permet de réduire la complexité. L'Épisode 4 s'est concentré sur la mesure fondamentale de toute bonne conception, à savoir sa capacité à être reconfigurée à mesure que les exigences changent, et ce, sans avoir à réimplémenter les blocs fonctionnels. Dans ce dernier article, l'Épisode 5, l'espace toujours plus important requis par les systèmes d'exploitation est remis en cause et la décomposition du système est brièvement abordée avant l'allocution d'ouverture de Randall au salon Embedded World 2021.

Dans ma dernière publication, j'ai présenté le point de vue de David Parnas, à savoir que les systèmes devaient masquer des informations derrière leur interface et qu'ils devaient être décomposés en modules s'adaptant facilement au changement. J'ai également mentionné Juval Löwy, défenseur contemporain de cette approche et auteur de Righting Software.

Cette approche diffère de la décomposition fonctionnelle qui est probablement l'approche la plus répandue à l'heure actuelle. Pourtant, de solides arguments prouvent que l'approche de David Parnas est meilleure, notamment le fait qu'un système conçu pour le changement est un système plus facile à comprendre. Il est plus facile de « comprendre intuitivement » (notion couverte par le néologisme anglais « grok ») ce genre de systèmes et de les recomposer sous forme de nouvelles implémentations. Il s'agit d'un concept clé pour augmenter la réutilisation, car il permet à des non-spécialistes d'accéder à l'expertise d'autres personnes. C'est aussi l'occasion d'étendre les marchés des ingénieurs de systèmes embarqués en créant un effet de levier pour permettre à d'autres de fabriquer ce qu'ils conçoivent. La mesure fondamentale de toute bonne conception est donc sa capacité à être reconfigurée à mesure que les exigences changent, et ce, sans avoir à réimplémenter les blocs fonctionnels. Ainsi, la variation des cas d'utilisation principaux se traduit simplement par des interactions entre les blocs fonctionnels conçus pour des cas d'utilisation et des exigences spécifiques.

Pourtant, hélas, cette approche comporte des freins et des risques, notamment l'inefficacité et le gaspillage. À mesure que les systèmes se développent, ils deviennent naturellement complexes. Je vous invite à lire cet article de blog intéressant d'un dénommé Nikita. Je suis heureux de constater qu'il est toujours accessible en ligne à la semaine 53 de l'année 2020. Nikita dit :

« Le système Android sans aucune application installée pèse quasiment 6 Go. Prenez juste une seconde pour vous rendre compte à quel point ce chiffre est énorme. Il y a quoi là-dedans ? Des films HD ? Je suppose que c'est essentiellement du code : kernel, drivers. Avec un peu de texte et quelques ressources, très certainement, mais ces derniers ne peuvent pas être si gros. Donc, de combien de drivers un téléphone a-t-il besoin pour fonctionner ?

Windows 95 pesait 30 Mo. Aujourd'hui, on a des pages Web plus lourdes que ça ! Windows 10 pèse 4 Go, ce qui est 133 fois plus lourd. Est-ce qu'il en est 133 fois supérieur pour autant ? Je veux dire, fonctionnellement parlant, c'est la même chose. Oui, il y a Cortana, mais je ne pense pas qu'elle pèse 3970 Mo. Et même si on laisse Windows de côté, est-ce qu'Android est 150 % meilleur ? »

La puce M1 d'Apple annoncée en novembre 2020 contient 16 milliards de transistors. C'est considérable selon les normes actuelles. Il existe aussi d'énormes FPGA proposés aux concepteurs de systèmes embarqués. Le matériel et les programmes informatiques à usage général deviennent lourds, et l'espace embarqué se heurte au même problème.

Le traitement des signaux numériques a été développé dès les années 1960 et utilisé pour traiter les signaux radar. C'était avant l'avènement du microprocesseur et de la logique programmable. Depuis, nous avons adopté des fonctionnalités développées par d'autres : les blocs de propriété intellectuelle du fournisseur de FPGA et de ses revendeurs à valeur ajoutée, et les bibliothèques logicielles de toutes sortes. Cela nous a permis d'être plus productifs, mais également d'étendre nos solutions. Problème : votre application n'a peut-être pas besoin de toutes les fonctionnalités incluses, fonctionnalités que vous ne connaissez sans doute pas toutes (par exemple : les suites de tests embarquées par le fournisseur dans le circuit intégré que vous utilisez). Il est devenu plus simple de regrouper des fonctionnalités définies et de les inclure dans le produit final. Trouver une solution plus compacte n'est pas rentable, car il faut plus de temps pour l'implémenter.

Dans mon précédent article, j'ai cité Juval Löwy qui disait qu'un éléphant et une souris présentaient essentiellement la même architecture. Ça me rappelle que mon ADN présente des gènes communs avec la banane (90 %) et la drosophile (95 %). Même si je porte en moi ces formules, je ne m'en rends pas compte. Selon moi, c'est ce qui se passe avec les systèmes embarqués. Nous ne faisons qu'y ajouter des ensembles supplémentaires de fonctionnalités déjà disponibles. Nous architecturons nos systèmes embarqués avec des infrastructures semblant provenir de services informatiques (par exemple, Harmony de Microchip, xDAIS de Texas Instruments ou MCUXpresso de NXP, entre autres).

J'ai récemment lu un article de Kevin Morris dans la revue EE Journal qui disait :

« Ni Xilinx ni Altera/Intel, alors que les deux firmes cumulent environ 80 % des parts de marché depuis vingt ans, n'ont fourni le plus grand nombre de dispositifs FPGA. Cette distinction revient à Lattice Semiconductor, et avec une marge importante. Cela s'explique, bien sûr, par le fait que, depuis quelques années, Lattice se concentre sur les segments milieu de gamme et bas de gamme du marché, alors que les entreprises de logique programmable plus connues luttent pour asseoir leur suprématie dans la fourniture de FPGA, SoC FPGA et autres composants similaires parmi les plus grands et les plus chers.

Les efforts stratégiques déployés par Lattice pour fournir des sockets plus abordables et en plus grande quantité lui ont permis de livrer des milliards de FPGA pour une vaste gamme de systèmes dans de nombreux segments de marché. C'est ainsi que Lattice, à mesure que les capacités de la technologie FPGA ont augmenté, a rattrapé les deux grands noms du secteur, en apportant une technologie considérée il y a quelques années encore comme haut de gamme dans des applications beaucoup plus limitées en termes de coûts, et la faisant évoluer dans de nouvelles directions avec des solutions pré-conçues qui permettent aux équipes d'ingénierie avec peu d'expertise FPGA d'en tirer parti. »

Tapez « microcontrôleur » dans la zone de recherche sur le site de DigiKey et vous verrez plus de 87 000 dispositifs différents répertoriés. Tapez « FPGA », et vous verrez plus de 25 000 dispositifs répertoriés. Regardons maintenant la Figure 1. Elle montre les types de microcontrôleurs achetés par les clients. Vous remarquerez que la part belle est faite au marché des microcontrôleurs 8 bits bas de gamme. À l'heure des architectures ARM et RISC-V, vous serez peut-être surpris, mais cela rejoint l'article sur Lattice.

Figure 1 : Popularité des types de microcontrôleurs

Notre défi, en tant qu'ingénieurs de systèmes embarqués, est de résister à la tentation de gonfler les fonctionnalités. Actel, maintenant Microsemi, une division de Microchip, possédait un outil appelé « gate gobbler », littéralement un engloutisseur de portes. Cet outil existe sans doute encore. Il visait à éliminer toute logique superflue. Il faudrait peut-être ressusciter de tels outils pour permettre à nos utilisateurs d'isoler les fonctionnalités inutiles.

Ma présentation au salon Embedded World comportera un exemple de décomposition d'un système se basant sur l'approche de David Parnas. Je soutiendrai que le marché pour les ingénieurs de systèmes embarqués est vaste et en plein essor. J'expliquerai l'idée de réduire la complexité afin de permettre aux novices comme aux experts d'utiliser les fonctionnalités développées par un autre. Je défendrai que cela augure d'un avenir prometteur. J'expliquerai également en quoi les entreprises de logique programmable ont nui à leurs marchés et ce qui doit être fait pour rectifier la situation.

Il est important pour les entreprises de rendre leurs produits utilisables par le plus grand nombre. Au début de ma carrière, une entreprise automobile américaine a dû procéder à des licenciements massifs. Je me souviens avoir lu un article qui expliquait que, dans ce nombre de mises à pied, il y avait probablement des Edison, des Ford et un ou deux DaVinci. C'est dans de vastes marchés non qualifiés que le prochain DaVinci commencera sa carrière. Nous avons besoin de ces personnes pour exploiter avec succès notre expertise.