Verificación de Hardware mediante Software: El Estándar 1149 y el Desarrollo en la PUCP de un Equipo Automático de Pruebas.

Transcripción

1 Verificación de Hardware mediante Software: El Estándar 1149 y el Desarrollo en la PUCP de un Equipo Automático de Pruebas. Marcos Caldas Torres, Arturo Miguel de Priego <amiguel@pucp.edu.pe> Grupo de Microelectrónica Pontificia Universidad Católica del Perú En este documento se presenta un sistema proyectado para la verificación remota y local de circuitos digitales en tarjetas de circuitos impresos bajo la norma IEEE (Boundary-Scan Test). Aunque el sistema aun se encuentra en desarrollo, los problemas de hardware prácticamente han sido superados casi totalmente, restando mucho trabajo por realizar en lo concerniente al software. En la primera parte de este documento se revisa brevemente la técnica de verificación de circuitos usando boundary-scan. En la segunda parte se explican las características del sistema proyectado. Seguidamente, en la tercera parte se muestran las tarjetas construidas para realizar pruebas genéricas con boundary-scan, las cuales sirven también como tarjetas experimentales para el diseño con lógica programable. A continuación, en la cuarta parte de este documento, se explica el diseño y estado del software para el sistema. Finalmente se indican las conclusiones y trabajo futuro. Este proyecto fue auspiciado en el año 2000 por la Dirección Académica de Investigación de la Pontificia Universidad Católica del Perú.

2 INTRODUCCIÓN En marzo de 1999 el Ing. Guillermo Jaquenod, de Argentina, visitó la Universidad Católica y ofreció un curso de diseño digital con lógica programable. El curso comprendió varios temas incluyendo tópicos de verificación de tarjetas de circuitos impresos mediante la técnica de boundary-scan. Antes de retornar a su país, Guillermo redactó un proyecto para construir un sistema de pruebas automáticas con boundary-scan. En tal proyecto se requería trabajar básicamente en el nivel del software, puesto que las arquitecturas de hardware necesarias para la verificación ya se encuentran incorporadas en la mayoría de los circuitos integrados comerciales de hoy. El proyecto fue presentado a la Dirección Académica de Investigación (DAI) de la Universidad Católica y fue aprobado en Septiembre de 1999, siendo responsable de su ejecución el Ing. Arturo Miguel de Priego. El trabajo se inició con Renato Carrero y Emilio Miranda, egresados de la especialidad de electrónica, quienes diseñaron el software para soportar verificación remota vía Internet. En el verano del 2000 Carlos León, Víctor Cordero, Jean Talledo y David Martín, estudiantes de 5to y 6to ciclo de la especialidad de electrónica, trabajaron sobre el hardware del boundary-scan, codificando programas en C y desarrollando un sistema didáctico para el aprendizaje de esta arquitectura. Los avances de los trabajos fueron presentados en el VI Workshop IBERCHIP, realizado en la ciudad de Sao Paulo, Brasil, del 16 al 18 de marzo del Marcos Caldas, egresado de la especialidad de electrónica, continuó desarrollando el hardware y software para el sistema de prueba automática. Los avances de este sistema se presentan en este artículo. En la primera parte se revisa brevemente la técnica de verificación de circuitos usando boundary-scan. En la segunda parte se explican las características del sistema proyectado. Seguidamente, en la tercera parte se muestran las tarjetas construidas para realizar pruebas genéricas con boundary-scan, las cuales sirven también como tarjetas experimentales para el diseño con lógica programable. A continuación, en la cuarta parte de este documento, se explica el diseño y estado del software para el sistema. Finalmente se indican las conclusiones y trabajo futuro. I. EL ESTÁNDAR El Estándar IEEE [1] fue producto del trabajo realizado por un grupo de compañías interesadas en resolver básicamente el problema del acceso físico a los pines de los circuitos integrados (IC) colocados sobre una tarjeta de circuitos impresos (PCB) [2]. Como las tarjetas de circuitos impresos crecen en complejidad y densidad de componentes, debido a las constantes mejoras en las tecnologías de fabricación de circuitos integrados y de las mismas tarjetas, resultan también más difíciles de verificar, volviendo obsoletos los métodos tradicionales de detección de fallas (como las puntas de prueba y los generadores de tramas). Por tales motivos, se necesitan métodos más baratos y confiables para realizar pruebas de conectividad entre los circuitos integrados montados sobre la tarjeta. En 1980 el grupo JTAG (Join Test Action Group) comenzó a trabajar en una especificación para el diagnóstico de PCBs mediante exploración de contorno (boundary-scan testing, BST) la misma que luego se estandarizó en 1990 con el nombre IEEE Std Test Access Port and Boundary-Scan Architecture (Norma IEEE , Puerto de Acceso para Pruebas y Arquitectura de Exploración por el Contorno). Esta norma se conoce abreviadamente como BST, y también como JTAG, por el nombre del grupo creador. La gran ventaja ofrecida por el Boundary-Scan radica en su poder para controlar y observar mediante software los valores lógicos ( 0, 1 ) en los pines de los circuitos impresos a través de una interfase sencilla de cuatro líneas (bits), opcionalmente cinco. Con esta arquitectura es posible diagnosticar el estado de las pistas en la tarjeta (pistas abiertas, cortocircuitos, soldaduras frías), por ejemplo, forzando un pin de un circuito integrado a un valor dado y leyendo ese valor en un pin de un circuito integrado interconectado al anterior. Aun si algunos circuitos impresos en el PCB no soportaran la norma, la verificación de la tarjeta puede hacerse parcialmente con esta técnica, con el beneficio de ahorro de tiempo y mano de obra.

