¿Cuál es la diferencia entre prueba y verificación?


15

Todos los libros de texto que he visto explican en gran medida el hecho de que las pruebas y la verificación son dos conceptos diferentes. Sin embargo, ninguno de ellos proporciona una distinción clara (o lo suficientemente clara para mí).

Para proporcionar algo de contexto, estoy interesado en la verificación de diseños de hardware digital utilizando lenguajes de diseño de hardware (HDL).

He visto algunas explicaciones que recurren a una diferencia "física" o "tangible": si se trata de un dispositivo fabricado, entonces está probando. ¿Es esta la historia completa? Si es así, ¿por qué la palabra "prueba" aparece con tanta frecuencia en la verificación (especialmente en la verificación funcional, hablamos de casos de prueba, bancos de pruebas, DUT (dispositivo bajo prueba), pruebas dirigidas, pruebas aleatorias, etc.)

Respuestas:


21

Fue ingeniero de verificación de diseño de ASIC en Qualcomm. De la manera más simple puedo explicarlo:

Prueba: Asegurarse de que un producto funciona, después de haberlo creado (piense en el control de calidad).

Verificación: Asegurarse de que un producto funcione ANTES de haberlo creado.

Ambos están probando, solo que la verificación es más complicada porque tienes que encontrar una forma de probar el producto antes de que exista y debes poder asegurarte de que funcione según lo diseñado y especificar cuándo sale realmente.

Por ejemplo, Intel está diseñando su próximo procesador, tienen las especificaciones, tienen los esquemas y las simulaciones. Gastan $ 1 mil millones de dólares para la fabricación y fabricación. Luego el chip regresa y lo prueban y descubren que no funciona. Simplemente arrojaron mucho dinero por la ventana.

Agregue la verificación. Los ingenieros de verificación crean modelos que simulan el comportamiento del chip, crean el banco de pruebas que probará esos modelos en particular. Obtienen los resultados de estos modelos y luego lo comparan con los resultados RTL (modelo de escritura de circuito en un lenguaje de diseño de hardware). Si coinciden, las cosas están (generalmente) bien.

Existen varias metodologías diferentes para el proceso de verificación, una popular es la Metodología de Verificación Universal (UVM) .

Hay mucha profundidad en el campo y las personas pueden pasar toda su carrera en él.

Otro dato aleatorio de información: por lo general, necesita 3 ingenieros de verificación para 1 ingeniero de diseño. Eso es lo que todos en el campo dicen de todos modos.

EDITAR: Mucha gente piensa en la verificación como un rol de prueba, pero no lo es; es un rol de diseño en sí mismo porque debe comprender todas las complejidades de su IC como lo hace un diseñador, y luego debe saber cómo diseñar modelos, bancos de pruebas y todos los casos de prueba que cubrirán todas las funciones de su IC , así como intentar alcanzar cada línea de código RTL para todas las combinaciones de bits posibles. Recuerde que un procesador hoy en día tiene miles de millones de transistores debido al proceso de fabricación que permite cada vez más pequeños (ahora 14nm).

Además, en grandes corporaciones como Intel, AMD, Qualcomm, etc., los diseñadores en realidad no diseñan el chip. Por lo general, el arquitecto definirá todas las especificaciones, diseñará los tipos de piezas que deben unirse para obtener una función particular con un requisito específico (es decir, velocidad, resolución, etc.), y luego el diseñador codificará eso en RTL. De ninguna manera es un trabajo fácil, simplemente no es tanto el diseño como piensan muchos ingenieros que salen de la escuela. Lo que todos quieren ser es arquitectos, pero se necesita mucha educación y experiencia para llegar a ese punto. Muchos arquitectos tienen doctorados y tienen entre 15 y 20 años de experiencia en el campo como diseñador. Estas son personas brillantes (y a veces locas) que merecen estar haciendo lo que están haciendo, y son buenos en eso. El arquitecto en el primer chip en el que trabajé era un poco incómodo y realmente no seguía algunas normas sociales, pero podía resolver cualquier cosa que tuvieras en relación con el chip, y a veces lo solucionaba en tu cabeza y te decía mirar una señal y dirías, "¿cómo demonios hizo eso?". Luego le pides que te explique y él lo hace y se te pasa por la cabeza. En realidad me inspiró a leer libros de texto a pesar de que ya me gradué.


+1 Gracias por el último comentario, nos ayuda a ver que el campo es realmente importante (aunque RTL y la ingeniería de diseño suenan más atractivas para la mayoría de los ingenieros, creo)
Adicto a VHDL

Para completar, ¿le importaría agregar lo que es un caso de prueba?
Adicto a VHDL el

Agregué un dato sobre lo que en realidad es la verificación debido a que su primer comentario sobre el rol del diseño es más atractivo; Ambos son buenos roles, solo depende de lo que te guste. En cuanto a un caso de prueba, un SoC como Snapdragon podría tener decenas a cientos de miles de casos de prueba, y con pruebas aleatorias, en millones. En pocas palabras: está aplicando un conjunto de bits de entrada y eso se cambia a través de muchos módulos, luego obtiene algunos bits de salida como resultado que compara con los resultados de su modelo. Algo tan simple como probar una imagen que aparece en su teléfono tendría ...
PGT

