[_sda 0]

Коллеги заметил одну неприятность в Квартусе 18.1, Win10, Arria V.

Весь проект разбит на партиции, для каждой партиции назначен Netlist Type request = Post-Fit. Если почистить базы в Квартусе и пересобрать проект то Logic utilization (in ALMs) = 63,716 / 113,200 ( 56 % ). Стоит только сделать незначительные изменения например в топ-файле (без партиции) и после перекомпиляции уже имеем Logic utilization (in ALMs) = 74,602 ALM. Ещё одно незначительное изменение (например инверсия сигнала на светодиод) даёт уже расход 96,214 ALM. При дальнейших компиляциях рост прекращается. Видно что расход увеличивается примерно равномерно (разброс около 30%) у всех партиций, хотя в отчёте Netlist Types Used уверенно сообщается что для всех партиций был применён именно Post-Fit Netlist. Это я замечал ещё в Q16.0 но там расход был меньшим и я смирился, но здесь же терять неизвестно на что 33000 ALM ну никак не хочется. При очистке баз и компиляции снова будем иметь utilization около 60000 ALM. Кто нибудь сталкивался с таким поведением? Поддаётся ли лечению?

[new123 0]

У меня в 19 такая же штука. При инкрементной последующей компиляции пухнет проект и значение SLACK падает процентов на 5-8%. Думал это норм.

Поэтому пробную компиль делаю инкремент, а боевую версию - зачищаю всю бд и компилю с нуля

[_sda 0]

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

У меня в 19 такая же штука. При инкрементной последующей компиляции пухнет проект и значение SLACK падает процентов на 5-8%. Думал это норм.

Поэтому пробную компиль делаю инкремент, а боевую версию - зачищаю всю бд и компилю с нуля

Спасибо! Похоже что-то у них с инкрементальной компиляцией не срослось...

А вот в Q13,емнип, такого не было. Видно новеньких в штат набрали...

[_sda 0]

Коллеги, случайно обратил внимание на рекурсию в структуре проекта. Похоже с этим и связано распухание проекта.

Обратите внимание что  модуль dsp_nb в структуре указан два раза! Причём dsp_nb размером 66705 алм якобы входит в состав top_filter_nb размером 29779 алм.

Пересборка проекта ничего не даёт. Никто у себя такого не замечал?

 

 

[new123 0]

Сподвигло меня еще раз погуглить по альтеровскому форуму. С запросом "incrimental compilation" и сраза наткнулся на тему похожую с комментарием и объяснением

https://forums.intel.com/s/question/0D50P00003yyMxWSAU/logic-utilization-with-incremental-compilation?language=en_US

[_sda 0]

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

Сподвигло меня еще раз погуглить по альтеровскому форуму. С запросом "incrimental compilation" и сраза наткнулся на тему похожую с комментарием и объяснением

https://forums.intel.com/s/question/0D50P00003yyMxWSAU/logic-utilization-with-incremental-compilation?language=en_US

Спасибо! Самое интересное - You would have to do some detective work...

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

А тут ещё непонятная рекурсия...Вопрос остаётся открытым.

[des00 25]

23 minutes ago, _sda said:

А тут ещё непонятная рекурсия...Вопрос остаётся открытым.

линейная сборка ваше все) 

[_sda 0]

2 минуты назад, des00 сказал:

линейная сборка ваше все) 

Это как? Я в проекте никакую рекурсию не закладывал....

После убивания баз всё выглядит замечательно.

[des00 25]

18 minutes ago, _sda said:

Это как? Я в проекте никакую рекурсию не закладывал....

После убивания баз всё выглядит замечательно.

ну это она и есть) т.е. не использование инкрементальной компиляции)) 

[_sda 0]

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

ну это она и есть) т.е. не использование инкрементальной компиляции)) 

Вы говорите загадками.

Т.е. вы предлагаете отказаться от партиций?

[des00 25]

Just now, _sda said:

Вы говорите загадками.

Т.е. вы предлагаете отказаться от партиций?

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

ЗЫ. Отказался от использования этого, глючная система, в альтеровском исполнении, ИМХО. 

[_sda 0]

4 минуты назад, des00 сказал:

 собирать нетлист с нуля каждый раз.

Этим я и занимаюсь, только забодался уже...

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

Совсем не факт что остальные скоростные модули не "разбегутся" по слэкам. Как думаете?

[des00 25]

15 minutes ago, _sda said:

Этим я и занимаюсь, только забодался уже...

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

Совсем не факт что остальные скоростные модули не "разбегутся" по слэкам. Как думаете?

думаю что разбегутся в процессе. можно пробовать лочить регионы или их физически. Но я бы модули правил, добил бы регистров где можно, подкрутил бы фанауты, глянул бы то, как ложиться написанное на целевую плис. А вот так... вы одно крутите, второе ломается. смысл.. 

[_sda 0]

3 минуты назад, des00 сказал:

думаю что разбегутся в процессе. можно пробовать лочить регионы или их физически. Но я бы модули правил, добил бы регистров где можно, подкрутил бы фанауты, глянул бы то, как ложиться написанное на целевую плис. А вот так... вы одно крутите, второе ломается. смысл.. 

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

 

33 минуты назад, des00 сказал:

ЗЫ. Отказался от использования этого, глючная система, в альтеровском исполнении, ИМХО. 

За это откровение спасибо, а то я уж подумал что только у меня да у new123 есть эта проблема.

[new123 0]

Ради интереса, какого прироста в компиляции добились при инкрементной? Хочется сказать, что съел на этом собаку, но пока не скажу. Я проводил широкомасштабные эксперименты по компиляции. Разные сервера: многоядерный (>10 ядер), среднеядерный (<10 ядер), обычный i3 c двумя физическими ядрами. Применял разные фишки в квартусе: партиции, залоченные партиции, без партиций. Что то может еще, надо посмотреть (Compile Time Advisor).. Короче все эти фишки квартуса для меня яйца выделенного не стоит. Если "очищенный" проект собирает в районе 68 минут. То применив все все все фишки по сокращению времени компиляции я выгадал максимум 15-20 мин. Чем сложнее проект делаешь, чем сложнее ставишь партиции для перекомпиляции, тем это время ниже. В итоге получаешь неведомо что.. То по слакам просядешь, то чип забьешь, а точнее и то и другое сразу.

Лучше посадить на многоядерную машину, если есть такая возможность. Она режет время в разы. Кстати на форуме часто читал, что лучше частота ядер, чем их кол-во. Но я лучше покомпилю на 14 ядрах 2600MHz, чем на двух 3500Mhz. Один час против четырех все же есть разница.

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