ограничение по времени для цепей синхронизатора шины

У меня есть схема синхронизатора шины для передачи широкого регистра через домены часов.

Я приведу упрощенное описание, исключая логику асинхронного сброса.

Данные генерируются за один час. Обновления имеют много (по крайней мере дюжину) угловых точек:

PROCESS (src_clk)
BEGIN
   IF RISING_EDGE(clock) THEN
      IF computation_done THEN
          data <= computation;
          ready_spin <= NOT ready_spin;
      END IF;
   END IF;
END PROCESS;

Управляющий сигнал для свежих данных, который кодируется NRZI (поэтому действительное слово на шине соответствует переходу на управляющем сигнале). Управляющий сигнал проходит через цепь DFF, действующую как синхронизатор.

PROCESS (dest_clk)
BEGIN
   IF RISING_EDGE(dest_clk) THEN
      ready_spin_q3 <= ready_spin_q2;
      ready_spin_q2 <= ready_spin_q1;
      ready_spin_q1 <= ready_spin;
   END IF;
END PROCESS;

Схема синхронизатора вводит небольшую задержку, которая обеспечивает достаточно времени для стабилизации шины данных; Шина данных отбирается напрямую без риска метастабильности:

PROCESS (dest_clk)
BEGIN
   IF RISING_EDGE(dest_clk) THEN
      IF ready_spin_q3 /= ready_spin_q2 THEN
         rx_data <= data;
      END IF;
   END IF;
END PROCESS;

Это компилируется и хорошо работает при синтезе в Cyclone II FPGA. Однако TimeQuest сообщает о нарушениях настройки и времени удержания, поскольку не распознает синхронизатор. Что еще хуже, руководство Quartus говорит

Сосредоточьтесь на улучшении путей, которые показывают худший провал. Монтажник больше всего работает на трассах с наихудшим провалом. Если вы исправите эти пути, монтажник сможет улучшить другие ошибочные пути синхронизации в проекте.

Поэтому я хочу добавить правильные временные ограничения в мой проект, чтобы Quartus потратил свои усилия Fitter на другие области дизайна.

Я почти уверен, что set_multicycle_pathэто правильная команда SDC (Synopsis Design Constraint), поскольку строки данных будут иметь несколько циклов такта назначения для стабилизации, но я не могу найти полных примеров использования этой команды для описания логики пересечения области часов ,

Я был бы очень признателен за рекомендации по написанию временных ограничений SDC для синхронизаторов. Если вы видите проблему с этим подходом, пожалуйста, дайте мне знать об этом.

Деталь часов:

Внешний генератор тактовых импульсов: два канала, refclk = 20 МГц, refclk2 = refclk / 2 (10 МГц и другие).

PLL Altera: src_clk = refclk * 9/5 = 36 МГц

PLL Altera: dest_clk = refclk2 * 10 = 100 МГц

У меня также есть данные, идущие в другом направлении: 100 МГц src_clk и 36 МГц dest_clk.

TL; DR: Каковы корректные временные ограничения SDC для приведенного выше кода?

У меня нет опыта работы с Quartus, поэтому относитесь к этому как к общему совету.

При работе с путями между доменами часов инструменты синхронизации расширяют часы до наименьшего общего кратного их периодов и выбирают ближайшую пару ребер.

Для трактов с тактовой частотой 36 МГц (27,777 нс) до тактовой частоты 100 МГц (10 нс), если я правильно выполнил свои быстрые вычисления, ближайшая пара нарастающих фронтов составляет 138,888 нс на тактовой частоте источника и 140 нс на тактовой частоте назначения. Это фактически ограничение 900 МГц для этих путей! В зависимости от округления (или для часов без отношения), может получиться хуже.

Существует как минимум три способа написания ограничений для этой структуры. Я собираюсь назвать часы, fast_clkи, slow_clkкак мне кажется, это понятнее для иллюстрации.

Вариант 1: отключить синхронизацию с set_false_path

Самое простое решение - использовать set_false_pathдля отключения синхронизации между часами:

set_false_path -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_false_path -from [get_clocks slow_clk] -to [get_clocks fast_clk]

Это не совсем правильно, так как для корректной работы синхронизатора существуют требования к времени. Если физическая реализация слишком сильно задерживает данные относительно управляющего сигнала, то синхронизатор не будет работать. Однако, поскольку на пути нет никакой логики, маловероятно, что ограничение по времени будет нарушено. set_false_pathОбычно используется для такой структуры, даже в ASIC, где соотношение усилий и риска для отказов с низкой вероятностью является более осторожным, чем для FPGA.

