Synopsys Design Constraint язык задания временных ограничений на примере Altera TimeQuest. Часть 1


Разработка устройств на базе ПЛИС - всегда борьба двух противоположных сторон: функциональности, заложенной разработчиком, и возможностей ПЛИС по ресурсу/производительности. Мерой оценки готовности устройства является его работоспособность во всем диапазоне условий, определенных техническим заданием на разработку.
Зачем нужно задание временных ограничений?
Есть два способа, которые используют разработчики для оценки работоспособности устройства на ПЛИС: натурные испытания и статический временной анализ (Static Timing Analysis, STA). Эти два способа отличаются кардинально. При натурных испытаниях каждое изделие должно быть проверено на работоспособность во всех наихудших случаях эксплуатации. При использовании STA можно без всяких испытаний и даже при отсутствии самого изделия проверить его работоспособность. Это возможно благодаря тому, что производители ПЛИС предоставляют библиотеки со всеми временными параметрами логических элементов в различных условиях. Поэтому оценить все временные ограничения можно аналитически, проверив все цепи в результирующем списке соединений (нетлисте) ПЛИС. Производители ПЛИС пошли еще дальше: все чаще они заявляют о поддержке технологии Timing Driven Synthesis для тех или иных ПЛИС. В этом случае при синтезе и разводке устройства на ПЛИС накладываемые на него временные ограничения влияют на результат синтеза, но не в ущерб временным ограничениям. Выбор способа оценки работоспособности зависит от разработчика. Кто-то не задает никаких ограничений и рассчитывает на авось и осциллограф, но автор предпочитает задать все временные ограничения и убедиться в работоспособности устройства, получив отчет об отсутствии нарушений заданных ограничений.Задание временных ограничений в Quartus
В свое время фирма Altera, чье программное обеспечение очень удобно в работе, создала инструмент под названием Timing Analyzer. Все было просто: задаем в Setting -> Timing Analyzer Settings тактовые частоты проекта и нажимаем кнопку Run для анализа. Но проекты становились все сложнее, частоты все выше, появились высокочастотные интерфейсы, многочастотные проекты, и возможностей Timing Analyzer стало не хватать. Нужен был более гибкий инструмент задания ограничений и их учета при синтезе, разводке и временном анализе проекта. Altera не стала изобретать велосипед и выбрала для этого Synopsys Design Constraint (SDC). Этот формат задания различных ограничений широко используется при разработке ASIC и представляет собой пакеты специальных команд на языке Tool Command Language (TCL). Этот язык, несмотря на все его недостатки, широко распространен среди производителей различных САПР, в том числе и в фирме Altera. Поэтому интеграция поддержки в Quartus формата SDC не составила труда. В результате этой интеграции и появилось программное обеспечение под названием TimeQuest. С этого момента в программном обеспечении фирмы Altera произошло разделение Timing Analyzer на Classic Timing Analyzer и TimeQuest Timing Analyzer. На текущий момент фирма Altera не рекомендует использовать Classic Timing Analyzer, потому как качество временного анализа и синтеза с ним хуже. Более того, для новых семейств ПЛИС (Aria II, Stratix IV/V) возможности выбора Classic Timing Analyzer просто нет. Для разработчиков, привыкших ра - ботать в Classic Timing Analyzer, переход на TimeQuest труден. Нужно понимать последовательность и необходимость задания тех или иных ограничений, помнить форматы SDC-команд, уметь пользоваться оболочкой TimeQuest для эффективной работы. Часто начинающие пользователи TimeQuest делают типовые ошибки, которые приводят их к ложной уверенности, что все временные ограничения выполняются. В результате попытка освоения TimeQuest заканчивается неудачей, и его дальнейшее использование, совершенно напрасно, откладывается на неопределенный срок. Этот цикл статей предназначен для тех, кто только начинает работать с TimeQuest. Автор не ставит перед собой цели перевода документации TimeQuest, вместо этого он предлагает осваивать его на практических примерах. Мы рассмотрим примеры задания временных ограничений для типовых проектов с комментариями и пояснениями. Каждый пример содержит тестовый код на языке SystemVerilog (при проверке примеров не забывайте включать его поддержку) и соответствующий ему SDC-файл. Все примеры выполнены в Quartus 9.0sp2. В качестве целевой платформы использовалась ПЛИС EP3C5E144C8 семейства Cyclone III. Итак, начнем с азов.Задание временных ограничений на примере проекта счетчика
Временные ограничения для TimeQuest пишутся в файле с расширением *.sdc. Этот файл представляет собой TCL-скрипт, в котором временные ограничения задаются с помощью специальных команд. Рассмотрим аналог проекта HelloWorld для ПЛИС:module hello (input clk, output led) ; |
||
logic (31 : 0) cnt; always_ff @(posedge clk) begin |
||
cnt <= cnt + 1'b1; led <= cnt(31); |
||
end | ||
endmodule |
create_clock -period 10MHz -name {clk} (get_ports {clk}) |
-
Указав в качестве источника регистр led:
set_false_path -from (get_registers {led*}) -to (get_ports {led}) |
set_false_path -from (get_clocks {clk}) -to (get_ports {led}) |
set_false_path -from (all_clocks) -to (get_ports {led}) |
Введение в основы временного анализа с помощью TimeQuest
TimeQuest - это программа для проверки выполнения временных ограничений, описанных в файле *.sdc. Тут следует упомянуть первое правило TimeQuest, которое нужно учитывать при работе: если TimeQuest рапортует вам об отсутствии ошибок, то не надо заранее полагать, что все хорошо. Может быть, вы просто не задали часть временных ограничений. Таким образом, главное отличие от Classic Timing Analyzer в том, что TimeQuest проверяет только те ограничения, которые вы задали. Поэтому при разработке файла *.sdc внимательно читайте предупреждения, которые он вам выдает, и обязательно проверьте, все ли временные ограничения вы задали. С TimeQuest можно работать в двух режимах: графическом и консольном. В консольном режиме все команды временного анализа и задания временных ограничений вводятся в консоли, а результаты могут быть просмотрены как в консоли, так и в специальных окнах. Но фирма Altera позаботилась о пользователях и снабдила TimeQuest неплохим графическим интерфейсом (GUI), с помощью которого можно, не зная полного синтаксиса sdc-команд, работать с той же эффективностью. Это относится не только к командам анализа, но и к командам задания самих временных ограничений.
Рис. 1. Состояние TimeQuest Timing Analyzer после запуска
-
Tasks Pane - окно команд. В этом окне перечислены основные команды временного
анализа.
Report Pane - окно отчетов. В этом
окне отображаются закладки отчетов временного анализа.
View Pane - окно отображения путей.
В этом окне будут перечислены пути, которые использовались при анализе, а также
отчеты об этих путях.
Консоль.