Un gran número de casos de prueba. Supongamos que desea mostrar un solo píxel en la pantalla de su dispositivo móvil. Lo que alguien fuera del campo pensará es aplicar 1 bit para blanco y 0 para negro. En el mundo móvil real, ese píxel puede diferir por tamaño, intensidad, rotación, formato de color (YUV ###, RGB ###, etc.). Y probablemente esté probando 1 bit dentro de un conjunto de bits que se aplica a la entrada juntos. Los otros bits pueden ser 0 porque es negro, o pueden ser 1 porque está manejando otra información como cómo manejar el modo de transmisión, CLK, habilita / deshabilita, disparadores, cosas sofisticadas como esas.
PGT

6

En mi libro, Verificación es asegurar que lo que ha diseñado "hace el trabajo", es decir, tiene un conjunto de cosas que el "dispositivo" debe realizar, y la verificación marca las que están en la lista.

Sin embargo, las pruebas se aseguran de que las cosas que hace el "dispositivo" se hagan correctamente. Tiene un conjunto de funciones y prueba cada función asegurándose de que la función se realice correctamente.

En pocas palabras, Verification está verificando el diseño, y Testing está verificando el producto.


Creo que estoy empezando a entender ... ¿Podría darme algunos ejemplos de cada uno?
Adicto a VHDL

¿Cómo encaja eso con un plan de verificación , que especifica qué se debe implementar y también cómo saber que la funcionalidad es correcta? Sería de poca utilidad implementar o marcar una función si no funciona.
Adicto a VHDL

@ Majenko: ¿Entonces ha escrito un libro sobre Verificación? ¿Compartirías más detalles al respecto?
Michael Karas

4

Viniendo de un fondo de diseño ASIC (hardware), hay tres términos importantes: validación , verificación y prueba . Las respuestas anteriores generalmente hablan de uno o dos de estos términos, pero no contrastan claramente los tres de la manera en que lo haría. Así es como los entiendo:

  • Validación: la especificación (a menudo un modelo C) cumple con los requisitos del mercado o del cliente
  • Verificación: ¿la implementación (RTL, netlist o GDS2) coincide con la especificación
  • Prueba: ¿el dispositivo fabricado coincide con la implementación?

¿Pueden las simulaciones netlist y GDS2 dar resultados diferentes?
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

1
@CiroSantilli 巴拿馬 文件 六四 事件 法轮功, supongo que estás preguntando sobre el comportamiento de las puertas frente a los transistores. Para voltajes digitales normales y formas de onda, diría que darán los mismos resultados. Pero podría haber efectos "analógicos" no considerados por puertas idealizadas, tales como variaciones de potencia / tierra o compartir la carga de la señal. Si esos efectos están presentes, entonces el comportamiento digital ideal puede no ser cierto.
Winston Smith

1
@CiroSantilli 新疆 改造 中心 法轮功 六四 事件 Sí, pueden dar resultados significativamente diferentes. Estado allí, cometió ese error.
Elliot Alderson

1

Una prueba está diseñada para ver si se cumple una especificación. La verificación es para ver si el dispositivo cumple con las entradas de diseño, es decir, todas las especificaciones. Supongo que hay muchas más interpretaciones, pero esto es lo que he visto en los documentos de orientación de la FIA.


Ya veo, he cambiado un poco la redacción (de prueba a prueba ) para aclarar que ambos son procesos. Estoy de acuerdo con usted en que para las pruebas individuales la palabra prueba es apropiada (a veces siento que estoy reafirmando lo obvio con estas preguntas de terminología ...) :)
Adicto a VHDL

1

Hacemos una distinción entre pruebas de verificación y pruebas de validación. Digamos que está diseñando un ventilador que enfría algunos equipos. Las pruebas de verificación se realizan para asegurarse de que el ventilador cumpla con todos los requisitos de diseño. Por lo tanto, puede probar el flujo de aire, el ciclo térmico, la vibración, etc.

Las pruebas de validación aseguran que los requisitos de diseño sean los correctos. ¿Las entradas de diseño que teníamos para el ventilador realmente nos dieron el ventilador que queríamos? Por ejemplo, se aseguraría de que el ventilador realmente enfríe el equipo según lo previsto.


Así es como los libros de Ingeniería de Software entienden los términos que he leído. Validación = asegúrese de que los requisitos sean correctos (verifíquelos con el cliente, regulaciones, etc.); Verificación = asegúrese de que el producto sea correcto (pruébelo según las especificaciones)
Wouter van Ooijen

1

ISO9000 habla sobre verificación y validación. En el contexto de la verificación ISO9000, significa probar un diseño de prototipo para demostrar que cumple con las expectativas funcionales y de rendimiento. La validación significa que probar la primera ejecución de producción también cumple con las expectativas de diseño. Verificar primero, validar después es mi pequeña forma de recordar el orden de las cosas.

Varios estándares de software invierten el orden de verificación y validación y esto realmente podría causar confusión, así que tenga en cuenta esto.

La conclusión es ... ¿Por qué está probando algo? ¿Es un diseño prototipo? Si es así, los estándares de calidad tienden a llamar a esta verificación. Si está probando una ejecución de producción por primera vez, los técnicos de hardware llaman a esto validación.

Solo mis experiencias personales.


0

Al leer estas respuestas, ahora me doy cuenta de que no existe una definición establecida de cómo la "prueba" difiere de la "verificación" en la industria.

Cuando trabajamos con diseño HW (diseño HW "real", como material en PCB, no programación VHDL) pasamos por una fase de verificación y validación, y una fase de prueba de producción (en realidad solo diseñamos las pruebas de producción y las entregamos al sitio de producción). - Verificación: (1) verifique que el prototipo / artículo producido en masa cumpla con los requisitos de HW (2) valide los requisitos de HW contra los requisitos de SYS. - Pruebas de producción: prueba de humo y casos de prueba de verificación simplificados y rápidos adaptados para detectar defectos de producción en masa sin tener que pasar por un proceso de verificación completo para cada una de las 500000 unidades producidas al año.

Entonces, en esa empresa multinacional en particular, "pruebas" se refiere a pruebas de producción y nada más.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.