Uma história de depuração de microprocessador, 1980–2016

Desde o surgimento do design eletrônico, onde existem designs, existem bugs. Mas onde havia bugs, inevitavelmente havia depuração, envolvida em uma luta épica com falhas, bugs e erros para determinar qual prevaleceria - e com que precisão.

De muitas maneiras, a evolução da tecnologia de depuração é tão fascinante quanto qualquer aspecto do design; mas raramente recebe os holofotes. A depuração evoluiu de abordagens simples de estímulo-resposta-observação a ferramentas, equipamentos e metodologias sofisticadas concebidas para lidar com projetos cada vez mais complexos. Agora, em 2017, estamos no alvorecer de uma nova e empolgante era com a introdução da depuração em vez de E / S funcional.

Este é o culminar de décadas de trabalho árduo e invenção de todo o mundo. Estou envolvido com depuração desde 1984, então, para realmente apreciar a mudança de paradigma que estamos experimentando agora em depuração, é útil dar uma olhada nas inovações que ocorreram ao longo dos anos.

anos 1970-1980
O design do sistema era muito diferente neste período em comparação com a forma como as coisas são hoje. Um sistema típico consistiria em uma CPU, (EP) ROM, RAM e alguns periféricos (PIC, UART, DMA, TIMERs, IO ...), cada um implementado em seu próprio IC.

