Ograniczenia czasowe ASIC przez SDC: Jak poprawnie określić zegar multipleksowany?

Wprowadzenie

Po znalezieniu wielu, czasem sprzecznych lub niekompletnych informacji w Internecie i na niektórych zajęciach szkoleniowych dotyczących prawidłowego tworzenia ograniczeń czasowych w formacie SDC , chciałbym poprosić społeczność EE o pomoc w niektórych ogólnych strukturach generowania zegara, z którymi się spotkałem.

Wiem, że istnieją różnice w tym, jak można zaimplementować określoną funkcjonalność na ASIC lub FPGA (pracowałem z obydwoma), ale uważam, że powinien istnieć ogólny, prawidłowy sposób ograniczenia taktowania danej struktury , niezależnie od technologia bazowa - daj mi znać, jeśli się mylę.

Istnieją również pewne różnice między różnymi narzędziami do implementacji i analizy czasowej różnych dostawców (pomimo, że Synopsys oferuje kod źródłowy parsera SDC), ale mam nadzieję, że są to głównie problemy ze składnią, które można sprawdzić w dokumentacji.

Pytanie

Chodzi o następującą strukturę multipleksera zegarowego, która jest częścią modułu clkgen , który ponownie stanowi część większego projektu:

Podczas gdy ext_clkzakłada się, że dane wejściowe są generowane zewnętrznie w projekcie (wejście przez pin wejściowy), sygnały clk0i clk4są również generowane i wykorzystywane przez moduł clkgen (zobacz moje powiązane pytanie dotyczące tętnienia zegara, aby uzyskać szczegółowe informacje) i mają powiązane ograniczenia zegarowe o nazwach baseclki div4clk, odpowiednio.

Pytanie brzmi, jak określić ograniczenia, takie jak analizator synchronizacji

1. Traktuje się cpu_clkjak zegar zwielokrotniony, który może być jednym z zegarów źródłowych ( fast_clklub slow_clklub ext_clk), biorąc pod uwagę opóźnienia przez różne bramki AND i OR
2. Jednocześnie nie przecinając ścieżek między zegarami źródłowymi, które są używane gdzie indziej w projekcie.

Podczas gdy najprostszy przypadek multipleksera zegarowego na chipie wydaje się wymagać tylko instrukcji set_clock_groupsSDC :

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

... w danej strukturze komplikuje to fakt, że clk0(poprzez dane fast_clkwyjściowe) i clk4(przez slow_clk) są nadal używane w projekcie, nawet jeśli cpu_clkjest skonfigurowane tak, aby było ext_clktylko use_extzapewnione.

Jak opisano tutaj , set_clock_groupspolecenie jak wyżej spowoduje następujące:

To polecenie jest równoważne z wywołaniem set_false_path z każdego zegara w każdej grupie do każdego zegara w każdej innej grupie i odwrotnie

... co byłoby niepoprawne, ponieważ inne zegary są nadal używane gdzie indziej.

Dodatkowe informacje

Te use_clk0, use_clk4i use_extwejścia są generowane w taki sposób, że tylko jedna z nich jest wysoki w danym momencie. Chociaż można tego użyć do zatrzymania wszystkich zegarów, jeśli wszystkie use_*sygnały wejściowe są niskie, to pytanie skupia się na właściwości multipleksowania zegara tej struktury.

X2 przykład (prosty bufor) na schemacie jest miejscem uchwyt podkreślić problem automaty miejsce i trasa narzędzia jest zwykle wolny miejsce gdziekolwiek bufory (takie jak pomiędzy and_cpu_1/zi or_cpu1/in2PIN). Najlepiej byłoby, gdyby na ograniczenia czasowe nie miało to wpływu.

Zdefiniuj podział przez 1 zegary w sieciach and_ * i zadeklaruj je jako fizycznie wykluczające się. Kompilator Cadence RTL poprawnie radzi sobie z sytuacją, generując 3 ścieżki czasowe dla rejestrów taktowanych przez cpu_clk (jedna ścieżka dla jednego zegara). Rejestry sterowane bezpośrednio przez clk0, clk4 i clk_ext mają własne łuki czasowe.

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]

Chociaż jest to stary wątek bez odpowiedzi ... obejmuje kilka podstawowych pojęć dotyczących synchronizacji i zegarów asynchronicznych

• Zasadniczo zegary synchroniczne muszą pozostać zsynchronizowane w fazie z minimalnymi opóźnieniami, aby Mux'ing nie spowodował usterki.
  • Często osiąga się to przez ponowne próbkowanie wszystkich bramkowanych źródeł zegara przy pełnej prędkości zegara.
• Zegary asynchroniczne nie są krytyczne dla taktowania, więc opóźnienia są dozwolone. takie jak liczniki tętnienia.