Comments 26
А Вы не в курс о причинах почему одна и та же версия Quartus даже на разных ОС собирает по разному, вроде бы как ожидается некая детерминированность. Просто никогда не собирал на Linux, открытие для меня такое поведение.
В разных ОС вызовы системных функций реализованы по-разному. У Linux свой API, у винды - свой. Поэтому и разница. А если вы не меняете ОС и версию IDE - то производитель гарантирует детерминированность. То есть выходные файлы будут бит-в бит идентичными.
Поэтому и разница.
Звучит как "вызовы системных функций реализованы по-разному, потому и сортировка даёт разные результаты".
Во-1, была задана заведомо недостижимая цель по частоте и в таком случае нет никакой гарантии, что софт всё ещё попытается выжать максимум, во-2 видимо, "понимая это" (при помощи каких-нибудь эвристических алгоримтов) софт ограничивает попытки фиттинга ну например каким-то временем (везде разным), и тут вылезает и рандом, и разница между машинами/виртуалками/etc.
В своих догадках мы можем опираться на документацию производителя. А производители говорят нам, что используют так называемый "timing driven" синтез и имплементацию. https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/logicops/logicops/def_synth_timing_driven_synthesis.htm
https://docs.amd.com/r/en-US/ug904-vivado-implementation/Routing
Это означает, что среда будет использовать тем более сложные и времязатратные алгоритмы, чем более высокие таргеты по частоте мы задаем.
А если цели добиваться высоких частот нет - среда будет экономить время и завершит сборку. Хотя возможности дополнительной оптимизации дизайна у нее еще есть
У меня был случай с ice40 (Lattice). Делал проект под заказ. Собирал у себя под линуксом на iceCube2, всё прекрасно работало. Собирали той же самой версией iceCube2 у заказчика под виндой. Не работало. Выходные файлы бит в бит разумеется не совпадали. Не знаю как фирма-производитель тестировала собственный софт... Кончилось тем, что стали собирать инструментами проекта iceStorm. Тот давал одинаковые результаты и под линуксом и под виндой.
А если вы не меняете ОС и версию IDE - то производитель гарантирует детерминированность.
Не совсем. Ещё недетерминированность даёт многопоточность. Если собираете несколькими потоками, то например в Vivado могут быть разные результаты из-за недетерминированности порядка завершения потоков и "сшивания" результата. В целом, хорошее обсуждение повторяемости для одного из вендоров есть здесь.
Плюс Вам в карму за Makefile.
В данном случае мы получили почти двукратный прирост в производительности прошивки ПЛИС, просто поменяв машину, на которой собираем релиз!
Вы сравнивали полученные прошивки на железе? В реальности какое совпадение расчетного быстродействия с действительным?
По-моему , это, как минимум, странно, что ОС виртуальной сборки влияет на быстродействие конечной прошивки.
Возможно, что 200 при сборке под Windows равно в железе 250 при сборке под Linux.
Возможно, что 200 при сборке под Windows равно в железе 250 при сборке под Linux.
Вполне логичное рассуждение. В IDE встроен временной анализатор, который делает для нас расчеты слеков и Fmax. Полное знание о том, как делаются эти расчеты, и какой там уровень пессимизма заложен - есть только у производителя. Нам ничего не остается, кроме как доверять этим отчетам
Как вы предлагаете проверить "действительную" производительность? Что и чем измерять? =)
Навскидку.
1) спросил бы у разработчиков IDE. Они, как минимум, должны доказать, что их IDE проектируют реальное, а не фантастику. Т е у них должны быть тесты оценки ошибок проектирования.
2) Сделал бы серию тестовых разработок от простого к сложному для Win и Linux и оценил различие реального и виртуального.
------------------
Но, как минимум, странно, что Вы не тестируете реальную производительность и не проверяете реальность виртуальных устройств.
"Если на клетке слона прочтешь надпись «буйвол», не верь глазам своим."
Козьма Прутков
Но, как минимум, странно, что Вы не тестируете реальную производительность и не проверяете реальность виртуальных устройств.
Странно было бы это делать. Коммерческие EDA для ПЛИС -- это тщательно отлаженный в части алгоритмов софт. В него вложены десятки лет исследований и миллиарды долларов денег. ПЛИС работают в медицине, энергетике и прочей критической инфраструктуре, в науке и т.д. Если бы там были такие ошибки, как вы предполагаете, то вендоров EDA давно бы засыпали исками и мы бы это не обсуждали. Так что лучше исходить, что железо при заданных температурных и прочих условиях будет работать корректно на тех частотах, что показывает EDA.
Тогда тем более странно, что Вы получаете под разными ОС разные результаты и полагаете, что это будет так же на реальном железе.
Скорее всего, что на разных ОС получается разный масштаб оценки времени работы вашей прошивки. Тогда у Вас время измеряется в попугаях. На винде - это зеленые попугаи, а на Линукс синие. И они разные по цвету.
Давайте немного отвлечемся от ОС и начнем с другого:
Пускай ОС и версия IDE одна и та же. Берем два одинаковых проекта и собираем их с разными SEED. Логика раскладывается на чипе различным образом, и поэтому в отчетах тайминга видим различные Fmax. Логично?
Теперь собираем одинаковые проекты в разных версиях IDE на одной ОС, SEED не трогаем. Разные версии среды отличаются версиями библиотек, или, может, какими-то настройками, реализацией алгоритмов, наличием или отсутствием дополнительных шагов оптимизации. Снова получим различную разводку логики на кристалле и разные Fmax
Ну и возвращаемся к ОС. Снова берем два идентичных проекта. Как и в случае 2, на процесс сборки будут влиять внешние условия. Расстановка примитивов на кристалле снова будет отличаться, что повлияет на Fmax
В итоге, на Fmax во всех рассмотренных случаях влияет один фактор - физическое расположение примитивов и связей между ними. Механизм одинаковый во всех трех случаях. Считать, что расчеты временного анализатора в одной из ОС "подкручены" - это из разряда теорий заговора =)
Скорее всего, что на разных ОС получается разный масштаб оценки времени работы вашей прошивки. Тогда у Вас время измеряется в попугаях. На винде - это зеленые попугаи, а на Линукс синие. И они разные по цвету.
Скорее всего, Вы мало знакомы с ПЛИС и софтом для разработки под них. Это не упрек лично Вам, тут скорее претензия к автору.
Все эти методики "гаданий на сиде" и так ограниченно применимы и, главное, вызывают уныние напоминанием завимости разработчика прошивок ПЛИС от вещи в себе - проприетарной среды разработки, которая не во всех моментах адекватно задокументирована, и которую в большинстве случаев невозможно заменить.
А попытка об этом рассказать в краткой статье, в том числе и тем, кто не ходит сам по этим граблям, местами на ощупь в потемках, создает привратное впечатление "мартышек, дергающих ручки оргАна, наугад в ожидание симфонии". Такой подход тоже бывает, и чаще чем хотелось бы. Но спешу заверить господ софтварных программистов - в RTL программирование недостаток квалификации и обмена опытом(в силу малочисленностии, специфичности, обьективной закрытости, отсутствия 300какосекунд) частично компенсируется реалтаймом выполнения и необходимостью взаимодействия с физическим миром. Вообщем откровенные мартышки "х..к, х..к и в продакшен" прилично отсеиваются на начальном этапе.
Тогда тем более странно, что Вы получаете под разными ОС разные результаты и полагаете, что это будет так же на реальном железе.
Но ведь не странно. Имплементация проекта, place & route -- это NP-полная задача. Поэтому лучшее решение без полного перебора найти сложно, но можно попытаться к нему приблизиться с помощью эвристик. На разных постановках будут построены разные решения. То, какое решение получится, существенно зависит от начальных условий, в том числе от порядка обхода, доступных ресурсов, порядка окончания подзадач и т.д. Даже в пределах одной ОС и одной среды разница обязательно будет на многопоточке, о чём упоминал раньше. По поводу ресурсов, насколько понимаю, в зависимости от свободной памяти/кэша тулза будет выбирать на какие порции разбивать задачу и отсюда тоже выползут различия. Возможно, в примере выше разница в том, что линукс выделяет немного больше памяти для тулзы.
Итого: имеем разные начальные постановки для задачи, которая существенно зависит от начальных условий, отсюда пляшут и все остальные различия. В результате получаем разные правильные решения одной и той же задачи, которые удовлетворяют таймингам и прочим констрейтам. Побитовое совпадение прошивок можно рассматривать как ещё один констрейнт, который как минимум некоторые тулы не соблюдают до тех пор, пока специально их об этом не попросишь.
Скорее всего, что на разных ОС получается разный масштаб оценки времени работы вашей прошивки.
Это не так. Масштаб один и тот же. В документации есть инструкции как получить побитовое совпадение на разных ОС.
Если я правильно понял, то в результате на разных ОС получились разные конфигурации железа и разные прошивки. И эти разности порождаются не параметрами IDE, не исходными данными, а особенностями исполнения IDE в конкретной ОС.
Если так, то вообще ничего не понятно, по какой причине одна и та же IDE с одинаковыми параметрами и алгоритмом дает различные прошивки в зависимости от ОС.
Ведь при исполнении задачи (одной задачи, без просмотра одновременно кино и игры в виртуальную реальность), ОС вообще не влияет на алгоритм задачи(IDE).
Но если разработчикам все это устраивает, то пусть будет так как есть. Успехов в изучении особенностей ОС.
Если я правильно понял, то в результате на разных ОС получились разные конфигурации железа и разные прошивки.
Да.
Ведь при исполнении задачи (одной задачи, без просмотра одновременно кино и игры в виртуальную реальность), ОС вообще не влияет на алгоритм задачи(IDE).
Влияние есть. Если упрощенно, то в ходе размещения на кристалле EDA разобьёт проект на планарные куски, каждый кусок будет размещаться/разводиться отдельно, например отдельным потоком. Затем результаты будут сшиты вместе как лоскутное одеяло. В зависимости от порядка завершения потоков на швах будут различия. Они обычно непринципиальны, но побитово прошивки получатся разные. Порядок завершения потоков зависит от ОС и от прочих вещей. Если все задачи выполняются на одном потоке, то различий на швах не будет.
Ещё одна причина скорее всего в размерах кусков, на которые разбивается задача. Насколько могу судить они как-то связаны с размером доступной оперативы и/или с размером кэша. Это тоже место соприкосновения с ОС.
В зависимости от порядка завершения потоков на швах будут различия.
Эта особенность IDE указана разработчикам в документации?
Как минимум должно быть указано, а еще лучше в самом IDE устанавливается приоритет решения задач в потоках. В любом случае разработчики должны это знать и предупреждать клиентов о сюрпризах.
Если этого нет в документации то это ошибка IDE. Я бы выкатил претензию разработчикам,либо попросил их решить указанную проблему, а не занимался изучением влияния погоды на движение луны.
В зависимости от порядка завершения потоков на швах будут различия. Они обычно непринципиальны, но побитово прошивки получатся разные.
Ну, да. Судя по статье, 20% быстродействия - это по Вашему "непринципиально"?
Эта особенность IDE указана разработчикам в документации?
Да. И она экономит много времени имплементации, иногда процентов 40-50. Если имплементация занимает час или 3 часа, то это ощутимо.
Ну, да. Судя по статье, 20% быстродействия - это по Вашему "непринципиально"?
Добро пожаловать в мир NP-полных задач. Эвристики не обещают всегда строить оптимальные решения. Но опытный инженер всегда найдёт, где добыть пару лишних процентов. По поводу конкретно 20%, конечно есть ещё вопрос к постановке эксперимента, соблюдены ли системные требования вендора по оперативе и т.д. EDA может не построить качественное решение, если на слабом железе пытаться имплементировать.
Я с Вами согласен. Но статью-то написали не дилетанты, а спецы из компании YADRO. Поэтому и удивляюсь и задаю вопросы.
Какая-то лютая ерунда написана про "зависимость от ОС".
Сравнивайте одинаковые версии с одинаковыми настройками и будет всё совпадать в пределах дёрганий генератора случайных чисел, который обильно используется в процессе P&R. На вашем же графике видно, что на обеих ОС результаты как 17-ых так и 20-ых версий в одних и тех же коридорах колеблются.
Вполне ожидаемо что старенькая 13-я версия хуже умеет в P&R и что агрессивные настройки дают прирост. Включите эти агрессивные настройки в 20-й версии на Win и получите статистически похожий результат.
Поправьте пожалуйста эту часть в статье чтобы людей в заблуждение не вводить. Особенно тех, кто судя по комментариям слабо понимает откуда этот Fmax получается.
Ох, Вашими бы устами... Когда-то давно получили класс новых компьютеров одной конфигурации, клонировали на них одну копию ОС. Ради интереса запустил на них компиляцию базового проекта на Nios (без перегенерации в QSys, с одинаковыми настройками - это важно). И получил на вех разные результаты по объему и быстродействию.
А как-то при переходе с Quartus 9 на 10 он перестал пробрасывать связь по DirectLink между соседними блоками и стал разбрасывать логику сложного счетчика вообще по блокам в разных строках и столбцах. Мне стало интересно, решил его заставить и сделал область LogicLock в два блока рядом в одной строке. Так он провел по строке межсоединений и все равно не использовал DirectLink. Такие вещи случаются редко, обычно следующие версии собирают проекты лучше, но все же - если есть готовый рабочий проект, лучше бы сохранить версию софта, в котором его собирали. И да, в новых версиях могут не только улучшаться алгоритмы, но и уточняться временные модели устройств, что также повлечет уточнение (как правило, повышение) быстродействия.
Design Space Explorer — отличная утилита, но она работает только с проектами для ПЛИС Intel/Altera. Прямых аналогов от других производителей я не знаю.
У Xilinx похожая функциональность есть для чипов 6-ой и более ранних серий - SmartXplorer.
Итеративная сборка FPGA-проектов