Jump to content

    
Sign in to follow this  
RobFPGA

Quartus - странная ситуация с IP умножителя

Recommended Posts

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

Продолжение "эпупеии "  -  "... Будь проклят тот день, когда я сел за баранку этого пылесоса!" иногда так и хочется воскликнуть :biggrin:

Вариант  с импортом .dxp  файла для умножителя не прокатил  - так как нетлист импортируется именно туда где и был экспортирован. То есть   опция  netlist-only   все же сохраняет и положение   на кристалле.  Странно!?  Пришлось расчехлить  Synplify  и синтезировать нетлист для mult там.   

Из положительного  - как оказалось методы для  P&R в Quartus и ISE почти одинаковы - если грамотно залочить  части дизайна (logicLock) то время сборки сокращается в разы.  В моем случае с 2-3 часов до  40-50 мин. 

Удачи! Rob.

Share this post


Link to post
Share on other sites

А на ваш взгляд за счёт чего такое ускорение при использовании logicLock? Если проект без logicLock разбит на партишины и каждый партишин прибит гвоздями вместе со связями?

Share this post


Link to post
Share on other sites

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

6 hours ago, _sda said:

А на ваш взгляд за счёт чего такое ускорение при использовании logicLock? Если проект без logicLock разбит на партишины и каждый партишин прибит гвоздями вместе со связями?

Пока у меня отношение к партишенам  слегка негативное.  Либо я готовить их все еще не умею, либо действительно "вкус" у них не тот.   
Например   переключение части партишенов с режима POST_SYNHT  в режим POST_FIT (PARTITION_FITTER_PRESERVATION_LEVEL = PLACEMENT_AND_ROUTING ) при последующей сборке в этом же,  уже разведенном без ошибок проекте,  дало  увеличение времени сборки  на 40 мин и толику временных ошибок типа "поиздеваться над разработчиком", в цепях регистр - адрес памяти  ошибка тайминга  ~0.05 ns. :ireful2:

А уменьшение времени сборки  при LogicLock  понятно.   Что в старом ISE что в Qu  алгоритм P&R базируется на начальном случайном  разбросе  камней примитивов по  полю кристалла  и последующей монотонной сборки оных в аккуратные кучки по возможности с соблюдением ограничений  времянки и возможностей роутинга.   Фактически это алгоритм полного перебора что при большом  числе элементов  (для больших проектов и кристаллов) дает катастрофический рост времени  работы. И не гарантирует нужных результатов так как легко попадает в локальный минимум функции оптимизации.  Если руками ограничить варианты начального размещения  то  можно уменьшить  полет "фантазии" при начальном разбросе и соответственно  значительно ускорить сходимость и повторяемость результатов P&R.  В ISE например для  достаточно было и зафиксировать пару - тройку  критических модулей или блочную память сгруппировать и время сборки уменьшалось в разы. То же похоже  и в Qu. 

Удачи! Rob.

 

Share this post


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

Из положительного  - как оказалось методы для  P&R в Quartus и ISE почти одинаковы - если грамотно залочить  части дизайна (logicLock) то время сборки сокращается в разы.  В моем случае с 2-3 часов до  40-50 мин. 

везет вам. Я лочу все партишины кроме одного и сокращается минут 10-15. С 80мин до 65-70

2 hours ago, RobFPGA said:

Например   переключение части партишенов с режима POST_SYNHT  в режим POST_FIT (PARTITION_FITTER_PRESERVATION_LEVEL = PLACEMENT_AND_ROUTING ) при последующей сборке в этом же,  уже разведенном без ошибок проекте,  дало  увеличение времени сборки  на 40 мин и толику временных ошибок типа "поиздеваться над разработчиком", в цепях регистр - адрес памяти  ошибка тайминга  ~0.05 ns

на форуме подымалась схожая тема (что у квартуса с партишенами не все так гладко). Может у вас так же. sda молодец, вычислил, что там партишины копию создают. У меня оказалась такая же штука, с такими же последствиями

 

Edited by new123

Share this post


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

дало  увеличение времени сборки  на 40 мин

Странно, у меня такой финт обычно заканчивается с минусовым временем. Я всегда устанавливаю флажок Ignore changes in source, похоже что кроме основного назначения он выполняет кое что ещё.

6 минут назад, new123 сказал:

У меня оказалась такая же штука, с такими же последствиями

А вы знаете, с тех пор как бабка пошептала, работает как танк.:clapping:

Share this post


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

это алгоритм полного перебора что при большом  числе элементов

Нет, это скорее алгоритм случайного перебора. Полный перебор с текущими вычислительными мощностями нереален.

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

так как легко попадает в локальный минимум функции оптимизации

Нет. При ухудшении функции оптимизации, вероятность принятия решения не нулевая. Это и позволяет выбираться из локальных минимумов.

Share this post


Link to post
Share on other sites

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

1 hour ago, dvladim said:

Нет, это скорее алгоритм случайного перебора. Полный перебор с текущими вычислительными мощностями нереален.

Понятное дело  что это не полный перебор.  Остановка как раз и происходит если алгоритм видит что какой то минимум достигнут.  Но вот какой минимум? 

1 hour ago, dvladim said:

При ухудшении функции оптимизации, вероятность принятия решения не нулевая. Это и позволяет выбираться из локальных минимумов.

Согласен вероятность не нулевая, но для больших, сильно связанных дизайнов и не высокая. Опять же зависит как далеко  в алгоритме заложена возможность уходить "вверх" от текущего минимума.  И как долго вы готовы ждать результатов этого "альпинизма" :to_take_umbrage:

Удачи! Rob.

Share this post


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

Согласен вероятность не нулевая, но для больших, сильно связанных дизайнов и не высокая.

Это не зависит от дизайна как такового. PnR обычно одна из версий simulated annealing алгоритма. Параметры обычному пользователю ПО недоступны ))). Для Qu одной из причин окончания размещения является выполнение STA.

Share this post


Link to post
Share on other sites

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

4 hours ago, dvladim said:

Параметры обычному пользователю ПО недоступны ))). Для Qu одной из причин окончания размещения является выполнение STA.

Доступны но косвенно - В том же Qu  когда вы выбираете   варианты оптимизации  Normal, High effort, Aggressive  это как раз косвенно и задает дистанцию поиска новых минимумов относительно текущего.  Понятное дело все это если STA в текущем минимуме  не выполняется.  

Удачи! Rob.

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.

Sign in to follow this