Gobernanza de sign-off de tape-out para SVA sintéticas creadas por IA

En un tablero sintético fijo, 8/8 PROVEN se convierte en 5/8 TRUSTWORTHY tras la auditoría.

Proof Firewall reaudita las aserciones SystemVerilog sintéticas PROVEN para verificar vacuidad, fuerza de aserción y cono de influencia antes de que entren en un archivo de sign-off. En el tablero fijo, convierte 8/8 demostraciones de flujo directo en cinco resultados certificados TRUSTWORTHY y enruta el resto a revisión humana con un motivo. Los agentes aconsejan, el código decide.

8/8 a 5/8

PROVEN a TRUSTWORTHY

Tablero sintético fijo de ocho propiedades tras la auditoría del firewall

0/6

Muertes por mutación de PIPE3

Caso sintético destacado de pipeline débil

18/18

Concordancia con el benchmark sintético etiquetado

Benchmark de demo local, no una afirmación de precisión en mundo abierto

Esta es una demostración ejecutable y reproducible que utiliza diseños y propiedades de sistemas de transición sintéticos creados en fixtures. No utiliza RTL de clientes, un solver en la nube ni una llamada a LLM en vivo en la ruta predeterminada.

El fallo de sign-off se oculta dentro de un resultado verde

El éxito en primer silicio se reportó en un 14% en el estudio de Wilson Research Group y Siemens EDA de 2024. Un resultado formal merece mayor escrutinio cuando la aserción puede haber sido creada por IA: una implicación puede resultar PROVEN porque su antecedente nunca ocurre, o porque su consecuente no restringe nada útil.

Proof Firewall es una puerta de gobernanza posdemostración determinista para esa decisión. No declara que un motor formal esté equivocado. Plantea si la demostración es lo suficientemente defendible como para registrarse para el sign-off humano de tape-out, y luego deja un motivo concreto para cada resultado que certifica o retiene.

Cómo funciona la puerta de gobernanza

El ancla es la calidad de la demostración. Cada comprobación determinista evalúa si una demostración verde tiene suficiente sustancia para registrarse.

Alcanzabilidad antes del crédito

El verificador de modelos de estados explícitos comprueba si el antecedente de una implicación puede ocurrir en la IR del sistema de transición sintético. Un antecedente inalcanzable se enruta como VACUOUS en lugar de registrarse como evidencia.

Prueba de muerte por mutación para evaluar la fuerza

Las mutaciones de diseño de punto único relevantes evalúan si la aserción rechaza variantes rotas. Una propiedad que sobrevive a esas mutaciones se enruta como WEAK en lugar de permitirle tomar prestada la confianza de un resultado verde del solver.

COI y enrutamiento por políticas

La puerta calcula el cono de influencia y asigna TRUSTWORTHY, BOUNDED-PROVEN, VACUOUS, WEAK, DEAD o VIOLATED. Solo TRUSTWORTHY recibe un certificado de demostración firmado.

El verificador de estados explícitos en Python puro de la demo encuentra trazas de alcanzabilidad y contraejemplos en el modelo finito. Un respaldo de profundidad acotada se etiqueta como acotado, no se reformula como una demostración no calificada.

Revisión práctica de demostraciones en el tablero sintético

Cada imagen es una captura de pantalla de la demo sintética en ejecución. El tablero comienza como ocho resultados PROVEN de flujo directo, y luego la auditoría hace visible la evidencia retenida.

La auditoría revierte tres resultados verdes

El Tablero de Sign-Off de Tape-Out muestra inicialmente 8/8 PROVEN en su vista de flujo directo. Tras la auditoría del firewall, 5/8 se certifican como TRUSTWORTHY; las tres restantes son una propiedad VACUOUS y dos WEAK. Este es un fixture sintético fijo, no un diseño de cliente ni un resultado de motor comercial.

Tablero de Sign-Off de Tape-Out de Proof Firewall que muestra cinco de ocho propiedades sintéticas marcadas como TRUSTWORTHY, con un resultado VACUOUS y dos WEAK retenidos para revisión. — El tablero sintético auditado: el firewall convierte una vista 8/8 PROVEN en cinco certificados TRUSTWORTHY y tres retenciones explicadas.

