TimeQuest для чайников. Часть 2 (TimeQuest лицом к лицу)

В предыдущей части мы рассмотрели самый простой проект для  ПЛИС, который только может быть. Перед тем как перейти к более сложным проектам надо освоить инструмент, о котором идет речь. Эта часть посвящена основам временного анализа с помощью TimeQuest.

TimeQuest это программа для проверки выполнения временных ограничений, заданных в sdc файле констрейнов. Вот тут возникает первое правило TimeQuest а:

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

Т.е. первое отличие от Classic TA  в том, что TimeQuest проверяет только те ограничения, которые вы задали. Поэтому при написании sdc файла внимательно читайте предупреждения, которые он вам выдает.

С TimeQuest можно работать в двух режимах: графическом и консольном. В консольном режиме все sdc команды вводятся в консоли, а результаты могут быть просмотрены как в консоли, так и в специальных окнах. Но фирма Альтера позаботилась о пользователях и снабдила TimeQuest ГУЙ интерфейсом, с помощью которого можно не зная полного синтаксиса sdc команд, работать с той же эффективностью. Это относиться не только к командам анализа, но и к командам задания самих констрейнов.

Итак собираем наш проект HelloWorld . Запускаем TimeQuest. Видим несколько окон.

В окне Getting Started мы видим подсказку:

   1. Tasks Pane - окно команд. В этом окне перечислены основные команды временного анализа.
   2. Report Pane - окно логов. В этом окне отображаются закладки отчетов о временном анализе.
   3. View Pane –окно отображения путей. В этом окне будут перечислены пути, которые использовались при анализе, а также отчеты об этих путях.
   4. Консоль

Временной анализ возможен только по уже существующему нетлисту. Для анализа нужно загрузить нетлист и соответствующий ему sdc файл. С помощью правой кнопки мыша загружаем их

Выполним анализ нашего проекта на пути, по которым констрейны не выполняются

В консоли мы видим, какие команды выполнялись и их результат.

    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

Разберем по полочкам, что все это значило. Для анализа TimeQuest применил загруженные в него констрейны к нетлисту (команда update_timing_netlist). Потом он обнаружил, что перечисленные констрейны, не позволяют ему достоверно проанализировать нетлист и выдал соответствующее предупреждение. Затем выполнил анализ путей, по которым констрейны не выполняются. Как мы видим таких путей нет (еще бы в таком то проекте на частоте 10МГц) и с этой точки зрения все хорошо.

Но надо вылечить предупреждение. Для этого нужно изменить файл констрейнов. Дописываем недостающую строку. Теперь файл hello.sdc выглядит так

    derive_clock_uncertainty

    create_clock -period 10MHz -name {clk} [get_ports {clk}]

    set_false_path -from [get_clocks {clk}] -to [get_ports {led}]

Нужно перезапустить временной анализ. В принципе можно заново выполнить команду Read SDC File, но в этом случае поверх уже существующих констрейнов будут прописаны новые. И может случиться переопределение/схлестывание констрейнов. Поэтому я рекомендую делать такие вещи через полный сброс и повторный запуск анализа. Делаем сброс

и запускаем анализ снова. В итоге нет ни предупреждения, ни ошибок.

В принципе не обязательно сбрасывать проект, наложить нужный констрейн можно и прямо с консоли или через меню constrains. Но для начинающих я рекомендую описанный выше способ. Также помните, что все констрейны вводимые через меню или консоль, не сохраняются в sdc файле до тех пор, пока вы не выполните команду Write SDC File. Но я обычно пишу sdc файл ручками и инициализирую анализ заново.

Теперь давайте немного сломаем наш проект. Поставим самый медленный сыклон 3 и в sdc файле напишем

    create_clock -period 300MHz -name {clk} [get_ports {clk}]

Результат анализа.

На сленге это называется что-то вроде «все в слаках»/«сплошные слаки». Т.е. запас (в данном случае по tsetup) выбран и его не хватает для работы на нужной частоте. В зависимости от того, что является источником slack его можно побороть либо констрейнами (это предмет следующих тем) либо изменением дизайна.

Для определения узкого места нужно посмотреть подробный временной отчет о пути.

Появилось окно подробного отчета о пути cnt[0]/cnt[31].

Во вкладке Data Path видно большое количество слоев логики между триггерами (если судить по вкладке Statistic 78% всей задержки), а во вкладке Waveform видно как именно выглядит нарушение tsetup.

Немного подумав причину нарушения легко обосновать. Мы уперлись в задержку цепей последовательного переноса на нашем счетчике. Другими словами счетчик не успевает считать. Вариантов решения тут два: взять более быструю ПЛИС или разбить 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

Вуаля, ошибок нет. Данный пример показательный, но достаточно простой. В более сложных случаях искать причину возникновения узкого места можно с помощью контекстно-вызываемых RTL/Techology Mapper Вьюверов.

По началу копаться в «мусоре» лютов и триггеров не привычно, но это дело опыта.