Документация

Сообщите о отказах во времени как предупреждениях

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

После устранения отказов синхронизации, чтобы убедиться, что отказы были устранены, можно использовать программное обеспечение HDL Coder. Измените отказы синхронизации, которые будут сообщены как ошибки, и повторите IP Core Generation рабочий процесс, чтобы убедиться, что Build FPGA Bitstream задача прошла. Если задача Build FPGA Bitstream все еще не выполнена, выполните шаги, описанные в предыдущих разделах, чтобы идентифицировать и устранить отказы синхронизации.

Чтобы указать отказы синхронизации, которые будут сообщаться как предупреждения:

Чтобы узнать, как идентифицировать критический путь и устранить отказы в синхронизации, выполните шаги, указанные в предыдущих разделах.

Стратегия 1: Проверьте отчет о времени

В подпанели Result, чтобы открыть отчет о времени, который генерируется инструментом синтеза, выберите timing_report ссылку. Можно использовать отчет для определения критического пути в проекте. В отчете, если вы ищете Worst Slackможно идентифицировать наихудшее слабое место настройки. Затем используйте Source и Destination указывает, чтобы идентифицировать критический путь. Для примера этот отчет для модели мигания светодиода hdlcoder_led_blinking показывает, что критический путь находится внутри блока HDL Counter.

-----------------------------------------------------------------------------------------
From Clock:  clk_out1_system_top_clk_wiz_0_0
  To Clock:  clk_out1_system_top_clk_wiz_0_0

Setup :   1193  Failing Endpoints,  Worst Slack   -2.478ns,  Total Violation  -1226.784ns
Hold  :      0  Failing Endpoints,  Worst Slack    0.034ns,  Total Violation      0.000ns
PW    :      2  Failing Endpoints,  Worst Slack   -0.576ns,  Total Violation     -0.731ns
-----------------------------------------------------------------------------------------

Max Delay Paths
-----------------------------------------------------------------------------------------
Slack (VIOLATED) : -2.478ns  (required time - arrival time)
  Source:     system_top_i/led_count_ip_0/U0/u_led_count_ip_dut_inst/
                   u_led_count_ip_src_led_counter/HDL_Counter1_out1_reg[0]/C
              (rising edge-triggered cell FDRE clocked by clk_out1_system_top_clk_wiz_0_0  
                                               {rise@0.000ns fall@1.000ns period=2.000ns})
 Destination:  system_top_i/led_count_ip_0/U0/u_led_count_ip_dut_inst/
                    u_led_count_ip_src_led_counter/HDL_Counter1_out1_reg[20]/R
               (rising edge-triggered cell FDRE clocked by clk_out1_system_top_clk_wiz_0_0  
                                                {rise@0.000ns fall@1.000ns period=2.000ns})
  Path Group:       clk_out1_system_top_clk_wiz_0_0
  Path Type:        Setup (Max at Slow Process Corner)
  Requirement:      2.000ns  (clk_out1_system_top_clk_wiz_0_0 rise@2.000ns - 
                                            clk_out1_system_top_clk_wiz_0_0 rise@0.000ns)
  Data Path Delay:  3.899ns  (logic 1.412ns (36.211%)  route 2.487ns (63.789%))

Стратегия 2: Оценка критического пути без выполнения синтеза

Используйте HDL Coder, чтобы оценить и выделить критический путь в вашей модели, не синтезируя ваш проект. Оценка критического пути идентифицирует критический путь путем выполнения статического анализа времени с данными синхронизации из целевых баз данных. Оценка критического пути без использования инструментов синтеза может привести к неточным результатам синхронизации. Оценка критического пути ускоряет процесс идентификации и оптимизации критического пути в вашем проекте. Это альтернатива выполнению FPGA Synthesis and Analysis с помощью HDL Workflow Advisor. Дополнительные сведения см. в разделе Оценка критического пути без выполнения синтеза.

Чтобы оценить критический путь, в Set Report Options задаче установите флажок Generate high-level timing critical path report. Запустите рабочий процесс к Generate RTL Code and IP Core задаче.

HDL Coder генерирует раздел оценки критического пути в отчете генерации кода. В этом разделе, когда вы выбираете ссылку на criticalpathestimated скрипт, генератор кода подсвечивает критический путь в сгенерированной модели. Этот рисунок показывает раздел hdlcoder_sfir_fixed_stream модель с выделенным критическим путем.

Стратегия 3: аннотировать критический путь при помощи Backannotation

Для получения более точной информации о критическом пути и подсветки критического пути в проекте используйте обратную аннотацию. Чтобы использовать backnotation, необходимо покинуть текущий сеанс Workflow Advisor, а затем запустить Generic ASIC/FPGA рабочий процесс для аннотации модели с результатами синтеза.