ARB3 no demuestra nada porque su disparador nunca ocurre

La aserción sintética ARB3, assert (g0 && g1) |-> (turn == 0), es VACUOUS porque su antecedente es inalcanzable en el árbitro sintético. El resultado demuestra por qué una implicación demostrada aún puede no certificar nada.

Forma de onda del árbitro sintético que muestra ARB3, cuyo antecedente g0 y g1 es inalcanzable y, por tanto, se clasifica como VACUOUS. — ARB3: un antecedente inalcanzable convierte una implicación verde en un resultado VACUOUS.

PIPE3 sobrevive a las mutaciones que debería detectar

La aserción sintética PIPE3, assert v2 |-> (s2 == s2), es WEAK. Su consecuente tautológico sobrevive a las mutaciones inyectadas relevantes, y el caso de pipeline presentado registra 0/6 muertes por mutación.

Forma de onda del pipeline sintético que muestra PIPE3, una propiedad tautológica clasificada como WEAK tras registrar cero de seis muertes por mutación. — PIPE3: un consecuente tautológico obtiene un resultado WEAK tras una prueba de muerte por mutación de 0/6.

Una propiedad CDC más fuerte puede mostrar su propio contraejemplo

La propiedad débil sintética CDC2 es WEAK. Reforzarla a assert (req && !ack) |-> ##1 req hace que sea VIOLATED en el fixture de CDC sintético y produce una forma de onda de contraejemplo concreta. Ilustra una clase de fallo de CDC por pérdida de transacción, no una afirmación sobre un chip real.

Forma de onda de contraejemplo concreta para una propiedad sintética de CDC reforzada clasificada como VIOLATED en el fixture. — La propiedad sintética de CDC reforzada es VIOLATED, con un contraejemplo que un revisor puede inspeccionar.

La revisión deja un recibo estructurado

El certificado de demostración firmado registra el veredicto de cada propiedad, la alcanzabilidad, los resultados de mutaciones, el COI y los registros de contraejemplos cuando procede, más un campo SHA-256. Hace que la auditoría sea auditable sin exigir que el revisor infiera por qué cambió un estado.

Certificado de demostración firmado de Proof Firewall que muestra veredictos por propiedad, alcanzabilidad, resultados de mutaciones, cono de influencia, registros de contraejemplos y un campo SHA-256. — El certificado de demostración firmado preserva la evidencia detrás de la certificación o de la revisión humana.

Una orientación a producción independiente del motor, no un solver de reemplazo

Proof Firewall demuestra una puerta en torno a la evidencia de demostración. El alcance a continuación separa lo que hace la demo del trabajo que se pospone.

Pregunta	Demo de Proof Firewall	Orientación a producción
Entrada de la demostración	IR de sistema de transición sintético y SVA creados en fixtures	Una puerta en torno al flujo formal existente del cliente
Comprobaciones mostradas	Vacuidad, prueba de muerte por mutación, COI, enrutamiento por políticas, exportación de certificados	Mismas preguntas de gobernanza aplicadas a la evidencia de demostración suministrada
Motores formales	Sin adaptador para motores reales	Orientación independiente del motor, no una afirmación de integración
Gestión de resultados	Certificados TRUSTWORTHY y retenciones explicadas	Revisión humana de sign-off con un registro estructurado de evidencia

Lo que esta demo no hace

✓ No analiza sintácticamente RTL en Verilog o SystemVerilog, ni opera sobre RTL de clientes, GDSII o el diseño de un chip real. La V1 utiliza fixtures de IR de sistemas de transición sintéticos.
✓ No reemplaza a JasperGold, VC Formal, Questa Formal, SymbiYosys ni a ningún otro motor formal. Los adaptadores para motores reales se posponen.
✓ No utiliza un LLM en vivo por defecto. Las propiedades son SVA creadas por LLM en fixtures, y la ruta de registro predeterminada es determinista.
✓ No afirma preparación para tape-out, certificación de seguridad, cero respins, resultados de clientes, despliegues, ROI ni cualificación regulatoria.
✓ No presenta 5/8, 18/18, 0/6 o 7/7 como rendimiento en producción o en toda la industria. Estos son resultados de pruebas y fixtures sintéticos locales fijos.