3 La Arquitectura BST La figura 1 [3] muestra la estructura básica de la arquitectura BST. El contorno de exploración (Boundaryscan) está formado por celdas (registro de desplazamiento y latches), cada una ligada a un pin y/o al sistema lógico interno del chip (System Logic). El dato puede ser desplazado serialmente por el contorno de exploración y capturado en los latches en los momentos indicados por el software. Para su implementación, esta arquitectura requiere como mínimo de cuatro pines de interconexión (TCK, TMS, TDI, TDO), tres registros (de Contorno o Boundary, de Paso o Bypass y de Instrucciones) y un Controlador de Acceso al Puerto de Pruebas (Test Access Port Controller o TAP Controller). Además debe soportar por lo menos 3 instrucciones: BYPASS (salto o paso de chip), SAMPLE/PRELOAD (muestreo / precarga) y EXTEST (fijación de un pin a un valor dado, con prioridad sobre el valor lógico de la salida). El fabricante del dispositivo con soporte para BST Copyright 1991, Texas Instruments Incorporated decide como armar la arquitectura, y la inclusión de registros e instrucciones opcionales. La información sobre Figura 1. Arquitectura Básica Boundary-Scan la arquitectura BST implementada en el dispositivo se provee normalmente en archivos BSDL (Boundary-Scan Description Language), que es un formato ampliamente aceptado y utilizado en la industria de test. El BSDL posee la misma sintaxis que el VHDL, el cual es un lenguaje estándar para la descripción de hardware. En el nivel de la tarjeta y en el nivel del sistema se emplea un lenguaje llamado HSDL (Hierarchical Scan Description Language) que describe la disposición de los circuitos en la tarjeta y la ubicación de las tarjetas en el sistema. Para los vectores de pruebas existe el formato SVF (Serial Vector Format). Estas normas (BST, BSDL, HSDL, VSF) [2] están soportadas, en su totalidad o parcialmente, por fabricantes y proveedores importantes como Texas Instruments, National Semiconductor, Hewlett Packard, Intel, Altera, Xilinx, etc. Descripción de Pines Pin Descripción Función TDI Test Data Input Entrada serial de datos como instrucciones, programación y vectores de prueba. Los datos son desplazados con cada cambio al nivel alto de TCK. TDO Test Data Output Salida serial de datos como instrucciones, programación y vectores de prueba. Los datos son desplazados con cada cambio al nivel bajo de TCK. Cuando no está activado el desplazamiento de datos su estado es tri-state. Uniendo TDO de un chip con TDI de otro, y así sucesivamente con todos los demás chips del PCB, se forma una cadena de boundary-scan, que puede ser manejada mediante software, por TMS TCK TRST Test Mode Select Test Clock Input Test Reset Input ejemplo, a través del puerto paralelo de una PC. Entrada de control que determina un cambio en la máquina de estados del controlador del TAP. Las transiciones se producen en el cambio al nivel alto de TCK. Entrada de reloj para el controlador del TAP y circuito BST. Activo en el nivel bajo. Inicializa el circuito de exploración de contorno. Es un pin opcional.

