Un historique du débogage du microprocesseur, 1980-2016

Depuis l'aube de la conception électronique, où il y a eu des conceptions, il y a eu des bugs. Mais là où il y avait eu des bugs, il y avait inévitablement eu un débogage, engagé dans un match de lutte épique avec des défauts, des bugs et des erreurs pour déterminer ce qui prévaudrait - et à quel point.

À bien des égards, l'évolution de la technologie de débogage est aussi fascinante que n'importe quel aspect de la conception ; mais il reçoit rarement le feu des projecteurs. Le débogage est passé d'approches simples stimulus-réponse-observation à des outils, équipements et méthodologies sophistiqués conçus pour traiter des conceptions de plus en plus complexes. Aujourd'hui, en 2017, nous sommes à l'aube d'une nouvelle ère passionnante avec l'introduction du débogage sur les E/S fonctionnelles.

C'est l'aboutissement de décennies de travail acharné et d'inventions du monde entier. Je suis impliqué dans le débogage depuis 1984, donc pour vraiment apprécier le changement de paradigme que nous vivons actuellement dans le débogage, il est utile de revenir sur l'innovation qui a eu lieu au fil des ans.

années 1970-1980
La conception du système était très différente à cette époque par rapport à la façon dont les choses sont aujourd'hui. Un système typique consisterait en un CPU, une (EP)ROM, une RAM et quelques périphériques (PIC, UART, DMA, TIMERs, IO…), chacun implémenté dans son propre IC.

