Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica IE – 0502 Proyecto Eléctrico Desarrollo de una herramienta para la obtención del identificador único para unidades ULT (Unit Level Traceability), para los procesadores Intel® Pentium® 4 Prescott-N Por: Richard Marín Benavides Ciudad Universitaria Rodrigo Facio Julio del 2006 Desarrollo de una herramienta para la obtención del identificador único para unidades ULT (Unit Level Traceability), para los procesadores Intel® Pentium® 4 Prescott-N Por: Richard Marín Benavides Sometido a la Escuela de Ingeniería Eléctrica de la Facultad de Ingeniería de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERÍA ELÉCTRICA Aprobado por el Tribunal: _________________________________ Ing. Federico Ruiz Ugalde Profesor Guía _________________________________ Dr. Jorge Romero Chacón Profesor lector _________________________________ Ing. Edward Castillo Solera Profesor lector ii DEDICATORIA Dedicado a mis padres José y Jeanina, y a esas personas y familiares que siempre guardare en mi corazón porque me brindaron una mano y apoyo incondicional. También les agradezco a todas las personas que han dejado en mi una enseñanza a lo mi largo de vida, me han enseñado a crecer. También le dedico este esfuerzo al ser superior que muy pocos logran comprender, pero que siempre esta ahí asombrándonos con las cosas de la vida. iii RECONOCIMIENTOS A mi profesor Guía Federico Ruiz Ugalde por paciencia y apoyo para realizar este proyecto. A Edward Castillo Solera por ser mi primer apoyo en Intel® y darme ánimo en momentos claves. A todas las personas dentro de Intel que aportaron su ayuda e ideas para que este proyecto tuviera éxito. iv ÍNDICE GENERAL ÍNDICE DE FIGURAS..................................................................................vii ÍNDICE DE TABLAS.................................................................................. viii NOMENCLATURA........................................................................................ix RESUMEN.......................................................................................................xi CAPÍTULO 1: Introducción ...........................................................................1 I. Justificación y Antecedentes........................................................................1 1.1 Objetivos.................................................................................................................3 1.1.1 Objetivo general..............................................................................................3 1.1.2 Objetivos específicos ......................................................................................3 1.2 Metodología ............................................................................................................3 CAPÍTULO 2: Desarrollo teórico ..................................................................4 2.1 ULT (Unit Level Traceability) ..................................................................4 2.2 Introducción al JTAG................................................................................4 2.3 Exploración Periférica (Boundary Scan).................................................5 2.4 Señales de interfaz del JTAG..................................................................10 2.5 El controlador del TAP............................................................................11 2.5.1 Registro de instrucción del TAP..................................................................................16 2.5.2 Registros de Datos (DR) ..............................................................................................16 2.6 Instrucciones del estándar IEEE 1149.1 ................................................19 2.6.1 Instrucciones Requeridas del IEEE 1149.1..................................................................19 2.6.2 Instrucciones opcionales del IEEE 1149.1 ..................................................................20 2.7 Modelo de Componentes de Objeto de Microsoft (COM) ...................22 Capitulo 3: Hardware y Software para acceder al ULT............................25 3.1 El puerto de Pruebas................................................................................25 3.1.1 Diseño del puerto de pruebas.......................................................................................26 3.1.2 Acceso al puerto Debug en Tarjetas madre comerciales ............................................31 3.2 Emulador ITP para leer ULT .................................................................32 3.3 Implementación del hardware ................................................................35 3.4 Implementación del Software .................................................................37 v Capitulo 4: Conclusiones y Recomendaciones ............................................50 4.1 Conclusiones .............................................................................................50 4.2 Recomendaciones .....................................................................................52 BIBLIOGRAFÍA............................................................................................53 vi ÍNDICE DE FIGURAS Figura 2.1 Estructura simplificada de las celdas periféricas de entrada y salida para un dispositivo de exploración periférica [1] ............................................................................6 Figura 2.2 Diagrama General de una interfaz de exploración periférica JTAG [3] ..........7 Figura 2.3 Diagrama de transición de los estados del controlador del TAP [3] ...............12 Figura 2.4 Registro de instrucción del TAP. [Fuente Confidencial] ................................15 Figura 2.5 Operación del registro de instrucción. [Fuente Confidencial] ........................15 Figura 2.6 Arquitectura simplificada del registro de datos [1] .........................................17 Figura 2.7. Estructura del registro de identificación del dispositivo [2]...........................18 Figura 3.1 Puerto de pruebas en tarjeta Madre especial para pruebas ..............................25 Figura 3.2 Vista superior del conector con la numeración de pines .................................29 Figura 3.3 Orden de conexión entre CPU (superior), “interposer” con puerto de pruebas (medio), y “socket” (abajo) [6] .........................................................................................32 Figura 3.3 Emulador de pruebas ITP-XDP.......................................................................33 Figura 3.4 Diagrama de conexión de la solución para acceder al puerto de pruebas con una tarjeta madre comercial, un “interposer” y el emulador ITP-XDP ...........................34 Figura 3.5 Vista Superior del “interposer” .......................................................................35 Figura 3.6 Vista lateral del “interposer” con el procesador insertado ..............................36 Figura 3.7 Tarjeta madre con “interposer”, procesador y ITP conectados .......................37 Figura 3.8 Diagrama de Flujo del programa realizado para leer ULT .............................38 Figura 3.9 Modelo del comunicación entre programa ejecutable implementado (.exe) y la consola de ITP. [Fuente Confidencial] .............................................................................39 vii ÍNDICE DE TABLAS Tabla 3.1. Descripción pines de entrada del puerto de pruebas que son manejadas por el emulador ...........................................................................................................................27 Tabla 3.2 Descripción pines de salida del puerto de pruebas que son manejadas por el sistema que se está probando ............................................................................................28 Tabla 3.3. Terminaciones Recomendadas del Puerto de Pruebas.....................................30 viii NOMENCLATURA ULT Registro identificador único para unidades“Unit Level Traceability”, TAP (Test Access Port) Puerto de acceso a pruebas IR Registro de instrucción del TAP DR Registro de tatos del TAP IC Circuito Integrado BSR (Boundary Scan Registry) Registro de exploración periférica BSCs (Boundary Scan Cells) Celdas de exploración periférica UDR (User Data Register) Registro de datos de usuario ITP (In Target Probe) Este acrónimo es usado para referirse a una herramienta de control de pruebas que es producido por Intel® y otros fabricantes. DP (Debug Port) Puerto de pruebas JTAG (Joint Test Action Group) referido al estandar para hacer pruebas en circuitos integrados Puerto JTAG Puerto estandarizado de pruebas por el estándar de la IEEE 1149.1 “Interposer” Dispositivo que funciona similar a un “socket” pero del cual se puede acceder al puerto JTAG, se coloca entre el procesador y “socket” de la tarjeta madre COM (Component Object Model) DLL (Dynamic Linking Library) ix QSC Quality Support Center (Centro de Soporte de Calidad). Centro de servicio y soporte a los clientes de la Corporación Intel. x RESUMEN El objetivo principal de este proyecto fue desarrollar una herramienta que permite leer el ULT, el cual es un identificador único para los Procesadores Intel® , sin embargo este encuentra protegido y codificado dentro de una cadena de fusibles en el procesador. El desarrollo del proyecto estuvo dividido en cuatro etapas principales: investigación, propuestas y selección, desarrollo del prototipo y la etapa de documentación. La investigación cumplió el objetivo de entender de que se trata el código ULT y la forma de accederlo, la etapa de propuestas y selección consistió en buscar alternativas para leer ULT y seleccionar una, la que se seleccionó fue utilizar un hardware llamado ITP y una tarjeta madre comercial, la cual al no tener puerto de pruebas (JTAG) se necesitó un hardware llamado “interposer” que implementa este puerto. La etapa de desarrollo del prototipo se logró utilizando una tarjeta madre comercial, fuente y disipador, además se tuvo que adquirir el ITP y el “interposer”. Se desarrolló la aplicación utilizando el lenguaje de programación C++, por medio del cual implementó la comunicación con el ITP, la lectura de fusibles, la selección de los bits adecuados y la descodificación de estos bits a ULT. Los mayores alcances de este proyecto fueron la aceleración de los procesos de estudio de las fallas en procesadores para dar una respuesta más rápida a los clientes y se disminuyen los costos, ya que se encontró que no se necesita comprar tarjetas madres especiales para pruebas que permiten leer ULT. xi CAPÍTULO 1: Introducción I. Justificación y Antecedentes Los laboratorios QSC (Centro de Soporte de Calidad) de Intel® se encargan de dar suporte a los clientes cuando se presentan fallas en los microprocesadores. Para este proceso es importante conocer el historial de su proceso, producción y pruebas a las que se sometió dicha unidad en el momento de fabricación, de esta manera se facilita la búsqueda de las posibles causas de problema. El propósito de este proyecto fue desarrollar una herramienta que permite obtener acceso a la información del ULT (Unit Level traceability), un identificador único para cada unidad y con el cual se puede acceder al historial de las diferentes etapas de producción y pruebas del procesador. Esta información puede ser obtenida utilizando los costosos y pesados sistemas disponibles en los laboratorios QSC’s y otras maquinas que se encuentran en el piso de producción de Intel®, sin embargo Intel® posee más sitios con oficinas que con fabricas, esto dificulta el trabajo de leer el ULT en sitios oficina. Debido a esto los microprocesadores tienen que ser enviados a una planta de manufactura Intel®, para hacer todos estos estudios. Algunos de los impactos positivos de este proyecto son: - Se reduce la dependencia en el uso de equipo de fábrica con lo que se hacen más eficientes las validaciones para el análisis de prueba de fallas. 1 2 - Al iniciar los estudios antes de que las unidades se envíen, permite una más pronta resolución de problemas reportados por los clientes debido a que se obtiene información clave en un lapso menor de tiempo - Todos los laboratorios QSC del mundo podrán desarrollada en este proyecto, utilizar la herramienta de esta forma no necesitaran enviar las unidades a las plantas de manufactura para leer ULT. 3 1.1 Objetivos 1.1.1 Objetivo general Desarrollar una herramienta alternativa a las máquinas de pruebas de manufactura de la empresa Componentes Intel® Costa Rica para poder obtener el ULT en procesadores Pentium® 4 Prescott (478-pin). 1.1.2 Objetivos específicos Identificar los contactos y fuentes de información para desarrollar el proyecto Identificar los requerimientos de hardware y software necesarios para la implementación de la herramienta. Probar la funcionalidad mediante prueba del prototipo. . 1.2 Metodología El desarrollo del proyecto estuvo dividido en cuatro etapas principales: Una etapa de investigación, la etapa de propuestas y selección, etapa de desarrollo del prototipo y la etapa de documentación. La etapa de investigación consistió en la recolección de la información relevante al proyecto y el estudio de la misma. La etapa de propuestas y selección consistió en proponer alternativas para la implementación del prototipo, teniendo en cuenta costos, tiempo, riesgos, entre otros . La etapa de desarrollo del prototipo consistió en la implementación de este y su validación. CAPÍTULO 2: Desarrollo teórico 2.1 ULT (Unit Level Traceability) El ULT es una identificación (xxxxxxxx xxx xx xx) única para cada microprocesador Intel®. Esta puede se utilizada para conocer información acerca de la historia del microprocesador en el proceso de fabricación y las pruebas que se le realizaron, esto a través de bases de datos utilizando como clave el ULT. Los primeros ocho caracteres alfanuméricos corresponden al lote de fabrica, los siguientes 3 números es del numero de oblea de silicio o "wafer" de donde se saco el microprocesador para ese lote, y los dos últimos pares de números son la posición del eje X y Y respectivamente (tomando el centro del "wafer" como centro de coordenadas), de donde fue cortado el procesador. El ULT esta almacenado dentro de una cadena de fusibles en el procesador, este puede ser obtenido por medio de un puerto llamado “Debug port”, puerto JTAG o puerto de pruebas el cual es un estándar para realizar variadas pruebas en los distintos circuitos integrados o procesadores. Sin embargo los fusibles de donde es obtenido el ULT, no son de acceso público y están protegidos y codificados en diversas áreas del microprocesador. 2.2 Introducción al JTAG Históricamente, la mayoría de tarjetas impresas eran probadas utilizando puntos de prueba (“bed-of-nail”) sobre la tarjeta. Los recientes avances en la tecnología de alta integración hacen que los dispositivos con circuitos integrados sean altamente densos, con 4 5 lo que se produjeron grandes retos y dificultades para el acceso a los puntos de prueba y un alto costo del equipo utilizado para pruebas. En el año 1985, una unión de compañías Europeas formó un Grupo para solucionar estas dificultades, Joint European Test Action Group (JETAG). El JETAG hizo un llamado a incorporar un hardware estándar en las tarjetas impresas y los componentes (controlados por software), eliminado la necesidad de sofisticados equipos de pruebas de circuitos. Para el año 1988, este concepto ganó reputación en Norte América y varias compañías formaron el Joint Test Action Group (JTAG) para formalizar la idea. En 1990, el Instituto de Ingeniería Eléctrica y Electrónica (IEEE) redefinió el concepto y creó el estándar 1149.1, el cual es un estándar de la IEEE para el acceso al puerto de pruebas (TAP) y a la arquitectura de la exploración periférica (Boundary Scan Architecture).1 2.3 Exploración Periférica (Boundary Scan) La exploración periférica es una metodología que permite el control y observación de los pines periféricos de un dispositivo compatible con el JTAG, este control se realiza por medio de software, lo cual permite realizar una amplia gama de pruebas en busca de errores (debugging) y diagnósticos en un sistema a través de un pequeño número de pines de prueba. 1 http://www.engr.udayton.edu/faculty/jloomis/ece446/notes/jtag/jtag1.html 6 Las señales en el dispositivo son monitoreadas seriamente por unas celdas especiales (I/O cells), controlando así las entradas y probando las salidas bajo diferentes condiciones.2 Figura 2.1 Estructura simplificada de las celdas periféricas de entrada y salida para un dispositivo de exploración periférica [1] La figura 2.1 ilustra de forma muy simplificada las posibles estructuras para los pines de entrada y salida que obedecen el estándar del JTAG. Durante operaciones normales (no de prueba), las celdas periféricas se encuentran inactivas y permiten a los datos ser propagados a través del dispositivo normalmente. Durante el modo de prueba, todas las señales son capturadas para analizarlas y todas las salidas son puestas en un tipo de cadena o secuencia. La operación de estas celdas es controlada a través del puerto de acceso a pruebas (Test Access Port ) o TAP y el registro de instrucciones. 2 http://www.embedded.com/story/OEG20021028S0049 7 Figura 2.2 Diagrama General de una interfaz de exploración periférica JTAG [3] En la figura 2.2 se muestra una posible interfaz o Arquitectura de exploración periférica JTAG. Sin embargo se debe aclarar que esta figura y su consecuente explicación es de fines didácticos y el objetivo es entender el funcionamiento de la exploración periférica, además como se verá más adelante en este apartado, algunas funciones o instrucciones que se van a explicar son opcionales en el estándar JTAG. 8 Como se observa en la figura 2.2 todas las señales entre la lógica-base (Core Logic) del chip y los pines son interceptados por un camino de monitoreo serial conocido como “Boundary Scan Register” (BSR) y se muestra como las celdas “C0”, “C1”, “C2”, “C3” y “C4”. En operación normal (No-Test) se pueden conectar de manera transparente a este camino las señales de la lógica-base a los pines y efectivamente volverse invisibles para el BSR. Para el modo de prueba externa (Extest), se puede desconectar la lógica-base de los pines, controlar los pines de salida (Pin1 y Pin2 ) por si mismo, además de leer y almacenar los estados de los pines de entrada (Pin0 y Pin2). En el caso de las pruebas internas (Intest3), se puede desconectar la lógica-base de los pines, manejando las señales de entrada de lógica-base, además de leer y almacenar los estados de las señales de salida de la lógicabase Como ejemplo en la figura 2.2, y suponiendo que la interfaz del JTAG esta en modo Extest, C0 es la celda BSR que está capturando el estado de la entrada en el pin 0. C1 es la celda BSR que está manejando el pin 1. Como se puede observar C2 no corresponde a algún pin específico, sin embargo esta habilita la celda que controla la dirección del pin 2 (bidireccional). La celda de entrada C3 captura el estado del pin 2, y C4 es una celda de salida que maneja también el pin 2. Resumiendo podemos identificar 3 tipos de celdas BSR: 3 Intest es una instrucción opcional del estándar JTAG y es agregada aquí para ayudar explicar el funcionamiento de las celdas 9 Celdas de entrada como C0 y C3. Las cuales siempre están asociadas con un pin de entrada y capturan esta entrada cuando la interfaz JTAG está en modo interno de prueba (INTEST) Celdas de salida como C1 y C4. Las cuales siempre están asociadas con un pin de salida, el cual es manejado cuando la interfaz JTAG está en modo externo de prueba (EXTEST) Celdas de Habilitación como C2. No están asociadas con algún pin especifico, pero si controlan la dirección de pines bidireccionales o habilitan el pin como entrada o como salida Las compuertas E0, E3 y E4 pueden operar bajo el control del TAP, capturando o aplicando los estados de la respectiva entrada o salida, hacia las celdas o desde los pines del chip. El estado de captura o aplicación tiene lugar durante las transiciones de la máquina de estados del TAP y sólo si la IR (registro de instrucciones) ha sido previamente cargado con una instrucción y contiene el código de instrucción apropiado (ejemplo: EXTEST). Las compuertas I0, I3 y I4 operan bajo el control del TAP capturando o aplicando los estados de la respectiva entrada o salida, hacia las celdas o desde las líneas de señales de la lógica interna del chip. La captura o aplicación tiene lugar durante las transiciones de la máquina de estados del TAP, y sólo si se ha colocado el código de instrucción en el IR adecuado, en este caso sería la instrucción INTEST. 10 Las compuertas N0, N1 y N3 son habilitadas únicamente cuando el sistema esta en modo normal de operación y conecta los pines del chip a las señales de la lógica base interna; es como si el camino de la exploración periférica no estuviera presente. El contenido del Registro BSR se puede leer bit a bit en una cadena serial, esto es, usando las señales TDI y TDO del JTAG. El BSR “lee” y “escribe” (coloca) operaciones que se dan al mismo tiempo, con cada nuevo valor que cambia en la señal TDI el valor previo es sacado afuera por TDO. La misma técnica también es usada para leer y escribir los valores de los otros registros del JTAG, teniendo el controlador del TAP conectado entre las señales de los pines TDI y TDO, en lugar del BSR. 2.4 Señales de interfaz del JTAG La interfaz del JTAG o TAP usa las siguientes señales, las cuales se deben proveer en cada chip que cumple con el estándar • TRST# * (Test-ReSeT) Esta señal de entrada es opcional, lo que hace es inicializar o deshabilitar la interfaz de prueba • TCK (Test CLocK) Es la señal de reloj que controla los tiempos de la interfaz JTAG y es independiente de cualquier reloj del sistema. TCK es generada por el equipo que controla la prueba y no por el dispositivo que se está probando. Este reloj puede tener cualquier frecuencia hasta un máximo de 100 MHz, inclusive el tamaño del pulso puede ser variado. 11 • TMS (Test Mode Select) Con esta señal de entrada se controla las transiciones de la máquina de estados de JTAG • TDI (Test Data Input line) Es una entrada a través de la cual ingresan los datos de manera serial a los registros del JTAG (BSR, registro de instrucción, y otros registros de datos) • TDO (Test Data Output line) Es utilizada como salida serial de los datos provenientes de los registros del JTAG al equipo que controla la prueba. Esta salida lleva una muestra de los valores de la cadena de bits de la exploración periférica y los propaga al siguiente chip de forma serial en los circuitos de pruebas. La organización normal del circuito de pruebas en una tarjeta impresa, que incorpora varios chips con soporte JTAG es conectado a las señales TRST*, TCK, y TMS a cada chip en paralelo, y se Interconectan las señales TDO y TDI directamente entre cada chip. De esta manera la tarjeta presenta una interfaz simple de pruebas que tiene las mismas cinco señales mencionadas arriba. Un arreglo simple para tarjetas que tienen solo unos pocos chips con interfaz JTAG sería proveer un puerto de pruebas para cada chip, y controlar estas independientemente. 2.5 El controlador del TAP La operación de la interfaz de pruebas es manejada por el controlador del TAP. Esta es una máquina de estados (dieciséis estados), la cual es mostrada en la figura 2.3, contiene 12 un estado de reset, un estado de correr-prueba/espera (run-test/idle), y dos ramas o caminos mayores que se pueden seguir (IR y DR). Estas ramas permiten el acceso al registro de instrucción del TAP o alguno de los tantos registros implementados en el TAP. La señal de entrada TMS es utilizada para controlar el rumbo a través de la máquina de estados del TAP. Las instrucciones y los datos de prueba son cargados serialmente (en los estados Shift-IR y Shift-DR respectivamente) usando el pin de entrada TDI. Figura 2.3 Diagrama de transición de los estados del controlador del TAP [3] 13 Generalmente la instrucción del TAP es seleccionada primero (a través de la rama IR). Si un registro es asociado con esa instrucción, este será automáticamente conectado entre TDI y TDO cuando la rama DR de la máquina de estados sea recorrida. El estándar IEEE 1149.1 hace una descripción de los estados y su operación: Test-Logic-Reset: En este estado, la lógica de pruebas es deshabilitada y la operación normal del chip es establecida. El registro de instrucción (IR) es forzado a tomar el valor IDCODE4. Sin importar cual sea el estado original de la máquina de estados, el controlador ingresa a este estado de reset cuando la señal de entrada TMS es mantenida activa por al menos cinco ciclos de reloj. También se entra en este estado inmediatamente después que la señal TRST·# es activada, y generalmente de manera automática cuando el chip es encendido. El controlador del TAP no puede dejar este estado mientras que la señal TRST# se encuentre activa. Run-Test/Idle: Este es un estado de espera o reatención. En este estado el contenido de todos los registros de prueba retienen sus valores previos. También aquí se corre la prueba. Select-IR-Scan: Este es un estado temporal del controlador en el cual se decide si se va o no a ingresar a la rama IR. Todos los registros mantienen sus valores previos. Capture-IR: En este estado, el registro Shift (ver figura 2.4) contenido en el IR carga un valor predeterminado (donde los dos bits menos significativos son “01”) en el flanco positivo del TCK. La salida paralela del IR no cambia (“instrucción actual”) en este estado. 14 Shift-IR: El registro Shift contenido en el IR es conectado entre TDI y TDO y se cambia un bit a la vez, es seriamente ingresado en TDI en el flanco positivo de TCK. La salida llega a TDO en el flanco negativo de TCK. La instrucción actual no cambia en este estado. Exit1-IR: Este es un estado temporal. La instrucción actual no cambia en este estado. Pause-IR: Detiene temporalmente cualquier cambio en el registro de instrucción. La instrucción actual no cambia en este estado. Exit2-IR: Este es un estado temporal. La instrucción no cambia en este estado Update-IR: La instrucción que ha sido ingresada al registro Shift dentro del IR (ver figura 2.4) es puesta a la salida del IR en el flanco negativo del TCK. Una vez que la instrucción ha sido puesta como instrucción actual, esta se mantiene como tal hasta el próximo estado Update-IR. (O hasta que el controlador de la maquina de estados sea reiniciado) Select-DR-Scan: Este es un estado temporal del controlador después del cual se decide si se va o no a ingresar a la rama DR. Todos los registros mantienen sus valores previos. Capture-DR: En este estado, El registro de datos es seleccionado por la instrucción actual y puede capturar datos en sus entradas paralelas (similar a Capture-IR) Shift-DR: El registro de datos que es conectado entre TDI y TDO es el resultado de la selección dada por la actual instrucción y se cambia un bit a la vez, es seriamente ingresado en TDI en el flanco positivo de TCK. La salida llega a TDO en el flanco negativo de TCK. La salida paralela del registro de datos no cambia mientras se están ingresando los bits en este registro. Exit1-DR: Este es un estado temporal. Todos los registros mantienen sus valores previos 15 Pause-DR: Permite que los datos seleccionados en el registro de datos sean temporalmente “congelados” sin detener el reloj. Todos los registros mantienen sus valores previos. Exit2-DR: Este es un estado temporal. Todos los registros mantienen sus valores previos Update-DR: Permite que datos desde registro Shift (camino entre TDI y TDO) sea cargado a la salida paralela del registro de datos seleccionado (si es que se aplica) en el flanco negativo del TCK. Figura 2.4 Registro de instrucción del TAP. [Fuente Confidencial] Figura 2.5 Operación del registro de instrucción. [Fuente Confidencial] 16 2.5.1 Registro de instrucción del TAP La figura 2.4 muestra una implementación física simplificada del registro de instrucción (IR) del TAP. Esta consiste en un registro Shift de 7 bits (conectados entre TDI y TDO), y el registro de la instrucción actual (el cual es cargado paralelamente del registro Shift). La salida paralela del IR sale al decodificador de instrucciones del TAP. Esta arquitectura es conforme a la especificación IEEE 1149.1. La figura 2.5 muestra la operación del IR del TAP durante los estados Capture-IR, Shift-IR y Update-IR. En el estado Capture-IR, el registro Shitf (que es una porción del registro IR) es cargado en paralelo con un valor predeterminado “0000001”. El estado Shift-IR, el registro Shift forma un camino serial entre TDI y TDO. En el estado Update-IR, el contenido del registro Shift es cargado en paralelo en el actual registro de instrucción. Note que la única vez las salidas del actual registro de instrucción cambian es durante el estado Update-IR., por esto una instrucción ingresada de manera serial no tiene efecto hasta que se llegue al estado Update-IR. 2.5.2 Registros de Datos (DR) En el estándar IEEE 1149.1 dos registros de datos son requeridos; el registro de exploración periférica (BSR) y el registro Bypass, además se incluye opcionalmente un tercer registro de identificación del dispositivo (Device Identification Register). Adicionalmente se puede definir por el fabricante del dispositivo otros registros que pueden ser incluidos. Todos los registros de datos están alineados en paralelo entre entrada primaria de TDI y la salida primaria de TDO. El IR provee las direcciones que permiten ingresar a uno de los DR durante un “escaneo” del registro de datos (rama DR). Obsérvese 17 en la figura 2.6 que todos los registros de datos están conectados en paralelo entre TDI y TDO, el registro es escogido generalmente por la instrucción que se esté ejecutando y por medio de un multiplexador. Todos los otros registros que no se estén utilizando permanecen sin cambios. Figura 2.6 Arquitectura simplificada del registro de datos [1] Registro Boundary-Scan (BSR) El BSR consiste en una serie o arreglo de celdas de exploración periférica (BSCs) colocadas en el camino de exploración o “escaneo” en la periferia del IC. Las BSCs proveen características de observabilidad y controlabilidad, que son requeridas para ejecutar pruebas en las periferia del chip como se describió en el apartado 2.1.1. Registro Bypass (Requerido) 18 El registro de bypass consiste en un simple registro “escaneo” de un bit. Cuando es seleccionado provee un camino directo de un bit entre TDI y TDO. Este registro permite acortar el camino de exploración de los dispositivos que no están involucrados 5 en la prueba. Registro de identificación del dispositivo (Opcional) – El registro de identificación del dispositivo es un registro opcional definido por IEEE 1149.1, para identificar el fabricante, número de parte, versión, y otra información especificada. La figura 2.7 muestra las asignaciones definidas por este registro. Figura 2.7. Estructura del registro de identificación del dispositivo [2] Aunque el registro de identificación es opcional, la especificación IEEE 1149.1 ha dedicado una instrucción para seleccionar este registro. El registro de identificación es seleccionado cuando el IR es cargado con la instrucción IDCODE, el cual es definido por el fabricante del IC. 5 En la exploracion periférica se pueden tener varios dispositivos interconectados serialmente entre las señales TDI y TDO. 19 2.6 Instrucciones del estándar IEEE 1149.1 2.6.1 Instrucciones Requeridas del IEEE 1149.1 El estándar define nueve instrucciones de prueba. De las nueve instrucciones, tres son requeridas y las otras seis son opcionales. Las siguientes sub. Secciones contienen una breve descripción de cada instrucción requerida por el estándar. Instrucción BYPASS La instrucción requerida BYPASS permite al IC mantenerse en modo funcional (operación normal del IC) y selecciona el registro de Bypass conectado entre TDI y TDO. Esta instrucción permite que los datos sean transferidos de manera serial por el IC y desde TDI hasta TDO sin afectar la operación del IC. El código para esta instrucción es definido como todos los bits en 1. Instrucción SAMPLE/PRELOAD Esta instrucción permite al IC mantenerse en modo funcional y selecciona el registro BSR para que sea conectado entre TDI y TDO. Durante esta instrucción, se puede ingresar al BSR por medio de la operación de “escaneo” de datos (rama Select DR-Scan), tomando una muestra de los datos funcionales entrando y saliendo del IC. Esta instrucción también es usada para pre-cargar datos de prueba dentro del BSR antes de utilizar la instrucción EXTEST. El código para esta instrucción es definido por el usuario. 20 Instrucción EXTEST Esta instrucción coloca el IC en un modo de pruebas periféricas externas y selecciona el BSR para ser conectado entre TDI y TDO. Durante esta instrucción, se ingresa al BSR para manejar los datos de prueba aislándolos de la lógica base del chip a través de las salidas periféricas y para recibir datos de prueba a través de las entradas periféricas. El código de bits es definido para esta instrucción como todos ceros. 2.6.2 Instrucciones opcionales del IEEE 1149.1 Las siguientes secciones contienen una breve descripción de las instrucciones opcionales del estándar. Instrucción INTEST La instrucción INTEST coloca al IC en un modo de pruebas periféricas internas y selecciona el BSR para ser conectado entre TDI y TDO. Durante esta instrucción, se ingresa al BSR para manejar los datos de pruebas en el chip a través de las entradas periféricas. Y recibir datos de prueba el chip a través de las salidas periféricas. El código de bits de esta instrucción es definido por el usuario Instrucción RUNBIST Esta instrucción coloca el IC en modo de auto prueba, habilitando una auto prueba comprensiva de la lógica base del chip, y selecciona un Registro de datos especificado por el usuario el cual se conecta entre TDI y TDO. Durante esta instrucción, las salidas periféricas son controladas y por lo tanto no pueden interferir con los ICs vecinos durante la 21 operación RUNBIST. También, las entradas periféricas son controladas de manera que no puedan interferir con la operación RUNBIST. El código de instrucción es definido por usuario. Instrucción CLAMP La instrucción CLAMP coloca las salidas de un IC a valores lógicos determinados por el contenido del registro BSR y selecciona el registro Bypass para que sea conectado entre TDI y TDO. Después de que se carga la instrucción, se puede colocar el contenido del registro BSR con la instrucción SAMPLE/PRELOAD. Durante esta instrucción, los datos pueden ser cambiados a través del registro Bypass desde TDI hasta TDO, sin afectar la condición de las salidas. El código de esta instrucción es definido por el diseñador del IC. Instrucción HIGHZ Esta instrucción coloca las salidas de alta impedancia del IC a un estado deshabilitado y selecciona el registro Bypass para que sea conectado entre TDI y TDO. Durante esta instrucción, los dados pueden ser cambiados a través del registro de Bypass desde TDI hasta TDO. El código de esta instrucción es definido por el diseñador del IC. Instrucción IDCODE Esta instrucción permite al IC permanecer en modo funcional y seleccionar el Registro de identificación del dispositivo para que sea conectado entre TDI y TDO. El registro de identificación (ver figura 2.7) es un registro de 32-bit que contiene información del fabricante, tipo de dispositivo, y código de versión del IC. Acceder al registro de identificación no debe interferir con la operación del IC. También, el acceso a este registro debe estar inmediatamente disponible, a través de una operación de exploración de datos 22 del TAP, después de haber encendido el IC o después de haber utilizado el pin opcional TRST. El código en bits de esta instrucción es definido por el diseñador del IC. Instrucción USERCODE Esta instrucción opcional permite al IC mantenerse en modo funcional y seleccionar el registro “User Data Register” (UDR) para ser conectado entre TDI y TDO. Este registro opcional y contiene 32 bits de información del IC definida por el usuario. Acceder el UDR no debe interferir con la operación del IC. El código en bits de esta instrucción es definido por el diseñador del IC. 2.7 Modelo de Componentes de Objeto de Microsoft (COM) COM (Component Object Model) Modelo de Objeto Componente, es el modelo de objetos componentes de Microsoft, creado originalmente para el desarrollo de componentes en el ambiente Windows, sin embargo, ahora se ha convertido en una tecnología básica para sistemas distribuidos. La idea inicial era habilitar aplicaciones para Windows desarrolladas independientemente para que se comunicaran entre ellas. Después de un análisis del problema se decidió desarrollar una aplicación que pudiera ingresar a la funcionalidad de componentes binarios arbitrarios de una manera orientada a objetos, así es como nace COM, el cual sólo soporta interacción de componentes en una máquina local. COM es independiente del lenguaje de programación y usa varias interfaces por las que se ingresa a la funcionalidad de los componentes. Hay una interfaz raíz que se llama IUnknown de la cual se derivan todas las interfaz y a las cuales les hereda sus métodos; además cada interfaz COM representa una faceta distinta de un objeto. Los accesos de los 23 clientes a cualquier funcionalidad particular de un objeto COM están controlados por medio de apuntadores y del polimorfismo6. La estructura física de las tablas de métodos está definida en COM, de tal forma que el acceso a una interfaz implementada por COM se da por medio de un apuntador de interfaz, que a su vez, apunta a una tabla de apuntadores de métodos. Para obtener un objeto que reside en un proceso diferente se usan proxies. Un proxy implementa exactamente la misma interfaz que el objeto COM representa, pero contrariamente al objeto COM, está disponible como un DLL. Lo anterior lo realiza la persona que este desarrollando el objeto COM mediante un lenguaje de definición MIDL (Microsoft Interfaz Definition Language) Lenguaje de Definición de Interfaz de Microsoft, el cual permite la definición de interfaz de COM, librerías y clases COM. Para identificar interfaz, clases y objetos, COM usa GUIDs (Globally Unique identifiers) Identificadores Únicos Globales, éstos identificadores están definidos por OSF (Open Software Foundation) y tienen un tamaño de 128 bits. Los GUIDs evitan conflictos entre objetos COM originados por diferentes fuentes. Los identificadores se usan para: 6 Clases COM (CLSIDs) Librerías de Información (LIBIDs) Interfaz (IIDs) Categorías de Interfaz (CATIDs) polimorfismo se refiere a la capacidad del código de un programa para ser utilizado con diferentes tipos de datos, por ejemplo una funcion que acepte distintos tipos paramentros para una misma entrada 24 Generalmente en programación orientada a objetos la herencia de implementación es muy útil para el re-uso de código, COM por su parte usa una técnica conocida como “agregación”. La agregación permite que un objeto externo use otro objeto interno de tal forma que la interfaz del objeto interno parece que pertenecen al objeto externo. Esto permite el re-uso de código en COM aún sin tener la herencia de implementaciones. Para ambientes interpretativos y pseudo códigos, como Visual Basic, existe una interfaz universal IDispatch, la cual les permite ingresar a la funcionalidad de los objetos COM. Esta interfaz pone a disposición sus métodos como apuntadores de métodos. Lo anterior permite que desarrolladores de Visual Basic por ejemplo, ingresen a operaciones usando IDispatch, mientras que los programadores de C++ usan la misma interfaz como si fuera una interfaz convencional de COM.7 7 http://sistemas.dgsca.unam.mx/publica/pdf/COMf.PDF 25 Capitulo 3: Hardware y Software para acceder al ULT Para poder acceder al ULT se utiliza el puerto de pruebas (ver figura 3.1), esto es posible aunque la unidad (procesador) no funcione correctamente y no se le pueda cargar ningún software, de hecho, uno de los usos principales del TAP es para hacer validaciones, es decir buscar la razón de porqué una unidad falló o no funciona correctamente, debido a que el TAP es un dispositivo prácticamente independiente del procesador, no necesita que este funcione correctamente en muchos de los casos. 3.1 El puerto de Pruebas La interfaz del TAP o Puerto de pruebas es ideal para obtener información del CPU, registros, memoria y otros registros especiales como es el caso del ULT. Aunque se fabrican y diseñan varios tipos de puertos de pruebas, se referirá aquí al puerto de 26 pines8 que aparece en la figura 3.1 Figura 3.1 Puerto de pruebas en tarjeta Madre especial para pruebas9 8 Conector de 26-pin especificado como “Framatone Connectors International” con numero de parte 61641303 o 61698-302TR. 9 Foto tomada para tarjeta madre de servidor XEON®, el puerto de pruebas se encuentra en el recuadro 26 3.1.1 Diseño del puerto de pruebas El puerto de pruebas es una interfaz de control para las herramientas de “debuging”10 o ITP (In-Target Probe)11. Esta herramienta está especializada en manipular el puerto de pruebas JTAG (TAP) que se enlaza entre los procesadores y el chipset a través de una ruta o cadena de exploración (“scan chain”) en el sistema a probar. Las principales operaciones del ITP y el respectivo puerto de pruebas son proveer el estado del sistema, ejecución e interfaces TAP en el sistema a probar 12 La interfaz del sistema informa a la herramienta de pruebas si la unidad está encendida, si los relojes están funcionando, si el acceso al sistema a probar está habilitado, etc. La interfaz de ejecución es usada para coordinar actividades de pruebas con el actual estado de ejecución de los dispositivos (ejemplo: procesadores y/o chipset) que están conectados al puerto de pruebas. La interfaz del TAP permite solicitar y editar los registros y estados dentro de los dispositivos incluidos en la cadena de exploración.13 En las dos tablas siguientes se muestra una breve descripción de los pines de entrada (Tabla 3.1) y los pines de salida (Tabla 3.2) del puerto de pruebas. 10 Debugging: despulgar o buscar errors en hardware o software Se refiere la herramienta o aparato que va a controlar el puerto, puede ser producida por Intel o terceros vendedores, sin embargo en este trabajo cuando se menciona ITP se refiere a la herramienta o producida por Intel, sin embargo si se hace mención a ITP700 se refiere a la guía de diseño del puerto de pruebas el cual pertenece a .Intel® 12 Un ejemplo puede ser una tarjeta madre en la que estan interconectados dos procesadores y un chipset por medio de una cadena de exploración. 13 Documento ITP700 Debug Port design guide: http://www.intel.com/design/Xeon/guides/24967914.pdf 11 27 Tabla 3.1. Descripción pines de entrada del puerto de pruebas que son manejadas por el emulador14 Señal Nombre de Descripción la señal 23 BPM5DR# Utilizada por el emulador para solicitar control del procesador(s). Similar a la función de PREQ en procesadores anteriores 4 DBA# Señal de reconocimiento de que el emulador ha ingresado a las señales del TAP. El emulador ha ingresado a las señales del TAP cuando el CPU está apagado 6 DBR# Señal de reinicio del sistema que se está probando. Cuando se pone en bajo, se reinicia el sistema y el CPU 10 TDI Ingreso de datos al TAP 12 TMS Selecciona los estados del TAP 14 TRST# Reinicio del TAP 16 TCK Reloj del TAP que es asincrónico al reloj del sistema y CPU 18 FBI Copia del TCK de uso opcional para el sistema 14 Nota de aplicación para diseño del puerto de pruebas para sistemas basados en Intel Pentium® 4 (PGA478)-extracto de: www.arium.com 28 Tabla 3.2 Descripción pines de salida del puerto de pruebas que son manejadas por el sistema que se está probando Señal Nombre de Descripción la señal 3 BPM[0]# Monitor “Break Point” 0 15 5 BPM[1]# Monitor “Break Point” 1 7 BPM[2]# Monitor “Break Point” 2 9 BPM[3]# Monitor “Break Point” 3 11 BPM[4]# Monitor “Break Point” 4. Utilizado por el emulador para detectar el control del procesador(es) 13 BPM[5]# Monitor “Break Point” 5. Permite al emulador detectar cuando el procesador es reiniciado 15 RST# Señal de reinicio del procesador 17 FBO Señal de retroalimentación al puerto de pruebas del reloj del TAP (TCK) 19 BCLKp Copia privada del reloj diferencial BCLK, que se activa en el flanco positivo de este. Permite al emulador proveer un TCK que es sincrónico con BCLK16 21 15 BCLKn Copia privada del reloj diferencial BCLK, que se activa en el flanco Las señales BPM[5:0]# (Breakpoint Monitor) son salidas del procesador para indicar el estatus de los Breakpoints y contadores programables utilizados para monitorear el rendimiento del procesador 16 BCLK[p/n] es el reloj diferencial de bus del procesador 29 negativo de este. Permite al emulador proveer un TCK que es sincrónico con BCLK 24 TDO Salida de datos del TAP (Desde el último dispositivo o procesador de la cadena de exploración al puerto de pruebas) 22 PWR Voltaje del sistema Vcc El emulador usa Vcc para detectar si el sistema tiene energía y para establecer niveles de voltaje o umbral La conexión al puerto de pruebas generalmente se implementa con un conector de 26-pin especificado como “Framatone Connectors International” y de número de parte 61641-303 o 61698-302TR. El Pin 26 del conector es removido y actúa como una llave. Obsérvese el siguiente diagrama de numeración de pines: 2 4 6 1 3 5 8 10 12 14 16 18 20 22 24 7 9 11 13 15 17 19 21 23 25 Figura 3.2 Vista superior del conector con la numeración de pines En la tabla 3.3 se muestran terminaciones de los pines en la tarjeta impresa, tanto de resistencia como de voltaje. 30 Tabla 3.3. Terminaciones Recomendadas del Puerto de Pruebas17 Señal Valor de terminación Voltaje de Terminación PWR 1.5kΩ 1% VTERM de BPM[5:0]# 150-240Ω 5% VCC BCLK(p/n) DBA# del circuito de recuperación del sistema DBR# 150-240 Ω 5% VCC del circuito de recuperación del sistema FBI 220Ω 5% FBO Conectado lo más cercano NA posible GND TCK entre BPM[5:0] y el bus TCK 27Ω 1% GND TMS 39 Ω 1% VTAP TDI 150Ω 5% VTAP TDO 75Ω 5% VTAP TRST# 500-680 Ω 5% GND BPM[5:0]# Impedancia característica de VTERM transmisión 5% Reset# 17 Impedancia característica de VTERM Documento: ITP700 Debug Port design guide: http://www.intel.com/design/Xeon/guides/24967914.pdf 31 la línea de transmisión 5% BPM5DR# Conecta a la señal BPM[5] NA en el puerto de pruebas (Debug Port) 3.1.2 Acceso al puerto Debug en Tarjetas madre comerciales Las tarjetas madres comerciales no tienen puerto Debug. Las Tarjetas que no son comerciales y son utilizadas para pruebas de los dispositivos, tienen un costo muy elevado (pueden costar hasta cuatro mil dólares). Se quiere reducir este precio y para esto la idea es utilizar una tarjeta madre comercial que puede ser adquirida por una suma aproximada de 50 dólares y buscar alguna forma de ingresar al ULT por medio de los pines del TAP. La forma más simple y adecuada que se encontró para acceder al puerto del TAP fue por medio de un “Interposer”, el cual es un dispositivo que se coloca entre el “socket”18 de la tarjeta madre y el procesador y provee un conector del puerto de pruebas (ver figura 2.10). Los “interposers” actualmente disponibles en el mercado pueden costar 500 dólares o más, sin embargo utilizar este con una tarjeta madre comercial podría ahorrar más de 3500 dólares. El “interposer” posee terminaciones y rutas de acuerdo con la guía de diseño de Intel® “ITP700”. 18 “socket”: donde se inserta el procesador en la Tarjeta Madre (o tarjeta impresa) 32 Figura 3.3 Orden de conexión entre CPU (superior), “interposer” con puerto de pruebas (medio), y “socket” (abajo) [6] Como se observa en la figura 2.10, el “interposer” se coloca en medio del “socket” y el procesador. El “interposer” tiene una mini tarjeta, en la que se observan los pines del conector macho de 26 pines, que es el mismo puerto Debug que se muestra en la figura 2.9. 3.2 Emulador ITP para leer ULT Después de investigar sobre las distintas formas para leer ULT se encontró que un grupo de desarrolladores en Estados Unidos de América de Intel®, produce un emulador para pruebas llamado ITP-XDP19 el cual posee un conector de 60 pines (Puerto extendido para pruebas). Este dispositivo se muestra en la figura 3.3 19 ITP-XDP es un Hardware para pruebas de Intel que utiliza un puerto de pruebas de 60 pines (XDP= eXtended Debup Port). En adelante cuando se hable de ITP o ITP-XDP no habrá diferencia. 33 Figura 3.3 Emulador de pruebas ITP-XDP20 Este dispositivo se conecta al puerto USB de una computadora anfitrión ("Host"), la cual recibe las señales del ITP-XDP y del sistema al que se le están haciendo las pruebas y también sirve de interfaz entre el usuario y el dispositivo que se está probando. Esta herramienta está provista de un software especial, en el que se pueden ingresar comandos, guardar archivos de comandos o desarrollar aplicaciones COM21 en visual C++ y visual Basic. En la figura 3.4 se muestran los requerimientos de hardware que se encontraron en este caso para utilizar ITP-XDP, para leer ULT. 20 21 Foto tomada en el laboratorio del ITP COM (Component Object Model) 34 Figura 3.4 Diagrama de conexión de la solución para acceder al puerto de pruebas con una tarjeta madre comercial, un “interposer” y el emulador ITP-XDP En las siguientes secciones de este capítulo se muestra la manera en que se implementó el hardware y el software para leer ULT. En el caso del hardware se hace referencia a la solución encontrada en el capitulo anterior y para el software se explicará de manera muy simplificada lo que se hizo, debido a la confidencialidad de la información. 35 3.3 Implementación del hardware Primeramente se necesitó una tarjeta madre comercial con “socket” de 478 pines, para lo cual se utilizó la tarjeta madre Intel® modelo D865GBF con una fuente22 ATX, también se tuvo que adquirir el “interposer”23 para poder tener acceso al puerto JTAG y la herramienta ITP. Se utilizó procesador Pentium® 4 en empaque de 478 pines además del ventilador y disipador. Cabe recalcar que no fue necesario tener ninguna memoria RAM u otros dispositivos como disco duro o tarjeta de video, esto debido a que el ULT se encuentra dentro de una cadena de fusibles dentro del procesador que son accedidos por el puerto JTAG, el cual tiene una máquina de estados casi independiente del procesador excepto por la alimentación. En la figura 3.5 se muestra el “interposer”, el cual como se puede observar es fundamental si se quiere acceder al JTAG en una tarjeta madre comercial24. Figura 3.5 Vista Superior del “interposer”25 22 Modelo Fuente de 300W ATX: POW-ENL-300 La compañia que produce estos “interposers” es International Test Tecnologies (http://www.intertesttech.com/ate/products_interposers.htm) 24 En la parte de investigación se busco tarjetas madres comerciales con puerto JTAG sin éxito 23 36 Nótese también en la figura anterior que el procesador se debe colocar sobre el “interposer” y sus pines son insertados en los huecos de este. A la derecha de la figura se observan nuevamente los 26 pines (conector macho) del Puerto JTAG. En la figura 3.6 se muestra el “interposer” con el micro procesador ya insertado en la parte superior. Es importante observar que debido a que el procesador es insertado a presión, esto podría eventualmente disminuir la vida útil del “interposer” y del microprocesador si es insertado muchas veces, según las hojas de datos del microprocesador26 este tiene hasta 15 inserciones para el “socket” mPGA478B27, pero no es conocido para el “interposer” que tiene características diferentes y no fue especificado por el fabricante. Figura 3.6 Vista lateral del “interposer” con el procesador insertado28 25 Foto del “interposer” tomada en el laboratorio Hojas de datos: Intel® Pentium® 4 Processor in the 478-Pin Package at 1.40 GHz, 1.50 GHz, 1.60 GHz, 1.70 GHz, 1.80 GHz, 1.90 GHz, and 2GHz (http://www.intel.com/design/intarch/designgd/303011.htm) 27 Este “socket” es ZIF (Zero Insertion Force), lo que quiere decir que no hay que aplicar fuerza o presion cuando se inserta el procesador, ya que el “socket” tiene una palanca para socarlo. 28 Foto tomada en el laboratorio 26 37 En la siguiente figura se muestra la conexión de la tarjeta madre con el “interposer”, el procesador y el ITP que a su vez se conectó por medio del puerto USB a una computadora. Figura 3.7 Tarjeta madre con “interposer”, procesador y ITP conectados29 En esta computadora de interfaz o “Host” se encarga de controlar el ITP por medio del USB, lo cual se hace con una ventana de comandos y también por medio de interfaces COM registradas por el software y el hardware del ITP. 3.4 Implementación del Software El programa o aplicación (ULT_Reader.exe) para leer ULT se desarrolló en visual C++.Net. El programa utiliza interfaces COM que comunican el ITP con la aplicación desarrollada. El diagrama de flujo del programa se muestra en la figura 3.8, en los 29 Foto tomada en el laboratorio 38 siguientes párrafos se comenta y explica el funcionamiento de cada uno de los bloques, además se incluye en algunas ocasiones parte del código, o seudo código, sin embargo no se puede mostrar todo el código debido a la confidencialidad de la información. Figura 3.8 Diagrama de Flujo del programa realizado para leer ULT 39 De la figura 3.8, al inicio del programa se inicializan las librerías COM 30 y las funciones necesarias para la comunicación por medio de interfaces de software entre el ITP y el computador. También se inicializan los punteros globales que apuntan hacia los diferentes tipos de interfaces del ITP. En la figura 3.9 se observa un diagrama de la comunicación entre la aplicación realizada (EXE) y las interfaces COM, las cuales a su vez se comunican con la consola ITP. Se debe recalcar que estas interfaces COM apuntan a una tabla de apuntadores de métodos o funciones, que son reconocidas por el ITP y posteriormente traducidas e ingresadas como instrucciones y datos a la máquina de estados del TAP en el procesador que se esta probando. ITP Console Interface X DLL Interface Y DLL calls COM interface EXE calls DLL EXE EXE calls COM interface Figura 3.9 Modelo del comunicación entre programa ejecutable implementado (.exe) y la consola de ITP. [Fuente Confidencial] 30 Para mas detalles de COM ver seccion 2.7 40 Nótese en la figura anterior que la aplicación EXE puede hacer llamadas a las interfaces COM directamente o también puede usar un DLL 31 para que haga estas llamadas. A continuación se observa la declaración de estos punteros de interfaz como variables globales, los cuales inicialmente son nulos, es decir todavía no están referenciados: // Variables Globales static ApiItp* iApiItp = NULL; static ItpConfiguration* iItpConfiguracion = NULL; En el siguiente seudo código y obviando el manejo de errores se muestra como COM y estas interfaces fueron inicializadas: InicializarCOM( ) { CoInitialize(NULL) //inicialización del COM // Obtiene la referencia hacia la interfaces iApiItp y iItpConfiguracion CoCreateInstance( CLSID_ApiItp, NULL, CLSCTX_LOCAL_SERVER, IID_ApiItp, iApiItp) CoCreateInstance( CLSID_ItpConfiguration, NULL, CLSCTX_LOCAL_SERVER, IID_ApiConfiguracion, iItpConfiguracion) } 31 DLL es el acrónimo de Dynamic Linking Library (Bibliotecas de Enlace Dinámico), término con el que se refiere a los archivos con código ejecutable que se cargan bajo demanda del programa por parte del sistema operativo. 41 La función “CoCreateInstance” crea un objeto sin inicializar de una clase asociada con una CLSID32 especificada. El último parámetro de esta función es el puntero que se inicializa con referencia a la interfaz. Si la función Inicializar COM devuelve algún error, entonces el programa despliega un mensaje de error y termina el programa, como se observa en el diagrama de flujo. Si no se produce ningún error, se abre la ventana de comandos de ITP automáticamente, esta ventana se muestra en la figura 3.10. Figura 3.10 Ventana de Comandos del “Software” propio de ITP Es importante que se abra el software propio de ITP, debido a que en esta ventana se pasaran algunos comandos desde la aplicación como se verá más adelante. 32 CLSID “Class Identification” (identificacion de clase) 42 Continuando con el diagrama de flujo de la figura 3.8, se debe verificar que el ITP esté listo para la comunicación COM. En esta parte se va mostrar casi todo el código de la función con algunos cambios en nombres de variables con respecto al código original, esto para facilitar la lectura, ya que las variables se escribieron originalmente en inglés y con nombres más largos: HRESULT ULTreader::ChequearITPListo( void ) { assert(iApiItp); //si la interfaz es nula, termina el programa HRESULT hResult = S_OK; //tipo de variable para manejo de errores BOOL estaItplisto = False; // verdadero si IPT esta listo //pregunta si el ITP esta listo y pone el resultado en estaItplisto hResult = ApiItp->ItpReady(&estaITPlisto); //si no esta listo lo chequea 20 veces hasta que lo este si no se rinde for( int intentos = 0; SUCCEEDED(hResult) && (intentos < 20) && (estaITPlisto==false); intentos++) { Sleep(1000); //retardo de 1 ms por cada intento hResult = ApiItp->ItpReady(&estaITPlisto); //Salida: True, si esta listo } if( SUCCEEDED(hResult) && (estaITPlisto==False) {hResult = E_FAIL;} 43 return hResult; } Se puede observar como es llamada la función “ItpReady” a través del puntero de interfaz ApiItp. La devuelve a la variable estaITPlisto verdadero si ITP esta listo o falso en caso contrario. Por medio de un “for” se hacen 20 intentos dando un tiempo entre cada uno de estos de 1 ms. Si el ITP no está listo para la Comunicación COM, la función devuelve un fallo, y se termina el programa. Si por el contrario el ITP está listo el programa continúa su curso. Una vez que la aplicación ha establecido comunicación con el ITP y siguiendo con el diagrama de flujo de la figura 3.8, se puede visualizar la ventana del “ULT_Reader.exe”. La ventana se muestra en la siguiente figura. Figura 3.11 Ventana de la aplicación para leer ULT (ULT_Reader.exe)33 33 Captura de pantallla de la aplicación ULT_Reader.exe 44 Como se puede observar esta ventana cuenta con información general acerca del procesador. En la primera casilla de caja combo, o de selección se puede observar la identificación de cual “thread”34 o procesador está observando el ITP. En el Caso del Pentium® 4 Prescott-N se observan dos procesadores lógicos, y en la casilla se puede escoger uno u otro, sin embargo esto no afecta ninguno de los datos que se muestran ya que solo hay un solo procesador físico. Otra información que lee el programa es el tipo de procesador, que en este caso es el Prescott, el “stepping” o versión que es la H1, el número de registro de identificación, o que es lo mismo el “idcode” y el tipo de arquitectura. Un seudo código de cómo se obtienen estos valores se muestra a continuación, estos valores se obtienen con esta misma función, lo que cambia es la palabra clave que se ingresa. HRESULT ULT_Reader::ConseguirInformacion( int ID, //identificación del procesador (0,1,…) char* Clave, //palabra clave de lo que se busca char* info ) //donde se guarda la info solicitada { HRESULT hResult = S_OK; CComVariant Valor; CComBSTR ccbstrKey(Clave); // llamada COM a ItpConfiguration: obtiene información del procesador correspondiente a la posicion actual del dispositivo en la cadena de exploración hResult = ItpConfiguracion-> get_info(ID, ccbstrKey, &Valor); if( FAILED(hResult) ) { AfxMessageBox("Error obteniendo información del procesador!"); } 34 De Hyper Threading, Esta tecnología consiste en usar dos procesadores lógicos dentro de un único procesador físico 45 else { //Crea un puntero a el SAFEARRAY dentro del variant SAFEARRAY* psaValor = Valor; Long iIndex = 0; CComBSTR ccbstrValor; hResult = SafeArrayGetElement(psaValor, &iIndex, &ccbstrValor); assert( SUCCEEDED(hResult) ); info= ccbstrValor; } return hResult; } Algo interesante es que la función “ConseguirInformación” devuelve la variable de tipo CComVariant con el valor de la información, esta información se debe referenciar con un puntero de tipo “SAFEARRAY” y luego con la función “SafeArrayGetElement” se debe puede obtener la variable ccbstrValor y igualarla a la variable “info”, que es una información que se puede leer fácilmente. Una vez desplegada la información en la pantalla, el usuario puede escoger que desea realizar con los botones dados, si presiona el botón “Exit” sale directamente del programa y se va a una función simple como la siguiente: ULT_Reader::OnExit() { //le dice al cuadro dialogo que termine lo antes posible EndDialog(IDEXIT); } Si presiona el botón leer ULT va a realizar una serie de funciones como se observó en la figura 3.8. Primero antes de poder leer los fusibles donde se encuentra el ULT, se 46 debe desbloquear el TAP. Normalmente la función de desbloqueo se realizan por medio de la ventana de comandos (Fig. 3.10), y antes de poder escribir el comando (supongamos que el comando se llama DesbloquearTap(), se debe incluir en esta ventana un archivo o “script” 35 donde esta definida la función DesbloquearTap(). Este archivo puede cambiar entre familias de procesadores, por lo que se pensó que era mejor tener en un “script” (archivo de texto ejecutable) con el comando de desbloqueo. Para no realizar la inclusión del archivo manualmente, se optó por cargar en archivo desde la aplicación a la ventana de comandos. Esto se muestra en el siguiente seudo código: CComBSTR ccbsUnlock ccbsUnlock.Append ("incluir ULT_desbloqueo.txt") //guarda el comando ApiItp->SetCommand (ccbsUnlock) La función “SetCommand” coloca una instrucción en la ventana de comandos en este caso coloca la función incluir, que lo que hace es cargar y ejecutar el archivo de texto ULT_desbloqueo.txt, el cual contiene las librerías y definiciones de la función DesbloquearTap(), donde además la carga y la ejecuta. Esta función de desbloquear ya es implementada por Intel® y comunica el software con un servidor de Intel®. Además la función pide nombre un nombre de usuario y clave de acceso, si el nombre y la clave de acceso son correctos y además se tiene permiso para desbloquear un determinado "stepping", el desbloqueo se realiza, en caso contrario, el TAP permanece bloqueado. 35 Un script es un fichero de texto que contiene una secuencia de instrucciones y/o definiciones que se pueden incluir en la ventana de comandos 47 Cuando el TAP del procesador ha sido desbloqueado se debe leer la cadena de Fusibles, lo cual no se puede realizar por medio de las instrucciones publicas36 del TAP. Dentro de esta misma función se obtuvo la información acerca de los Fusibles, es decir que grupos lo componen y la ubicación de estos dentro de la cadena de bits, de los cuales uno de estos grupos es el ULT codificado. Se sabe que el ULT tiene un determinado número de bits y se conoce su ubicación (bit menos significativo y más significativo), a partir de esto se seleccionaron los bits del ULT y se guardaron en un arreglo. Una vez que los Fusibles fueron leídos y que el subgrupo que pertenece al ULT codificado se ha separado, se debe decodificar el mismo en una cadena de caracteres alfanuméricos que es legible fácilmente 37 , para esto se realizó una función para decodificarlo. Esta función se valió del recurso de que en C/C++ se puede ingresar o inyectar código ASM o de ensamblador, el cual tiene funciones como por ejemplo RLC38 que permiten trabajar más cómodamente con los bits de una variable, con cual se obtuvieron los bits de cada parte del ULT codificado, los cuales se decodificaron para obtener el lote de Fábrica, el número de “wafer” de donde salió el procesador y la posición de las coordenadas X y Y de este. Parte de este código el cual no es confidencial se muestra a continuación: int GetULT_SubGroup( const char* const c_pszID_SubGroup, //[IN] Puntero a segmento inicial de subgrupo unsigned char ucNumBits) //[IN] Número de bits { 36 Las instrucciones públicas del TAP se pueden observar en capitulo 2, sección 2.6 Las definición del ULT decodificado se encuentra en el capitulo 2, sección 2.1 38 Función que rota los bits a la izquierda poniendo la bandera de carry en el bit menos significativo 37 48 int iULT_SubGroup=0; for( int i=0; i<ucNumBits;++i) { if(c_pszID_SubGroup[i] == '1') //if ULT bit is one __asm STC //pone la bandera en 1 else //else ULT bit is cero __asm CLC //limpia la bandera de carry __asm RCL iULT_SubGroup, 1 //Rotate with carry to bit 0 } return iULT_SubGroup; } La función anterior toma como entrada el puntero a la posición inicial del subgrupo de ULT (la cadena esta invertida y cada byte es un bit), y el número de bits a sacar. Obsérvese como la función pregunta si el byte es igual a uno, si es así pone la bandera de “Carry” en uno (STC) y si es cero pone la bandera en cero (CLC). Al usar la función de ensamblador RCL, rota los bits con el “Carry” a la izquierda, con lo que se va transformando los bytes en bits y a la vez se invierten para tomar el orden adecuado, entonces la función finalmente devuelve la cadena de bits. La función anterior se usa en la decodificación de ULT, sobre todo cuando hay números. El ULT es finalmente decodificado como variable tipo “char” y es guardado además en un archivo de texto. Esto se hace con la visión de que en otro proyecto se pueda automatizar la búsqueda del historial del chip en las bases de datos por medio del ULT. El archivo de texto es guardado de la siguiente manera: FILE *stream; char list[30]; /* Abre archive de escritura en modo texto */ if( (stream = fopen( "LastULT.txt", "w+t" )) != NULL ) { fwrite( pszDisplayString, sizeof( list ),1, stream ); //DisplaySring es ULT 49 //decodificado fclose( stream ); } else AfxMessageBox("Problema creando LastULT!"); En la siguiente figura 3.12 se muestra un ULT decodificado después de que el usuario ha presionado el botón ReadULT, si embargo no se pueden dar más detalles de los que aparecen al inicio del capitulo 2 Figura 3.12 Ventana de la aplicación para leer ULT (ULT_Reader.exe) con el ULT decodificado en la casilla de texto “ULT:”39 39 Captura de Pantalla de la ventana de aplicación de programa desarrollado, despues de presionar el botón “Read ULT” 50 Capitulo 4: Conclusiones y Recomendaciones 4.1 Conclusiones Durante la primera fase del proyecto se logró identificar contactos y fuentes de información para desarrollar el proyecto, mucha de la información fue encontrada dentro de la intranet de Intel® y a partir de reuniones personales, telefónicas y vía correo electrónico. Se logró identificar los requerimientos del hardware necesario para la implementación de herramienta. Este hardware no estaba implementado en Intel® Costa Rica y el proyecto al inicio no estuvo orientado a utilizar una herramienta determinada, si no más bien para la selección del hardware se realizó un proceso de investigación sobre las posibles capacidades de la herramienta. Se logró reducir el costo del hardware, utilizando una tarjeta madre comercial, en lugar de una tarjeta madre especial para pruebas (con puerto JTAG). Aunque la tarjeta madre comercial no tiene puerto JTAG, la solución fue utilizar un hardware especial llamado “interposer”, el cual es un tipo de “socket” con pines para acceder al JTAG que se coloca entre el “socket” de la tarjeta madre y el procesador. Se puede decir que el precio de la tarjeta madre comercial más el “interposer” es menor que el precio de la tarjeta madre de pruebas. Se encontraron los requerimientos de software y los accesos necesarios a las claves para permitir obtener ULT. El programa se desarrolló en el lenguaje de programación C++, 51 el cual se comunica con el hardware de ITP por medio de interfaces COM, ya implementadas por el software de ITP. Con esto el software se pudo comunicar con el ITP y a partir de aquí se crearon las funciones necesarias para leer los bits donde se encuentra el ULT, sacarlo y finamente decodificarlo en una cadena de caracteres alfanuméricos. En este proyecto se cumplió satisfactoriamente el objetivo general, donde se logró la implementación de la herramienta para poder leer el ULT. Una vez obtenido este registro, será posible ingresarlo a bases de datos y obtener valiosa información, donde el estudio de esta información es muy útil en los procesos de validación. Un valor agregado que se le da a este proyecto y que no estuvo contemplado en sus objetivos iniciales, es la aplicación a otros procesadores no solo Pentium® 4 (478 pin). Aunque en el desarrollo del proyecto no se nombró, se hicieron pruebas a servidores XEON® con ITP y se logró de manera exitosa obtener ULT, también aunque no se probó la implementación en Pentium® 4 LGA 775, se sabe por investigación que esta herramienta servirá para este tipo de paquete. Lo que cambia en estos tipos de procesadores o servidores es la tarjeta madre y el tipo de “interposer” (cambia tipo de “socket”). Otro valor adicional del proyecto es la movilidad de esta herramienta, ya que un Ingeniero del Laboratorio QSC podría tener un juego de “interposer”s, el ITP y una computadora portátil y obtener el ULT directamente con el cliente, este solo tendría que tener la tarjeta madre con el procesador. Con esto se podrían acelerar los procesos de validación por fallas en los procesadores. 52 4.2 Recomendaciones Se encuentra que es preferible utilizar un “interposer” con “socket” tipo ZIF (Zero Insertion Force) sobre él, o sea igual o similar al “socket” que tienen las tarjetas madre Intel® para Pentium® 4 (mPGA478B). Esto debido a que no se necesita hacer presión para insertar el procesador en el “interposer” y se presenta gran facilidad para extraerlo, esto a diferencia del “interposer” que fue comprado y utilizado en este proyecto. En la investigación del proyecto se encontraron dos fabricantes de “interposers” : Intertesttech y American Arium. El “interposer” utilizado en este proyecto se adquirió en Intertesttesch por razones de costo ya que ninguno de estos fabricantes pudo indicar cual es el número máximo de inserciones. Es recomendable sugerir a estos fabricantes hacer las pruebas necesarias con el fin de determinar el número máximo de inserciones. Con este parámetro se puede analizar una razón entre precio y vida útil del producto, y escoger la mejor opción. Otra opción seria diseñar un “interposer” propio para Intel®, donde se tenga en cuenta que los materiales a utilizar sean de muy buena calidad y que permitan al procesador tener un gran numero de inserciones. También se debe tener en cuenta la primera recomendación, es decir, es preferible que el procesador no se insertado a presión, si no que se soque de manera similar al socket mPGA478 que es con una pequeña palanca. Aunque el costo inicialmente podría ser más elevado que comprarlo externamente, a largo plazo el “interposer” podría tener una mayor vida útil y finalmente el costo seria menor. 53 BIBLIOGRAFÍA 1. Escrito por Sun Microelectronics. “Introduction to JTAG Boundary Scan”, Enero 1997, http://www.engr.udayton.edu/faculty/jloomis/ece446/notes/jtag/jtag1.html 2. Oshana, Rob. “Introduction to JTAG”, octubre 2002, http://www.embedded.com/story/OEG20021028S0049 3. Patavalis, Nick. “A Brief Introduction to the JTAG Boundary Scan Interface”, noviembre 2001, http://www.inaccessnetworks.com/projects/ianjtag/jtag-intro/jtagintro.html 4. Intel® . “ITP700 Debug Port Design Guide”, http://www.intel.com/design/Xeon/guides/24967914.pdf 5. American Arium. “Debug Port Design Guide for Target Systems Based on a Single Intel® Pentium® 4 Processor (PGA-478)”, http://www.arium.com/support/pdf/P4_PGA478_UP.pdf 6. International Test Tecnologies. “Debug Port Desing Guidelines” http://www.intertesttech.com/download/App1_Debug_Port_Design_Guidelines.pdf 7. Intel. “Intel® Pentium® 4 Processor in the 478-Pin Package at 1.40 GHz, 1.50 GHz, 1.60 GHz, 1.70 GHz, 1.80 GHz, 1.90 GHz, and 2GHz” http://www.intel.com/design/intarch/designgd/303011.htm 8. “Comunicacion en todas partes”, febrero 1999 http://sistemas.dgsca.unam.mx/publica/pdf/COMf.PDF