Рис. 2. Загрузка списка соединений и соответствующего ему sdc-файла

Рис. 3. Запуск анализа всех цепей на выполнение временных ограничений
Info: Reading SDC File: 'hello.sdc' update_timing_netlist Critical Warning: The following clock transfers have no clock uncertainty assignment. For more accurate results, apply clock uncertainty assignments or use the derive_clock_uncertainty command. Critical Warning: From clk (Rise) to clk (Rise) (setup and hold) qsta_utility::generate_top_failures_per_clock "Top Failing Paths" 200 Info: No fmax paths to report Info: No fmax paths to report Info: No failing paths found |
derive_clock_uncertainty create_clock -period 10MHz -name {clk} (get_ports {clk}) set_false_path -from (get_clocks {clk}) -to (get_ports {led}) |

Рис. 4. Сброс результатов временного анализа
Info: Reading SDC File: 'hello.sdc' Info: Clock uncertainty calculation is delayed until the next update_ timing_netlist call. update_timing_netlist Info: Deriving Clock Uncertainty |
|
Info: set_clock_uncertainty -rise_from (get_clocks {clk}) -rise_to (get_clocks {clk}) -setup 0.020 Info: set_clock_uncertainty -rise_from (get_clocks {clk}) -fall_to (get_clocks {clk}) -setup 0.020 Info: set_clock_uncertainty -fall_from (get_clocks {clk}) -rise_to (get_clocks {clk}) -setup 0.020 Info: set_clock_uncertainty -fall_from (get_clocks {clk}) -fall_to (get_clocks {clk}) -setup 0.020 Info: set_clock_uncertainty -rise_from (get_clocks {clk}) -rise_to (get_clocks {clk}) -hold 0.020 Info: set_clock_uncertainty -rise_from (get_clocks {clk}) -fall_to (get_clocks {clk}) -hold 0.020 Info: set_clock_uncertainty -fall_from (get_clocks {clk}) -rise_to (get_clocks {clk}) -hold 0.020 Info: set_clock_uncertainty -fall_from (get_clocks {clk}) -fall_to (get_clocks {clk}) -hold 0.020 |
|
qsta_utility::generate_top_failures_per_clock "Top Failing Paths" 200 Info: No fmax paths to report Info: No fmax paths to report Info: No failing paths found |
create_clock -period 300MHz -name {clk} (get_ports {clk}) |

Рис. 5. Результат временного анализа проекта HelloWorld для тактовой частоты 300 МГц

Рис. 6. Запуск генерации подробного отчета об анализе пути

Рис. 7. Результат генерации подробного отчета об анализе пути данных между регистрами cnt(0) и cnt(31)
Введение в основы временного анализа синхронных схем
Для того чтобы понять, как правильно читать отчеты TimeQuest, нужно знать, как проводится временной анализ и какими временными параметрами описываются триггеры. У триггера есть три основных параметра, определяющие его временные характеристики:-
Tsetup (tsu) - время предустановки данных (время, в течение которого данные
на входе триггера должны быть неизменны
до фронта тактовой частоты).
Thold (th) - время удержания данных
(время, в течение которого данные на входе триггера должны быть неизменны после
фронта тактовой частоты).
Tclock-to-out (tco) - время появления
данных на выходе триггера после фронта
тактовой частоты.

Рис. 8. Фронты тактового сигнала, используемые для временного анализа одноцикловых синхронных путей

Рис. 9. Отчет об анализе пути данных между регистрами cnt(0) и cnt(31) на выполнение условий по tsu

