[des00 25]

Всем доброго.

Прошу объяснить вот такое поведение вивады это баг/фича/норма?

Есть проект, трехчастотный, все 3 частоты в разных, асинхронных группах. Частоты 50,100,50МГц (сам проект гонится до 250). Никакой асинхры, все на синхронизаторах и блоках памяти между доменами. Чип артикс200, проект занимает 99% чипа, интересует только синтез, для оценки ресурса.

Vivado 2016.4 выполняет синтез за 15-20 минут, Vivado 2019.1.3 мурыжит синтез порядка 1 часа. Причем, обе вивады довольно бодро начинают синтез, пробегают до фазы Initializing timing engine и потом 2016.4 довольно быстро все завершает, а 2019.1.3. не понятно чем занимается.

Еще заметил что 2019, после отмены синтеза, создает своего клона (vivado.exe) в системных процессах ОС, который делает дюже долгой следующую сборку. Лечится удалением этого процесса.

Ну не могли же разработчики настолько все так испортить. Может просто я готовить виваду не умею?

Спасибо.

[Nick_K 0]

Я прямо с 16-той Вивады не начинал, а гд-то на 18-ю с ISE пересел и в общем тоже был удивлён странными поведениями. Есть подозрение, что разрабы прикрутили в синтез инструмент, который частично занимается анализом физического плейсмента. То есть раньше просто в примитивы превращало, а теперь оно ещё анализирует в какие примитивы и как оно потом лучше ляжет в кристалл. Это достаточно распространённая практика (добавлять анализатор физики) не только Хилые таким занимаются. Но опять же это непотверждённые догадки

[des00 25]

42 minutes ago, Nick_K said:

Я прямо с 16-той Вивады не начинал, а гд-то на 18-ю с ISE пересел и в общем тоже был удивлён странными поведениями. Есть подозрение, что разрабы прикрутили в синтез инструмент, который частично занимается анализом физического плейсмента. То есть раньше просто в примитивы превращало, а теперь оно ещё анализирует в какие примитивы и как оно потом лучше ляжет в кристалл. Это достаточно распространённая практика (добавлять анализатор физики) не только Хилые таким занимаются. Но опять же это непотверждённые догадки

согласился бы с вами, если бы это уменьшало общее время сборки. Взял другой проект, со схожими параметрами частоты/ресурс/производительность. Разность по времени сборки порядка 1 часа не в пользу более современной.

[Nick_K 0]

Так я же про это и пишу, что новые стали намного умнее и перебирают больше параметров при синтезе. Отсюда возникает увеличение времени сборки. А старая версия работает по более "тупому" принципу: что вижу - то синтезю, без всяких оптимизаций и т.п.

Теоретически если покопаться в настройках, может и можно поотключать всякие мудрые мудрости синтеза. Но у меня что проекта нет объёмного, что особо времени этим заниматься :)

p.s. Может этот AR немного поможет: https://www.xilinx.com/support/answers/62215.html

[RobFPGA 35]

Приветствую!

Трудно судить  о внутренней кухне  Vviado не  будучи работником оной.

На сколько я разобрался синтез в Vivado состоит как бы из двух этапов  - непосредственно синтез модулей (RTL -> netlist)  и последующий этап оптимизации полученного нетлиста. 

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

У меня тормоза на этапе синтеза чаще  всего возникали  при нестандартном описании большой памяти или  инициализации ROM  константами  из функций. 

 

Удачи! Rob.

[des00 25]

2 hours ago, RobFPGA said:

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

Были бы они, эти логи. А то в консоли надпись Initializing timing engine и все, через полчаса начинают валиться логи продолжения процесса.

2 hours ago, RobFPGA said:

У меня тормоза на этапе синтеза этапе чаще  всего возникали  при .....  инициализации ROM  константами  из функций.

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

[RobFPGA 35]

Приветствую!

2 hours ago, des00 said:

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

Как я понял проблемы с памятью и ROM  происходят потому  как если  память описана по стандартном шаблону  то она  инферится в стандартные блоки памяти еще на этапе первоначального синтеза.  Но если  же нет,  то при синтезе память превращается в толпу регистров с mux-ами  которые уже на этапе оптимизации  Vivado пытается  упаковать как память. Отсюда и тормоза. 

Удачи! Rob.

[Dr.Alex 0]

Кстати именно 2016.4 считаю самой приятной (наименее неприятной) из всех вивад, и слез с неё лишь в начале 19 года по печальному поводу: прожект в какой-то момент стал собираться неправильно. Потратил массу времени чтобы удостовериться в том, что это именно ОНО, а не я, и перешёл на последнюю на тот момент. И чип как раз артикс-200 был.

 