4 Registros Registro de Instrucciones (IR) Registro de Datos (DR) Según la instrucción cargada en esté registro se realizará una acción y se accederá al registro de datos adecuado. Está compuesto por varios registros multiplexados (algunos son opcionales). Solamente uno de los siguientes registros es el registro de datos propiamente dicho. Registro de Bypass (Bypass Register) Registro de Contorno de Exploración (Boundary-Scan Register) Registro de IDCODE (Opcional) Este registro tiene una longitud de 1 bit y provee un camino directo entre TDI y TDO Es un registro de desplazamiento con latches compuesto por todas las celdas del Contorno de Exploración del dispositivo. Su longitud varia según el dispositivo. Aquí se carga el código de identificación del vendedor. El Controlador del TAP El controlador del TAP es una máquina de 16 estados (ver figura 2). El reloj de esta máquina es TCK y su control es TMS. Estando en cualquier estado se puede volver al estado inicial (Test Logic Reset) fijando TMS en el nivel bajo y enviando 5 pulsos consecutivos de reloj por TCK. En esta máquina se realizan 3 operaciones básicas: captura (CAPTURE), desplazamiento (SHIFT) y actualización (UPDATE) sobre los registros de Instrucciones (IR) y de Datos (DR) Copyright 1991, Texas Instruments Incorporated Instrucciones del BST Figura 2. Diagrama de Estados del Controlador Instrucción BYPASS Selecciona el registro de Bypass (de un 1 bit) y lo coloca entre los pines TDI y TDO. Sirve para saltar al chip directamente y seguir con otro en la cadena. El dispositivo no interrumpe su funcionamiento normal. Figura 3. Una vez que se entra al estado Shift-DR los datos pasan a través del dispositivo por intermedio del Registro Bypass. Copyright 1991, Texas Instruments Incorporated

5 Instrucción SAMPLE/PRELOAD Toma una muestra de la data del dispositivo sin afectar el funcionamiento de la lógica del dispositivo. Esta instrucción se realiza en 3 fases: captura, desplazamiento y actualización. Figura 4. La fase de CAPTURA se realiza en el estado Capture-DR. Los datos de los pines del dispositivo pasan a los Registros de Captura. porated Copyright 1991, Texas Instruments Incorporated Figura 5. La fase de DESPLAZAMIENTO se realiza en el estado Shift-DR. En esta fase los datos capturados se desplazan y se cargan por TDI nuevos datos para actualizar. Copyright 1991, Texas Instruments Incorporated Figura 6. La fase de ACTUALIZACION se realiza en el estado Update-DR. Los nuevos datos se cargan en los registros de actualización (latches). Copyright 1991, Texas Instruments Incorporated

6 Instrucción EXTEST Fuerza los valores de los pines del dispositivo con los valores almacenados en los registros de actualización (en el estado Update-IR). Al igual que la anterior instrucción se realiza en 3 fases: captura, desplazamiento y actualización. Esta instrucción afecta el funcionamiento normal del dispositivo. En la fase de actualización los valores en los latches pasan a los pines de salida del chip. Instrucción IDCODE (Opcional) Selecciona el registro de IDCODE y lo coloca entre los pines TDI y TDO. El IDCODE lo provee el fabricante del chip. II. DISEÑO DEL SISTEMA DE VERIFICACIÓN El sistema ha sido proyectado para permitir la prueba de circuitos impresos a través de la Internet. El modo de uso sería como sigue: 1. El usuario envía la información de su sistema en un archivo HSDL, así como los archivos BSDL de cada componente. 2. Dos programas, Servidor y Cliente, guían los pasos del usuario. 3. El programa Servidor genera el archivo SVF a partir de los archivos BSDL y HSDL, y lo envía al programa Cliente. 4. El programa Cliente se encarga de aplicar los vectores de prueba a través del puerto paralelo de la máquina del usuario. El intercambio de información entre los programas Servidor y Cliente se puede realizar mediante aplicaciones CGI, a través de archivos html o vía ftp. Adicionalmente, existe un problema de hardware cuando se trata de verificar las interconexiones del sistema con el medio exterior. Ello puede resolverse con módulos de hardware construidos a medida del sistema bajo prueba, solamente para la interfase de la tarjeta. Finalmente, para abarcar una amplia variedad de circuitos de prueba, en la etapa de desarrollo del sistema se ha optado por utilizar dispositivos de lógica programable de Altera Corp [4]. Gracias a su reprogramación, tanto en lógica como en interconexiones, estos dispositivos servirán para emular varios tipos de tarjetas PCB. III. EL SISTEMA DE DESARROLLO. TARJETAS DE EXPERIMENTACIÓN Para realizar las pruebas con JTAG (BST) se construyeron unos módulos para diferentes aplicaciones. Las tarjetas construidas están basadas en chips de lógica programable de Altera Corp [5]. La figura 7 muestra un arreglo básico para realizar pruebas generales con BST. El ByteBlaster [6] es un dispositivo de diseño muy sencillo que se conecta entre el puerto paralelo de la PC y el circuito bajo prueba, que en este caso consta de dos tarjetas basadas en el chip EPF10K10LC Un teclado matricial de 16 teclas y un adaptador de teclado y visualizador constituyen el sistema periférico del sistema bajo prueba. El teclado se utiliza como botonera de entrada, el visualizador se utiliza para la salida de datos. Un adaptador para pruebas en cascada es necesario para formar la cadena JTAG entre ambos chips de lógica programable. Sirve para conectar los chips en cascada y formar un registro de boundary-scan múltiple.

