[Jul'etta 0]

Здравствуйте. Уже пару недель бодаюсь с проблемой таймингов в проекте.

Задача такая: портировать проект с одной платформы на другую. Был проект под Kintex с программным процессором микроблейз, нужен под Zynq с аппаратными процессорами арм. Соответственно, править начала с блочного дизайна в Vivado. Этап синтеза проходит без ошибок, далее имплементация - и вот тут начинается интересное. Проект пока не проходит по таймингам.

Что было сделано: ознакомилась с документом "UG903 Using Constraints". Файл с временнЫми ограничениями (timing constraints) перешел ко мне от старого проекта, в соответствии с документом разобралась как это пишется.

Прочитаны статьи по конвейеризации проекта (как один из вариантов решения проблем с временем распространения сигналов) - но не пойму куда (в какое место в коде) тут надо вставлять регистры, да и поможет ли это?

Прочитана статья по стратегиям синтезатора.

Подскажите, пожалуйста, в каком направлении копать? Разбираться ли плотней с конвейеризацией схемы или лучше изучить стратегии синтезатора или прописывать новые и новые временнЫе ограничения в файле?

 

 

timings.xdc

[des00 25]

6 minutes ago, Jul'etta said:

Подскажите, пожалуйста, в каком направлении копать? Разбираться ли плотней с конвейеризацией схемы или лучше изучить стратегии синтезатора или прописывать новые и новые временнЫе ограничения в файле?

Открыть Timing Report и посмотреть где именно возникает ошибка. На каких тактовых, в каком блоке и почему. После этого понять как это лечится. Может быть у вас не полные тактоковые группы и валится путь, который должен быть false_path.

ЗЫ. На фпгасистемс есть цикл статей по временному анализу в вивадо.

[Jul'etta 0]

On 3/16/2023 at 11:47 AM, des00 said:

Открыть Timing Report и посмотреть где именно возникает ошибка. На каких тактовых, в каком блоке и почему. После этого понять как это лечится. Может быть у вас не полные тактоковые группы и валится путь, который должен быть false_path.

ЗЫ. На фпгасистемс есть цикл статей по временному анализу в вивадо.

Timing Report смотрела, проблемы с какими часами знаю. 

On 3/16/2023 at 11:47 AM, des00 said:

После этого понять как это лечится

Вот как раз в этом я и прошу помощи, научите, чем лечится :)

За статью спасибо, ознакомлюсь.

[des00 25]

20 minutes ago, Jul'etta said:

Timing Report смотрела, проблемы с какими часами знаю. 

Вот как раз в этом я и прошу помощи, научите, чем лечится 🙂

ну так и покажите что у вас валится) там же есть Detalied Path Timing Report + схематик этого пути между source/sink триггерами. Там будет видно: количество слоев логики, задержка разводки, задержка логики и т.д. И только тогда, с опорой на код и функциональность вашего модуля, можно предлагать пути решения.

[RobFPGA 35]

Для начала   надо убрать конфликты  unsafe (и другие).  в таблице  отношений разных  клоков   - задав  правильно асинхронные  clock group для несвязанных клоков.    Без  этого таймиги  могут не сходится для разных клоков даже  в  простых случаях.
А  уже  потом, если ошибки  будут повторятся,  смотреть что и как править в логике.

 
 

