Condiciones indiferentes en mapas de Karnaugh

Resumen: Una condición indiferente permite elegir el valor de salida cuando el contrato del sistema no lo restringe. En un mapa K, incluye celdas X solo si amplían un grupo útil; nunca cubras un cero requerido en SOP ni un uno requerido en POS. La optimización solo es válida si la hipótesis del conjunto de cuidado es cierta en el punto de uso. Una X de HDL, un valor desconocido en simulación y una condición indiferente de síntesis no son automáticamente lo mismo.

La minimización lógica normalmente conserva una función para todas las entradas posibles. Las condiciones indiferentes relajan ese requisito: ciertos casos de entrada/salida pueden asignarse como 0 o 1, lo que permite una implementación más pequeña para los casos que realmente importan.

Esa libertad puede eliminar literales y puertas. También puede eliminar la recuperación tras un reinicio, exponer un patrón de pantalla no válido o crear una discrepancia entre simulación y silicio si la hipótesis es incorrecta. Un diseño profesional registra juntas tres cosas:

1. el conjunto de activación requerido (on-set), donde la salida debe ser 1;
2. el conjunto de desactivación requerido (off-set), donde la salida debe ser 0;
3. el conjunto indiferente (don’t-care set), donde cualquiera de los dos resultados satisface el contrato del sistema.

Dos razones por las que una salida puede no estar restringida

1. La entrada es inalcanzable

El entorno garantiza que un vector de entrada concreto no puede llegar a esta lógica en un momento de observación relevante.

Un dígito BCD válido pertenece al conjunto 0–9, por lo que 10–15 pueden ser inalcanzables si:

• la fuente siempre produce BCD válido;
• el reinicio y el encendido no pueden exponer otro valor;
• las transiciones intermedias no se muestrean como dígitos;
• los fallos que corrompen el código quedan fuera del modelo de fallos requerido por el diseño.

«El algoritmo nunca pide 12» no basta si un bus de cuatro bits puede convertirse brevemente en 1100 al cambiar entre dos valores registrados válidos.

2. La entrada puede ocurrir, pero esta salida no se observa

Una etapa de una tubería puede transportar datos arbitrarios mientras valid=0. Si cada consumidor valida los datos con ese mismo estado, la salida de datos es irrelevante durante los ciclos no válidos.

Esta es una condición de observabilidad, no una entrada inalcanzable. Solo sigue siendo segura mientras ningún consumidor registre, compare, reenvíe o utilice de otra forma el campo nominalmente irrelevante.

Ambos casos se convierten en celdas X en un problema de minimización de dos valores. Sus demostraciones son diferentes, así que conserva el motivo en la especificación.

X no significa una sola cosa

El símbolo X está sobrecargado:

• En un mapa K, X significa «la implementación puede elegir 0 o 1».
• En una simulación HDL de cuatro estados, X suele significar «desconocido, conflictivo o no inicializado».
• En un documento de tabla de verdad, X puede significar que un valor de entrada es irrelevante para esa fila.
• En una directiva de síntesis, una construcción específica de la herramienta puede autorizar la optimización.

Estos significados no son intercambiables.

Asignar 'x en RTL puede mejorar la optimización en algunos flujos, propagar desconocidos en la simulación, ignorarse o transformarse en otro flujo y ocultar un error real de inicialización. Una asignación combinacional incompleta puede inferir un latch en lugar de una condición indiferente. Las directivas de herramientas como full_case también pueden hacer que el comportamiento sintetizado difiera del de la simulación; la documentación de Intel advierte explícitamente de esta posibilidad.

Expresa la intención de una forma compatible con el lenguaje de destino, el simulador, la herramienta de síntesis, las reglas de lint y el flujo formal. Después verifica el resultado sintetizado bajo las mismas hipótesis ambientales.

Reglas de los mapas K

Para una suma de productos minimizada:

1. Representa cada celda como 0 requerido, 1 requerido o X.
2. Forma rectángulos de tamaño potencia de dos que contengan solo 1 y X.
3. Cubre todos los 1 requeridos.
4. No incluyas nunca un 0 requerido.
5. Deja sin usar cualquier X que no mejore la cobertura.
6. Elige una cobertura según el objetivo de coste real: literales, celdas, profundidad, términos compartidos u otra métrica de implementación.

Para el producto de sumas, aplica el principio dual:

• agrupa los 0 requeridos con X opcionales;
• cubre todos los 0 requeridos;
• no incluyas nunca un 1 requerido.

Cada salida puede utilizar una X de forma diferente. Una función de segmento puede elegir 1 para una celda BCD no válida concreta, mientras otra puede elegir 0. No hay obligación de asignar un único patrón global para los valores no válidos, salvo que la especificación de la interfaz lo imponga.

Ejemplo práctico: un dígito BCD válido es al menos 5

Sea A el MSB del BCD y D el LSB. El comportamiento requerido es:

• F=0 para los dígitos 0–4;
• F=1 para los dígitos 5–9;
• X para los códigos 10–15.

Usando el orden Gray para las filas y columnas:

              CD
           00  01  11  10
