Home » Seminario del IIE » Soluciones de observabilidad para test en campo de sistemas con procesador

Soluciones de observabilidad para test en campo de sistemas con procesador

Julio Pérez Acle

Se presentarán algunos aspectos del test en campo de sistemas con procesadores. El objetivo del trabajo es mejorar la calidad del test, es decir minimizar la cantidad de fallas que escapan al mismo o lo que es lo mismo maximizar el “coverage”.

Dado que el testing de circuitos electrónicos es una disciplina bastante lejana para buena parte de la audiencia, voy a dedicar al comienzo parte del tiempo a dar una panorámica general sobre la misma.

El trabajo está orientado a “fallas de performance”, fallas que no afectan el resultado final de un cálculo pero sí la duración del mismo. El trabajo consistió en proponer y evaluar diferentes mecanismos de observación del resultado del test para mejorar el coverage de fallas de performance.

La herramienta aceptada para evaluar el coverage es un simulador de fallas, es decir, una herramienta que para cada una de las fallas consideradas simula el comportamiento del circuito defectuoso y compara las salidas del mismo contra las obtenidas con el circuito sano. Es una herramienta pensada para tests de fin de producción, donde p. ej. todas las salidas pueden observarse durante todo el test. Buena parte de la dificultad ha estado en cómo emular con esta herramienta los mecanismos de observación mucho más limitados disponibles en un test en campo.

 

