¿Es mejor arreglar x en la simulación o en el diseño?

Supongo que depende de dónde se encuentren los x 's en el diseño.

Tomemos un ejemplo de esquema de comunicación dentro del chip. Es posible que desee pasar datos entre dos componentes, pero digamos que no en cada ciclo de reloj. Puede decidir entonces tener un bus de datos y una señal válida. La señal válida dice cuando los datos son válidos. Debido a esto, siempre que la señal válida sea baja, el valor de la señal de datos no importa (porque se ignora).

En este ejemplo, siempre que la señal válida sea nunca , no importa, el diseño nunca hará nada inesperado. La señal de datos puede no importarle, en realidad no importa, porque siempre sabe que habrá datos válidos (cualquiera que sea) cuando la señal válida sea alta.

Si la señal válida alguna vez fue "no importa", entonces tiene un problema. ¿Por qué? porque significa que tienes un escenario en el que no tienes idea de lo que sucederá. Esto puede o no causar un problema, pero es una pesadilla rastrearlo.

Entonces, con eso en mente, es mi opinión que:

Si te encuentras con x 's en un bus de datos, no es el fin del mundo, en realidad no sabes cómo serán los datos en un momento dado.

Si aparecen en las señales de control puede o no ser malo, no lo sabes. En esta situación, debe ejecutar su simulación dos veces, una vez que se asegure de que no le importe que se vea forzado a ser 0, y una segunda vez que se asegure de que sea un 1. De esta manera sabrá lo que sucederá en ambos casos.

Si no puede estar seguro (es decir, a partir del código que ha escrito) de que no le importan los problemas, no debe ignorarlo, x es un posible desastre desconocido. Si sabe que el valor en cualquier punto dado no importa, entonces x es perfectamente válido.

Además, todos los registros de control, para lo que sean, deben inicializarse a un valor al reiniciar. Un registro de control sin inicializar en el encendido podría ser desastroso. Imagina que creas un sistema de control para lanzar armas nucleares y no inicializaste el registro de 'lanzamiento' a 0. Por lo que sabes cuando enciendes la energía, puedes comenzar WW3.

Hay muchas causas diferentes para el estado X en una simulación, pero desafortunadamente todas están representadas por un estado en Verilog. VHDL tiene el estado U para representar un valor sin inicializar. Puede que no tenga una representación física en el hardware, pero ciertamente es una propiedad real de un diseño de hardware además del nivel de voltaje de la señal.

La propagación precisa del estado X es una simulación dinámica difícil para cualquier RTL o netlist. Es posible que desee ver herramientas formales para este propósito, especialmente para la verificación de reinicio. Son adecuados para esta aplicación para probar exhaustivamente todas las combinaciones.

En lo que respecta al costo asociado con la adición de la lógica de reinicio, los diseños siempre tienen algún tipo de límite en sus especificaciones; Potencia, área, características. Por lo tanto, ciertamente no desea agregar una lógica innecesaria para hacer que su simulación de lista de redes funcione. Algunos simuladores le permiten inicializar aleatoriamente la lógica, de modo que al menos puede obtener un cierto nivel de confianza antes de intentar enmascarar las X.

Si está ejecutando el código generado por un compilador 'C' (en lugar de un ensamblador en bruto) en un núcleo ARM, es probable que tenga problemas con las simulaciones de netlist a menos que empiece por inicializar el banco de registros. Dependiendo de lo agresivo que haya sido el compilador, es posible que necesite inicializar todo el estado (y esto luego comienza a ser riesgoso).

El problema más obvio es que las operaciones de configuración de marca en los registros inicializados moverán una ruta de datos X bastante inofensiva a la ruta de control de una manera que no siempre es inofensiva. Esto no es algo que deba suceder en un código escrito a mano con sensatez, pero el compilador 'C' está (creo) en libertad de reordenar las operaciones y, a veces, hacer cosas en las que ignorará el resultado. La RTL se comportará de manera consistente si se le da una entrada numérica arbitraria, pero a veces reacciona mal si se le da X como un valor de datos.

Tan pronto como tenga la lógica de captación previa expuesta a datos X, no es difícil imaginar que una lógica de control más pueda generar un resultado X en lugar de un tipo de comportamiento de rendimiento rápido / lento.

RTL se escribe con frecuencia para que sea X-pesimista, por lo que cualquier valor de X (que represente valores no conocidos) se pasará a través de un diseño.

Si sus pruebas se ejecutan sin inicializar el banco de registros a 0 en su código de inicio, manténgalo así. Es más probable que detecte un problema de esta manera (como ejecutar la imagen de código para ejecutar datos). Sin embargo, no se desespere si tiene que inicializar algunos registros en el software para ejecutar en una lista de redes.

Si encuentra que su lista de redes necesita todos los flops que se inicializaron al reiniciarse, debe consultar la documentación principal (manual de integración) y hacer un seguimiento de la asistencia si es necesario.

Para admitir esta vista, busque el código de inicio que se proporciona con el banco de pruebas de ejecución. Si hay algunas inicializaciones cero allí, las necesitarás para la simulación de la lista de red (pero probablemente no en silicio real).