7 ByteBlaster Adaptador para Pruebas en Cascada Adaptador de Teclado y Visualizador con Siete Segmentos Teclado Matricial Tarjeta 1 (basada en EPF10K10LC84) Tarjeta 2 (basada en EPF10K10LC84) Figura 7. Sistema Básico de Emulación de Tarjetas PCB Tarjeta de prueba basada en FLEX10K10 LC84 Requiere de una fuente (no necesariamente regulada) de 7.5V a 35V que proporcione 500mA. (los transformadores AC-DC que se consiguen en las tiendas comerciales sirven bien). Posee dos zócalos para cristales y dos entradas para señales de reloj externas. Los pines de usuario (59 pines en total, entre pines I/O, señales de reloj y pines dedicados), GND y VCC se encuentran disponibles repartidos en dos zócalos de expansión. Cumple doble propósito: como tarjeta para realizar pruebas con JTAG en cascada y como módulo experimental para diseños con lógica programable basados en el chip EPF10K10LC84. Su programación se puede realizar por la computadora mediante el software MAXPLUS-II de Altera Corp. Esta tarjeta soporta los siguientes modos de configuración: Modo Configuración Serial Pasiva con cable ByteBlaster. EPF10K 10 Figura 8. Esquemático de la Tarjeta de prueba basada en EPF10K10LC84.