Перед использованием backflow-аннотации рекомендуется экспортировать текущие параметры HDL Workflow Advisor в скрипт. Экспортировав параметры в скрипт, можно выполнить итерацию по критическому пути и настроить различные параметры, чтобы оптимизировать проект до тех пор, пока вы не достигнете требуемых временных параметров. Можно импортировать скрипт Workflow Advisor в HDL Workflow Advisor, а затем запустить рабочий процесс. См. также раздел Запуск рабочего процесса HDL со скриптом.

Чтобы использовать резервную аннотацию:

Когда вы запускаете ссылку на Annotate Model with Synthesis Result задачу, генератор кода подсвечивает критический путь в сгенерированной модели. Этот рисунок показывает, что критический путь в hdlcoder_led_blinking модель находится внутри блока HDL Counter.

Рекомендация 1: Используйте оптимизацию скорости

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

Оптимизация распределённые конвейеризации и иерархическая оптимизация распределённой конвейеризации перемещает существующие задержки, имеющиеся в проекте, по иерархии подсистем. При использовании иерархического распределённой конвейеризации убедитесь, что все блоки Subsystem DistributedPipelining включены. Если ваш проект не соответствует требованиям времени, можно добавить больше трубопроводов с помощью InputPipeline или OutputPipeline свойств блоков. Можно задать эти свойства в диалоговом окне HDL Block Properties Subsystem.

Если распределённая конвейеризация не может переместить регистры, можно добавить Delay блоки к модели, а затем включить настройку Preserve design delays. Сбросьте Check Global Settings задачу и запустите рабочий процесс к Build FPGA Bitstream задаче. Можно итерировать на этом подходе и использовать другие оптимизации, такие как конвейеризация с тактовой частотой с большим значением для Oversampling factor, если проект не соответствует требованиям синхронизации. Чтобы задать эти параметры, используйте вкладку Pipelining Set Optimization Options задачи в HDL Workflow Advisor. Для получения дополнительной информации см. Раздел «Оптимизация скорости».

Рекомендация 2. Задайте ограничения многоколесного пути на основе включения

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

Если ваш критический путь находится на более медленной скорости сигнала, инструменты синтеза могут не соответствовать требованиям синхронизации. Отказ синхронизации происходит, потому что инструменты не могут вывести частоты дискретизации из сгенерированного HDL-кода и предположить, что эти пути должны запускаться с самой быстрой скоростью. Можно использовать основанные на разрешении ограничения многоколесного пути, чтобы сгенерировать файл ограничений, который позволяет инструменту синтеза облегчить ограничение синхроимпульса на многоколесных путях. Чтобы задать генерацию многожильных путей, в Set Optimization Options задаче установите флажок Включить-основанные ограничения. Запустите рабочий процесс к Build FPGA Bitstream задаче. Для получения примера смотрите Использовать Многоколесные Пути ограничения, чтобы соответствовать времени для медленных Путей.

Рекомендация 3: Сокращение целевой частоты

Используйте настройку Target Frequency (MHz), чтобы задать целевую частоту для HDL Coder, чтобы изменить настройку синхроимпульса в исходный проект, чтобы получить синхроимпульс с этой частотой. См. также Целевой частотный параметр.

Чтобы устранить отказы во времени, уменьшите настройку Target Frequency (MHz), чтобы инструмент синтеза мог соответствовать ограничению во времени. Чтобы увидеть, какую целевую частоту вы можете задать, используйте slack и информацию о критическом пути из отчета о синхронизации инструмента синтеза. Поскольку slack равен различию между необходимым временем и временем прибытия, можно добавить slack к необходимому времени, а затем использовать эту сумму как New required time. Используйте взаимное значение этого New required time как целевое значение частоты, удовлетворяющее требованиям синхронизации, поскольку New required time равен времени прибытия. Чтобы вычислить целевую частоту, в MATLAB^® Командное окно, запустите этот скрипт.

% Specify the required time (ns) and slack (ns) using timing report
required_time = 2;
slack = 2.2;

% Slack is difference between required_time and arrival_time
% By adding slack to required_time you can resolve 
New_required_time = required_time + slack;
Target_frequency = 1 / (New_required_time);

% Since we computed the new time in nanoseconds
Target_frequency_MHz = Target_frequency * 10^3;

В Set Target Frequency задаче задайте это значение для Target Frequency (MHz), а затем запустите рабочий процесс к Build FPGA Bitstream задаче. Если вы видите отказ синхронизации, можно использовать этот подход для итерации целевого значения частоты до тех пор, пока ваш проект не удовлетворяет требованиям синхронизации, и ослабление не станет нулем.

Можно также экспортировать настройки HDL Worflow Advisor в скрипт и продолжать итерацию целевого значения частоты путем определения Target_frequency_MHz как значение для TargetFrequency свойство. Затем запустите скрипт.

% Set this frequency as the new target frequency
hdlset_param('hdlcoder_led_blinking', 'TargetFrequency', Target_frequency_MHz);