Un historial de depuración de microprocesadores, 1980-2016

Desde los albores del diseño de la electrónica, donde ha habido diseños, ha habido errores. Pero donde han habido errores, inevitablemente hubo depuración, involucrado en un combate de lucha épico con fallas, errores y errores para determinar cuál prevalecería, y con qué profundidad.

En muchos sentidos, la evolución de la tecnología de depuración es tan fascinante como cualquier aspecto del diseño; pero rara vez recibe la atención. Debug ha evolucionado desde enfoques simples de observación de estímulo-respuesta hasta herramientas, equipos y metodologías sofisticadas concebidas para abordar diseños cada vez más complejos. Ahora, en 2017, nos encontramos en los albores de una nueva y emocionante era con la introducción de la depuración sobre E / S funcional.

Esta es la culminación de décadas de arduo trabajo e invención de todo el mundo. He estado involucrado en la depuración desde 1984, por lo que para apreciar verdaderamente el cambio de paradigma que estamos experimentando ahora en la depuración, es útil echar un vistazo a la innovación que ha tenido lugar a lo largo de los años.

Décadas de 1970 a 1980
El diseño del sistema era muy diferente en este período en comparación con la forma en que son las cosas hoy. Un sistema típico constaría de una CPU, (EP) ROM, RAM y algunos periféricos (PIC, UART, DMA, TIMER, IO ...), cada uno implementado en su propio IC.

