Informe - Escuela de Ingeniería Eléctrica

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