обмеження часу для схем синхронізатора шини


10

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

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

Дані генеруються за один годинник. Оновлення - це багато (принаймні десяток) країв годинника один від одного:

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;

Це компілюється та працює добре, коли синтезується в FPGA Cyclone II. Однак TimeQuest повідомляє про налаштування та утримує порушення часу, оскільки він не розпізнає синхронізатор. Гірше, йдеться в посібнику Quartus

Сфокусуйтесь на вдосконаленні шляхів, які показують найгірший слабкість. Fitter працює найважче на доріжках з найгіршим слабкістю. Якщо ви виправите ці шляхи, Fitter може змогти вдосконалити інші невдалі таймінг-контури в дизайні.

Тому я хочу додати правильні обмеження в моєму проекті, щоб Quartus витратив свої зусилля Fitter на інші сфери дизайну.

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

Я дуже вдячний деяким вказівкам щодо написання обмежень синхронізації SDC для синхронізаторів. Якщо ви бачите проблеми з таким підходом, будь ласка, повідомте мене про це.


Деталі годинника:

Зовнішній тактовий генератор: два канали, refclk = 20 МГц, refclk2 = refclk / 2 (10 МГц і пов'язані з ними).

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

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

У мене також є дані, що йдуть в іншому напрямку, з 100 MHz src_clk та 36 MHz dest_clk.


TL; DR: Які правильні обмеження часу SDC для вищевказаного коду?


1
Це було б краще на запропонованому веб-сайті FPGA Design, але ця пропозиція ще не досягла бета-версії.
Бен Войгт

Чи можете ви розмістити визначення годин для src_clk та dest_clk? Чи пов’язані вони між собою (синхронні кратні)? Якщо вони не пов'язані між собою, то в цій ситуації типово використовувати set_false_path.
Енді

@Andy: Я додав деякі деталі. Дякуємо, що допомогли у цьому.
Ben Voigt

Відповіді:


9

Я не маю досвіду роботи з 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. Частіше використовувати мульти-велосипедні доріжки з тісно пов’язаними годинниками (наприклад, взаємодіючі 1Х та 2Х годин), але це спрацює тут, якщо інструмент достатньо підтримує його.

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. Ці команди дозволяють ще один цикл тактової точки кінцевої точки ( -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щоб відключити чеки утримування, якщо ваш інструмент це підтримує.


Горі деталі вибору краю для багатоциклічних доріжок

Щоб зрозуміти коригування затримки, яке поєднується з кожним коригуванням налаштування, розглянемо цей простий приклад із співвідношенням 3: 2. Кожна цифра представляє зростаючий край годинника:

1     2     3
4   5   6   7

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

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

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


2

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

set_mulicycle_path не є правильним для використання, оскільки це, як правило, стосується випадків, коли і джерело, і місце призначення знаходяться на одному домені годинника. Знову ж таки, я базую це на своєму досвіді Xilinx, щоб ваш пробіг мінявся.


1

Я думаю, що безпечно покласти 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?
Ben Voigt

set_false_path -from src_clk -to ready_spinЯ не впевнений, що доречно поставити помилковий шлях на дані, оскільки ви їх не синхронізуєте.
fbo

0

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


Чи не set_multicycle_pathбуде способом сказати синтезатору / аналізатору синхронізації, як часто можуть змінюватися вихідні сигнали? І я не впевнений, що ви маєте на увазі під "годинником шини", тут сигнальна шина перетинає доменні годинники, тож який годинник ви називаєте "годинником шини"? Я думаю, ти маєш рацію, що метастабільність все-таки може бути, якщо синтезатор введе глюки в періоди, коли я не оновлююсь data. Напевно, я міг би спеціально створити блоки DFF там :(
Бен Войгт

@BenVoigt: Я думаю, що "set_multcycle_path" частіше використовується для того, щоб сказати валідатору часу, що ланцюгу комбінаторної логіки між двома точками фіксації слід дозволити приймати N (Tc) -Ts-Tp (N разів циклічного часу мінус час вибірки мінус засувка час поширення) замість просто Tc-Ts-Th. Я не знаю, як така річ взаємоділа б із засувкою різних годинників.
supercat
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.