Restrições de tempo ASIC via SDC: Como especificar corretamente um relógio multiplexado?

Introdução

Tendo encontrado várias informações, às vezes conflitantes ou incompletas, na Internet e em algumas aulas de treinamento sobre como criar restrições de tempo no formato SDC corretamente, gostaria de pedir à comunidade de EE ajuda com algumas estruturas gerais de geração de relógio que encontrei.

Eu sei que existem diferenças em como alguém implementaria uma certa funcionalidade em um ASIC ou FPGA (trabalhei com ambos), mas acho que deve haver uma maneira geral e correta de restringir o tempo de uma determinada estrutura , independentemente da tecnologia subjacente - informe-me se eu estiver errado.

Também existem algumas diferenças entre diferentes ferramentas para implementação e análise de tempo de diferentes fornecedores (apesar da Synopsys oferecer um código-fonte do analisador SDC), mas espero que sejam principalmente um problema de sintaxe que pode ser consultado na documentação.

Questão

Trata-se da seguinte estrutura do multiplexador de clock, que faz parte do módulo clkgen , que novamente faz parte de um design maior:

Embora se ext_clkpresuma que a entrada seja gerada externamente ao design (entrando através de um pino de entrada), os sinais clk0e clk4também são gerados e usados ​​pelo módulo clkgen (consulte minha pergunta relacionada ao relógio de ondulação para obter detalhes) e têm restrições de relógio associadas nomeadas baseclke div4clk, respectivamente.

A questão é como especificar as restrições para que o analisador de temporização

1. Trata cpu_clkcomo um relógio multiplexado que pode ser um dos relógios de origem ( fast_clkou slow_clkou ext_clk), tendo os atrasos através das diferentes portas AND e OR em conta
2. Ao mesmo tempo, não corta os caminhos entre os relógios de origem que são usados ​​em outras partes do design.

Embora o caso mais simples de um multiplexador de clock no chip pareça exigir apenas a set_clock_groupsinstrução SDC :

set_clock_groups -logically_exclusive -group {baseclk} -group {div4clk} -group {ext_clk}

... na estrutura fornecida, isso é complicado pelo fato de que clk0(via fast_clksaída) e clk4(via slow_clk) ainda são usados ​​no design, mesmo se cpu_clkestiver configurado para ser ext_clkquando somente use_extfor declarado.

Conforme descrito aqui , o set_clock_groupscomando como acima causaria o seguinte:

Este comando é equivalente a chamar set_false_path de cada relógio em cada grupo para cada relógio em qualquer outro grupo e vice-versa

... o que seria incorreto, pois os outros relógios ainda são usados ​​em outros lugares.

informação adicional

Os use_clk0, use_clk4e use_extentradas são geradas de tal maneira que apenas um deles é alta em qualquer momento dado. Embora isso possa ser usado para parar todos os relógios se todas as use_*entradas forem baixas, o foco desta questão está na propriedade de multiplexação de clock dessa estrutura.

A instância X2 (um buffer simples) no esquema é apenas um espaço reservado para destacar o problema das ferramentas automáticas de localização e rota, geralmente livres para colocar buffers em qualquer lugar (como entre os pinos and_cpu_1/ze or_cpu1/in2). Idealmente, as restrições de tempo não devem ser afetadas por isso.

Defina a divisão por 1 relógio nas redes e_ * e declare-as como fisicamente exclusivas. O compilador Cadence RTL lida com a situação corretamente, gerando três caminhos de tempo para registros com registro de clock por cpu_clk (um caminho cada para um relógio). Registros acionados diretamente por clk0, clk4 e clk_ext têm seus próprios arcos de tempo.

create_generated_clock -source [get_ports clk0] \
-divide_by 1 -name and_clk0    [get_pins and_cpu_1/Y]

create_generated_clock -source [get_ports clk4] \
-divide_by 1 -name and_clk4    [get_pins and_cpu_2/Y]

create_generated_clock -source [get_ports clk_ext] \
-divide_by 1 -name and_clk_ext [get_pins and_cpu_ext1/Y]

set_clock_groups \
-physically_exclusive \
-group [get_clocks and_clk0] \
-group [get_clocks and_clk4] \
-group [get_clocks and_clk_ext]

Embora este seja um thread antigo sem resposta ... ele abrange alguns entendimentos básicos de relógios sync vs async

• Basicamente, os relógios síncronos devem permanecer sincronizados em fase, com atrasos mínimos adicionados, para que o Mux'ing não crie uma falha.
  • Isso geralmente é realizado re-amostrando todas as fontes de relógio bloqueadas no relógio de velocidade máxima.
• Relógios assíncronos não são críticos para o tempo, portanto, atrasos são permitidos. como Contadores de Ondulações.