Estoy trabajando en un laboratorio para un curso que tengo sobre VHDL, y parte de esto es implementar un sumador de acarreo de ondulación de n bits y luego probarlo como un sumador de 16 bits. Mi problema es que realmente no se COMO probarlo, o mas bien que insumos darle para probarlo a fondo. Esta es la primera vez que hago algo como esto, así que lo siento si parece que no tengo idea de lo que estoy hablando.
Mi primer pensamiento fue que, dado que el sumador es solo un grupo de sumadores completos idénticos encadenados, si pudiera demostrar que los bloques de sumadores individuales funcionan bien, entonces sería trivial demostrar que el sumador de 16 bits funcionó correctamente ya que tiene tal diseño simple. Así que mis dos entradas serían XXXXXXXX01101010 y XXXXXXXX01011100 con un Cin inicial de 0. Usando estos valores iniciales, los primeros 8 sumadores de la cadena realizarían cada uno una suma única (en función de ambas entradas y Cin) que cubriría completamente la verdad tabla para un sumador completo. Entonces, si los bits correspondientes en la suma son correctos y el acarreo no falla en el camino, mostraría que el sumador funciona correctamente.
Sin embargo, tengo un montón de razones para pensar que este es el enfoque equivocado. En primer lugar, parece demasiado simple. El manual de laboratorio se refiere a CASOS de prueba, pero obviamente solo he hecho un caso. También menciona que debe obtener información de tiempo de la simulación, pero no entiendo cómo funcionaría eso con un solo caso. Y lo más importante, la estrategia simplemente no tiene sentido para mí. Todo lo que realmente estoy haciendo es encontrar una forma realmente incómoda de probar un sumador completo encadenando un montón de ellos y obligando a Cin para cada caso de prueba a vincularse con el caso de prueba anterior. No estoy probando la funcionalidad de todo el asunto.
Como probablemente puedas decir, estoy bastante confundido. Realmente no tengo idea de cómo probar correctamente un sumador de 16 bits además de probar las partes individuales que lo componen. ¿Debería tratarlo como una caja negra y solo preocuparme por el resultado final y la suma? Pero dado que la suma es de 16 bits, ¿cuántas pruebas debo hacer para demostrar que funciona correctamente?
Siempre que sea factible, una prueba completa es una opción segura. con 2 permutaciones de entrada, un chip rápido y un poco de paciencia, esto podría ser factible. (En 1 prueba por nosotros, tomaría menos de 2 horas).
Cuando solo 'probaba un sumador' y no tenía tiempo para una prueba completa, prefería una prueba aleatoria.
Pero en su caso, sabe que i es un sumador ondulado, y podría incluir los acarreos en su salida. Eso significa que puede probar cada sección de forma independiente, eligiendo las entradas adecuadas. Eso significa solo alrededor de 16 * ( 2 ^ 3 ) vectores de prueba (cada combinación de AB y carry, y eso para cada sección). Esa es una pequeña prueba de prueba, pero debido a que puede verificar los acarreos, todavía tiene una cobertura completa.
Digamos que queremos hacer un buen trabajo probando esto, pero sin pasar por todo el espacio 2^32 de posibles operandos. (No es posible que dicho sumador tenga un error tal que solo afecte a una sola combinación de operandos, lo que requiere una búsqueda exhaustiva del espacio 2^32, por lo que es ineficiente probarlo de esa manera).
Si los sumadores individuales funcionan correctamente y la propagación de la ondulación entre ellos funciona correctamente, entonces es correcto.
Le daría prioridad a algunos casos de prueba que se centren en enfatizar la ondulación del acarreo, ya que los sumadores han sido probados individualmente.
Mi primer caso de prueba sería agregar 1 a 1111..1111, lo que provoca un acarreo de cada bit. El resultado debe ser cero, con un acarreo del bit más alto.
(Cada caso de prueba debe probarse en ambas conmutaciones: A + B y B + A, por cierto).
El siguiente conjunto de casos de prueba sería agregar 1 a varios patrones de "cero solitario" como 011 ... 111, 1011 ... 11, 110111 ... 111, ..., 1111110. La presencia de un cero debería "comer " la propagación del acarreo correctamente en esa posición de bit, de modo que todos los bits en el resultado que estén por debajo de esa posición sean cero, y todos los bits más altos sean 1 (y, por supuesto, no hay acarreo final del registro).
Otro conjunto de casos de prueba agregaría estos patrones de potencia de dos bits "solitario 1" a varios otros patrones: 000...1, 0000...10, 0000...100, ..., 1000...000 . Por ejemplo, si esto se agrega al operando 1111.1111, todos los bits desde esa posición de bit a la izquierda deberían borrarse, y todos los bits debajo de eso no deberían verse afectados.
A continuación, un caso de prueba útil podría ser sumar las 16 potencias de dos (los vectores "1 solitario"), así como el cero, a cada uno de los 65536 valores posibles del operando opuesto (y, por supuesto, conmutar y repetir ).
Finalmente, repetiría las dos pruebas anteriores de "solo 1" con "solo 11": todos los patrones de bits que tienen 11 incrustados en 0, en todas las posiciones posibles. De esta manera, estamos en situaciones en las que cada sumador combina dos bits 1 y un acarreo, lo que requiere que produzca 1 y lleve a cabo 1.
Hay varias suites de herramientas de banco de pruebas semiautomáticas para VHDL; Creo que el campo se llama "prueba de equivalencia", pero supongo que desea desarrollar algo desde cero.
Tenemos computadoras rápidas que pueden iterar a través de todas las combinaciones posibles muy rápidamente, por lo que le recomiendo que no lo piense demasiado: simplemente pruebe cada caso. Como estás hablando de un sumador de 16 bits, eso significa 65536 combinaciones para la primera entrada y 65536 para la segunda entrada. Un contador de 32 bits conectado a las entradas del sumador recorrerá cada combinación de entrada posible: conecte los 16 bits inferiores a una entrada y los 16 superiores a la otra entrada. Activar el contador de una señal de reloj generada a partir de un proceso de estímulo (salida <= '1' después de 10 ns; salida <= '0' después de 10 ns;)
Ahora, necesita probar para ver si la salida de su sumador es correcta. Las herramientas que tiene disponibles dependen en gran medida de su entorno. Lo más fácil de comprender es probablemente tomar la salida de su sumador y restar la primera entrada y luego restar la segunda entrada y luego mirar el resultado; si no son todos ceros, levante una bandera. VHDL tiene funciones matemáticas y de comparación incorporadas, por lo que construir un bloque VHDL que realice esta operación debería ser bastante trivial. Agregue un pestillo al final para mantener el valor, y luego puede simularlo y luego mirar el último valor del resultado de su simulación: si es 0, funciona, si es 1, no funciona.
Este es un ejercicio académico. Como tal, el problema en sí es fácil, así que lo que importa es la lección, no los detalles del problema. En este caso trivial, puede encontrar muchas formas ad hoc de probarlo con la confianza de que probará o desaprobará que el módulo funciona según lo previsto. Pero la verdadera lección en este caso es averiguar cómo producir cobertura de prueba para algo que puede ser demasiado complejo para estar seguro de que una forma de prueba de 'atajo' construida intuitivamente será confiable para la integridad. No es que esas no sean habilidades útiles, de hecho, son necesarias cuando la cobertura completa no es práctica desde el punto de vista computacional, pero esa no es la lección aquí, de lo contrario, el problema de ejemplo se habría formulado como tal.
Así que escribe un banco de pruebas, conecta tu uut (unidad bajo prueba), dale todas las entradas posibles (puedes usar un bucle for anidado para esto) y compara la salida con el resultado conocido, calculado usando la biblioteca matemática vhdl, que know es correcto y usa el procesador de su PC para el cálculo, y si la salida es alguna vez diferente, use la función de informe (o escriba en el archivo) para mostrar en la consola las entradas para las que falló la prueba, de modo que luego pueda investigar la anomalía.
Como nota al margen, la cobertura total es en realidad imposible para una caja negra real, por lo que en realidad necesita tener una idea del diseño. Por ejemplo, podría crear un sumador que siempre le proporcione la respuesta correcta para cualquier conjunto de entradas dado, a menos que las adiciones anteriores sigan un patrón específico (bienvenido al mundo de las puertas traseras de hardware), por lo que deberá probar arbitrariamente gran cantidad de secuencias de entrada, a menos que conozca la cantidad máxima de elementos de memoria interna, etc. Pero estoy divagando.