Computadora de placa única (SBC) de la década de 1980
(Fuente:http://oldcomputers.net/ampro-little-board.html)

El flujo de desarrollo típico era escribir su código en ASM o C y compilarlo, vincularlo y ubicarlo de manera que terminara con un archivo HEX para la imagen ROM. Luego, sacaría las EEPROM antiguas de los enchufes de la placa de destino, las colocaría en un borrador de EEPROM UV y las proyectaría con luz ultravioleta durante 20 minutos.

EPROM Eraser
(Fuente:https://lightweightmiata.com/arcade/area51/area5114.jpg)

Luego colocó la (s) EEPROM (s) en un programador EEPROM y descargó el archivo HEX de su computadora (generalmente a través de una interfaz en serie o paralela) para programarlos.

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

Finalmente, conectó la (s) EPROM (s) nuevamente a la placa de destino y la encendió para ver si su programa funcionaba. Si su programa no funcionó como se esperaba, entonces tenía varias opciones disponibles para depurar su código de la siguiente manera:

Inspección de código: En este caso, recorrerá su código mirándolo detenidamente en busca de errores. ¡Esta técnica todavía es utilizada hoy por aquellos que ven el uso de cualquier herramienta de depuración como una falla en la habilidad de programación! La otra razón por la que haría esto es si las siguientes técnicas no estuvieran disponibles debido a restricciones de hardware o debido al costo.

LED: Esta técnica también se sigue utilizando en la actualidad. Si tiene LED o cualquier otro indicador en el sistema de destino, puede determinar la ruta a través de su código modificando el código para señalar un estado en lugares importantes del código. Luego, puede simplemente mirar los LED para ver el progreso (o, a menudo, la falta de progreso) a través de su código, lo que lo ayudará a determinar dónde enfocar su atención. (Consulte también Cuando la vida no proporciona una interfaz de depuración, parpadea un LED RGB .) Si tuviera varias E / S digitales de repuesto y tuviera la suerte de tener acceso a un analizador lógico, podría rastrear efectivamente su ruta a través del código en tiempo real rastreando los estados (ubicaciones) de salida de su programa.

En el monitor de destino: Para aquellas placas de destino que tenían un puerto serie (RS232) y suficiente EPROM / RAM libre para incluir un programa de monitorización, puede recorrer su código en el nivel de ensamblaje y mostrar el contenido de los registros y las ubicaciones de la memoria. El programa de monitoreo fue efectivamente un depurador de bajo nivel que incluyó en su propio código. En algún lugar de su programa, saltaría al programa de monitoreo y comenzaría a depurar. El puerto serial se usaba para interactuar con el programa de monitoreo y el usuario emitía comandos como "s" para avanzar una instrucción y "m 83C4,16" para mostrar el contenido de 16 ubicaciones en la memoria comenzando en la dirección 0x83C4, por ejemplo. Una vez que el código funcionaba como se esperaba, el programa final generalmente se compilaba sin el monitor en su lugar.

Emulador en circuito: Para aquellos que podían pagarlo, el emulador en circuito (ICE) era la herramienta de depuración definitiva. De alguna manera, esta herramienta proporcionó más funcionalidad que las herramientas de depuración de última generación que brindan a los desarrolladores en la actualidad. El ICE reemplazaría la CPU en el sistema de destino con componentes electrónicos que emularan la CPU. Estas herramientas ICE eran grandes (mucho más grandes que una PC de escritorio) y muy caras; estamos hablando de muchos miles de dólares. En esta era, el ICE fue diseñado típicamente por el fabricante de la CPU o una de las principales compañías de herramientas de la época (Tektronix, HP / Agilent, Microtek, etc.) y contendría una versión 'bond-out' de la CPU bajo emulación. . La CPU de salida de enlace literalmente tenía señales internas adicionales en los pines del dispositivo para que el emulador pudiera controlar la CPU y obtener visibilidad adicional de su funcionamiento interno. El emulador podría observar las operaciones realizadas por la CPU y proporcionaría puntos de interrupción complejos y funciones de rastreo que serían la envidia de muchos desarrolladores en la actualidad. También fue posible reemplazar un área de la memoria en el objetivo (típicamente la EPROM) con la RAM de emulación contenida en el ICE. Esto le permite descargar su código en la memoria RAM de emulación, no más borrado y soplado de EPROM durante el desarrollo, ¡una bendición!

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

1982-1990
Durante la década de 1980, se desarrollaron tres cambios principales para el desarrollador integrado. La primera fue que comenzaron a aparecer circuitos integrados más integrados que contenían combinaciones de CPU, PIC, UART, DMA, todos incluidos en un solo dispositivo. Ejemplos serían el Intel 80186/80188, que fue una evolución de las CPU 8086/8088 (PC IBM original), el Zilog Z180, que fue una evolución del Z80 (Sinclair Spectrum), y la familia Motorola CPU32 (por ejemplo, el 68302), que fue una evolución del 68000 (Apple Lisa).

La segunda fue que ICE se volvió mucho más accesible para los desarrolladores. Varias empresas habían comenzado a fabricar herramientas ICE a un costo mucho menor que los sistemas de los fabricantes de CPU. Muchas de estas empresas no utilizaron chips extraíbles. Si bien esto llevó a una pequeña disminución en la funcionalidad disponible, contribuyó significativamente a una mayor disponibilidad de productos ICE de menor costo. Un ICE para un 80186 ahora se puede recoger por menos de $ 10,000.

La tercera fue que las velocidades de reloj de la CPU en constante aumento comenzaron a causar problemas para la tecnología ICE. Esto planteó desafíos importantes a los sistemas de cableado que usaban los ICE y comenzó a causar problemas con la tecnología de control de emulación, que simplemente no podía operar a estas altas velocidades sin volverse muy costosa (nuevamente). Los fabricantes de CPU también se estaban volviendo más reacios a crear versiones de enlace de las CPU, ya que las conexiones adicionales en el chip interferían con el funcionamiento del chip. La solución a estos problemas fue construir el circuito de control de depuración de la CPU en el chip. Esto permitió que la tecnología de un solo paso, el acceso a la memoria y el registro, y el punto de interrupción funcionaran a la velocidad máxima de la CPU, pero en este momento no proporcionaba un seguimiento, que aún necesitaba acceso a los pines de la interfaz del bus externo del dispositivo.

Este rastreo también fue menos funcional ya que para muchos accesos periféricos internos no se utilizó el bus externo. Por lo tanto, solo los accesos externos eran completamente visibles y los accesos periféricos internos estaban oscuros. El acceso a la tecnología de depuración en chip (OCD) se realizó a través de una tecnología de interfaz patentada, generalmente conocida como BDM (Modo de depuración en segundo plano), o mediante la interfaz JTAG estándar, que se usaba más tradicionalmente para pruebas de producción que para depurar. Estas interfaces permitieron a las empresas crear herramientas de depuración de bajo costo para el control de la ejecución de la CPU sin limitaciones de velocidad de reloj. Las características variaron ligeramente entre las implementaciones; por ejemplo, algunos permitieron que la herramienta de depuración acceda a la memoria mientras la CPU se estaba ejecutando, mientras que otros no.

1990-2000
El rastro externo prácticamente se extinguió. El aumento en las velocidades de reloj de la CPU, junto con la introducción de la memoria caché interna de la CPU, hizo que el rastreo externo fuera prácticamente inútil. Sin embargo, para diagnosticar defectos de programa más complejos, todavía existía el requisito de poder registrar la ruta de ejecución de la CPU. El desafío era cómo hacer esto usando la lógica en el chip (para que pueda operar a la velocidad máxima de la CPU) pero para transportar los datos de seguimiento fuera del chip a una frecuencia de reloj factible usando la menor cantidad de pines posible. La solución fue transformar la ruta de ejecución de la CPU en un conjunto de datos comprimidos, que podrían ser transportados fuera del chip y capturados por una herramienta de depuración. Luego, la herramienta puede usar el conjunto de datos para reconstruir la ruta de ejecución. Se advirtió que si la herramienta de depuración tenía acceso al programa ejecutado, la compresión podría tener pérdidas. Por ejemplo, si solo se emitieran los cambios de contador de programa no secuenciales, la herramienta de depuración podría "llenar los vacíos" utilizando el conocimiento del programa que se está ejecutando. PowerPC de IBM, las CPU ColdFire de Motorola, los núcleos basados ​​en ARM 7TDMI y otros implementaron sistemas de rastreo basados ​​en este concepto.

2000-2010
Con la introducción de conjuntos de datos de seguimiento de núcleo comprimidos, se volvió factible elegir entre transportar el conjunto de datos fuera del chip y / o usar un búfer de seguimiento en el chip relativamente pequeño para almacenar los datos. A principios de la década de 2000, varios proveedores se esforzaron por mejorar el rendimiento del rastreo; ARM, por ejemplo, diseñó el búfer de seguimiento integrado (ETB), al que se podía acceder a través de JTAG y de tamaño configurable para contener los datos de seguimiento. Esto resolvió el problema de tener que proporcionar un puerto de rastreo fuera del chip de velocidad relativamente alta (aunque todavía no se acerca a la velocidad del reloj del núcleo) a expensas de usar el área de silicio en el SoC.

A mediados de la década de 2000, los diseñadores de CPU integradas comenzaron a implementar sistemas multinúcleo. Los diseños que usaban ARM IP hicieron uso de la tecnología JTAG, y cada núcleo apareció en la cadena de escaneo JTAG en serie. Esto no fue un problema hasta que se implementó la administración de energía del núcleo, lo que resultó en que los núcleos perdieran su presencia en la cadena de escaneo en serie JTAG cuando se apagaban. JTAG no admite dispositivos que aparecen y desaparecen de la cadena de escaneo en serie, por lo que esto causó complicaciones tanto para las herramientas de depuración como para los diseñadores de SoC. Para superar esto, ARM creó una nueva arquitectura de depuración llamada CoreSight. Esto permitió que un único puerto de acceso de depuración basado en JTAG (un dispositivo en la cadena de exploración de JTAG) brindara acceso a muchos componentes CoreSight asignados en memoria, incluidos todos los núcleos ARM del sistema. Ahora, los dispositivos compatibles con CoreSight podían apagarse libremente sin afectar la cadena de escaneo JTAG (puede leer más sobre la tecnología CoreSight en este nuevo documento técnico). Esta tecnología todavía se utiliza en sistemas ARM basados ​​en IP más modernos, y mucho más complicados, diseñados en la actualidad.

2010-
A medida que aumentaba la capacidad de los procesadores integrados, especialmente con la llegada de los núcleos de 64 bits, era más factible admitir la depuración de dispositivos. Anteriormente, el sistema de depuración típico usaba herramientas de depuración en una estación de trabajo de alta potencia utilizando una conexión JTAG / BDM al sistema de destino para controlar la ejecución / rastreo. A medida que Linux / Android ganó un uso generalizado, el kernel se amplió con controladores de dispositivo para acceder a los componentes CoreSight en el chip. Al utilizar el subsistema de rendimiento, ahora es posible la captura y el análisis de trazas en el objetivo.

Con la introducción del ARM Embedded Logic Analyzer (ELA), ahora es posible volver a los días del ICE y tener acceso a puntos de interrupción, disparadores y rastreo complejos en el chip con acceso a señales internas de SoC, como en el pasado. chips de unión solían proporcionar a principios de la década de 1980.

Hoy, después de 40 años de innovación, estamos en la cúspide de una nueva era en la depuración, en la que los ingenieros pueden realizar la depuración y el seguimiento sobre E / S funcionales, ahorrando así tiempo y dinero. El impulso para realizar la depuración en las interfaces de dispositivos existentes no solo proporcionará una solución más sencilla, sino que también ayudará a aumentar la capacidad de depuración y seguimiento al siguiente nivel. Así comienza un nuevo capítulo en nuestra fascinante y larga historia en la guerra contra los insectos.