Рис. 10. Отчет об анализе пути данных между регистрами cnt (0) и cnt (31) на выполнение условий по th
-
Data Arrival - это реальное время прибытия
данных от триггера-источника до триггераприемника. На рис. 9 видно, что это время
состоит из двух компонентов: Clock Delay =
2,725 нс и Data Delay = 4,108 нс и рассчитывается относительно Setup Launch Edge.
Clock Delay - это задержка сигнала тактовой
частоты от порта ПЛИС до тактового входа
триггера cnt(0). Data Delay - это задержка
сигнала с выхода триггера cnt(0) до входа
триггера cnt(31), в эту задержку входит tco
триггера-источника и задержка комбинационной и трассировочной логики.
Data Required - это требуемое время
прибытия данных от триггера-источника
до триггера-приемника. На рис. 10 видно, что это время состоит из Clock Delay =
2,629 нс, Clock Uncertainty = 0,020 нс и tsu =
0,021 нс триггера-приемника и считается
относительно Setup Latch Edge (со сдвигом
на период тактовой частоты для одноцикловых путей). При этом обратите внимание
на знаки, с которыми входят те или иные
значения в расчет требуемого времени.
-
Data Arrival считается относительно Hold
Launch Edge и состоит из Clock Delay
= 2,628 нс и Data Delay = 3,621 нс.
Data Required считается относительно
Hold Latch Edge и состоит из Clock Delay
= 2,725 нс, Clock Uncertainty = 0,020 нс
и th = 0,212 нс триггера-приемника.
Выполнение временных ограничений проекта со счетчиком
Вернемся к нашему проекту со счетчиком. Во вкладке Data Path (рис. 9) отчета о временном анализе видно большое количество слоев логики между триггерами (если судить по вкладке Statistic, это 78% всей задержки). В этом случае причина нарушения легко определяется. Это задержка цепей последовательного переноса на счетчике. Другими словами, счетчик не успевает считать. Есть два варианта обеспечить выполнение требуемых временных ограничений:-
Уменьшить время Data Arrival. Это можно сделать, взяв более быструю ПЛИС
или разбив 32-битный счетчик, например,
на два 16-битных с конвейеризированным
переносом между ними.
Увеличить время Data Required для некоторых триггеров. Это можно сделать
с помощью дополнительного тактового
сигнала, сдвинутого по фазе с помощью
PLL, или непосредственно задержав сигнал
тактовой частоты на логике. В этом случае будет больший перекос между битами
счетчика, но для проекта hello это не критично.
Уменьшение времени Data Arrival
Разобьем 32-битный счетчик на два 16-битных счетчика с конвейеризированным переносом между ними:module hello (input clk, output led) ; |
||||
logic (15 : 0) | cnt_low, cnt_high; | |||
logic |
cnt_low_done; |
|||
always_ff @(posedge clk) begin | ||||
cnt_low | <= cnt_low + 1'b1; | |||
cnt_low_done | <= (cnt_low == 16'hFFFE); | |||
if (cnt_low_done) |
||||
cnt_high <= cnt_high + 1'b1; | ||||
led <= cnt_high(15); | ||||
end | ||||
endmodule |

Рис. 11. Отчет об анализе пути данных между регистрами cnt(0) и cnt(31) на выполнение условий по tsu после конвейеризации модуля
Увеличение времени Data Required
Разобьем триггеры 32-битного счетчика на два 16-битных регистра. Один из регистров будем тактировать от сигнала тактовой частоты, а второй - от этого же сигнала, но пропущенного через дополнительный LUT:module hello (input clk, output led); |
||
logic clk_delay; lcell lcell (clk, clk_delay); logic (31 : 0) cnt, cnt_next; assign cnt_next = cnt + 1'b1; always_ff @(posedge clk) begin |
||
cnt(15 : 0) <= cnt_next(15 : 0); | ||
end always_ff @(posedge clk_delay) begin |
||
cnt(31 : 16) <= cnt_next(31:16); led <= cnt(31); |
||
end | ||
endmodule |

Рис. 12. Отчет об анализе пути данных между регистрами cnt(0) и cnt(31) на выполнение условий по tsu после введения дополнительной фазы тактовой частоты
Заключение
Мы рассмотрели самый простой проект для ПЛИС и работу с временными ограничениями для этого проекта. Причина нарушения временных ограничений в этом проекте была очевидна, но в более сложных случаях искать причину возникновения «узкого места» можно с помощью контекстно-вызываемых RTL/Techology Mapper Viewer (рис. 13). Благодаря возможности контекстного вызова различных Viewer, TimeQuest является простым, но в то же время мощным и удобным инструментом для анализа проекта.
Рис. 13. Вызов различных Viewer для просмотра информации о конкретном пути
Литература
-
Quartus II Handbook Version 9.0 -
/literature/lit-qts.jsp
SDC and TimeQuest API Reference Manual -
/literature/manual/mnl_sdctmq.pdf
Quartus II TimeQuest Timing Analyzer
Cookbook - /literature/manual/mnl_timequest_cookbook.pdf
/blog/des00