Preguntas que hacen los líderes de verificación

¿Ya ejecutamos verificación formal. ¿Por qué pondríamos otra puerta tras un resultado PROVEN?

Un resultado PROVEN aún puede basarse en un antecedente inalcanzable o en una propiedad que no falla cuando el comportamiento relevante del diseño está roto. Proof Firewall demuestra una puerta posdemostración determinista para esas cuestiones: alcanzabilidad, pruebas de muerte por mutación, cono de influencia y enrutamiento por políticas. No reemplaza a un motor formal; su orientación a producción es una puerta independiente del motor en torno a un flujo formal existente.

¿Proof Firewall se conecta hoy con JasperGold, VC Formal, Questa Formal o SymbiYosys?

No. Los adaptadores para motores reales se posponen en esta demo, por lo que no debe interpretarse como un reemplazo de JasperGold, VC Formal, Questa Formal, SymbiYosys u otro motor formal. La orientación a producción demostrada es una puerta de gobernanza independiente del motor en torno al flujo de trabajo formal existente del cliente.

¿Estos resultados provienen de RTL de clientes o de un generador de aserciones de IA en vivo?

No. El tablero, las aserciones SystemVerilog, los diseños, el benchmark y los contraejemplos son sintéticos. La ruta de registro predeterminada utiliza propiedades SVA creadas por LLM en fixtures y una IR de sistema de transición sintética, no RTL de clientes ni una llamada a LLM en vivo.

¿Qué midió realmente el resultado de 8/8 a 5/8?

Es un tablero sintético fijo de ocho propiedades. Su línea base de flujo directo muestra 8/8 PROVEN; tras la auditoría del firewall, cinco se certifican como TRUSTWORTHY, mientras que una es VACUOUS y dos son WEAK. No es una tasa de RTL en producción, un resultado de cliente ni un resultado general para aserciones sintéticas creadas por IA.

¿Cómo decide la demo que una aserción es vacua o débil?

La puerta de gobernanza comprueba si el antecedente es alcanzable, ejecuta mutaciones de diseño de punto único relevantes y calcula el cono de influencia de cada propiedad. ARB3 es VACUOUS porque su antecedente es inalcanzable en el árbitro sintético. PIPE3 es WEAK porque su consecuente tautológico sobrevive a las mutaciones inyectadas relevantes, con un resultado de 0/6 muertes por mutación en el caso de pipeline presentado.

¿Qué evidencia puede extraer un revisor de esta demo?

La interfaz de usuario exporta signoff_certificate.json con veredictos por propiedad, alcanzabilidad, resultados de mutaciones, cono de influencia, registros de contraejemplos cuando procede y un campo SHA-256. Solo TRUSTWORTHY recibe un certificado de demostración firmado; los resultados BOUNDED-PROVEN, VACUOUS, WEAK, DEAD y VIOLATED se retienen para revisión humana con un motivo.

Investigación técnica

La investigación detrás de esta demo: la arquitectura, el diseño de verificación y el plano empresarial.

Solución completa

Explorar la solución de Semiconductor AI Verification & Silicon Correctness →

Lleva la gobernanza de la calidad de las demostraciones a la conversación de sign-off

Invitamos a los líderes de verificación a debatir sobre rutas de evidencia deterministas para flujos de trabajo de ingeniería de alto riesgo asistidos por IA.

La siguiente conversación útil trata sobre los artefactos de demostración que su equipo necesita inspeccionar, el límite de política que un revisor puede defender y lo que requeriría una orientación a producción independiente del motor.

Evaluación de gobernanza de demostraciones

✓ Mapear la ruta actual de revisión de demostraciones
✓ Identificar evidencia de vacuidad y fuerza
✓ Definir estados de políticas de sign-off
✓ Especificar registros de certificados auditables

Diseño de la ruta de gobernanza

✓ Diseñar puertas de evidencia independientes del motor
✓ Construir enrutamiento determinista por políticas
✓ Modelar flujos de trabajo de auditoría y excepciones
✓ Planificar transferencias para el sign-off humano

Conectar por WhatsApp Enviar un correo a nuestro equipo