_sda 0 24 февраля, 2020 Опубликовано 24 февраля, 2020 · Жалоба Коллеги заметил одну неприятность в Квартусе 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 26 февраля, 2020 Опубликовано 26 февраля, 2020 · Жалоба У меня в 19 такая же штука. При инкрементной последующей компиляции пухнет проект и значение SLACK падает процентов на 5-8%. Думал это норм. Поэтому пробную компиль делаю инкремент, а боевую версию - зачищаю всю бд и компилю с нуля Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 26 февраля, 2020 Опубликовано 26 февраля, 2020 · Жалоба 4 минуты назад, new123 сказал: У меня в 19 такая же штука. При инкрементной последующей компиляции пухнет проект и значение SLACK падает процентов на 5-8%. Думал это норм. Поэтому пробную компиль делаю инкремент, а боевую версию - зачищаю всю бд и компилю с нуля Спасибо! Похоже что-то у них с инкрементальной компиляцией не срослось... А вот в Q13,емнип, такого не было. Видно новеньких в штат набрали... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба Коллеги, случайно обратил внимание на рекурсию в структуре проекта. Похоже с этим и связано распухание проекта. Обратите внимание что модуль dsp_nb в структуре указан два раза! Причём dsp_nb размером 66705 алм якобы входит в состав top_filter_nb размером 29779 алм. Пересборка проекта ничего не даёт. Никто у себя такого не замечал? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
new123 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба Сподвигло меня еще раз погуглить по альтеровскому форуму. С запросом "incrimental compilation" и сраза наткнулся на тему похожую с комментарием и объяснением https://forums.intel.com/s/question/0D50P00003yyMxWSAU/logic-utilization-with-incremental-compilation?language=en_US Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 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 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 23 minutes ago, _sda said: А тут ещё непонятная рекурсия...Вопрос остаётся открытым. линейная сборка ваше все) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 2 минуты назад, des00 сказал: линейная сборка ваше все) Это как? Я в проекте никакую рекурсию не закладывал.... После убивания баз всё выглядит замечательно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 18 minutes ago, _sda said: Это как? Я в проекте никакую рекурсию не закладывал.... После убивания баз всё выглядит замечательно. ну это она и есть) т.е. не использование инкрементальной компиляции)) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 6 минут назад, des00 сказал: ну это она и есть) т.е. не использование инкрементальной компиляции)) Вы говорите загадками. Т.е. вы предлагаете отказаться от партиций? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба Just now, _sda said: Вы говорите загадками. Т.е. вы предлагаете отказаться от партиций? какие загадки, у вас глючит инкрементальная компиляция, значит надо ее отключить и собирать нетлист с нуля каждый раз. больше моделировать и анализировать, чтобы время сэкономить. Вы, по сути, стирая базу, это и делаете. Оцените что больше от использования вами инкрементальной компиляции: выигрыша от частых сборок для отладки или проигрыша от постоянных ловли мух и багов инкрементальной компиляции и примите решение. ЗЫ. Отказался от использования этого, глючная система, в альтеровском исполнении, ИМХО. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 4 минуты назад, des00 сказал: собирать нетлист с нуля каждый раз. Этим я и занимаюсь, только забодался уже... Вот такой пример: есть в проекте пять скоростных модулей, четыре проходят по слэкам, а один нет. С партишининами я могу крутить seed только для конкретного модуля, а без них буду крутить для всего проекта. Совсем не факт что остальные скоростные модули не "разбегутся" по слэкам. Как думаете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 15 minutes ago, _sda said: Этим я и занимаюсь, только забодался уже... Вот такой пример: есть в проекте пять скоростных модулей, четыре проходят по слэкам, а один нет. С партишининами я могу крутить seed только для конкретного модуля, а без них буду крутить для всего проекта. Совсем не факт что остальные скоростные модули не "разбегутся" по слэкам. Как думаете? думаю что разбегутся в процессе. можно пробовать лочить регионы или их физически. Но я бы модули правил, добил бы регистров где можно, подкрутил бы фанауты, глянул бы то, как ложиться написанное на целевую плис. А вот так... вы одно крутите, второе ломается. смысл.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 · Жалоба 3 минуты назад, des00 сказал: думаю что разбегутся в процессе. можно пробовать лочить регионы или их физически. Но я бы модули правил, добил бы регистров где можно, подкрутил бы фанауты, глянул бы то, как ложиться написанное на целевую плис. А вот так... вы одно крутите, второе ломается. смысл.. Да я просто описал какой вижу смысл в партициях,конечно при условии что этот механизм работает безглючно. Попробую оставить партиции только для самых-самых ответственных узлов, совсем убирать как то стрёмно, застопорюсь со слэками. 33 минуты назад, des00 сказал: ЗЫ. Отказался от использования этого, глючная система, в альтеровском исполнении, ИМХО. За это откровение спасибо, а то я уж подумал что только у меня да у new123 есть эта проблема. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
new123 0 10 апреля, 2020 Опубликовано 10 апреля, 2020 (изменено) · Жалоба Ради интереса, какого прироста в компиляции добились при инкрементной? Хочется сказать, что съел на этом собаку, но пока не скажу. Я проводил широкомасштабные эксперименты по компиляции. Разные сервера: многоядерный (>10 ядер), среднеядерный (<10 ядер), обычный i3 c двумя физическими ядрами. Применял разные фишки в квартусе: партиции, залоченные партиции, без партиций. Что то может еще, надо посмотреть (Compile Time Advisor).. Короче все эти фишки квартуса для меня яйца выделенного не стоит. Если "очищенный" проект собирает в районе 68 минут. То применив все все все фишки по сокращению времени компиляции я выгадал максимум 15-20 мин. Чем сложнее проект делаешь, чем сложнее ставишь партиции для перекомпиляции, тем это время ниже. В итоге получаешь неведомо что.. То по слакам просядешь, то чип забьешь, а точнее и то и другое сразу. Лучше посадить на многоядерную машину, если есть такая возможность. Она режет время в разы. Кстати на форуме часто читал, что лучше частота ядер, чем их кол-во. Но я лучше покомпилю на 14 ядрах 2600MHz, чем на двух 3500Mhz. Один час против четырех все же есть разница. Изменено 10 апреля, 2020 пользователем new123 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться