Een geschiedenis van microprocessor-foutopsporing, 1980–2016

Sinds het begin van het elektronica-ontwerp, waar ontwerpen zijn geweest, zijn er bugs geweest. Maar waar het bugs waren, was er onvermijdelijk debug, verwikkeld in een epische worstelwedstrijd met fouten, bugs en fouten om te bepalen welke zou zegevieren - en hoe grondig.

In veel opzichten is de evolutie van debug-technologie net zo fascinerend als elk aspect van ontwerp; maar het komt zelden in de schijnwerpers. Debug is geëvolueerd van eenvoudige stimulus-respons-observatie-benaderingen tot geavanceerde tools, apparatuur en methodologieën die zijn ontworpen om steeds complexere ontwerpen aan te pakken. Nu, in 2017, staan ​​we aan het begin van een nieuw en opwindend tijdperk met de introductie van debug over functionele I/O.

Dit is het hoogtepunt van tientallen jaren hard werken en uitvindingen van over de hele wereld. Ik ben al sinds 1984 betrokken bij debuggen, dus om de paradigmaverschuiving die we nu in debuggen echt te waarderen, is het nuttig om terug te blikken op de innovatie die door de jaren heen heeft plaatsgevonden.

jaren '70-'80
Het systeemontwerp was in deze periode heel anders dan hoe het nu is. Een typisch systeem zou bestaan ​​uit een CPU, (EP)ROM, RAM en enkele randapparatuur (PIC, UART, DMA, TIMER's, IO...), elk geïmplementeerd in zijn eigen IC.

De typische ontwikkelingsstroom was om je code in ASM of C te schrijven en deze te compileren, te koppelen en te lokaliseren zodat je een HEX-bestand voor de ROM-image kreeg. Je zou dan de oude EEPROM('s) uit de sockets op het doelbord halen, ze in een UV EEPROM-wisser plaatsen en ze 20 minuten met UV-licht bestralen.

Vervolgens plaatste u de EEPROM('s) in een EEPROM-programmeur en downloadde het HEX-bestand van uw computer (meestal via een seriële of parallelle interface) om ze te programmeren.

Ten slotte heb je de EPROM('s) weer op het doelbord aangesloten en ingeschakeld om te zien of je programma werkte. Als uw programma niet werkte zoals verwacht, had u verschillende opties om uw code als volgt te debuggen:

Code-inspectie: In dit geval zou je door je code lopen en er lang en hard naar staren op zoek naar fouten. Deze techniek wordt vandaag de dag nog steeds gebruikt door degenen die het gebruik van een foutopsporingsprogramma beschouwen als een gebrek aan programmeervaardigheid! De andere reden waarom u dit zou doen, is als de volgende technieken niet voor u beschikbaar waren vanwege hardwarebeperkingen of vanwege de kosten.

LED's: Ook vandaag wordt deze techniek nog steeds gebruikt. Als je toevallig LED's of een andere indicator op het doelsysteem hebt, kun je het pad door je code bepalen door de code aan te passen om een ​​status op belangrijke plaatsen in de code aan te geven. U kunt dan gewoon naar de LED's kijken om de voortgang (of vaak het gebrek aan voortgang) door uw code te zien, zodat u kunt bepalen waar u uw aandacht op moet richten. (Zie ook Als het leven geen foutopsporingsinterface biedt, knippert een RGB-led .) Als u meerdere reserve digitale IO's had en het geluk had toegang te hebben tot een logische analysator, zou u uw pad door de code in realtime kunnen volgen door de statussen (locaties) die door uw programma worden uitgevoerd te traceren.

Op doelmonitor: Voor die doelborden die een seriële poort (RS232) en voldoende vrije EPROM/RAM hadden om een ​​monitorprogramma op te nemen, zou u uw code op assembly-niveau kunnen doorlopen en de inhoud van registers en geheugenlocaties kunnen weergeven. Het monitorprogramma was in feite een debugger op laag niveau die u in uw eigen code had opgenomen. Op een bepaalde plaats in uw programma zou u in het monitorprogramma springen en beginnen met debuggen. De seriële poort werd gebruikt om te communiceren met het monitorprogramma en de gebruiker zou opdrachten geven zoals "s" om een ​​instructie te geven en "m 83C4,16" om de inhoud van 16 locaties in het geheugen weer te geven, bijvoorbeeld vanaf adres 0x83C4. Zodra de code werkte zoals verwacht, werd het uiteindelijke programma meestal gebouwd zonder dat de monitor op zijn plaats was.

In-Circuit-emulator: Voor degenen die het zich konden veroorloven, was de In-Circuit Emulator (ICE) de ultieme debug-tool. In sommige opzichten bood deze tool meer functionaliteit dan de state-of-the-art debug-tools die ontwikkelaars tegenwoordig bieden! De ICE zou de CPU in het doelsysteem vervangen door elektronica die de CPU emuleerde. Deze ICE-tools waren groot (veel groter dan een desktop-pc) en erg duur - we hebben het over vele duizenden dollars. In dit tijdperk werd de ICE meestal ontworpen door de CPU-fabrikant of een van de grote gereedschapsbedrijven van die tijd (Tektronix, HP/Agilent, Microtek, enz.) en zou een 'bond-out'-versie van de CPU bevatten onder emulatie . De bond-out CPU liet letterlijk extra interne signalen naar de pinnen op het apparaat brengen, zodat de emulator zowel de CPU kon besturen als extra inzicht kon krijgen in de interne werking ervan. De emulator zou de bewerkingen kunnen volgen die door de CPU worden uitgevoerd en zou zorgen voor complexe breekpunten en traceringsfunctionaliteit waar menig ontwikkelaar vandaag jaloers op zou zijn. Het was ook mogelijk om een ​​gebied van on-target geheugen (meestal de EPROM) te vervangen door emulatie-RAM in de ICE. Hiermee kunt u uw code downloaden naar het emulatie-RAM - geen EPROM's meer wissen en opblazen tijdens de ontwikkeling - gelukzaligheid!

1982-1990
Tijdens de jaren 80 kwamen er drie belangrijke veranderingen voor de embedded ontwikkelaar. De eerste was dat er meer geïntegreerde IC's begonnen te verschijnen die combinaties van CPU, PIC, UART, DMA bevatten - allemaal opgenomen in één apparaat. Voorbeelden zijn de Intel 80186/80188, die een evolutie was van de 8086/8088 CPU's (originele IBM PC), de Zilog Z180, die een evolutie was van de Z80 (Sinclair Spectrum), en de Motorola CPU32-familie (bijvoorbeeld de 68302), een evolutie van de 68000 (Apple Lisa).

De tweede was dat de ICE veel toegankelijker werd voor ontwikkelaars. Verschillende bedrijven waren begonnen met de productie van ICE-tools tegen veel lagere kosten dan de systemen van de CPU-fabrikanten. Veel van deze bedrijven gebruikten geen bond-out-chips. Hoewel dit leidde tot een kleine afname van de beschikbare functionaliteit, droeg het aanzienlijk bij aan de grotere beschikbaarheid van goedkopere ICE-producten. Een ICE voor een 80186 kan nu worden opgehaald voor minder dan $ 10.000.

De derde was dat de steeds toenemende CPU-kloksnelheden problemen begonnen te veroorzaken voor de ICE-technologie. Dit stelde grote uitdagingen voor de bekabelingsystemen die ICE's gebruikten, en begon problemen te veroorzaken met de emulatiebesturingstechnologie, die gewoon niet op deze hoge snelheden kon werken zonder (opnieuw) serieus duur te worden. CPU-fabrikanten werden ook steeds terughoudender om bond-out-versies van de CPU's te maken, omdat de extra on-chip-verbindingen de werking van de chip belemmerden. De oplossing voor deze problemen was om de CPU-debug-besturingscircuits op de chip te bouwen. Hierdoor konden single-step, geheugen- en registertoegang en breekpunttechnologie op volledige CPU-snelheid werken, maar op dit moment was er geen traceerfunctie, waarvoor nog steeds toegang nodig was tot de externe businterface-pinnen van het apparaat.

Deze trace was ook minder functioneel omdat voor veel interne perifere toegangen de externe bus niet werd gebruikt. Daarom waren alleen externe toegangen volledig zichtbaar en waren de interne perifere toegangen donker. Toegang tot de on-chip debug (OCD)-technologie was ofwel via een eigen interfacetechnologie - meestal aangeduid als BDM (Background Debug Mode) - of via de standaard JTAG-interface, die meer traditioneel werd gebruikt voor productietests dan voor debuggen. Dankzij deze interfaces konden bedrijven goedkope debug-tools maken voor de controle van de CPU-uitvoering zonder kloksnelheidsbeperkingen. Functies varieerden enigszins tussen implementaties; sommige stonden bijvoorbeeld de debug-tool toe om toegang te krijgen tot het geheugen terwijl de CPU aan het uitvoeren was, terwijl andere dat niet deden.

1990-2000
Externe sporen zijn vrijwel uitgestorven. De toename van de CPU-kloksnelheden, in combinatie met de introductie van interne CPU-cache, maakte externe tracering vrijwel nutteloos. Om complexere programmafouten te diagnosticeren, was er echter nog steeds een vereiste om het uitvoeringspad van de CPU te kunnen registreren. De uitdaging was om dit te doen met behulp van on-chip logica (zodat het op volledige CPU-snelheid kan werken), maar om de traceergegevens van de chip af te transporteren met een haalbare kloksnelheid met zo min mogelijk pinnen. De oplossing was om het uitvoeringspad van de CPU om te zetten in een gecomprimeerde dataset, die off-chip kon worden getransporteerd en vastgelegd door een debug-tool. De tool kan vervolgens de dataset gebruiken om het uitvoeringspad te reconstrueren. Men realiseerde zich dat als de debug-tool toegang had tot het uitgevoerde programma, de compressie lossy zou kunnen zijn. Als bijvoorbeeld alleen de niet-sequentiële programmatellerwijzigingen werden uitgevoerd, zou de debug-tool "de gaten kunnen opvullen" met behulp van kennis van het programma dat wordt uitgevoerd. IBM's PowerPC, Motorola's ColdFire CPU's, ARM's op 7TDMI gebaseerde cores en andere hebben allemaal traceersystemen geïmplementeerd op basis van dit concept.

2000-2010
Met de introductie van gecomprimeerde kerntraceerdatasets werd het mogelijk om te kiezen tussen het off-chip transporteren van de dataset en/of het gebruik van een relatief kleine on-chip traceerbuffer om de data te bewaren. In het begin van de jaren 2000 streefden verschillende leveranciers ernaar om de traceerprestaties te verbeteren; ARM heeft bijvoorbeeld de Embedded Trace Buffer (ETB) ontworpen, die toegankelijk was via JTAG en in grootte kon worden geconfigureerd om de traceringsgegevens vast te houden. Dit loste het probleem op van het moeten voorzien in een relatief hoge snelheid off-chip traceerpoort (hoewel nog lang niet in de buurt van de kernkloksnelheid) ten koste van het gebruik van siliciumgebied in de SoC.

Halverwege de jaren 2000 begonnen embedded CPU-ontwerpers multi-coresystemen te implementeren. De ontwerpen met ARM IP maakten gebruik van JTAG-technologie, waarbij elke kern in de seriële JTAG-scanketen verscheen. Dit was geen probleem totdat kernenergiebeheer werd geïmplementeerd, wat ertoe leidde dat kernen hun aanwezigheid op de JTAG seriële scanketen verloren wanneer ze werden uitgeschakeld. JTAG ondersteunt geen apparaten die verschijnen en verdwijnen uit de seriële scanketen, dus dit veroorzaakte complicaties voor zowel debug-tooling als SoC-ontwerpers. Om dit te verhelpen, heeft ARM een nieuwe debug-architectuur gemaakt, CoreSight genaamd. Hierdoor kon een enkele op JTAG gebaseerde toegangspoort voor foutopsporing (één apparaat in de JTAG-scanketen) toegang bieden tot veel aan geheugen toegewezen CoreSight-componenten, inclusief alle ARM-kernen in het systeem. Nu waren CoreSight-compatibele apparaten vrij om uit te schakelen zonder de JTAG-scanketen te beïnvloeden (u kunt meer lezen over CoreSight-technologie in deze nieuwe whitepaper). Deze technologie wordt nog steeds gebruikt in modernere - en veel gecompliceerdere - op ARM IP gebaseerde systemen die tegenwoordig worden ontworpen.

2010-
Naarmate de capaciteit van embedded processors toenam, vooral met de komst van 64-bit cores, werd het beter mogelijk om debuggen van apparaten te ondersteunen. Voorheen gebruikte het typische debug-systeem debug-tooling op een krachtig werkstation met behulp van een JTAG/BDM-verbinding met het doelsysteem om de uitvoering/tracering te regelen. Toen Linux/Android wijdverbreid werd gebruikt, werd de kernel uitgebreid met apparaatstuurprogramma's om toegang te krijgen tot de on-chip CoreSight-componenten. Door gebruik te maken van het perf-subsysteem is het vastleggen en analyseren van sporen op het doel nu mogelijk.

Met de introductie van de ARM Embedded Logic Analyzer (ELA) is het nu mogelijk om terug te keren naar de dagen van de ICE en toegang te hebben tot complexe on-chip breakpoints, triggers en trace met toegang tot interne SoC-signalen - net als de oude bond-out-chips die in het begin van de jaren tachtig werden gebruikt.

Vandaag, na 40 jaar innovatie, staan ​​we aan de vooravond van een nieuw debug-tijdperk, een tijdperk waarin technici debug en tracering kunnen uitvoeren over functionele I/O, waardoor zowel tijd als geld wordt bespaard. De push voor het uitvoeren van foutopsporing via bestaande apparaatinterfaces zal niet alleen een slankere oplossing bieden, maar zal ook helpen om de foutopsporings- en traceermogelijkheden naar een hoger niveau te tillen. Zo begint een nieuw hoofdstuk in onze fascinerende en lange geschiedenis in de strijd tegen insecten.