Эта особенность IDE указана разработчикам в документации?
Да. И она экономит много времени имплементации, иногда процентов 40-50. Если имплементация занимает час или 3 часа, то это ощутимо.
Ну, да. Судя по статье, 20% быстродействия - это по Вашему "непринципиально"?
Добро пожаловать в мир NP-полных задач. Эвристики не обещают всегда строить оптимальные решения. Но опытный инженер всегда найдёт, где добыть пару лишних процентов. По поводу конкретно 20%, конечно есть ещё вопрос к постановке эксперимента, соблюдены ли системные требования вендора по оперативе и т.д. EDA может не построить качественное решение, если на слабом железе пытаться имплементировать.
Если я правильно понял, то в результате на разных ОС получились разные конфигурации железа и разные прошивки.
Да.
Ведь при исполнении задачи (одной задачи, без просмотра одновременно кино и игры в виртуальную реальность), ОС вообще не влияет на алгоритм задачи(IDE).
Влияние есть. Если упрощенно, то в ходе размещения на кристалле EDA разобьёт проект на планарные куски, каждый кусок будет размещаться/разводиться отдельно, например отдельным потоком. Затем результаты будут сшиты вместе как лоскутное одеяло. В зависимости от порядка завершения потоков на швах будут различия. Они обычно непринципиальны, но побитово прошивки получатся разные. Порядок завершения потоков зависит от ОС и от прочих вещей. Если все задачи выполняются на одном потоке, то различий на швах не будет.
Ещё одна причина скорее всего в размерах кусков, на которые разбивается задача. Насколько могу судить они как-то связаны с размером доступной оперативы и/или с размером кэша. Это тоже место соприкосновения с ОС.
Тогда тем более странно, что Вы получаете под разными ОС разные результаты и полагаете, что это будет так же на реальном железе.
Но ведь не странно. Имплементация проекта, place & route -- это NP-полная задача. Поэтому лучшее решение без полного перебора найти сложно, но можно попытаться к нему приблизиться с помощью эвристик. На разных постановках будут построены разные решения. То, какое решение получится, существенно зависит от начальных условий, в том числе от порядка обхода, доступных ресурсов, порядка окончания подзадач и т.д. Даже в пределах одной ОС и одной среды разница обязательно будет на многопоточке, о чём упоминал раньше. По поводу ресурсов, насколько понимаю, в зависимости от свободной памяти/кэша тулза будет выбирать на какие порции разбивать задачу и отсюда тоже выползут различия. Возможно, в примере выше разница в том, что линукс выделяет немного больше памяти для тулзы.
Итого: имеем разные начальные постановки для задачи, которая существенно зависит от начальных условий, отсюда пляшут и все остальные различия. В результате получаем разные правильные решения одной и той же задачи, которые удовлетворяют таймингам и прочим констрейтам. Побитовое совпадение прошивок можно рассматривать как ещё один констрейнт, который как минимум некоторые тулы не соблюдают до тех пор, пока специально их об этом не попросишь.
Скорее всего, что на разных ОС получается разный масштаб оценки времени работы вашей прошивки.
Это не так. Масштаб один и тот же. В документации есть инструкции как получить побитовое совпадение на разных ОС.
А если вы не меняете ОС и версию IDE - то производитель гарантирует детерминированность.
Не совсем. Ещё недетерминированность даёт многопоточность. Если собираете несколькими потоками, то например в Vivado могут быть разные результаты из-за недетерминированности порядка завершения потоков и "сшивания" результата. В целом, хорошее обсуждение повторяемости для одного из вендоров есть здесь.
Но, как минимум, странно, что Вы не тестируете реальную производительность и не проверяете реальность виртуальных устройств.
Странно было бы это делать. Коммерческие EDA для ПЛИС -- это тщательно отлаженный в части алгоритмов софт. В него вложены десятки лет исследований и миллиарды долларов денег. ПЛИС работают в медицине, энергетике и прочей критической инфраструктуре, в науке и т.д. Если бы там были такие ошибки, как вы предполагаете, то вендоров EDA давно бы засыпали исками и мы бы это не обсуждали. Так что лучше исходить, что железо при заданных температурных и прочих условиях будет работать корректно на тех частотах, что показывает EDA.
А кстати (отвлекаясь от темы конкретно Эдиков) - очень интересно - как сделать, чтобы из микросхемы нельзя было извлечь закрытый ключ? Если предположить, что микросхема у нас в руках, распаяна?
В некоторых микросхемах, например в ПЛИС Xilinx и прочих, есть память ключей (для шифрования прошивки). Что-то такое может быть использовано и в вашей микросхеме. У Xilinx это Battery Backed RAM (встроенная оперативная память на внешней батарейке) или eFUSE (пережигаемые перемычки). В первом случае, если микросхема у вас в руках -- то ключ уже потерян и его не восстановить. Во втором случае, можно попробовать специальным дорогим рентгеном и электронной микроскопией что-то посмотреть, но тоже не факт, там из 4000 фьюзов используются только 288, так что придётся ещё реверсить, перебирать и думать, какие из них ключ. В общем, без хороших бюджетов, доступа к оборудованию и мотивации скорее всего оба способа сработают.
Для цифровой подписи надо выработать пару секретный/открытый ключ. Открытым ключом подпись будут проверять, секретным ставить. Для формирования этой пары надо этот алгоритм.
Еще про "цифровую подпись, гарантирующую неизменяемость". Никаких данных (по крайней мере, в "полной инструкции") - на чем это основано. Подозреваю, что это просто метаданные файла WAV типа "Запись сделана 17.06.2024 в 21-07 диктофоном Эдик СР№ 123456" Ну, в лучшем случае, к метеданным хэш файла добавят. Т.е. эти метаданные любым редактором можно изменить и снова на Эдик записать.
Обычно это основано на математике и криптографии с открытым ключом. Можно менять всё, что хотите, но если у вас нет секретного ключа, то подделать подпись не сможете. Секретный ключ скорее всего только в девайсе и его не извлечь.
Что вы мне посоветуете изучить, чтобы я написал об этом исследование?
Возможно, ответ есть в формулировке. Выглядит, как будто это студент старших курсов, выбирающий тему диплома или магистерской, но не совсем из своей области. Кажется, что человек пытается оценить трудозатраты, реализуемость и т.д. пока есть время и нет обязательств. Место, где не надо сдавать кодинг-интервью -- это запросто может быть кафедра или исследовательская лаборатория универа. Причины могут быть разные: откос от армии, тёплое место и т.д. и т.п.
Во времена Alpha (середина 1990-х) эти трюки не считались важными, дизайнеры их не использовали, и это вероятно главная причина, почему Alpha жрала больше чем могла бы для своей частоты и техпроцесса.
Clock-gating в какой-то форме всё же был в Alpha. Есть статейка интересная на тему устройства клоков в этих процессорах (в открытом доступе тоже гуглится).
2) Почему они сказали что сделать low-power невозможно, они про их конкретную микроархитектурную реализацию?
Имхо, Alpha очень богата трюками, даже слишком. Мне кажется, проблема с переделкой Alpha в том, что многое на самом низком уровне (та же сеть клоков) рождено своими кустарными алгоритмами до нормальных EDA. Эти алгоритмы порождают серию допущений и предположений, на которых строится вся дальнейшая реализация. Поэтому возможно на других допущениях такая производительная вещь не соберётся.
Кроме того, этот процессор многими вещами заточен на высокую производительность, есть ощущение, что его целиком выстрадали под эту цель, на всех уровнях. Переделка под другие цели даст что-то среднее.
Круто! Если не секрет, какие получились характеристики: сколько оно заняло по ресурсам (ПЛИС), на какой частоте, какую производительность в МБ/с имеет?
Разговор про ничтожную стоимость ошибки, как в программировании.
Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны))
Также должны учитываться издержки на 1 итерацию и скорость итераций, как быстро может быть получена ценность. FPGA по этим критериям позволяют приблизиться к гибким методологиям в софте, получать рабочие промежуточные результаты, адаптироваться к изменениям в требованиях и тестировать в приближенных к реальным условиях. Частые итерации позволяют снизить стоимость ошибки и уменьшить требования к кадрам.
Насколько понял, Catapult где-то тогда разделился на ветку ускорителей ИИ Brainwave и ветку прочих ускорителей для Azure. Brainwave что-то исследовали, поначалу что-то получалось, но сейчас уже всё, уступили место GPU. В Azure ускорители ушли зарабатывать деньги в продакшн, поделившись ещё на какие-то ветки. Одна, Azure Boost примерно соответствует функциональности Catapult и здравствует до сих пор, но про исследования не слышно.
Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.
И всё же цена ошибки получается на порядки меньше цены ошибки для ASIC-ов, не правда ли? Ведь не требуется делать респин, выкладывая за это очередные миллионы долларов и месяца времени ожидания. Время обратной связи, имхо, критический фактор, в случае FPGA респин занимает от пары минут до нескольких часов. NRE существенно меньше в случае FPGA даже для сложной массовой аппаратуры, вот пример, где Microsoft делится своими восторгами по поводу скорости разработки хардвера, которая была у них при использовании FPGA. Их начинку Azure-карточек на всех стадиях делала команда из 5 FPGA-шников и горстки программистов.
Да. И она экономит много времени имплементации, иногда процентов 40-50. Если имплементация занимает час или 3 часа, то это ощутимо.
Добро пожаловать в мир NP-полных задач. Эвристики не обещают всегда строить оптимальные решения. Но опытный инженер всегда найдёт, где добыть пару лишних процентов. По поводу конкретно 20%, конечно есть ещё вопрос к постановке эксперимента, соблюдены ли системные требования вендора по оперативе и т.д. EDA может не построить качественное решение, если на слабом железе пытаться имплементировать.
Да.
Влияние есть. Если упрощенно, то в ходе размещения на кристалле EDA разобьёт проект на планарные куски, каждый кусок будет размещаться/разводиться отдельно, например отдельным потоком. Затем результаты будут сшиты вместе как лоскутное одеяло. В зависимости от порядка завершения потоков на швах будут различия. Они обычно непринципиальны, но побитово прошивки получатся разные. Порядок завершения потоков зависит от ОС и от прочих вещей. Если все задачи выполняются на одном потоке, то различий на швах не будет.
Ещё одна причина скорее всего в размерах кусков, на которые разбивается задача. Насколько могу судить они как-то связаны с размером доступной оперативы и/или с размером кэша. Это тоже место соприкосновения с ОС.
Но ведь не странно. Имплементация проекта, place & route -- это NP-полная задача. Поэтому лучшее решение без полного перебора найти сложно, но можно попытаться к нему приблизиться с помощью эвристик. На разных постановках будут построены разные решения. То, какое решение получится, существенно зависит от начальных условий, в том числе от порядка обхода, доступных ресурсов, порядка окончания подзадач и т.д. Даже в пределах одной ОС и одной среды разница обязательно будет на многопоточке, о чём упоминал раньше. По поводу ресурсов, насколько понимаю, в зависимости от свободной памяти/кэша тулза будет выбирать на какие порции разбивать задачу и отсюда тоже выползут различия. Возможно, в примере выше разница в том, что линукс выделяет немного больше памяти для тулзы.
Итого: имеем разные начальные постановки для задачи, которая существенно зависит от начальных условий, отсюда пляшут и все остальные различия. В результате получаем разные правильные решения одной и той же задачи, которые удовлетворяют таймингам и прочим констрейтам. Побитовое совпадение прошивок можно рассматривать как ещё один констрейнт, который как минимум некоторые тулы не соблюдают до тех пор, пока специально их об этом не попросишь.
Это не так. Масштаб один и тот же. В документации есть инструкции как получить побитовое совпадение на разных ОС.
Не совсем. Ещё недетерминированность даёт многопоточность. Если собираете несколькими потоками, то например в Vivado могут быть разные результаты из-за недетерминированности порядка завершения потоков и "сшивания" результата. В целом, хорошее обсуждение повторяемости для одного из вендоров есть здесь.
Странно было бы это делать. Коммерческие EDA для ПЛИС -- это тщательно отлаженный в части алгоритмов софт. В него вложены десятки лет исследований и миллиарды долларов денег. ПЛИС работают в медицине, энергетике и прочей критической инфраструктуре, в науке и т.д. Если бы там были такие ошибки, как вы предполагаете, то вендоров EDA давно бы засыпали исками и мы бы это не обсуждали. Так что лучше исходить, что железо при заданных температурных и прочих условиях будет работать корректно на тех частотах, что показывает EDA.
Извините, я не из этой конторы и никак с ней не связан. Ничего не могу сказать на этот счёт.
В некоторых микросхемах, например в ПЛИС Xilinx и прочих, есть память ключей (для шифрования прошивки). Что-то такое может быть использовано и в вашей микросхеме. У Xilinx это Battery Backed RAM (встроенная оперативная память на внешней батарейке) или eFUSE (пережигаемые перемычки). В первом случае, если микросхема у вас в руках -- то ключ уже потерян и его не восстановить. Во втором случае, можно попробовать специальным дорогим рентгеном и электронной микроскопией что-то посмотреть, но тоже не факт, там из 4000 фьюзов используются только 288, так что придётся ещё реверсить, перебирать и думать, какие из них ключ. В общем, без хороших бюджетов, доступа к оборудованию и мотивации скорее всего оба способа сработают.
Для цифровой подписи надо выработать пару секретный/открытый ключ. Открытым ключом подпись будут проверять, секретным ставить. Для формирования этой пары надо этот алгоритм.
Обычно это основано на математике и криптографии с открытым ключом. Можно менять всё, что хотите, но если у вас нет секретного ключа, то подделать подпись не сможете. Секретный ключ скорее всего только в девайсе и его не извлечь.
Возможно, ответ есть в формулировке. Выглядит, как будто это студент старших курсов, выбирающий тему диплома или магистерской, но не совсем из своей области. Кажется, что человек пытается оценить трудозатраты, реализуемость и т.д. пока есть время и нет обязательств.
Место, где не надо сдавать кодинг-интервью -- это запросто может быть кафедра или исследовательская лаборатория универа. Причины могут быть разные: откос от армии, тёплое место и т.д. и т.п.
Clock-gating в какой-то форме всё же был в Alpha. Есть статейка интересная на тему устройства клоков в этих процессорах (в открытом доступе тоже гуглится).
Имхо, Alpha очень богата трюками, даже слишком. Мне кажется, проблема с переделкой Alpha в том, что многое на самом низком уровне (та же сеть клоков) рождено своими кустарными алгоритмами до нормальных EDA. Эти алгоритмы порождают серию допущений и предположений, на которых строится вся дальнейшая реализация. Поэтому возможно на других допущениях такая производительная вещь не соберётся.
Кроме того, этот процессор многими вещами заточен на высокую производительность, есть ощущение, что его целиком выстрадали под эту цель, на всех уровнях. Переделка под другие цели даст что-то среднее.
Наверно поэтому её сейчас постоянно ставят в топовые роутеры и GPU, которые на наших глазах творят революцию в ИИ.
Полезная инфа, спасибо!
В примере из Электроникса, насколько понимаю, ограниченная постановка: хэшируют блоки фиксированной длины 64 байта, а не произвольной.
Интересная инфа, спасибо!
Круто! Если не секрет, какие получились характеристики: сколько оно заняло по ресурсам (ПЛИС), на какой частоте, какую производительность в МБ/с имеет?
Кстати, в недавнем анонсе Spartan Ultrascale+ (достаточно бюджетной плисины) Xilinx акцентировала внимание на 15+ годах поддержки своих моделей.
Также должны учитываться издержки на 1 итерацию и скорость итераций, как быстро может быть получена ценность. FPGA по этим критериям позволяют приблизиться к гибким методологиям в софте, получать рабочие промежуточные результаты, адаптироваться к изменениям в требованиях и тестировать в приближенных к реальным условиях. Частые итерации позволяют снизить стоимость ошибки и уменьшить требования к кадрам.
Насколько понял, Catapult где-то тогда разделился на ветку ускорителей ИИ Brainwave и ветку прочих ускорителей для Azure. Brainwave что-то исследовали, поначалу что-то получалось, но сейчас уже всё, уступили место GPU. В Azure ускорители ушли зарабатывать деньги в продакшн, поделившись ещё на какие-то ветки. Одна, Azure Boost примерно соответствует функциональности Catapult и здравствует до сих пор, но про исследования не слышно.
И всё же цена ошибки получается на порядки меньше цены ошибки для ASIC-ов, не правда ли? Ведь не требуется делать респин, выкладывая за это очередные миллионы долларов и месяца времени ожидания. Время обратной связи, имхо, критический фактор, в случае FPGA респин занимает от пары минут до нескольких часов. NRE существенно меньше в случае FPGA даже для сложной массовой аппаратуры, вот пример, где Microsoft делится своими восторгами по поводу скорости разработки хардвера, которая была у них при использовании FPGA. Их начинку Azure-карточек на всех стадиях делала команда из 5 FPGA-шников и горстки программистов.