[yes 7]

если уже было, то извиняйте. на ксалинском форуме сразу посылают с такими вопросами

как-то раньше не озабачивался рантаймом вивады...

--------------

собственно виваду (не ML а из архива 2020.2) поставил на сервер, который от азиков остался - думал, что сейчас все полетит... а вот ничего не стало лучше с рантаймом по сравнению с миникомпьютером 5х10х10 см размером, где она была раньше 

------------

в сервере 10 ядер

Intel(R) Core(TM) i9-10900X CPU @ 3.70GHz
MemAvailable:   249071480 kB

openSUSE
VERSION = 15.2

на реальном железе, не виртуалка

настройки вивады:

get_param general.maxThreads
8

launch_runs impl_1 -jobs 10

(это гуи 10 жопс предложил)

в top-e два процесса, суммарно по отчету  top-а  CPU ~100%

pstree

vivado───loader───vivado─┬─2*[loader]
                                          ├─loader───vrs───runme.s+
                                          └─93*[{vivado}]
 

------------

в миникомпютере-коробочке

Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz   1.99 GHz

32.0 GB (31.9 GB usable)

и еще винда впридачу

============================

ЧЯДНТ ???

 

UPD: пока не понятно - измерялось на разных проектах, как выяснилось. вопрос оставлю, но может паника преждевременная - ожидаю в 1.5-2 раза быстрее, когда с проектами разберемся

 

[pavlovconst 5]

Я в свое время разбирался в теме, перечитал все ксайлинксовые форумы на этот счет. Вот что можно сделать для ускорения:

*   set_param synth.maxThreads 8

*   set_param general.maxThreads 32

*   опция -ultrathreads для шага impl.place и impl.route (пишу по памяти)

*   стратегия RuntimeOptimized  для синтеза и для имплементации (стратегия Quick ещё быстрее, но для реальных задач не годится)

*   инкрементальный синтез и инкрементальная имплементация 

*   report strategy - выбрать no reports

*   отключить шаг impl.power_opt

 

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

 

Низкая производительность  Win относительно Lin - на моих проектах не ообнаружена

 

Реальное, гарантированное ускорение, на мой взгляд, можно получить только на правильно подобранном железе:

*   самое важное! - процессор с максимальной однопоточной производительностью - один из https://www.cpubenchmark.net/singleThread.html Количество ядер - вторично

*   Хорошее охлаждение

*   Много оперативки

*   Производительный SSD для  папки Vivado и важно! для папки с проектом

[RobFPGA 35]

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

 

IMHO кратного ускорение  только за счет железа  не достигнуть. Конечно если не брать крайние случаи  апгрейда с обычного Пентиума 

Для кратного ускорения, и как я считаю что более важное,  повторяемости результатов P&R нужна грамотная структура дизайна и оптимальна стратегия сборки проекта.
И это не те стратегии которые  присутствуют  в Vv.  Это стратегия последовательности шагов сборки с применением как различных встроенных опций Vv так и различных оптимизаций на уровне дизайна и констрейнов.

      

Успехов! Rob.

[fguy 5]

14 часов назад, RobFPGA сказал:

Конечно если не брать крайние случаи  апгрейда с обычного Пентиума

По факту разница производительности одного ядра между и5 3й серии и 9900К составила всего раза 1.5 и то на даблах, а на сингл еще меньше. Это фактически соответствует разнице в тактовых цпу и ддр. Так что да - ждать какого то жуткого прироста на одном ядре от апгрейда не приходится. За счет числа ядер и озу можно получить хороший прирост только на поядерном синтезе в виваде и то один раз при первом запуске.

14 часов назад, RobFPGA сказал:

Для кратного ускорения, и как я считаю что более важное,  повторяемости результатов P&R нужна грамотная структура дизайна и оптимальна стратегия сборки проекта.

Тут согласен, но при условии заполнения чипа по логике более 40-50% или работе на предельных частотах, а если проект без фанатизма, то чаще всего разводится и с ExtraTimingOpt. Попытка запихнуть больше обойдется в немалые временные затраты и тут уже нужно решать на уровне проекта - стоит ли оно того или проще поставить плис побольше (зачастую на то же место без переразводки платы).

Ну и опять же если вы написали весь проект сами в VHDL/Verilog, то выбрать опции оптимизации и стратегии разводки будет гораздо легче, чем когда проект в бд на 80% из штатных ядер, которым никакие примочки не помогают.

Изменено 5 сентября, 2021 пользователем fguy

[RobFPGA 35]

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

5 hours ago, fguy said:

Тут согласен, но при условии заполнения чипа по логике более 40-50% или работе на предельных частотах, а если проект без фанатизма, то чаще всего разводится и с ExtraTimingOpt.

Я  как раз и имел ввиду не "прогулочные" дизайны которые "без фанатизма", а  тяжелые проекты с заполнением >70%  и  сложные про частотам. Именно на  них наиболее актуальны методы ускорения и повторяемости P&R.
А чей код большой разницы нет.  Понятное дело со своим RTL проще чем с табуном "дареных  коней" на BD. Но от этого подходы  оптимизации P&R сильно не меняются.

 

Удачи! Rob. 

[fguy 5]

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

[RobFPGA 35]

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

7 minutes ago, fguy said:

Оптимизация разводки плис констрэйнами не имеет цели развести быстро - это в лучшем случае побочный эффект

Это две  стороны одной медали! Именно с целю ускорения и в конце концов успешности P&R как раз констрейны и применяются.
Устранение избыточности констрейнов (false path, multicycle, ...),  ограничения зоны расположения отдельных модулей AREA_GROUP/LOGIC_LOCK,  фиксация отдельных LUT/DSP/RAM абсолютно или относительно друг друга,  значительно сокращают время P&R (порой в разы) и обеспечивают гарантию успешной сборки даже при существенном изменении дизайна.