AB = 00     0   0   0   0
AB = 01     0   1   1   1
AB = 11     X   X   X   X
AB = 10     1   1   X   X

Las celdas X permiten tres grupos útiles:

• las dos filas con A=1 forman un octeto, que produce A;
• 0110, 0111, 1110 y 1111 producen BC;
• 0101, 0111, 1101 y 1111 producen BD.

Por tanto:

o, factorizada:

Comprueba el conjunto de cuidado:

• los dígitos 0–4 producen 0;
• los dígitos 5–7 satisfacen $B(C+D)$;
• los dígitos 8–9 satisfacen A.

La expresión produce casualmente 1 para todos los códigos no válidos 10–15. Solo es aceptable porque esas filas se dejaron explícitamente sin restricciones.

Si los códigos no válidos deben producir 0

Ya no son condiciones indiferentes. Con F=0 para 10–15, una SOP válida es:

Esta versión conserva el cero requerido para los códigos no válidos. Es más grande porque el contrato de la interfaz es más estricto.

Un caso en el que las condiciones indiferentes no ayudan

Para un dígito BCD válido, «es par» es:

El LSB ya codifica la paridad. Permitir que los códigos 10–15 sean X no puede eliminar el único literal sin cambiar los valores requeridos, así que el mínimo permanece igual.

Las condiciones indiferentes amplían el espacio de optimización; no garantizan una mejora.

Un caso en el que desaparece un literal

Define F=1 para los dígitos BCD válidos 8 y 9, y F=0 para los dígitos válidos 0–7.

Si los códigos no válidos 10–15 también deben producir cero:

Solo 1000 y 1001 satisfacen la expresión.

Si 10–15 son condiciones indiferentes, los unos requeridos pueden agruparse con las seis celdas X:

Ambas implementaciones coinciden para el BCD válido. Difieren intencionadamente en algunas entradas no válidas.

Esta comparación correcta es importante: un diseño no puede afirmar «sin condiciones indiferentes» mientras utiliza silenciosamente celdas no válidas para ampliar un grupo.

Entradas transitorias y límites de muestreo

Aunque los registros de origen y destino contengan códigos válidos, los bits combinacionales no cambian simultáneamente. Una transición del BCD 7 (0111) al 8 (1000) cambia cuatro bits y puede atravesar otras combinaciones eléctricas.

Que esto importe depende de la frontera:

• Un registro de destino que muestrea solo después de que el decodificador se estabilice quizá nunca capture el resultado intermedio.
• Un habilitador de salida asíncrono, un estrobo de escritura o un reloj derivados de la lógica minimizada pueden reaccionar a un transitorio.
• Una pantalla multiplexada puede mostrar brevemente un patrón fantasma.
• Un analizador lógico puede revelar valores que el software nunca observa.

Por tanto, la demostración del conjunto inalcanzable debe indicar cuándo importa la salida, no solo qué valores en régimen permanente pretende el software.

Registrar las entradas o salidas, restringir la temporización, diseñar un control sin hazards o añadir un intervalo de apagado puede hacer verdadera la hipótesis. Declarar X en un mapa K no lo hace.

Estados no válidos en máquinas de estados

Supón que cinco estados se codifican en tres bits. Tres códigos no se utilizan durante el funcionamiento normal. Optimizar la lógica de siguiente estado y de salida usando esos códigos como condiciones indiferentes puede ser razonable si el reinicio está garantizado y la corrupción del estado queda fuera del alcance.

Si entran en el alcance un upset de evento único, un error de CDC, un reinicio parcial o la inyección de fallos, esos códigos no son irrelevantes. El diseño puede necesitar:

• detectar un estado ilegal;
• suprimir inmediatamente las salidas peligrosas;
• volver al reinicio o a otro estado seguro;
• informar del fallo;
• utilizar una codificación con una distancia de Hamming requerida.

Las herramientas FPGA ofrecen mecanismos explícitos de estado seguro. Por ejemplo, FSM_SAFE_STATE de AMD Vivado añade detección de estados no válidos y lógica de recuperación, con un compromiso entre área y rendimiento. La documentación de Intel Quartus también distingue la síntesis ordinaria de las opciones de máquinas de estados seguras.

No optimices los estados ilegales hasta eliminarlos y afirmes a la vez que existe una recuperación garantizada desde ellos. Son especificaciones diferentes.

Entradas one-hot y de prioridad

Una interfaz de $n$ bits exactamente one-hot tiene n vectores legales y $2^n-n$ vectores adicionales. El vector cero también es legal si el protocolo es one-hot-o-cero.

Un codificador simple puede tratar varios bits activos como condiciones indiferentes si la lógica anterior garantiza una entrada exactamente one-hot. Un codificador de prioridad define deliberadamente las filas con varios bits activos y, por tanto, no puede tratarlas como no restringidas. Aun así puede definir el código como irrelevante cuando no hay ninguna solicitud activa, siempre que una salida válida califique el código.

Esa distinción es una razón para documentar las hipótesis de entrada en los límites de los módulos, en lugar de deducirlas de un nombre como «codificador».

Datos irrelevantes para la salida

