[RobFPGA 27]

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

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

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

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

Удачи! Rob.

[_sda 0]

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

[RobFPGA 27]

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

6 hours ago, _sda said:

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

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

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

Удачи! Rob.

 

[new123 0]

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 молодец, вычислил, что там партишины копию создают. У меня оказалась такая же штука, с такими же последствиями

 

Изменено 9 мая, 2020 пользователем new123

[_sda 0]

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

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

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

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

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

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

[dvladim 0]

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

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

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

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

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

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

[RobFPGA 27]

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

1 hour ago, dvladim said:

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

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

1 hour ago, dvladim said:

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

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

Удачи! Rob.

[dvladim 0]

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

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

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

[RobFPGA 27]

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

4 hours ago, dvladim said:

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

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

Удачи! Rob.