19 minutes ago, fguy said:

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

???  Если  быстрее P&R и времянки соблюдены, а  результат неработоспособен   Значит что скорее всего надизайнили  не то  

 Удачи! Rob. 

[fguy 5]

1 час назад, RobFPGA сказал:

???  Если  быстрее P&R и времянки соблюдены, а  результат неработоспособен   Значит что скорее всего надизайнили  не то  

 Удачи! Rob. 

Тут кто то предлагал использовать стратегию Performance_ExploreWithRemap - она действительно относительно Performance_ExtraTimingOpt дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.

[RobFPGA 35]

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

9 hours ago, fguy said:

...  дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.

Совсем запутали  -  "меньше failed point"  это как?
Если времянки не сошлись то ожидать работу дизайна глупо,  а если сошлись что что за  failed point?

 

Удачи! Rob.

[dxp 65]

14 часов назад, fguy сказал:

Тут кто то предлагал использовать стратегию Performance_ExploreWithRemap - она действительно относительно Performance_ExtraTimingOpt дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.

Это я упоминал. На 2018.2 она у нас давала лучше результаты по таймингам, на других стратегиях они просто не сходились. Но тут подтянул 2021.1 и получил сюрприз: тайминги развалились. Поменял на Performance_ExplorePostRoutePhysOpt и всё получилось.

 

По поводу неработоспособности Performance_ExploreWithRemap. Такого ни разу не было, если проект собрался с неотрицательными слаками, всё работало исправно.

[fguy 5]

9 часов назад, RobFPGA сказал:

Если времянки не сошлись то ожидать работу дизайна глупо,  а если сошлись что что за  failed point?

Failed Point пишутся в виваде на странице Project Summary в блоке Timing для Setup и Hold. Их количество ненулевое при отрицательных WNS и WHS соответственно.

Не знаю как для чистого VHDL, а на штатных ядрах и хлс проекты стабильно работают и при TNS в несколько сотен и фп в пару тысяч.

4 часа назад, dxp сказал:

По поводу неработоспособности Performance_ExploreWithRemap. Такого ни разу не было, если проект собрался с неотрицательными слаками, всё работало исправно.

Я для теста переразводил с ним рабочий проект в 2018.3, который давал с Performance_ExtraTimingOpt небольшие минуса и фп - проект развелся по этим параметрам лучше, но работать перестал.

Изменено 9 сентября, 2021 пользователем fguy

[RobFPGA 35]

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

7 minutes ago, fguy said:

Не знаю как для чистого VHDL, а на штатных ядрах и хлс проекты стабильно работают и при TNS в несколько сотен и фп в пару тысяч.

Так вы  оказывается любитель  "русской рулетки" 

Если в после P&R  времянки не сошлись  даже на  -1 ps  это  уже нерабочий дизайн.  И работа с ним  все равно что крутить барабан револьвера - когда ни будь да и выстрелит. 

Удачи! Rob.

[fguy 5]

5 минут назад, RobFPGA сказал:

Так вы  оказывается любитель  "русской рулетки" 

Если в после P&R  времянки не сошлись  даже на  -1 ps  это  уже нерабочий дизайн.  И работа с ним  все равно что крутить барабан револьвера - когда ни будь да и выстрелит.

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

[TRILLER 0]

20 hours ago, fguy said:

Тут кто то предлагал использовать стратегию Performance_ExploreWithRemap - она действительно относительно Performance_ExtraTimingOpt дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.

Довольно беспредметный разговор получается. Это как рассуждать, на какой передаче тот или иной вело-любитель ездит - 3-й или 4-ой..
Любая стратегия, это всего лишь последовательность конкретных настроек оптимизации(пример для 17.4):

Советую разобраться, какие конкретно оптимизации позволяют Вам достигать результата, ибо в новой версии вивады "стратегия" может просто исчезнуть! Лично для меня наиболее полезной настройкой является "раннее расположение BRAM и DSP"(в таблице выше их нет - старая версия).
Ну и Pblocks - само собой..

 

1 hour ago, RobFPGA said:

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

Так вы  оказывается любитель  "русской рулетки" 

Если в после P&R  времянки не сошлись  даже на  -1 ps  это  уже нерабочий дизайн.  И работа с ним  все равно что крутить барабан револьвера - когда ни будь да и выстрелит. 

Удачи! Rob.

Сбой в дизайне - это всё же вероятностный процесс. А ввиду этого, между слаком -1пс и + 1пс разницы никакой.
Лично систематически наблюдал, когда 17.4 на большом и быстром проекте постоянно не сводила 1-2 пути на единицы пик.
Эти пути всегда были разные и объективных причин его не свести у роутера не было. Для себя сделал вывод, что как-раз из-за многопоточности завершение P&R происходило немного раньше, чем было нужно. И разработчики вивады не посчитали это значимой проблемой.. Поэтому, озвученный fguy подход, на мой взгляд, имеет право на жизнь.

Насчёт многопоточности.. Как сейчас - не знаю(нет жирных проектов), но лет несколько назад она ничего, кроме проблем, не давала. Выигрыш по скорости, как уже говорили, был незначительный, но при это разводился проект не так, как при 1 потоке.
Думаю, допустимо сказать - хуже.

[fguy 5]

1 час назад, TRILLER сказал:

Советую разобраться, какие конкретно оптимизации позволяют Вам достигать результата

Я уже писал выше что определиться с оптимизациями и констрэйнами гораздо легче когда всем рулишь сам и проект написан от и до на VHDL/Verilog, а когда 80% это штатные ядра, для которых фэншуй оптимизаций нигде не описан совсем, остается действовать по методу перебора вариантов.