[Jul'etta 0]

On 3/16/2023 at 4:40 PM, RobFPGA said:

Для начала   надо убрать конфликты  unsafe (и другие).  в таблице  отношений разных  клоков   - задав  правильно асинхронные  clock group для несвязанных клоков.    Без  этого таймиги  могут не сходится для разных клоков даже  в  простых случаях.
А  уже  потом, если ошибки  будут повторятся,  смотреть что и как править в логике.

 
 

Спасибо за ответы. Прикрепила скриншот одного из путей - path177. Во вкладке с общими сведениями о пути указаны и источник и пункт назначения. Каков должен быть синтаксис, если для этого пути прописать  set_false_path ?

Пока написала так:

create_clock -period 8.000 -name clk_125mhz -waveform {0.000 4.000} [get_nets design_1_i/axi_pcie_0/inst/comp_axi_pcie_mm_s/comp_slave_bridge/comp_slave_read_cpl_tlp/last_data_received_reg/C]
set_clock_groups -asynchronous -group [get_clocks clk_125mhz]

 

У меня до этого ругался еще на fclk_clk0 и fclk_clk1, прописала для них следующее:

create_clock -period 50.000 -name fclk_clk0 -waveform {0.000 25.000} [get_nets design_1_i/processing_system7_0/FCLK_CLK0]
set_clock_groups -asynchronous -group [get_clocks fclk_clk0]

create_clock -period 50.000 -name fclk_clk1 -waveform {0.000 25.000} [get_nets design_1_i/processing_system7_0/FCLK_CLK1]
set_clock_groups -asynchronous -group [get_clocks fclk_clk1]

Помогло.

Надо ли для каждого из десятка путей для клокового домена clk_125mhz указывать асинхронные клоки? или для каждого прописывать set_false_path ?

[RobFPGA 35]

Политика кострейнинга клоков имеет несколько подходов. Каждый из которых имеет свои + и - ,и зависит в том числе от общей организации проекта.  

Если у вас есть несколько группы  разных клоков  от разных источников (например fclk_clk0 или fclk_clk1) и эти источники (как сгенерированные группы ) между собой независимы (асинхронны) то  можно задать сразу 
set_clock_groups -asynchronous -group [get_clocks -include_generated_clocks fclk_clk0]
set_clock_groups -asynchronous -group [get_clocks -include_generated_clocks fclk_clk1]

Это  эквивалентно  тому что вы зададите false_path  между  всеми клоками одной группы  и всеми клоками другой группы (и наоборот).
При этом внутри группы  клоки останутся связаны и между ними будут проверятся таймиги. 

Это  подход прост но чреват тем что пути CDC между такими группами клоков полностью убираются из анализа (этот констрейн имеет самый высокий приоритет и отменяет другие кострейны time exceptions которые вы возможно задавали для таких CDC) и некорректные переходы в RTL могут быть пропущены при анализе.  

Второй вариант  состоит в том что вы задаете  set_clock_groups -asynchronous ...  только  для  малого числа  конкретных клоков в которых вы уверенны что нет CDC переходов.  
Или вообще не задаете такого, а CDC тайминги разруливаются  в  констрейнах примитивов CDC (либо для каждого конкретного пути) через set_false_path ... или set_max_delay -datapath_only ... 
В этом варианте  некорректные в RTL или необконстрейненые  переходы CDC сразу  "светятся" при анализе и легко находятся и правятся. Но и работы по констрейнам может быть больше  
 

3 hours ago, Jul'etta said:

У меня до этого ругался еще на fclk_clk0 и fclk_clk1, прописала для них следующее:

...

Помогло.

Надо ли для каждого из десятка путей для клокового домена clk_125mhz указывать асинхронные клоки? или для каждого прописывать set_false_path ?

То что  set_clock_groups -asynchronous "помогает"  решить проблемы это понятно,  но и цианид говорят помогает от головной боли ...  

Что нужно и или нет, и как, надо смотреть по структуре конкретного дизайна,  увы без того тут возможны только общие советы.    

[des00 25]

14 hours ago, Jul'etta said:

Во вкладке с общими сведениями о пути указаны и источник и пункт назначения. Каков должен быть синтаксис, если для этого пути

Эмм, это что у вас за дичь с проектом? Откуда при передаче, судя по названиям сигналов, данных 8 слоев логики, в том числе . Из-за того и задержка роутинга у вас больше 6нс. Я бы, перед началом натягивания констрейнов, посмотрел бы что в этом месте происходит и почему. Если этот флаг используется для передачи данных, то натягивать туда false_path нельзя. Сломается логика работы. Этот констрейн используется, как отметил выше @RobFPGA для CDC, передачи констант времени исполнения и все такое. 

[Jul'etta 0]

On 4/12/2023 at 7:42 AM, des00 said:

Эмм, это что у вас за дичь с проектом? Откуда при передаче, судя по названиям сигналов, данных 8 слоев логики, в том числе . Из-за того и задержка роутинга у вас больше 6нс. Я бы, перед началом натягивания констрейнов, посмотрел бы что в этом месте происходит и почему. Если этот флаг используется для передачи данных, то натягивать туда false_path нельзя. Сломается логика работы. Этот констрейн используется, как отметил выше @RobFPGA для CDC, передачи констант времени исполнения и все такое. 

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

Объективно ли судить по "отчету" задействованных ресурсов на вкладках power и project summary?

Ладно бы, если проект на этапе трассировки/размещения валился, а то ведь вот вроде все разместилось на кристалле, только тайминги подправить - и усе. Но вот это пока что не решаемая задача, как ни прописываю тайминги. И документации много - ug903 и ug906 изучаю, и статьи, что вы мне посоветовали, прочитала - но общего понимания синтаксиса, что и как прописать, применительно к моему проекту, увы, пока не имею.

Кстати, изначально проект был под Kintex-7, конкретно xc7k325tffg676-2. А у меня сейчас под Zynq-7000 xc7z015clg485-2

[des00 25]

22 minutes ago, Jul'etta said:

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

вроде уже советовал посмотреть схематик этого конкретного пути вместе с detailed view (вы его открыли как раз). У вас там похоже PCI-E IP смотрит на IP акси шины, и там какое то хитрое преобразование. Может быть можно поставить слой axi_register_slice чтобы в этом месте расслабить времянку. 

22 minutes ago, Jul'etta said:

Объективно ли судить по "отчету" задействованных ресурсов на вкладках power и project summary?

Для анализа проблем, нет, это так, общие попугаи.

22 minutes ago, Jul'etta said:

Ладно бы, если проект на этапе трассировки/размещения валился, а то ведь вот вроде все разместилось на кристалле, только тайминги подправить - и усе. Но вот это пока что не решаемая задача, как ни прописываю тайминги. И документации много - ug903 и ug906 изучаю, и статьи, что вы мне посоветовали, прочитала - но общего понимания синтаксиса, что и как прописать, применительно к моему проекту, увы, пока не имею.

Можете мои статьи из подписи почитать, они попроще для понимания системного подхода. Правда на примере квартуса, но тем не менее.

22 minutes ago, Jul'etta said:

Кстати, изначально проект был под Kintex-7, конкретно xc7k325tffg676-2. А у меня сейчас под Zynq-7000 xc7z015clg485-2

Вооот, надо было сразу об этом написать. Вы портируете проект со "слона" на "пипетку". А на мелких чипах, помимо непосредственно размера, могут быть конфигурации не удобные для разводки (например поле плис выглядит как буква Н, а не квадратное поле). И там действительно порой надо расслаблять времянки, за счет вставки регистровых слайсов. Это я к тому что все ваши танцы с бубном могут ни к чему не привести. А намекает про это соотношение ваших задержек. Логика это 20% от общей задержки, остальное роутинг. 

[Jul'etta 0]

On 4/11/2023 at 8:01 PM, RobFPGA said:

Это  подход прост но чреват тем что пути CDC между такими группами клоков полностью убираются из анализа (этот констрейн имеет самый высокий приоритет и отменяет другие кострейны time exceptions которые вы возможно задавали для таких CDC) и некорректные переходы в RTL могут быть пропущены при анализе.  

Второй вариант  состоит в том что вы задаете  set_clock_groups -asynchronous ...  только  для  малого числа  конкретных клоков в которых вы уверенны что нет CDC переходов.  
Или вообще не задаете такого, а CDC тайминги разруливаются  в  констрейнах примитивов CDC (либо для каждого конкретного пути) через set_false_path ... или set_max_delay -datapath_only ... 
В этом варианте  некорректные в RTL или необконстрейненые  переходы CDC сразу  "светятся" при анализе и легко находятся и правятся. Но и работы по констрейнам может быть больше  

Спасибо!

 Информация из Report CDC (картинку прикрепила). Там имеется мой проблемный домен (один из) - clk_125mhz - во вкладке exception указано, что он относится к асинхронной группе. Что это значит? ведь все равно ругается на него.

[Jul'etta 0]

On 4/12/2023 at 11:47 AM, des00 said:

вроде уже советовал посмотреть схематик этого конкретного пути вместе с detailed view (вы его открыли как раз). У вас там похоже PCI-E IP смотрит на IP акси шины, и там какое то хитрое преобразование. Может быть можно поставить слой axi_register_slice чтобы в этом месте расслабить времянку. 

Для анализа проблем, нет, это так, общие попугаи.

Можете мои статьи из подписи почитать, они попроще для понимания системного подхода. Правда на примере квартуса, но тем не менее.

Вооот, надо было сразу об этом написать. Вы портируете проект со "слона" на "пипетку". А на мелких чипах, помимо непосредственно размера, могут быть конфигурации не удобные для разводки (например поле плис выглядит как буква Н, а не квадратное поле). И там действительно порой надо расслаблять времянки, за счет вставки регистровых слайсов. Это я к тому что все ваши танцы с бубном могут ни к чему не привести. А намекает про это соотношение ваших задержек. Логика это 20% от общей задержки, остальное роутинг. 

Добрый день. кажется, получилось. Поставила "enable register slice" в блоке axi interconnect, куда подключен блок pcie. Это решило одну проблему с критическими путями (отрицательное значение slack по параметру tsetup).

Вторую проблему (отрицательное значение slack по параметру thold) помогли решить 2 строчки в файле констрейнов:

set_clock_groups -asynchronous -group [get_clocks PCIe_RefClkn]
set_clock_groups -asynchronous -group [get_clocks PCIe_RefClkp]

Спасибо за отличные статьи и дельные советы.  

[RobFPGA 35]

10 minutes ago, Jul'etta said:

set_clock_groups -asynchronous -group [get_clocks PCIe_RefClkn]
set_clock_groups -asynchronous -group [get_clocks PCIe_RefClkp]

Вам не нужно объявлять 2 разных клока PCIe_RefClkn и PCIe_RefClkp  для одного и  того же клока.  Ведь это всего лишь дифф вход оного клока для pcie_ref.  Достаточно объявить один клок только для пина  PCIe_RefClkp