Definiciones

  • Test: procura identificar productos fallados
  • Diagnosis
  • Faults
    • de Diseño
    • Defectos Físicos
      • de fabricación o en fase operativa
      • permanentes, intermitentes o transitorias
  • Fault model
    • Logical faults
    • Ejemplos:
      • stuck-at
      • Single Event Upset. Bit Flip
    • Espacio de fallas
      • En gral producto cartesiano
        • ubicación x tipo [ x tiempo ]
      • fallas permanentes stuck-at:
        • (nodos del circuito) x (sat-0, sat-1)
      • SEUs:
        • (elementos de memoria) x (instante)
  • Test application
    • ## slide 1
  • Test stimuli generation
    • aka Test Pattern Generation (TPG)
    • Diseñar el conjunto de estímulos a aplicar a la UUT
    • Para detectar una falla el estímulo debe (## slides 2 a 4):
      • Activar la falla
      • Propagar hasta una salida observable
    • Dados:
      • circuito
        • entradas que puedo controlar
        • salidas que puedo observar
      • lista de fallas
    • Encontrar estímulos que “cubran” cada una de las fallas
    • Automatic TPG (ATPG)
      • problema matemático orden alto
      • bastante resuelto para circuitos combinatorios
      • lejos de resolverse para circuitos con memoria
  • Qué tan bueno es un test
    • Defect Level: % defectuosos / pass
    • Yield: % ok / producidos
    • Fault coverage: % detected / total faults
    • Overtesting: good products marked as faulty

Tipos de test

  • Design validation and verification
    • NO es test
    • Validación: compara especificación contra lo que quiere el usuario
    • Verificación
      • En general, equivalencia entre descripciones en diferente nivel de abstracción
      • Diseño vs Especificación
      • estática (modelos matemáticos)
      • dinámica (simulación con determinados estímulos y comparación con resultado esperado)
        • a menudo estos estímulos se toman como punto de partida para Test Pattern Generation
  • Verification testing (aka Characterization)
    • design correctness, specs compliance
    • defines operating limits (temp, voltages,…)
    • performed on prototypes
  • Production (or Manufacturing) Testing
    • applied to all circuits, must be minimal cost
    • wafer test, packaged circuit test
    • Parametric test: currents, frequencies,… Must be redesigned each time technology changes
    • Functional test: functional behavior, independent of technology
  • Burn-In
    • accelerated aging
    • or to all production to detect infant mortality
    • or to a sample to characterize reliability
  • Incoming Inspection
    • by the buyer, often on samples
    • limited information about internal structure
  • On-line/In-field Testing.
    • no testers
    • in system
    • aims at fault detection before they cause serious consequences
    • Concurrent/no concurrent
    • Muy limitado
      • entradas que puedo estimular (Controlabilidad)
      • salidas que puedo observar (Observabilidad)
      • tiempo disponible
    • A favor:
      • velocidad normal de operación
    • Si hay un uProcesador:
      • ejecuto programa de test
      • analizo al final resultados en memoria
      • Software Based Self Test (SBST)
    • Requerido por normas en sistemas Safety Critical
      • IEC 61508 for generic safety- related systems
      • ISO 26262 for automotive applications
      • similar para sistemas médicos (Pedro?, Fernando?)
      • duda abierta de cuán cierto es esto

Design for Testability

  • Scan test. pseudo combinational circuits to simplify test sequences generation
  • Access to embedded memories
  • Pros: Increased test quality, reduced test cost and time.
  • Cons: complexity, area, delay, power, pin count
  • Practically all digital ICs include some DfT
  • Usualmente no disponible In-field por falta de información

Objetivo 1: evaluar degradación de coverage por pasar de Production Test a In-field Test

  • Fabricantes tienen programas de test
    • diseñados para fin de producción
    • observando todas las salidas
  • Evaluar degradación de coverage al disminuir observabilidad

Objetivo 2: mejorar coverage en Performance faults

  • Ejemplo:
    • cache que siempre da “miss”
    • debo traer siempre el dato de memoria principal
    • ejecución demora mucho más
    • pero resultado del cálculo no se modifica
  • difíciles de detectar por el procedimiento de correr un programa y ver el resultado
  • Cómo mejorar observabilidad?
    • con recursos existentes o simples de incorporar
  • Cómo evaluar esa mejora?
    • Simulaciones y experimentos para medir el “coverage”

Observability Solutions

  • S1 Module-Level
  • S2 Processor-Level
  • S3 System Bus
  • S4 Memory Content
  • S5 Performance Counters
  • S6 Debug interface

Fault Simulator

  • Dados:
    • circuito (netlist gate level)
    • lista de fallas a considerar
    • lista de salidas a observar
    • estímulos para las entradas
  • Simula comportamiento para cada falla
    • compara con “golden run”
    • clasifica fallas DETECTED, UNDETECTED, etc.
  • Antes análisis estático
    • identifica fallas UNTESTABLE
    • con las entradas y salidas disponibles
    • no hay estímulo que las pueda activar u observar
  • Costo computacional
    • tamaño del circuito
    • tamaño de lista de fallas
    • duración de los estímulos
  • Pensado para “production test”
    • en general solo “gate level”, dificulta agregar memoria y periféricos
    • limitadas opciones para definir qué observar y cómo

Test Case #1: Branch Prediction Unit/miniMIPS (##slides 5 a 8)

 

Procesador: miniMIPS

  • RISC, pipeline 5 stages
  • Target: Branch Prediction Unit
    • tabla branches recientes
    • taken/not taken en base a historia
    • Cuando se llena desalojo como en un caché
    • Misprediction implica vaciar pipeline
      • presumiblemente performance faults

Fault simulation

  • 1 run / each solution
  • 16 processors server
  • 2 hs aprox. each
  • Programa en ROM

Test Case #2: Cache controller/Leon3 (##slides 10 a 12)

 

Procesador: Leon3

  • RISC, pipeline 7 stages
  • Target: Data Cache controller

Fault simulation

  • 1 run / each solution
  • 8 processors server
  • algún día cada corrida
  • No se pudo incluir la memoria
    • simulación lógica sin fallas del sistema completo
    • se obtiene entradas para fault simulation
    • volveremos sobre este tema

Test Case #3: Full processor/miniMIPS (##slide 13)

  • mismo sistema que Test Case #1
    • miniMIPS + Wrapper
  • Cambia
    • Target es todo el procesador
    • diferente programa de Test
      • el del mejor alumno del curso Testing del año anterior
      • pensado para production test
      • adaptado para agregar observación en memoria
    • diferente fault list: todo el procesador
  • Objetivo:
    • analizar coverage en cada módulo

Fault simulation, algunos problemas

  • ##slides 14-15