Peter van den Eijnden, Director General de Tecnologías de JTAG, explica cómo la combinación de los límites de exploración con un lenguaje de código abierto, es una combinación perfecta:
El JTAG / Límites de exploración de la interfaz, como ideado por el Grupo de Acción Conjunta, de prueba y ratificado como estándar IEEE. 1.149,1 en 1990, fue inicialmente concebida para superar los problemas pin, a nivel de tarjeta de acceso que se introdujeron con dispositivos de montaje superficial (SMD). Los usuarios probadores en circuito (TIC), y los defectos de fabricación analizadores (MDA), en particular, basado tradicionalmente, en el acceso pasador a través del agujero para comprobar, si hay cortocircuitos la red a la red y algunas funciones del dispositivo o, simplemente, la presencia del dispositivo y orientación.
Durante la década de 1990, los dispositivos IEEE 1149.1 JTAG compatibles, se había convertido en mucho más comúnes, ayudado en gran parte por la popularidad de los dispositivos lógicos programables, altamente integrados, tales como FPGAs y CPLDs, y el uso de JTAG, con su prueba de E / S, en las células de la límite de dispositivo, se convirtió en un complemento esencial a la fase de prueba los llamados estructurales.
Con algunas mejoras JTAG inteligentes, se utilizó para comprobar, si hay abierto y corto-circuitos, en el dispositivo a dispositivo se interconectado, device-to-I/O-connectors, y las conexiones de dispositivo, a la memoria del banco. Configuración del PLD y FPGA, y de programación en sistema de flash, también puede lograrse ya sea directa o indirectamente a través de JTAG.
Sin embargo, en casi todos los casos, el enfoque de la prueba de JTAG, ha sido "vectorial" (es decir, utilizando una secuencia estricta de patrones de prueba definidos), y no "lenguaje base." Esto es comprensible, ya que JTAG, es ante todo una técnica de prueba digital, que sólo necesitan dar un PASS / FAIL como indicación, y tienen una capacidad de diagnóstico que se pueden analizar los resultados, para dar descripciones sensibles culpa.
Ha quedado claro que el acceso que los diseños de JTAG, compatibles con pagar a los dispositivos de señales mixtas, en un circuito se podrían aprovechar para poner a prueba, los dispositivos de una manera funcional. Por ejemplo, considere un I ² C, o un dispositivo de bus SPI, tales como un sensor de temperatura, que se conecta de nuevo a una parte de JTAG compatibles. Si bien, es posible utilizar un enfoque basado en vectores, para simular los ciclos de bus, y transmitir instrucciones y recibir datos, el límite de pruebas es algo más difícil - o ha sido hasta ahora.
Las Tecnologías introducidas JTAG JTAG, donde las rutinas de alto nivel de acceso, que pueden ser vinculados en el lenguaje Python ™, software gratuito de código abierto. Llamado JTAG Prueba funcional (JFT) de rutinas, ellos trabajan en dos niveles (o perspectivas), a saber: límite de exploración a nivel de pines, y "cluster" nivel de distinción.
En la frontera de exploración ejemplo pin-nivel (ver Figura 1), los usuarios pueden configurar pruebas, con un mínimo conocimiento de las interconexiones, y sin referencia a una lista de conexiones de diseño. Clavijas individuales pueden ser conducidas con DriveHigh, (por ejemplo, en IC1.19), DriveLow (a IC1.16) y HighZ (a IC1.13), y las clavijas individuales se pueden leer con TestHigh, (por ejemplo en IC1.11) y TestLow (en IC2.11).
Además, los grupos de los pernos se pueden definir por DeclareGroup. Por ejemplo, los pines de un dispositivo compatible con JTAG, que se conectan a un (no compatible con JTAG) CAD pueden ser agrupados (por ejemplo IC2.18, 17 y 14) y denominado "de entrada del CAD." La variable "CAD-entrada", entonces se puede controlar mediante un comando de DriveVar.
Del mismo modo, la salida de un ADC puede ser adecuadamente-con nombre, y leído por una rutina TestVar.
Uso de JFT, a este nivel permite a los ingenieros de diseño para llevar a cabo sesiones de depuración, sin la necesidad de crear el firmware de prueba específica, o configuraciones de prueba de FPGA. Igualmente, personal de reparación o servicio puede crear scripts de prueba para cubrir firmas fallo conocido.
La perspectiva de racimo pin-nivel (ver Figura 2), se realizan pruebas al siguiente nivel / etapa al permitir al usuario especificar pin-nivel, y las unidades de nivel variable - las pruebas del dispositivo bajo prueba (DUT), el punto de vista.
Al igual que antes pines de entrada individuales, se pueden controlar, pero esta vez utilizando diferentes comandos (por ejemplo, en InputHigh IC3.1 y OutputLow en IC3.3). Y de nuevo, los pernos pueden ser declarados como pertenecientes a un grupo, y las variables definidas. Por ejemplo, puede declarar IC3.2, 7, 12 y 20, agrupados y asignar la variable "Us", que se correspondan con una salida analógica. "Us" podría ser controlado mediante una llave hexagonal de uno o número decimal.
Esto tiene ventajas considerables, cuando se utiliza junto con un sistema de desarrollo "netlist-consciente", como JTAG ProVision. Rutinas de nivel de dispositivo de prueba, se pueden crear y guardar como un módulo de Python, sin hacer referencia de nuevo a la [frontera de exploración], pines que proporcionan las señales de estímulo y respuesta. Esto los convierte en portátil y reutilizable a través de diseños y proyectos.
Además, mientras que ProVision ha apoyado modelos reutilizables durante algún tiempo, principalmente para el componente de discapacidad, a participar en red y pruebas de componentes genéricos, tales como memorias y familias lógicas. El JFT Python rutinas ™, agrega una dimensión adicional a la capacidad de desarrollo de la herramienta. Pruebas como la programación de un reloj de tiempo real (RTC), del dispositivo con un sello de tiempo capturado en el PC de control que había sido difícil, en el pasado son ahora un "clic" con las rutinas JFT.
Para obtener más información, visite www.jtag.com.
No hay comentarios:
Publicar un comentario