Решение временных Отказов в генерации ядра IP и Simulink Real-Time рабочих процессов FPGA ввода-вывода

Синхронные схемы требуют, чтобы данные распространялись из регистра источника в регистр назначения в течение одного такта. Для инструментов синтеза Delay блоки, которые вы добавляете к Simulink® модель запускается с тактовой частотой. Инструменты требуют данных для перемещения между блоками в течение одного такта. Если инструмент не может распространить данные между регистрами для одного или нескольких сигнальных путей в вашей модели в течение одного такта, происходит отказ синхронизации.

Инструменты сообщают информацию о slack для каждого пути сигнала, которая соответствует различию между необходимым временем и временем прибытия. Требуемое время - это ожидаемое время, в течение которого сигнал должен поступить в регистр назначения. Время прибытия - это время, прошедшее для поступления сигнала в эту точку. Положительное ослабление указывает, что сигнал поступил намного быстрее, чем необходимое время, и путь проходит требование синхронизации. Отрицательное ослабление указывает, что путь сигнала медленнее, чем необходимое время, и путь отказывает в требовании синхронизации. Чтобы убедиться, что ваш проект соответствует требованиям синхронизации, ускорите все пути сигнала, которые имеют отрицательное ослабление.

Чтобы определить, соответствует ли ваш проект требованиям к синхронизации и как можно устранить отказы в синхронизации, выполните эти шаги.

Шаг 1: Идентифицируйте отказ синхронизации

Когда вы запускаете IP Core Generation рабочий процесс или Simulink Real-Time FPGA I/O рабочий процесс для Vivado®- на основе плат, если ваша модель Simulink не соответствует требованиям синхронизации, HDL- Coder™ генерирует ошибку на Build FPGA Bitstream шаге рабочего процесса. См.:

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

Во внешней консоли, если есть отказ синхронизации, вы видите худший сбой и это сообщение: Timing constraints NOT met!

Когда вы снимаете флажок Run build process externally, а затем запускаете Build FPGA Bitstream задачу, если происходит отказ синхронизации, задача прекращает работать, и вы видите эти сообщения в подпанели Result.

В обоих случаях, когда происходит отказ синхронизации, генератор кода заменяет предыдущий битовый поток на битовый поток, который имеет то же имя и постфикс _timingfailure.bit или _timingfailure.sof в зависимости от того, создали ли вы проект при помощи Vivado или Quartus®. Для примера, если был вызван предыдущий сгенерированный битовый поток system_top_wrapper.bitи в случае отказа синхронизации HDL Coder переименовывает этот битовый поток в system_top_wrapper_timingfailure.bit.

Если вы запускаете Program Target Device задачу, задача прекращает работать.

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

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

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

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

  • После запуска Build FPGA Bitstream задачи экспортируйте HDL Workflow Advisor в скрипт. В скрипте, чтобы сообщить о отказах во времени в качестве предупреждений, используйте ReportTimingFailure свойство hdlcoder.WorkflowConfig класс. Затем можно запустить скрипт или импортировать скрипт в HDL Workflow Advisor, а затем запустить рабочий процесс.

    hWC.ReportTimingFailure = hdlcoder.ReportTiming.Warning; 
    
  • Если вы нацелены на пользовательский исходный проект, который вы уже определили для платы, чтобы сообщить о отказах во времени в качестве предупреждений, используйте ReportTimingFailure свойство hdlcoder.ReferenceDesign класс.

    hRD.ReportTimingFailure = hdlcoder.ReportTiming.Warning; 
    

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

Шаг 2: Найти критический путь

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

Стратегия 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 со скриптом.

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

  1. В Set Target Device and Synthesis Tool задаче выберите Generic ASIC/FPGA как Target workflow. Для Synthesis tool укажите тот же инструмент, который вы использовали для запуска IP Core Generation рабочий процесс.

    Когда вы задаете эти настройки, HDL Coder сбрасывает эту задачу и все задачи, которые следуют за ней.

  2. Выберите Run This Task.

  3. В Set Target Frequency задаче задайте ту же целевую частоту, которую вы использовали для запуска IP Core Generation рабочий процесс. Выберите Run This Task.

  4. Щелкните правой кнопкой мыши Annotate Model with Synthesis Result задачу и выберите Run to Selected Task.

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

Шаг 3: Устранение отказов в синхронизации

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

Рекомендация 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);

См. также

|

Похожие темы