Computador de placa única dos anos 80 (SBC)
(Fonte:http://oldcomputers.net/ampro-little-board.html)
O fluxo de desenvolvimento típico era escrever seu código em ASM ou C e compilá-lo, vinculá-lo e localizá-lo de forma que você acabasse com um arquivo HEX para a imagem ROM. Em seguida, você retiraria os antigos EEPROM (s) dos encaixes no quadro de destino, os colocaria em uma borracha EEPROM UV e os iluminaria com luz ultravioleta por 20 minutos.

Borracha EPROM
(Fonte:https://lightweightmiata.com/arcade/area51/area5114.jpg)
Em seguida, você colocou a (s) EEPROM (s) em um programador EEPROM e baixou o arquivo HEX de seu computador (normalmente por meio de uma interface serial ou paralela) para programá-los.

Programador EPROM
(Fonte:http://www.dataman.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/m/e/mempro.jpg)
Finalmente, você conectou a (s) EPROM (s) de volta à placa de destino e a ligou para ver se o programa funcionou. Se o seu programa não funcionou conforme o esperado, você tinha várias opções disponíveis para depurar seu código da seguinte maneira:

Inspeção de código: Nesse caso, você percorreria seu código olhando por muito tempo para ele, procurando erros. Essa técnica ainda é usada hoje por aqueles que veem o uso de qualquer ferramenta de depuração como uma falha de habilidade de programação! A outra razão pela qual você faria isso é se as técnicas a seguir não estivessem disponíveis devido a restrições de hardware ou por causa do custo.

LEDs: Essa técnica também é usada até hoje. Se acontecer de você ter LEDs, ou qualquer outro indicador no sistema de destino, você pode determinar o caminho através do seu código, modificando o código para sinalizar um estado em locais significativos no código. Você pode então apenas olhar para os LEDs para ver o progresso (ou geralmente a falta de progresso) em seu código, ajudando assim a determinar onde focar sua atenção. (Veja também Quando a vida falha em fornecer uma interface de depuração, piscar um LED RGB .) Se você tivesse vários IOs digitais sobressalentes e tivesse a sorte de ter acesso a um analisador lógico, poderia rastrear efetivamente seu caminho através do código em tempo real, rastreando os estados (locais) de saída de seu programa.

No monitor de destino: Para aquelas placas de destino que tinham uma porta serial (RS232) e EPROM / RAM livre suficiente para incluir um programa de monitor, você poderia percorrer seu código no nível de montagem e exibir o conteúdo dos registros e locais de memória. O programa monitor era efetivamente um depurador de baixo nível que você incluía em seu próprio código. Em algum lugar do programa, você pularia para o programa do monitor e iniciaria a depuração. A porta serial foi usada para interagir com o programa do monitor e o usuário emitia comandos como "s" para passar uma instrução e "m 83C4,16" para exibir o conteúdo de 16 locais na memória começando no endereço 0x83C4, por exemplo. Uma vez que o código estava funcionando conforme o esperado, o programa final normalmente seria criado sem o monitor instalado.

Emulador In-Circuit: Para aqueles que podiam pagar, o In-Circuit Emulator (ICE) era a ferramenta de depuração definitiva. De certa forma, essa ferramenta fornecia mais funcionalidade do que as ferramentas de depuração de última geração fornecem aos desenvolvedores hoje! O ICE substituiria a CPU no sistema de destino por componentes eletrônicos que emulavam a CPU. Essas ferramentas ICE eram grandes (muito maiores do que um PC de mesa) e muito caras - estamos falando de muitos milhares de dólares. Nesta era, o ICE era normalmente projetado pelo fabricante da CPU ou por uma das principais empresas de ferramentas da época (Tektronix, HP / Agilent, Microtek, etc.) e conteria uma versão 'bond-out' da CPU sob emulação . A CPU bond-out literalmente tinha sinais internos extras trazidos para os pinos do dispositivo para que o emulador pudesse controlar a CPU e ganhar visibilidade extra em sua operação interna. O emulador poderia observar as operações realizadas pela CPU e forneceria pontos de interrupção complexos e funcionalidade de rastreamento que causaria inveja a muitos desenvolvedores atualmente. Também foi possível substituir uma área de memória no destino (normalmente a EPROM) pela RAM de emulação contida no ICE. Isso permite que você baixe seu código para a RAM de emulação - chega de apagar e soprar EPROMs durante o desenvolvimento - bliss!

Motorola Exorciser ICE
(Fonte:http://www.exorciser.net/personal/exorciser/Original%20Files/exorciser.jpg)
Intel MDS ICE
(Fonte:http://www.computinghistory.org.uk/userdata/images/large/PRODPIC-731.jpg)
1982-1990
Durante a década de 1980, três mudanças principais evoluíram para o desenvolvedor embarcado. A primeira foi que mais CIs integrados começaram a aparecer contendo combinações de CPU, PIC, UART, DMA - todos incluídos em um único dispositivo. Os exemplos seriam o Intel 80186/80188, que foi uma evolução das CPUs 8086/8088 (IBM PC original), o Zilog Z180, que foi uma evolução do Z80 (Sinclair Spectrum), e a família Motorola CPU32 (por exemplo, o 68302), que foi uma evolução do 68000 (Apple Lisa).

A segunda foi que o ICE se tornou muito mais acessível aos desenvolvedores. Várias empresas começaram a fabricar ferramentas ICE a um custo muito mais baixo do que os sistemas dos fabricantes de CPU. Muitas dessas empresas não usavam chips de liquidação. Embora isso tenha levado a uma pequena diminuição na funcionalidade disponível, contribuiu significativamente para o aumento da disponibilidade de produtos ICE de baixo custo. Um ICE para um 80186 agora poderia ser adquirido por menos de US $ 10.000.

A terceira foi que as velocidades cada vez maiores do clock da CPU começaram a causar problemas para a tecnologia ICE. Isso colocou desafios significativos nos sistemas de cabeamento que os ICEs usavam e começou a causar problemas com a tecnologia de controle de emulação, que simplesmente não conseguia operar nessas altas velocidades sem se tornar seriamente cara (de novo). Os fabricantes de CPU também estavam ficando mais relutantes em criar versões vinculadas das CPUs, uma vez que as conexões extras no chip interferiam na operação do chip. A solução para esses problemas foi construir o circuito de controle de depuração da CPU no chip. Isso permitia que a etapa única, o acesso à memória e ao registro e a tecnologia de ponto de interrupção operassem na velocidade total da CPU, mas não fornecia, neste momento, o rastreamento, que ainda precisava de acesso aos pinos da interface de barramento externo do dispositivo.

Este rastreamento também foi menos funcional, pois para muitos acessos periféricos internos o barramento externo não foi usado. Assim, apenas os acessos externos eram totalmente visíveis e os acessos periféricos internos eram escuros. O acesso à tecnologia de depuração no chip (OCD) era por meio de uma tecnologia de interface proprietária - normalmente referida como BDM (Background Debug Mode) - ou por meio da interface JTAG padrão, que era mais tradicionalmente usada para teste de produção em vez de depuração. Essas interfaces permitiram que as empresas criassem ferramentas de depuração de baixo custo para controle da execução da CPU sem limitações de velocidade do clock. Os recursos variaram ligeiramente entre as implementações; por exemplo, alguns permitiam que a ferramenta de depuração acessasse a memória enquanto a CPU estava em execução, enquanto outros não.

1990-2000
O traço externo praticamente desapareceu. O aumento na velocidade do clock da CPU, juntamente com a introdução do cache interno da CPU, tornou o rastreamento externo praticamente inútil. No entanto, para diagnosticar defeitos de programas mais complexos, ainda era necessário ser capaz de registrar o caminho de execução da CPU. O desafio era como fazer isso usando lógica on-chip (para que pudesse operar na velocidade total da CPU), mas transportar os dados de rastreamento fora do chip em uma taxa de clock viável usando o mínimo de pinos possível. A solução foi transformar o caminho de execução da CPU em um conjunto de dados compactado, que poderia ser transportado para fora do chip e capturado por uma ferramenta de depuração. A ferramenta pode então usar o conjunto de dados para reconstruir o caminho de execução. Percebeu-se que se a ferramenta de depuração tivesse acesso ao programa executado, a compressão poderia ser com perdas. Por exemplo, se apenas as alterações não sequenciais do contador do programa forem geradas, a ferramenta de depuração pode “preencher as lacunas” usando o conhecimento do programa que está sendo executado. PowerPC da IBM, CPUs ColdFire da Motorola, núcleos baseados em 7TDMI da ARM e outros, todos implementaram sistemas de rastreamento baseados neste conceito.

2000-2010
Com a introdução de conjuntos de dados de rastreamento de núcleo compactado, tornou-se viável escolher entre transportar o conjunto de dados fora do chip e / ou usar um buffer de rastreamento relativamente pequeno no chip para armazenar os dados. No início dos anos 2000, vários fornecedores se esforçaram para melhorar o desempenho do rastreamento; A ARM, por exemplo, arquitetou o Embedded Trace Buffer (ETB), que era acessível via JTAG e configurável em tamanho para armazenar os dados de rastreamento. Isso resolveu o problema de ter que fornecer uma porta de rastreamento fora do chip de velocidade relativamente alta (embora ainda longe da velocidade do clock do núcleo) às custas do uso da área de silício no SoC.

Em meados dos anos 2000, os designers de CPU embarcados começaram a implementar sistemas multi-core. Os designs usando ARM IP usaram a tecnologia JTAG, com cada núcleo aparecendo na cadeia de varredura serial JTAG. Isso não era um problema até que o gerenciamento de energia do núcleo fosse implementado, o que resultou na perda de presença dos núcleos na cadeia de varredura serial JTAG quando desligados. JTAG não oferece suporte a dispositivos que aparecem e desaparecem da cadeia de varredura serial, portanto, isso causou complicações para ferramentas de depuração e designers de SoC. Para superar isso, o ARM criou uma nova arquitetura de depuração chamada CoreSight. Isso permitiu uma única porta de acesso de depuração baseada em JTAG (um dispositivo na cadeia de varredura JTAG) para fornecer acesso a muitos componentes CoreSight mapeados em memória, incluindo todos os núcleos ARM no sistema. Agora, os dispositivos compatíveis com CoreSight estavam livres para desligar sem afetar a cadeia de varredura JTAG (você pode ler mais sobre a tecnologia CoreSight neste novo white paper). Essa tecnologia ainda está em uso em sistemas mais modernos - e muito mais complicados - baseados em IP ARM que são projetados hoje.

2010-
À medida que a capacidade dos processadores embarcados aumentava - especialmente com o advento dos núcleos de 64 bits - tornou-se mais viável oferecer suporte na depuração do dispositivo. Anteriormente, o sistema de depuração típico usava ferramentas de depuração em uma estação de trabalho de alta potência utilizando uma conexão JTAG / BDM com o sistema de destino para controlar a execução / rastreamento. À medida que o Linux / Android ganhou amplo uso, o kernel foi aumentado com drivers de dispositivo para acessar os componentes CoreSight no chip. Ao utilizar o subsistema perf, agora é possível a captura e análise de rastreamento no destino.

Com a introdução do ARM Embedded Logic Analyzer (ELA), agora é possível retornar aos dias do ICE e ter acesso a complexos pontos de interrupção, gatilhos e rastreamento on-chip com acesso a sinais SoC internos - assim como os antigos chips de ligação usados ​​para fornecer no início de 1980.

Hoje, após 40 anos de inovação, estamos à beira de uma nova era em depuração, na qual os engenheiros podem depurar e rastrear E / S funcional, economizando tempo e dinheiro. O impulso para realizar a depuração nas interfaces de dispositivos existentes não apenas fornecerá uma solução mais enxuta, mas também ajudará a aumentar a capacidade de depuração e rastreamento para o próximo nível. Assim começa um novo capítulo em nossa longa e fascinante história na guerra contra insetos.