Design Vision
Propósito e Configuração
Interação gráfica de inspeção e síntese de design do DC. Use o Design Compiler para síntese headless reproduzível; o Design Vision é útil para investigação de hierarquia, tempo (timing) e esquemas.
Resolva design_vision a partir do ambiente configurado ou perfil de ferramenta do usuário.
Descubra a release real, opções suportadas, licenças e documentação localmente.
Use descoberta de ambiente; não assuma um diretório de instalação, conta, endpoint de licença ou shell de inicialização específico.
Mantenha inventários de instalação, logs e índices de documentação em estado local privado.
Invocação e Convenções de Comando
Use o executável configurado diretamente a partir do ambiente preparado. Preserve seu nome de wrapper; alterar o nome de invocação de um dispatcher pode selecionar um produto diferente. Confirme as convenções interativas e em lote na documentação daquela release. Esta referência fornece candidatos a comando, não prova de que existem em toda release.
design_vision -f design.tcl
Para scripts de estágio suportados, flow.py captura comandos, status, logs, artefatos e checkpoints sem exigir um wrapper de shell. As ferramentas podem fornecer interfaces nativas com semânticas diferentes para flags semelhantes.
Entradas e Saídas
Arquivos .ddc do DC ou RTL/netlist suportados com bibliotecas correspondentes, SDC e configuração de design; um display funcional para uso da GUI. Use cópias de checkpoints para edição exploratória.
Checkpoints de design compatíveis com DC, relatórios e logs de sessão; artefatos de GUI exportados explicitamente quando suportados. Não sobrescreva checkpoints de síntese aceitos durante a inspeção.
Operações de Estágio
Recupere a sintaxe do comando instalado, tipos de argumento, padrões, restrições, exemplos, requisitos de recurso e pré-requisitos de estado de design antes de construir novos comandos. Identifique se cada operação consulta estado, atualiza estado derivado, modifica um design ou exporta artefatos.
| Estágio | Comandos ou procedimento nativo | Pré-requisitos e verificações |
|---|---|---|
| Carregar/inspecionar | read_ddc current_design report_hierarchy report_timing | Use contexto de biblioteca/restrição de síntese correspondente ao design salvo. |
| Síntese | analyze elaborate compile | Delegue síntese reproduzível e portas formais para synopsys-design-compiler. |
| Salvar | write_file write_sdc | Trate qualquer modificação de design como um novo candidato que requer verificação. |
Tcl, Inspeção e Documentação
Comandos de design/coleção do DC se aplicam onde documentados: current_design, get_designs *, report_hierarchy, report_timing, report_area e check_design. APIs específicas da GUI devem ser consultadas separadamente.
Para interfaces Tcl, construa caminhos/argumentos como listas Tcl, manipule coleções usando as APIs de coleção suportadas, capture erros e inspecione valores de retorno explícitos de comandos. Um arquivo Tcl sintaticamente válido não estabelece disponibilidade de comando. Para drivers nativos, use seu formato de entrada documentado.
python3 scripts/docs.py search '' --tool design-vision --limit 20
# Selecione a versão/instalação instalada quando houver múltiplas correspondências.
# Recupere uma entrada retornada com: python3 scripts/docs.py show DOCUMENT_ID
Os exemplos são executados a partir do diretório do bundle. Leia descoberta de comando para criação de índice privado, recuperação limitada, disponibilidade em tempo de execução e verificações de ciclo de vida. Uma entrada de manual pode descrever uma variável ou diagnóstico em vez de um comando chamável. Documentação ausente continua sendo um bloqueador para seleção de comando não suportado.
Parâmetros Controlados e Dependências
As configurações de síntese seguem a política do DC. As configurações de display/layout da GUI são observacionais; qualquer edição de design mapeada invalida a equivalência downstream e a evidência física.
Mesmo contexto de release/database/biblioteca do DC; Bibliotecas/display da GUI podem falhar independentemente do dc_shell. Use o nome exato do wrapper porque ele seleciona a personalidade do produto.
Registre valores originais/propostos, a hipótese suportada por relatório, referência manual, estágio válido e métrica esperada. Use otimização para comparações limitadas com funcionalidade imutável e restrições rígidas.
Recuperação de Falhas e Verificação
Diagnostique erros de display/GUI separadamente de erros de síntese. Preserve nomes de wrapper e contexto de design/biblioteca. Qualquer edição de design requer nova evidência de síntese/formal antes da promoção downstream.
Capture o comando/status, logs internos, relatórios e identidade de estado/checkpoint. Classifique a causa, consulte a documentação instalada relevante e aplique a correção justificada menos disruptiva. Restaure uma cópia gravável do último checkpoint de entrada válido e reexecute os estágios afetados. Compare métricas verificadas antes de manter uma alteração; retenha tentativas rejeitadas. Use solução de problemas para a decisão de recuperação.
Alterações funcionais precisam de autorização explícita. Não relaxe requisitos de tempo, remova restrições necessárias ou ignore a verificação para relatar sucesso. Pare quando não restar correção justificada ou um orçamento configurado for esgotado, e reporte qual entrada ou reparo de ambiente é necessário.
Modelos e Aceitação
Inspecione as saídas reais e relatórios específicos do produto em relação ao escopo solicitado. Para síntese/implementação, exija artefatos mapeados/ligados e restrições preservadas; reprove a funcionalidade após transformações. Para verificação, exija cobertura completa e verificações obrigatórias limpas. Para simulação/depuração, exija que a tarefa/teste pretendido seja concluído com diagnósticos revisados.
Mantenha a validação da documentação, verificações de sintaxe Tcl, execução da ferramenta, aceitação do estágio e evidências de aprovação ponta a ponta separadas. Um fluxo gerado não é uma implementação verificada. Consulte contrato de execução e escopo de validação para os limites de evidência exigidos.