Considera:

valid = 0
data  = anything

Solo es seguro optimizar la lógica posterior dependiente de datos cuando todo efecto observable está controlado:

write_enable = valid AND condition(data)

Pero incluso aquí, la conmutación física de condition(data) puede consumir energía, crear filtraciones por canales laterales o afectar a la temporización. «No observable funcionalmente» no significa necesariamente «irrelevante eléctricamente».

Para facilitar la simulación, muchos equipos siguen asignando un valor determinista a los datos no válidos y dejan que la síntesis optimice mediante restricciones explícitas o habilitadores circundantes. La mejor elección depende del flujo de verificación e implementación.

Orientación para HDL

Evita traducir directamente la notación del mapa K en asignaciones X improvisadas de HDL.

Un patrón combinacional conservador define todas las salidas:

always_comb begin
  valid = (bcd <= 4'd9);
  ge_five = 1'b0;
  if (valid)
    ge_five = (bcd >= 4'd5);
end

Esto especifica el comportamiento no válido como cero. Si el proyecto quiere que las entradas no válidas sean condiciones indiferentes de síntesis, expresa esa intención mediante un mecanismo revisado y compatible con la herramienta, acompañado de la hipótesis correspondiente. Algunos ejemplos son las restricciones formales de entrada, los atributos de síntesis, las interfaces de módulo restringidas o una primitiva específica de la tecnología.

Sea cual sea el método elegido:

• ejecuta lint para detectar asignaciones incompletas y latches no intencionados;
• compara el comportamiento RTL y a nivel de puertas cuando el flujo lo requiera;
• demuestra la equivalencia en el conjunto de cuidado;
• verifica que se cumplen las hipótesis ambientales;
• revisa las advertencias sobre estados inalcanzables y cobertura de casos;
• evita casex o las coincidencias con comodines que puedan ocultar bits de control desconocidos, salvo que ese comportamiento sea intencionado.

Plan de verificación

Una optimización con condiciones indiferentes necesita dos comprobaciones complementarias.

Equivalencia funcional en el conjunto de cuidado

Para cada entrada requerida:

Con cuatro variables, enumera la tabla de verdad completa. Para una lógica mayor, utiliza aserciones o equivalencia formal con una restricción explícita del conjunto de cuidado.

Validación de hipótesis

Demuestra o comprueba que:

• las codificaciones no válidas no pueden muestrearse cuando importa la salida;
• el reinicio y el encendido respetan la hipótesis;
• las rutas CDC no pueden crear combinaciones no admitidas;
• los requisitos de fallos no incluyen el conjunto «inalcanzable»;
• el control de validez posterior cubre todos los efectos secundarios;
• los modos de prueba y depuración no eluden el calificador.

Probar únicamente la ecuación booleana minimizada verifica la mitad equivocada del contrato si es el entorno el que hace legal la X.

Construye el ejemplo BCD en DigiSim

Construye dos detectores de digit ≥ 5:

1. Versión con valores no válidos definidos: implementa $F=\overline A BC+\overline A BD+A\overline B\overline C$.
2. Versión optimizada con condiciones indiferentes: implementa $F=A+BC+BD$.
3. Recorre las dieciséis entradas.
4. Confirma que ambas coinciden para 0–9.
5. Registra sus diferencias intencionadas para 10–15.
6. Añade valid = NOT(A AND (B OR C)) para BCD 0–9 y controla una salida observable.
7. Cambia varios bits de entrada a la vez e inspecciona si el simulador modela las transiciones intermedias; no infieras un comportamiento analógico de hazards si utiliza actualizaciones simultáneas ideales.

El ejercicio muestra el intercambio correcto: lógica más pequeña a cambio de una promesa de comportamiento más limitada.

Lista de revisión

Antes de marcar una celda como X, pregunta:

• ¿Por qué no está restringida esta salida: por una entrada inalcanzable o por una salida no observada?
• ¿En qué frontera de muestreo u observación es cierta esa afirmación?
• ¿La infringen el reinicio, CDC, el modo de prueba o el comportamiento ante fallos?
• ¿Es X un permiso del mapa K, un desconocido de HDL o una directiva de herramienta?
• ¿Deben recuperarse los estados ilegales?
• ¿Se verifica la implementación optimizada para cada entrada del conjunto de cuidado?
• ¿Se afirma o se demuestra la propia hipótesis?

Las condiciones indiferentes no son «puertas gratis». Intercambian el comportamiento fuera de un conjunto de cuidado definido por libertad de implementación. Cuando el conjunto de cuidado es explícito y está verificado, se trata de una optimización disciplinada. Cuando solo se presupone, es funcionalidad oculta.

Continúa con Fundamentos de BCD para conocer el contrato de codificación, decodificación de BCD a siete segmentos para una aplicación con siete salidas y hazards estáticos y dinámicos para el comportamiento durante las transiciones.

Referencias

• Síntesis de AMD Vivado: FSM_SAFE_STATE
• Directrices HDL de máquinas de estados de Intel Quartus
• Atributo de síntesis full_case de Intel Quartus y advertencia de discrepancia con la simulación