Jump to content

    
yes

и про мультизадачность (точнее скорость вообще) линуксной вивады вопрос

Recommended Posts

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

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

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

собственно виваду (не 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 раза быстрее, когда с проектами разберемся

 

Share this post


Link to post
Share on other sites

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

*   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 и важно! для папки с проектом

Share this post


Link to post
Share on other sites

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

 

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

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

      

Успехов! Rob.

Share this post


Link to post
Share on other sites
14 часов назад, RobFPGA сказал:

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

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

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

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

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

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

Edited by fguy

Share this post


Link to post
Share on other sites

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

5 hours ago, fguy said:

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

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

 

Удачи! Rob. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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 и времянки соблюдены, а  результат неработоспособен :scratch_one-s_head:  Значит что скорее всего надизайнили  не то  :yes3:

 Удачи! Rob. 

Share this post


Link to post
Share on other sites
1 час назад, RobFPGA сказал:

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

 Удачи! Rob. 

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

Share this post


Link to post
Share on other sites

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

9 hours ago, fguy said:

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

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

 

Удачи! Rob.

Share this post


Link to post
Share on other sites
14 часов назад, fguy сказал:

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

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

 

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

Share this post


Link to post
Share on other sites
9 часов назад, RobFPGA сказал:

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

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

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

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

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

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

Edited by fguy

Share this post


Link to post
Share on other sites

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

7 minutes ago, fguy said:

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

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

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
5 минут назад, RobFPGA сказал:

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

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

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

Share this post


Link to post
Share on other sites
20 hours ago, fguy said:

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

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

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

 

1 hour ago, RobFPGA said:

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

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

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

Удачи! Rob.

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


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

Share this post


Link to post
Share on other sites
1 час назад, TRILLER сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.