Verificación de CPU suave

18

Actualmente estoy en el proceso de diseñar una CPU simple en VHDL usando Xilinx ISE e ISIM. La parte de diseño está yendo notablemente bien, pero parece que no puedo encontrar una manera de hacer la verificación de manera consistente.

En este momento tengo un banco de pruebas VHDL que actualizo para probar la función en la que estoy trabajando en cualquier momento en particular. Esto es muy ad-hoc, y no me ayuda a detectar regresiones y no se puede usar para verificar el cumplimiento del conjunto de especificaciones / instrucciones.

He pensado en desarrollar un extenso conjunto de pruebas, pero el problema es que el estado potencial de una parte de propósito general como CPU es enorme en comparación con componentes menos genéricos.

Estoy buscando un método que me permita realizar el diseño y las pruebas de una manera más controlada. Algún tipo de "hardware TDD" si se quiere. ¿Existe tal cosa? ¿Se puede aplicar con relativa facilidad a piezas de uso general como una CPU?

drxzcl
fuente

Respuestas:

16

Todo el problema de la verificación de la CPU es muy grande y difícil. Hay personas que hacen una carrera con solo esto. Solo te daré el resumen ...

  1. Escriba un programa en lenguaje ensamblador que pruebe cada instrucción y cada pequeño detalle de cada instrucción. Por ejemplo, al probar la instrucción ADD, puede probarla con números que sean positivos, negativos y uno de cada uno (dos veces). Luego probaría el indicador de acarreo, el indicador de cero, etc. Otras características especiales de la CPU (como la predicción de rama, etc.) tendrían su propia parte especial de esta prueba.

  2. Escriba, usando C / C ++ o algo así, un modelo de su CPU. Esta es tu CPU virtual. Esta es también su "CPU dorada", lo que significa que esta es la CPU con la que se compara todo lo demás. Idealmente, la persona que escribió el VHDL NO es la misma persona que escribe el modelo C / C ++.

  3. Escriba / cree un sistema en el que pueda ejecutar el modelo C / C ++ y el modelo VHDL uno al lado del otro, y compare los resultados ciclo por ciclo. Ejecute su programa de ensamblaje desde el Paso 1 y asegúrese de que los dos modelos coincidan.

  4. Ejecute sus dos modelos en "instrucciones" aleatorias. Básicamente, llene "ram" con datos aleatorios y ejecute esos datos aleatorios como si fueran instrucciones reales. Ejecute los mismos datos aleatorios en los modelos VHDL y C / C ++ y compare los resultados. Este modelo C / C ++ se ejecutaría en alguna estación de trabajo y / o servidor (no en la nueva CPU en sí).

  5. Configure una máquina, o varias máquinas, para repetir el paso 4 esencialmente para siempre. Incluso si su CPU está "terminada" y ha estado en producción durante un año o más, seguirá ejecutando esta prueba.

  6. Repita estos pasos siempre que haya más cosas para simular. Por ejemplo, lo ejecutaría en el VHDL posterior a la ruta con tiempo cuando esté disponible.

No hay garantía de que comparar las versiones VHDL y C / C ++ detecte cada error, pero realmente no hay una mejor manera. Y probar la CPU en instrucciones aleatorias lleva tiempo, pero eso también es muy útil. La única alternativa real a esto es contratar a mucha gente para que simplemente escriba código todo el día para probar diferentes partes de la CPU, y las compañías más grandes hacen esto, pero también hacen cosas de datos aleatorios también.

Para una sola persona que escribe código VHDL, generalmente solo se realiza el paso 1. Pero si va a vender la CPU, entonces al menos algunos de los otros pasos deben hacerse (y realmente, debe hacerlos todos).


fuente
Excelente respuesta, gracias! Esto tiene mucho sentido. La "CPU dorada" es, de hecho, la pieza faltante del rompecabezas que le permite hacer una verificación ciclo por ciclo durante las pruebas. Dado que este es principalmente un proyecto de juguete, creo que me conformaré con la primera oración del último párrafo y haré solo el paso # 1. Pero saber lo que debería estar haciendo es invaluable.
drxzcl
También puede tener un modelo C ++ dorado, pero no preciso para el ciclo, que le permite ser mucho más simple y, por lo tanto, más probable que sea correcto, útil para probar la funcionalidad de ALU, por ejemplo ("2 + 2 = 4 y algunos indicadores, I no me importa cuando "en lugar de" 2 + 2 = 4 después de una marca y las banderas después de 2 marcas ")
Martin Thompson
Además, ejecute la cobertura de código (para verificar que haya ejercido todo) y la cobertura de prueba (para verificar que todas las pruebas hayan sido probadas tanto para pasar como para fallar)
Martin Thompson,
Seguimiento: Utilizando el procedimiento del "primer paso", logré encontrar muchas fallas ... en mi ensamblador: P El núcleo en sí parece estar relativamente bien.
drxzcl