Вариант 2: ослабьте ограничение с помощью set_multicycle_path

Вы можете выделить дополнительное время для определенных путей с помощью set_multicycle_path. Более распространено использование многоцикловых путей с близко связанными часами (например, взаимодействующие часы 1X и 2X), но это будет работать здесь, если инструмент поддерживает его в достаточной степени.

set_multicycle_path 2 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -setup
set_multicycle_path 1 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -hold

Отношения края по умолчанию для установки является один цикл, то есть set_multicycle_path 1. Эти команды допускают еще один цикл конечной точки clock ( -end) для путей установки. -holdРегулировка с номером один меньше , чем ограничение установки почти всегда необходимо при установке мульти велодорожки, подробнее см ниже.

Чтобы аналогичным образом ограничить пути в другом направлении (ослабление ограничения на один период более быстрых часов), измените -endна -start:

set_multicycle_path 2 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -setup
set_multicycle_path 1 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -hold

Вариант 3: указать требование непосредственно с set_max_delay

Это похоже на эффект, set_multicycle_pathно избавляет от необходимости продумывать отношения ребер и влияние на ограничения удержания.

set_max_delay 10 -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_max_delay 10 -from [get_clocks slow_clk] -to [get_clocks fast_clk]

Вы можете связать это с set_min_delayпроверками удержания или оставить проверку удержания по умолчанию на месте. Вы также можете set_false_path -holdотключить удержание чеков, если ваш инструмент поддерживает это.

Gory детали выбора ребер для многоцикловых путей

Чтобы понять настройку удержания, которая связана с каждой настройкой настройки, рассмотрим этот простой пример с соотношением 3: 2. Каждая цифра представляет восходящий фронт тактовой частоты:

1     2     3
4   5   6   7

Проверка установки по умолчанию использует ребра 2 и 6. Проверка удержания по умолчанию использует ребра 1 и 4.

Применение многоциклового ограничения 2 с -endнастройками по умолчанию устанавливает и удерживает проверки для использования следующего ребра после того, что они первоначально использовали, то есть проверка установки теперь использует ребра 2 и 7, а проверка удержания использует ребра 1 и 5. Для двух тактирование на той же частоте, эта настройка имеет смысл - каждый запуск данных соответствует одному захвату данных, и если край захвата смещен на один, проверка удержания также должна сместиться на один. Такое ограничение может иметь смысл для двух ветвей одного такта, если одна из ветвей имеет большую задержку. Тем не менее, для этой ситуации нежелательная проверка с использованием ребер 1 и 5 нежелательна, поскольку единственный способ исправить это - добавить полный тактовый цикл задержки на пути.

Ограничение многоциклового удержания, равное 1 (для удержания, по умолчанию - 0), настраивает край целевого времени uesd для проверок удержания назад на один край. Сочетание ограничений 2-тактовой настройки MCP и 1-циклического удержания MCP приведет к проверке настройки с использованием ребер 2 и 7 и проверке удержания с использованием ребер 1 и 4.

Я не знаю ответа для Altera, но в Xilinx Land вы можете установить временную задержку от одного часового домена до следующего. Вам придется выработать математику (это зависит от дизайна), но обычно это самый короткий из двух тактов. Думайте об этом времени как о максимальном перекосе между любыми двумя сигналами (включая ваш управляющий сигнал), и вы можете решить, сможет ли ваша схема синхронизации справиться с этим.

set_mulicycle_path не является правильным для использования, потому что это обычно имеет дело со случаями, когда и источник, и пункт назначения находятся в одном и том же часовом домене. Опять же, я основываюсь на своем опыте с Xilinx, поэтому ваш пробег может отличаться.

Я думаю, что безопасно поставить set_false_path поверх синхронизатора.

Также вы можете поместить "set_global_assignment -name SYNCHRONIZER_IDENTIFICATION AUTO" в qsf, чтобы помочь Quartus определить синхронизатор.

Я подозреваю, что проблема в том, что, хотя вы, возможно, знаете, что сигналы шины не изменятся где-либо рядом с точкой, в которой они зафиксированы, программное обеспечение этого не знает. Лучше всего, вероятно, сообщить программному обеспечению явно, что входящие сигналы шины синхронизируются с часами шины, и отключить любые оптимизации заранее, в месте, где вы их фактически фиксируете (оптимизатор теоретически может заменить вашу схему такой, которая была бы эквивалентна если бы входы действительно были синхронными, но которые могли бы быть выброшены для цикла, если они меняются на тактах, которые схема, которую вы нарисовали, не заботила бы).