Design Compiler
Propósito e configuração
Elaborar RTL, mapear lógica para células padrão caracterizadas, otimizar timing/área/potência e exportar netlists de implementação. A saída do DC é uma implementação lógica; não é um resultado físico ou de signoff.
Resolva dc_shell a partir do ambiente configurado pelo usuário ou perfil da ferramenta.
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 em particular.
Mantenha inventários de instalação, logs e índices de documentação em estado local privado.
Convenções de invocação e comandos
Use o executável configurado diretamente a partir do ambiente preparado. Preserve seu nome de arquivo 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 dessa release. Esta referência fornece comandos candidatos, não prova de que existem em toda release.
dc_shell -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 similares.
Entradas e saídas
Fontes Verilog/SystemVerilog/VHDL ordenadas, top, parâmetros/defines/caminhos de include, bibliotecas .db de target/link, SDC aprovado; referências UPF e físicas quando necessário. Registre semânticas de reset e dependências DesignWare. A conversão .lib requer um Library Compiler funcionando; verifique sua disponibilidade localmente.
.v mapeado, .ddc, .sdc exportado, .svf de síntese; design, constraint, área, timing, potência e relatórios QoR. Retenha evidências não mapeadas/de elaboração e os hashes originais de RTL/SDC. A área da biblioteca tutorial está em unidades de biblioteca, não em um valor de micrômetro quadrado afirmado.
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 do 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 |
|---|---|---|
| RTL | analyze elaborate link check_design | Bibliotecas lógicas e fontes ordenadas devem resolver toda referência necessária. |
| Constraints | read_sdc check_timing report_clock | Inspecione definições de clock, todos os atrasos de interface, recovery/removal, exceções e endpoints não restritos. |
| Mapeamento | compile compile_ultra | Use compile -map_effort medium/high; compile_ultra precisa de sua licença de recurso e pré-requisitos de modo. |
| Inspeção | report_area report_timing report_power report_qor | Leia unidades, suposições de atividade e cobertura de caminho; potência é uma estimativa sem atividade apropriada. |
| Exportação | set_svf write_file write_sdc | Habilite SVF antes das transformações; emita netlist mapeada e checkpoint juntos. |
Tcl, inspeção e documentação
current_design; get_designs *; get_cells -hierarchical; get_clocks *; report_hierarchy; check_design; check_timing. Verifique sizeof_collection, não Tcl llength, para coleções Synopsys.
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 do comando. 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-compiler --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 comandos 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 comandos não suportados.
Parâmetros controlados e dependências
Esforço de mapeamento (medium/high), compilação incremental, seleções de buffer/célula permitidas pelo PDK, ênfase em área versus timing. compile_ultra -timing_high_effort_script e -area_high_effort_script são estratégias distintas; recupere restrições antes de combinar switches. Retime, mudanças de hierarquia e gating de clock alteram obrigações de verificação e exigem nova evidência de equivalência.
Área menor pode aumentar atraso e fanout. Configurações physical-aware/topographical exigem bibliotecas físicas e tecnologia RC; nunca as habilite apenas porque suas flags existem. Período de clock e budgets de interface permanecem fixos. Um netlist alterado invalida Formality e todos os checkpoints downstream.
Registre valores originais/propostos, a hipótese suportada pelo 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 ordem de fonte, defines, referências não resolvidas, seleção de biblioteca e restrições antes de ajustar. Revise latches inferidos e múltiplos drivers contra intenção funcional. Comandos não suportados precisam de documentação da versão instalada. Falhas de licença ou loader precisam de reparo no ambiente.
Capture o comando/status, logs internos, relatórios e identidade do 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 válido recebido e reexecute 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 timing, remova restrições necessárias ou ignore verificação para relatar sucesso. Pare quando nenhuma correção justificada restar ou um budget 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 contra o escopo solicitado. Para síntese/implementação, exija artefatos mapeados/linkados e restrições preservadas; comprove funcionalidade após transformações. Para verificação, exija cobertura completa e verificações necessárias limpas. Para simulação/debug, exija que a tarefa/teste pretendido seja concluído com diagnósticos revisados.
Mantenha validação de documentação, verificações de sintaxe Tcl, execução de ferramenta, aceitação de estágio e evidências de signoff ponta a ponta separadas. Um fluxo gerado não é uma implementação verificada. Veja contrato de execução e escopo de validação para os limites de evidência necessários.