Ordinateur monocarte (SBC) des années 1980
(Source :http://oldcomputers.net/ampro-little-board.html)

Le flux de développement typique consistait à écrire votre code en ASM ou C et à le compiler, le lier et le localiser de manière à obtenir un fichier HEX pour l'image ROM. Vous devez ensuite retirer les anciennes EEPROM des supports de la carte cible, les placer dans un effaceur UV EEPROM et les faire exploser avec une lumière UV pendant 20 minutes.

Gomme EPROM
(Source :https://lightweightmiata.com/arcade/area51/area5114.jpg)

Vous avez ensuite placé la ou les EEPROM dans un programmeur EEPROM et téléchargé le fichier HEX à partir de votre ordinateur (généralement via une interface série ou parallèle) pour les programmer.

Programmeur EPROM
(Source :http://www.dataman.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/m/e/mempro.jpg)

Enfin, vous avez rebranché la ou les EPROM sur la carte cible et l'avez mise sous tension pour voir si votre programme fonctionnait. Si votre programme ne fonctionnait pas comme prévu, plusieurs options étaient disponibles pour déboguer votre code, comme suit :

Contrôle du code : Dans ce cas, vous parcourriez votre code en le regardant longuement et durement à la recherche d'erreurs. Cette technique est encore utilisée aujourd'hui par ceux qui considèrent l'utilisation de tout outil de débogage comme un échec en programmation ! L'autre raison pour laquelle vous le feriez est si les techniques suivantes n'étaient pas disponibles en raison de restrictions matérielles ou en raison de leur coût.

LED : Cette technique est également encore utilisée aujourd'hui. S'il vous arrive d'avoir des LED ou tout autre indicateur sur le système cible, vous pouvez déterminer le chemin à travers votre code en modifiant le code pour signaler un état à des endroits importants dans le code. Vous pouvez alors simplement regarder les LED pour voir la progression (ou souvent l'absence de progression) dans votre code, vous aidant ainsi à déterminer où concentrer votre attention. (Voir également Lorsque Life ne parvient pas à fournir une interface de débogage, faites clignoter une LED RVB .) Si vous aviez plusieurs E/S numériques de rechange et que vous aviez la chance d'avoir accès à un analyseur logique, vous pourriez tracer efficacement votre chemin à travers le code en temps réel en traçant les états (emplacements) sortis par votre programme.

Sur moniteur cible : Pour les cartes cibles qui avaient un port série (RS232) et suffisamment d'EPROM/RAM libre pour inclure un programme de surveillance, vous pouvez parcourir votre code au niveau de l'assemblage et afficher le contenu des registres et des emplacements mémoire. Le programme de surveillance était en fait un débogueur de bas niveau que vous avez inclus dans votre propre code. À un certain endroit dans votre programme, vous sauteriez dans le programme de surveillance et commenceriez le débogage. Le port série était utilisé pour interagir avec le programme du moniteur et l'utilisateur émettait des commandes telles que « s » pour exécuter une instruction et « m 83C4,16 » pour afficher le contenu de 16 emplacements dans la mémoire commençant à l'adresse 0x83C4, par exemple. Une fois que le code fonctionnait comme prévu, le programme final était généralement construit sans le moniteur en place.

Émulateur en circuit : Pour ceux qui pouvaient se le permettre, l'émulateur en circuit (ICE) était l'outil de débogage ultime. À certains égards, cet outil a fourni plus de fonctionnalités que les outils de débogage de pointe offrent aujourd'hui aux développeurs ! L'ICE remplacerait le CPU du système cible par une électronique émulant le CPU. Ces outils ICE étaient volumineux (beaucoup plus gros qu'un PC de bureau) et très chers - nous parlons de plusieurs milliers de dollars. À cette époque, l'ICE était généralement conçu par le fabricant du processeur ou l'une des principales sociétés d'outils de l'époque (Tektronix, HP/Agilent, Microtek, etc.) et contenait une version « bond-out » du processeur sous émulation . Le processeur bond-out avait littéralement des signaux internes supplémentaires envoyés aux broches de l'appareil afin que l'émulateur puisse à la fois contrôler le processeur et obtenir une visibilité supplémentaire sur son fonctionnement interne. L'émulateur pourrait surveiller les opérations effectuées par le processeur et fournirait des points d'arrêt complexes et des fonctionnalités de traçage qui feraient l'envie de nombreux développeurs aujourd'hui. Il était également possible de remplacer une zone de mémoire sur cible (typiquement l'EPROM) par une RAM d'émulation contenue dans l'ICE. Cela vous permet de télécharger votre code dans la RAM d'émulation - plus d'effacement et de soufflage des EPROM pendant le développement - le bonheur !

Motorola Exorciser ICE
(Source :http://www.exorciser.net/personal/exorciser/Original%20Files/exorciser.jpg)
Intel MDS ICE
(Source :http://www.computinghistory.org.uk/userdata/images/large/PRODPIC-731.jpg)

1982-1990
Au cours des années 1980, trois changements principaux ont évolué pour le développeur embarqué. Le premier était que des circuits intégrés plus intégrés ont commencé à apparaître qui contenaient des combinaisons de CPU, PIC, UART, DMA - tous inclus dans un seul appareil. Des exemples seraient l'Intel 80186/80188, qui était une évolution des processeurs 8086/8088 (PC IBM d'origine), le Zilog Z180, qui était une évolution du Z80 (Sinclair Spectrum), et la famille Motorola CPU32 (par exemple, le 68302), qui était une évolution du 68000 (Apple Lisa).

La seconde était que l'ICE est devenu beaucoup plus accessible aux développeurs. Plusieurs entreprises avaient commencé à fabriquer des outils ICE à un coût bien inférieur à celui des systèmes des fabricants de processeurs. Bon nombre de ces sociétés n'utilisaient pas de puces bond-out. Bien que cela ait entraîné une légère diminution des fonctionnalités disponibles, cela a contribué de manière significative à la disponibilité accrue des produits ICE à moindre coût. Un ICE pour un 80186 pouvait désormais être récupéré pour moins de 10 000 $.

Le troisième était que les vitesses d'horloge sans cesse croissantes du processeur ont commencé à poser des problèmes à la technologie ICE. Cela a posé des défis importants aux systèmes de câblage utilisés par les ICE et a commencé à poser des problèmes avec la technologie de contrôle d'émulation, qui ne pouvait tout simplement pas fonctionner à ces vitesses élevées sans devenir (encore une fois) très chère. Les fabricants de processeurs étaient également de plus en plus réticents à créer des versions bond-out des processeurs, car les connexions supplémentaires sur puce interféraient avec le fonctionnement de la puce. La solution à ces problèmes était de construire le circuit de contrôle de débogage CPU sur puce. Cela permettait à la technologie de point d'arrêt et d'accès à la mémoire et aux registres en une seule étape de fonctionner à pleine vitesse du processeur, mais ne fournissait pas pour le moment de trace, qui nécessitait toujours un accès aux broches de l'interface de bus externe de l'appareil.

Cette trace était également moins fonctionnelle puisque pour de nombreux accès périphériques internes le bus externe n'était pas utilisé. Par conséquent, seuls les accès externes étaient entièrement visibles et les accès périphériques internes étaient sombres. L'accès à la technologie de débogage sur puce (OCD) se faisait soit via une technologie d'interface propriétaire - généralement appelée BDM (Background Debug Mode) - soit via l'interface JTAG standard, qui était plus traditionnellement utilisée pour les tests de production plutôt que pour le débogage. Ces interfaces ont permis aux entreprises de créer des outils de débogage à faible coût pour contrôler l'exécution du processeur sans limitation de vitesse d'horloge. Les fonctionnalités variaient légèrement entre les implémentations ; par exemple, certains autorisaient l'outil de débogage à accéder à la mémoire pendant l'exécution du processeur, tandis que d'autres ne le faisaient pas.

1990-2000
La trace externe s'est pratiquement éteinte. L'augmentation des vitesses d'horloge du processeur, couplée à l'introduction d'un cache interne du processeur, a rendu la trace externe pratiquement inutile. Cependant, pour diagnostiquer des défauts de programme plus complexes, il était toujours nécessaire de pouvoir enregistrer le chemin d'exécution de la CPU. Le défi était de savoir comment faire cela en utilisant la logique sur puce (afin qu'elle puisse fonctionner à pleine vitesse du processeur) mais pour transporter les données de trace hors de la puce à une fréquence d'horloge réalisable en utilisant le moins de broches possible. La solution consistait à transformer le chemin d'exécution du processeur en un ensemble de données compressées, qui pourrait être transporté hors puce et capturé par un outil de débogage. L'outil peut ensuite utiliser l'ensemble de données pour reconstruire le chemin d'exécution. On s'est rendu compte que si l'outil de débogage avait accès au programme exécuté, la compression pouvait entraîner des pertes. Par exemple, si seuls les changements de compteur de programme non séquentiels étaient affichés, l'outil de débogage pourrait « combler les lacunes » en connaissant le programme en cours d'exécution. Le PowerPC d'IBM, les processeurs ColdFire de Motorola, les cœurs 7TDMI d'ARM et d'autres ont tous mis en œuvre des systèmes de trace basés sur ce concept.

2000-2010
Avec l'introduction d'ensembles de données de trace compressés, il est devenu possible de choisir entre le transport de l'ensemble de données hors puce et/ou l'utilisation d'un tampon de trace sur puce relativement petit pour conserver les données. Au début des années 2000, divers fournisseurs se sont efforcés d'améliorer les performances de la trace ; ARM, par exemple, a conçu l'Embedded Trace Buffer (ETB), accessible via JTAG et configurable en taille pour contenir les données de trace. Cela a résolu le problème de devoir fournir un port de trace hors puce à vitesse relativement élevée (bien que toujours loin de la vitesse d'horloge du cœur) au détriment de l'utilisation de la zone de silicium dans le SoC.

Au milieu des années 2000, les concepteurs de processeurs embarqués ont commencé à implémenter des systèmes multicœurs. Les conceptions utilisant ARM IP utilisaient la technologie JTAG, chaque cœur apparaissant dans la chaîne de balayage série JTAG. Ce n'était pas un problème jusqu'à ce que la gestion de l'alimentation des cœurs soit mise en œuvre, ce qui a entraîné la perte des cœurs sur la chaîne de balayage série JTAG lors de la mise hors tension. JTAG ne prend pas en charge les périphériques apparaissant et disparaissant de la chaîne d'analyse série, ce qui a entraîné des complications à la fois pour les outils de débogage et les concepteurs de SoC. Pour surmonter cela, ARM a créé une nouvelle architecture de débogage appelée CoreSight. Cela a permis à un seul port d'accès de débogage basé sur JTAG (un périphérique sur la chaîne d'analyse JTAG) de fournir un accès à de nombreux composants CoreSight mappés en mémoire, y compris tous les cœurs ARM du système. Désormais, les appareils compatibles CoreSight étaient libres de se mettre hors tension sans affecter la chaîne de numérisation JTAG (vous pouvez en savoir plus sur la technologie CoreSight dans ce nouveau livre blanc). Cette technologie est toujours utilisée dans les systèmes IP ARM plus modernes et beaucoup plus complexes qui sont conçus aujourd'hui.

2010-
Au fur et à mesure que les capacités des processeurs embarqués augmentaient, en particulier avec l'avènement des cœurs 64 bits, il est devenu plus possible de prendre en charge le débogage de l'appareil. Auparavant, le système de débogage typique utilisait des outils de débogage sur un poste de travail puissant utilisant une connexion JTAG/BDM au système cible pour contrôler l'exécution/la trace. Au fur et à mesure que Linux/Android se généralisait, le noyau a été complété par des pilotes de périphérique pour accéder aux composants CoreSight sur puce. En utilisant le sous-système perf, la capture et l'analyse des traces sur la cible sont désormais possibles.

Avec l'introduction de l'analyseur logique intégré (ELA) ARM, il est désormais possible de revenir à l'époque de l'ICE et d'avoir accès à des points d'arrêt, des déclencheurs et des traces complexes sur puce avec accès aux signaux SoC internes, tout comme l'ancien puces de liaison utilisées pour fournir au début des années 1980.

Aujourd'hui, après 40 ans d'innovation, nous sommes à l'aube d'une nouvelle ère en matière de débogage, une ère dans laquelle les ingénieurs peuvent effectuer le débogage et la traçabilité sur les E/S fonctionnelles, économisant ainsi du temps et de l'argent. La poussée pour effectuer le débogage sur les interfaces de périphériques existantes fournira non seulement une solution plus légère, mais contribuera également à augmenter la capacité de débogage et de traçage au niveau supérieur. Ainsi commence un nouveau chapitre de notre longue et fascinante histoire dans la guerre contre les insectes.