У меня есть схема синхронизатора шины для передачи широкого регистра через домены часов.
Я приведу упрощенное описание, исключая логику асинхронного сброса.
Данные генерируются за один час. Обновления имеют много (по крайней мере дюжину) угловых точек:
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
Обычно используется для такой структуры, даже в ASIC, где соотношение усилий и риска для отказов с низкой вероятностью является более осторожным, чем для FPGA.Вариант 2: ослабьте ограничение с помощью
set_multicycle_path
Вы можете выделить дополнительное время для определенных путей с помощью
set_multicycle_path
. Более распространено использование многоцикловых путей с близко связанными часами (например, взаимодействующие часы 1X и 2X), но это будет работать здесь, если инструмент поддерживает его в достаточной степени.Отношения края по умолчанию для установки является один цикл, то есть
set_multicycle_path 1
. Эти команды допускают еще один цикл конечной точки clock (-end
) для путей установки.-hold
Регулировка с номером один меньше , чем ограничение установки почти всегда необходимо при установке мульти велодорожки, подробнее см ниже.Чтобы аналогичным образом ограничить пути в другом направлении (ослабление ограничения на один период более быстрых часов), измените
-end
на-start
:Вариант 3: указать требование непосредственно с
set_max_delay
Это похоже на эффект,
set_multicycle_path
но избавляет от необходимости продумывать отношения ребер и влияние на ограничения удержания.Вы можете связать это с
set_min_delay
проверками удержания или оставить проверку удержания по умолчанию на месте. Вы также можетеset_false_path -hold
отключить удержание чеков, если ваш инструмент поддерживает это.Gory детали выбора ребер для многоцикловых путей
Чтобы понять настройку удержания, которая связана с каждой настройкой настройки, рассмотрим этот простой пример с соотношением 3: 2. Каждая цифра представляет восходящий фронт тактовой частоты:
Проверка установки по умолчанию использует ребра 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 определить синхронизатор.
источник
set_false_path -from ready_spin -to ready_spin_q2
? Аset_false_path -from data -to rx_data
?set_false_path -from src_clk -to ready_spin
Я не уверен, что уместно указывать ложный путь к данным, поскольку вы не синхронизируете его.Я подозреваю, что проблема в том, что, хотя вы, возможно, знаете, что сигналы шины не изменятся где-либо рядом с точкой, в которой они зафиксированы, программное обеспечение этого не знает. Лучше всего, вероятно, сообщить программному обеспечению явно, что входящие сигналы шины синхронизируются с часами шины, и отключить любые оптимизации заранее, в месте, где вы их фактически фиксируете (оптимизатор теоретически может заменить вашу схему такой, которая была бы эквивалентна если бы входы действительно были синхронными, но которые могли бы быть выброшены для цикла, если они меняются на тактах, которые схема, которую вы нарисовали, не заботила бы).
источник
set_multicycle_path
бы способом сказать синтезатору / анализатору времени, как часто сигналы источника могут меняться? И я не уверен, что вы имеете в виду под «автобусными часами», здесь есть сигнальная шина, пересекающая домены часов, так какие часы вы называете «автобусными часами»? Я думаю, вы правы, что метастабильность все еще может быть, если синтезатор вводит глюки во время периодов, когда я не обновляюсьdata
. Я думаю, что я мог бы специально создать там экземпляры блоков DFF :(