8 ( ( Modo Programación y Configuración JTAG. Modo Programación y Configuración JTAG de Múltiples Dispositivos. Las figuras siguientes muestran las fotografías de un par de tarjetas construidas con funciones similares a la anterior, con algunas variantes y excepciones. Estas tarjetas servirán para realizar pruebas en cascada con chips de diferentes familias de dispositivos. Figura 9. Tarjeta de prueba basada en EPM9320GC Posee modo de programación y prueba con JTAG. Figura 10. Tarjeta basada en EPF10K10LC84. Es muy similar a la anterior; posee dispositivos 74LS244 de entrada y salida para algunos pines de usuario Modo Programación y Configuración JTAG La programación y configuración por interfase JTAG de un dispositivo requiere conectar el cable ByteBlaster en el conector J4 y las señales TDI y TDO del CPLD a los pines respectivos del cable ByteBlaster (J17). J4 y J17 se refieren a la tarjeta basada en el EPM9320GC ! $ %! #! " " # & % # ' ) + Figura 11. Conexión de un solo dispositivo para programación y test. ) * Modo Programación y Configuración JTAG de Múltiples Dispositivos La programación y configuración por interfase JTAG de múltiples dispositivos requiere para la primera tarjeta de la conexión del cable ByteBlaster en el conector J4, de la conexión de la señal TDI del PLD al TDI del ByteBlaster y de la conexión de la señal TDO de la última tarjeta con la señal TDO del ByteBlaster (J17). Además el conector TX_J debe conectarse con el conector RX_J de la siguiente tarjeta. Para las demás tarjetas se requiere de la conexión de la señal TDI del PLD con la señal TDO de la anterior tarjeta (J17), además de la habilitación de la recepción de las señales TCK y TMS (J16). Para la última tarjeta de la cadena su conector TX_J se conecta con el conector RX_J de la primera tarjeta. La figura 12 muestra una conexión de tres tarjetas en cascada JTAG.

9 <, -. / ; : 9 = 9 = 9 : 9 : Figura 12. Ejemplo de conexión de tres tarjetas en cascada para programación y verificación con JTAG. IV. SOFTWARE BASADO EN LA ARQUITECTURA BST El desarrollo del software para el sistema de verificación es la tarea más delicada y laboriosa. Requiere la aplicación de algoritmos matemáticos y gráficos para encontrar las mejores rutas que cubran en el menor tiempo posible la mayor cobertura práctica de casos. Se espera que la cobertura sea de un 100% en el nivel de la tarjeta, mas el tiempo de prueba aun no ha sido estimado, el cual depende básicamente de la complejidad de la tarjeta (chips e interconexiones) y de los algoritmos implementados sobre el sistema operativo de la máquina. Desde un principio se ha empleado el lenguaje C para construir los programas, pero en versiones posteriores se pretende utilizar C++ (para facilitar la estructuración y crecimiento del programa) y Java (para verificación remota interactiva). Incluso se ha previsto implementar en hardware las partes más críticas del sistema, ubicadas en los circuitos y algoritmos para las transferencias de datos. El software desarrollado hasta el momento realiza las funciones básicas de control señaladas en la norma BST. Para la configuración del controlador del TAP se implementó el código en C correspondiente a cada instrucción JTAG. Se utilizaron los diagramas de tiempo de cada instrucción, junto con el diagrama de estados del controlador. De estos se dedujo la secuencia para las señales TCK y TMS, y los estados para escribir en TDI y leer por TDO. Para ejecutar una instrucción se debe ejecutar los siguientes pasos: 1. Habilitar ByteBlaster 2. Inicializar máquina de estados 3. Cargar instrucción en el Registro de Instrucciones (IR) 4. Leer/Escribir en el Registro de Datos(DR) Algunas de las funciones del programa de prueba son: void envia(byte TMS, byte TDI); byte recibe(byte); byte recibe_envia(byte TMS, byte TDI); void reset_tap(void); void inic_tap(void); void carga(byte instr); void instrucc(byte instr); void retardo(void); Rutinas para la lectura y/o escritura de datos del controlador TAP Rutina para inicializar el Controlador Inicializa el controlador y habilita el ByteBlaster Cargar instrucción en el IR Para la ejecución de una instrucción Retardo de tiempo

10 Los códigos de las instrucciones se almacenan en arreglos estáticos (por ejemplo CODIGOS_INSTRUCCION[5]). Hay que notar que dependiendo del dispositivo su longitud y contenido cambian. Para el caso del EPF10K10L84, las instrucciones tienen una longitud de 10 bits y su valor se muestra a continuación. /* Instrucciones del EPF10K10L84 */ char *CODIGOS_INSTRUCCION[5]= { " ", /* SAMPLE_PRELOAD */ " ", /* EXTEST */ " ", /* BYPASS */ " ", /* UESCODE */ " " /* IDECODE */ }; Actualmente, una tarjeta puede revisarse con este sistema, suministrando las interconexiones entre los chips, los archivos BSDL de los chips y ajustando manualmente en el programa las variables para la cadena JTAG. En el nivel del software, todas las instrucciones han sido confirmadas y han trabajado tal como lo manda la norma sobre los dispositivos que se emplearon, sin embargo, restan realizar varias tareas para obtener un sistema con mejores prestaciones, tales como: 1. Conversión automática de archivos BSDL en datos dinámicos para los programas. 2. Conversión automática de archivos HSDL para reconocer la interconexión entre chips 3. Generación de los archivos VSF para la aplicación de los vectores de prueba. 4. Aplicaciones para programación remota vía Internet. El diseño del software es modular por lo que conforme se vayan construyendo los módulos se irán incorporando y habilitando para el funcionamiento del sistema. V. CONCLUSIONES La arquitectura boundary-scan permite la revisión de un sistema digital mediante técnicas de software. Teniendo en cuenta que esta arquitectura se encuentra incorporada en los chips de los principales fabricantes para aplicaciones comerciales, resulta viable el desarrollo del software para JTAG, puesto que el software se puede desarrollar un ambiente académico casi bajo las mismas condiciones que en el resto del mundo. Otras aplicaciones interesantes se derivan de la arquitectura Boundary-Scan. Además de su aplicación en los dispositivos de lógica programable y memorias FLASH, esta arquitectura se aprovecha para la configuración y reprogramación de hardware local o remotamente. También en este campo es posible competir desarrollando las herramientas de software, que incluso pueden abarcar las herramientas de diseño integrado de software y hardware. VI. REFERENCIAS [1] IEEE Standard "Test Access Port and Boundary-Scan Architecture," disponible en IEEE, 445 Hoes Lane, PO Box 1331, Piscataway, New Jersey , USA. La norma fue revisada en 1993 y otra vez en [2] Boundary-Scan Tutorial. 1998, ASSET InterTech, Inc. 1998, R. G. Bennetts. Disponible en [3] Scan Educator Texas Instruments Incorporated 1991 [4] Altera Corporation, [5] IEEE (JTAG) Boundary-Scan Testing in Altera Devices Nota de Aplicación 39 - Febrero 1998, ver. 4.0 [6] ByteBlaster Parallel Port Download Cable Data Sheet Febrero 1998, ver 2.01