Схемы синхронизации требуют, чтобы данные распространили от исходного регистра до целевого регистра в одном такте. Для инструментов синтеза, блоки Delay, которые вы добавляете в свой запуск модели Simulink® на тактовой частоте. Инструменты требуют, чтобы данные переместились между блоками в одном такте. Если инструмент не может распространить данные между регистрами для одного или нескольких путей прохождения сигнала в вашей модели в одном такте, отказ синхронизации происходит.
Инструменты сообщают информацию slack для каждого пути прохождения сигнала, который соответствует различию между необходимым временем и временем поступления. Необходимое время является ожидаемым временем, в которое сигнал должен прибыть в целевой регистр. Время поступления является временем, истекшим для сигнала прибыть в ту точку. Положительное слабое указывает, что сигнал прибыл намного быстрее, чем необходимое время, и путь передает требование синхронизации. Слабое отрицание указывает, что путь прохождения сигнала медленнее, чем необходимое время, и путь приводит требование синхронизации к сбою. Чтобы убедиться, что ваш проект удовлетворяет требования синхронизации, ускорьте все пути прохождения сигнала, которые имеют слабое отрицание.
Идентифицировать, удовлетворяет ли ваш проект требования синхронизации и как можно разрешить отказы синхронизации, выполнить эти шаги.
Когда вы запускаете IP Core Generation рабочий процесс или Simulink Real-Time FPGA I/O рабочий процесс для плат Vivado®-based, если ваша модель Simulink не удовлетворяет требования синхронизации, HDL Coder™, генерирует ошибку на шаге Build FPGA Bitstream рабочего процесса. См.:
Начало работы с Предназначением для Платформы Xilinx Zynq для получения информации о том, как запустить IP Core Generation рабочий процесс.
Программирование FPGA и Настройка для получения информации о том, как запустить Simulink Real-Time FPGA I/O рабочий процесс. Когда вы запускаете этот рабочий процесс, используйте плату Speedgoat, которая поддерживает Xilinx® Vivado как инструмент синтеза.
Когда вы запускаете задачу 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. Прежде, чем запрограммировать целевое устройство SoC, рекомендуется, чтобы вы разрешили отказы синхронизации.
После того, как вы разрешили отказы синхронизации, чтобы проверить, что отказы были разрешены, можно использовать программное обеспечение 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;
Изучить, как можно идентифицировать критический путь и разрешить отказы синхронизации, выполнить шаги в предыдущих разделах.
Критический путь является комбинационным путем между входом и выходом, который имеет максимальную задержку. Этот путь соответствует пути прохождения сигнала, который имеет худшее слабое отрицание. Путем идентификации и оптимизации критического пути, можно разрешить отказы синхронизации и улучшить синхронизацию проекта. Можно идентифицировать критический путь в проекте при помощи любой из этих стратегий.
В подпанели Result, чтобы открыть отчет синхронизации, который сгенерирован инструментом синтеза, выбирают ссылку timing_report. Можно использовать отчет идентифицировать критический путь в проекте. В отчете, если вы ищете Worst Slack, можно идентифицировать худшую слабую настройку. Затем используйте Source и Destination точки, чтобы идентифицировать критический путь. Например, этот отчет для LED мигающая модель 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%))
Используйте 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 модель с подсвеченным критическим путем.
Для более точной информации о критическом пути и выделения критического пути в вашем проекте, используйте backannotation. Чтобы использовать backannotation, необходимо оставить текущего Советника по вопросам Рабочего процесса сеансом, и затем запустить Generic ASIC/FPGA рабочий процесс, чтобы аннотировать модель результатами синтеза.
Прежде чем вы будете использовать backannotation, рекомендуется, чтобы вы экспортировали текущие настройки HDL Workflow Advisor в скрипт. Путем экспорта настроек в скрипт можно выполнить итерации на критическом пути и настроить различные настройки, чтобы оптимизировать проект, пока вы не удовлетворяете требования синхронизации. Можно импортировать Советника по вопросам Рабочего процесса скрипт к HDL Workflow Advisor и затем запустить рабочий процесс. См. также Рабочий процесс HDL Запуска со Скриптом.
Использовать backannotation:
В задаче Set Target Device and Synthesis Tool выберите Generic ASIC/FPGA как Target workflow. Для Synthesis tool задайте тот же инструмент, что вы раньше запускали IP Core Generation рабочий процесс.
Когда вы задаете эти настройки, HDL Coder сбрасывает эту задачу и все задачи, которые следуют за ним.
Выберите Run This Task.
В задаче Set Target Frequency задайте ту же целевую частоту, что вы раньше запускали IP Core Generation рабочий процесс. Выберите Run This Task.
Щелкните правой кнопкой по задаче Annotate Model with Synthesis Result и выберите Run to Selected Task.
Когда вы запускаете ссылку на задачу Annotate Model with Synthesis Result, генератор кода подсвечивает критический путь в сгенерированной модели. Этот рисунок показывает что критический путь в hdlcoder_led_blinking модель в блоке HDL Counter.
Чтобы разрешить отказы синхронизации, можно использовать любую из этих рекомендаций или комбинацию рекомендаций, пока проект не встречает целевой частоте.
Можно использовать оптимизацию скорости такой, как распределено конвейеризация и конвейеризация тактовой частоты, чтобы повредить критический путь путем добавления конвейерных регистров при сохранении функционального поведения. Путем сокращения критического пути можно достигнуть более высоких частот часов и увеличить время поступления сигнала, пока это не равняется необходимому времени, и слабое становится нулевым.
Распределенная конвейеризация и иерархическая распределенная оптимизация конвейеризации перемещают существующие задержки, которые вы имеете в своем проекте через иерархию подсистемы. То, когда вы используете иерархическую распределенную конвейеризацию, включило, убедитесь, что всем блокам 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. Для получения дополнительной информации смотрите Оптимизацию Скорости.
Если ваш проект содержит несколько частот дискретизации или использует определенные реализации блока HDL или оптимизацию скорости, которая вставляет конвейерные регистры на более быстром уровне после того, как генерация кода, ваш проект может иметь мультивелосипедные дорожки. По умолчанию HDL Coder использует один режим тактовой синхронизации, который генерирует основной тактовый генератор на уровне самой быстрой частоты дискретизации и создает контроллер синхронизации сущность. Контроллер синхронизации генерирует набор часов, включает с необходимым уровнем и информацией о фазе, чтобы произвести сигнал часов для блоков, которые действуют в более медленном шаге расчета.
Если ваш критический путь находится на более медленном уровне сигнала, инструменты синтеза могут не удовлетворить требования синхронизации. Отказ синхронизации происходит, потому что инструменты не могут вывести частоты дискретизации из сгенерированного HDL-кода и принять, что эти пути должны запуститься на самом быстром уровне. Можно использовать, позволяют - базирующиеся ограничения тракта мультицикла сгенерировать ограничительный файл, который позволяет инструменту синтеза упростить ограничение часов на пути к мультициклу. Чтобы задать генерацию ограничений тракта мультицикла, в задаче Set Optimization Options, выбирают Enable - базирующийся ограничительный флажок. Запустите рабочий процесс к задаче Build FPGA Bitstream. Для примера смотрите Ограничения тракта Мультицикла Использования, чтобы Соответствовать Синхронизации для Медленных Путей.
Используйте установку Target Frequency (MHz), чтобы задать целевую частоту для HDL Coder, чтобы изменить установку модуля тактовой синхронизации в исходном проекте, чтобы произвести сигнал часов с той частотой. См. также Целевую Частоту.
Чтобы разрешить отказы синхронизации, уменьшайте установку Target Frequency (MHz) так, чтобы инструмент синтеза мог соответствовать ограничению синхронизации. Чтобы видеть, какую целевую частоту можно задать, используйте слабое и информацию о критическом пути из отчета синхронизации инструмента синтеза. Поскольку слабый равно различию между необходимым временем и временем поступления, можно добавить слабое в необходимое время, и затем использовать эту сумму в качестве 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);
hdlcoder.Board | hdlcoder.ReferenceDesign