Design Vision
Propósito y configuración
Interacción de inspección y síntesis de diseño gráfico de DC. Use Design Compiler para síntesis headless reproducible; Design Vision es útil para la investigación de jerarquía, temporización y esquemáticos.
Resuelva design_vision desde el entorno configurado del usuario o el perfil de la herramienta.
Descubra la versión real, las opciones compatibles, las licencias y la documentación localmente.
Use descubrimiento de entorno; no asuma un
directorio de instalación, cuenta, punto final de licencia o shell de inicio en particular.
Mantenga los inventarios de instalación, los registros y los índices de documentación en un estado local privado.
Convocatoria y convenciones de comandos
Use el ejecutable configurado directamente desde el entorno preparado. Preserve su nombre de archivo wrapper; cambiar el nombre de invocación de un despachador puede seleccionar un producto diferente. Confirme las convenciones interactivas y por lotes en la documentación de esa versión. Esta referencia proporciona candidatos a comandos, no la prueba de que existan en cada versión.
design_vision -f design.tcl
Para scripts de etapa compatibles, flow.py captura comandos, estado, registros, artefactos y puntos de control sin necesidad de un shell wrapper. Las herramientas pueden proporcionar interfaces nativas con diferentes semánticas para banderas similares.
Entradas y salidas
DC .ddc o RTL/netlist compatible con bibliotecas coincidentes, SDC y configuración de diseño; una pantalla funcional para uso de GUI. Use copias de puntos de control para edición exploratoria.
Puntos de control de diseño compatibles con DC, informes y registros de sesión; artefactos de GUI exportados explícitamente cuando sean compatibles. No sobrescriba puntos de control de síntesis aceptados durante la inspección.
Operaciones de etapa
Recupere la sintaxis de comando instalada, tipos de argumentos, valores predeterminados, restricciones, ejemplos, requisitos de funciones y requisitos previos de estado de diseño antes de construir comandos nuevos. Identifique si cada operación consulta el estado, actualiza el estado derivado, modifica un diseño o exporta artefactos.
| Etapa | Comandos o procedimiento nativo | Requisitos previos y comprobaciones |
|---|---|---|
| Cargar/inspeccionar | read_ddc current_design report_hierarchy report_timing | Use el contexto de biblioteca/restricción de síntesis que coincida con el diseño guardado. |
| Síntesis | analyze elaborate compile | Delegue la síntesis reproducible y las compuertas formales a synopsys-design-compiler. |
| Guardar | write_file write_sdc | Trate cualquier modificación de diseño como un nuevo candidato que requiera verificación. |
Tcl, inspección y documentación
Los comandos de diseño/colección de DC se aplican donde estén documentados: current_design, get_designs *, report_hierarchy, report_timing, report_area y check_design. Las API específicas de GUI deben consultarse por separado.
Para interfaces Tcl, construya rutas/argumentos como listas Tcl, maneje colecciones usando las API de colección compatibles, capture errores e inspeccione los valores de retorno explícitos de los comandos. Un archivo Tcl sintácticamente válido no establece la disponibilidad del comando. Para controladores nativos, use su formato de entrada documentado en su lugar.
python3 scripts/docs.py search '' --tool design-vision --limit 20
# Seleccione la versión/instalación instalada cuando haya múltiples coincidencias.
# Recupere una entrada devuelta con: python3 scripts/docs.py show DOCUMENT_ID
Los ejemplos se ejecutan desde el directorio del paquete. Lea descubrimiento de comandos para la creación de índices privados, recuperación acotada, disponibilidad en tiempo de ejecución y comprobaciones de ciclo de vida. Una entrada de manual puede describir una variable o diagnóstico en lugar de un comando invocable. La documentación faltante sigue siendo un bloqueo para la selección de comandos no compatibles.
Parámetros controlados y dependencias
La configuración de síntesis sigue la política de DC. La configuración de pantalla/diseño de GUI es observacional; cualquier edición de diseño mapeada invalida la evidencia de equivalencia y física posteriores.
Mismo contexto de versión de DC/base de datos/biblioteca; las bibliotecas/pantalla de GUI pueden fallar independientemente de dc_shell. Use el nombre exacto del wrapper porque selecciona la personalidad del producto.
Registre los valores originales/propuestos, la hipótesis respaldada por el informe, la referencia manual, la etapa válida y la métrica esperada. Use optimización para comparaciones acotadas con funcionalidad inmutable y restricciones estrictas.
Recuperación de fallos y verificación
Diagnostique la configuración de pantalla/GUI por separado de los errores de síntesis. Preserve los nombres de wrapper y el contexto de diseño/biblioteca. Cualquier edición de diseño requiere nueva evidencia de síntesis/formal antes de la promoción aguas abajo.
Capture el comando/estado, los registros internos, los informes y la identidad del estado/punto de control. Clasifique la causa, consulte la documentación instalada relevante y aplique la corrección justificada menos disruptiva. Restaure una copia modificable del último punto de control entrante válido y vuelva a ejecutar las etapas afectadas. Compare las métricas verificadas antes de mantener un cambio; retenga los intentos rechazados. Use solución de problemas para la decisión de recuperación.
Los cambios funcionales necesitan autorización explícita. No relaje los requisitos de temporización, elimine las restricciones necesarias ni omita la verificación para reportar éxito. Deténgase cuando no quede ninguna corrección justificada o se haya agotado un presupuesto configurado, e informe qué reparación de entrada o entorno se necesita.
Plantillas y aceptación
Inspeccione las salidas reales y los informes específicos del producto contra el ámbito solicitado. Para síntesis/implementación, requiera artefactos mapeados/enlazados y restricciones preservadas; vuelva a probar la funcionalidad después de las transformaciones. Para verificación, requiera cobertura completa y comprobaciones requeridas limpias. Para simulación/depuración, requiera que la tarea/prueba prevista se complete con diagnósticos revisados.
Mantenga la validación de documentación, las comprobaciones de sintaxis Tcl, la ejecución de herramientas, la aceptación de etapas y la evidencia de aprobación de extremo a extremo por separado. Un flujo generado no es una implementación verificada. Consulte contrato de ejecución y ámbito de validación para los límites de evidencia requeridos.