Насчёт неправильной остановки синтеза - вот про синтез не помню, а имплементацию остановить действительно невозможно, приходится вручную удалять процессы. Это было всегда и уже очевидно что будет всегда :-))))))

 

[des00 25]

18 hours ago, Nick_K said:

Так я же про это и пишу, что новые стали намного умнее и перебирают больше параметров при синтезе. Отсюда возникает увеличение времени сборки. А старая версия работает по более "тупому" принципу: что вижу - то синтезю, без всяких оптимизаций и т.п.

ну если он больше делает при синтезе, то при роутинге должен делать меньше) да и особых, выдающихся, результатов по ресурсу/производительности от 2019 ой не видно.

4 hours ago, Dr.Alex said:

Кстати именно 2016.4 считаю самой приятной (наименее неприятной) из всех вивад, и слез с неё лишь в начале 19 года по печальному поводу

аналогично, US в проект пошел, пришлось перелезать. а с 2016.4 я смог подружиться)

11 hours ago, RobFPGA said:

Как я понял проблемы с памятью и ROM  происходят потому  как если  память описана по стандартном шаблону  то она  инферится в стандартные блоки памяти еще на этапе первоначального синтеза.  Но если  же нет,  то при синтезе память превращается в толпу регистров с mux-ами  которые уже на этапе оптимизации  Vivado пытается  упаковать как память. Отсюда и тормоза.

но 2016ый то по другому работает) либо команда у них сменилась, либо подход. ИМХО зря они так, константы и в африке константы)

[disel 0]

1 hour ago, des00 said:

либо команда у них сменилась, либо подход.

То ли здесь на форуме, то ли где то на семинарах, уж и не помню где, слышал байку, что в ксалинксе две команды. Одна делает четные релизы, другая нечетные :)

[Raven 11]

3 hours ago, des00 said:

но 2016ый то по другому работает) либо команда у них сменилась, либо подход. ИМХО зря они так, константы и в африке константы)

Так дело-то не в том, что константы, а в том (возможно), что 2016.4 сразу признает фрагменты памяти за таковую (с последующим облегчением жизни), а 2019.1 - уже нет. В такую "эволюцию" Vivado как раз можно поверить.

А раскладывание констант по толпе рассеянных регистров - это действительно муторное и долгое занятие, по сравнению с раскладкой всего по нескольким BRAM'ам. Вообще, в части инициализации памяти альтеровцы оказализись куда как гуманнее и клиент-ориентированными, чем хилые.

[andrew_b 17]

2 часа назад, disel сказал:

То ли здесь на форуме, то ли где то на семинарах, уж и не помню где, слышал байку, что в ксалинксе две команды. Одна делает четные релизы, другая нечетные :)

Это было когда выпускалось по четыре релиза в год. С 2019 в год пекут по два релиза. Одну из команд соптимизировали.

[RobFPGA 35]

Приветствую!

45 minutes ago, Raven said:

А раскладывание констант по толпе рассеянных регистров - это действительно муторное и долгое занятие, по сравнению с раскладкой всего по нескольким BRAM'ам. Вообще, в части инициализации памяти альтеровцы оказализись куда как гуманнее и клиент-ориентированными, чем хилые.

Вопрос не в раскладке  констант,  а в том как эта раскладка реализована в коде

Например можно  инитить    память  через readmem*    и проблем при синтезе не должно быть.   А можно и так сделать:

(* rom_style = "block" *)
logic [WH_K*2-1:0] mem_sca [0:NPT-1];
(* rom_style = "block" *)
logic [WH_K*2-1:0] mem_scb [0:NPT-1];

for (genvar jj=0; jj<NPT; jj++) begin : g_rom
    assign mem_sca[jj][0     +: WH_K] = Kar(jj);
    assign mem_sca[jj][WH_K  +: WH_K] = Kai(jj);

    assign mem_scb[jj][0     +: WH_K] = Kbr(jj);
    assign mem_scb[jj][WH_K  +: WH_K] = Kbi(jj);
end

и вот тут уже синтез может сначала  сделать набор регистров а потом уж упаковать их как ROM блок памяти. 
Причем работает эта упаковка  для любой логики  которую по факту после синтеза можно упаковать как RAM или ROM, если не лень описывайте хоть 64К слов  памяти  через if ... else 

Удачи! Rob.

[Raven 11]

3 minutes ago, RobFPGA said:

Вопрос не в раскладке  констант,  а в том как эта раскладка реализована в коде

Это подразумевалось.

Но большое увеличение времени компиляции мы получим уже от самого факта нераспознавания синтезатором паттернов в коде в качестве BRAM'ов, с последующей возней с толпой регистров. И если переход Vivado 2016 -> 2019 ведет именно к этому, то IMHO, это и есть причина данного неприятного явления для данного конкретного FPGA проекта ТС.