В статье много недосказанного, похоже на вредные советы. Про клоковые ресурсы вообще ни слова. Затактировать внешнее устройство на килогерцы такой поделкой ещё наверно можно, но не более того. Попытка затактировать таким внутреннюю логику ПЛИС наверно будет неплохим упражнением на знакомство с клоковой инфраструктурой и констрейнтами.
В чём недобросовестность? Идёт конкуренция на уровне экосистем. AMD и Intel хотят сфокусировать свою экосистему. Это должно повысить пользу их продуктов для конечных юзеров.
Не увеличение качества. Не снижение проблем. Не понижение цен. Не увеличение сроков поддержки.
Консолидация может решить все эти вопросы для x86.
Кроме того, происходящее потребует от участников экосистемы ARM дополнительных усилий для повышения пользы от своих продуктов. В целом, от разгорающейся конкурентной борьбы будет профит как конечным пользователям, так и участникам этой борьбы. Как минимум будет стимул улучшать продукты.
"Искусство войны" достаточно сухой и сжатый трактат, эдакая имперская методичка Древнего Китая. Имхо, шикарной исторической иллюстрацией очень многих концептов из неё является "Троецарствие" Ло Гуаньчжуна. Кстати, у римлян была своя подобная имперская методичка "Стратагемы. Военные хитрости" С. Фронтина.
Правда ни разу не сталкивался чтобы такое кто-то что-то делал и где бы это было реально востребовано, а не чисто в академических интересах)
В Alveo и прочих подобных карточках для датацентров широко используется эта тема. Например Amazon F1 такое юзает. В плисине организуется фиксированный регион shell с системной логикой и реконфигурируемый регион для пользовательской логики. В частности это используется например, чтобы сдавать подобные инстансы в аренду -- пользователь арендует на пару часов такое и гоняет образы, не влияя на других. В одной физической плисине могут бегать ядра разных пользователей.
При этом софтвер для синтеза Xilinx Vivado, который используется для Artix-7 FPGA на Nexys A7 - работает в несколько раз медленнее, чем софтвер Gowin EDA, который используется для Gowin FPGA на плате Марсоход3GW2.
Так ведь и размеры оптимизационных задач, которые решают EDA в обоих случаях отличаются во много раз. На нексусе заведомо более мощные и навороченные плисины -- artix 50 или artix 100, которые содержат 32000 или 64000 6-входовых LUT, 240 DSP-слайсов, а на gowin-e всего порядка 8000 4-входовых LUT и 20 DSP-слайсов.
Есть несколько успешных атак, упомянутая с Usenix выглядит самой простой по оборудованию и квалификации. Пожалуй, такое сможет студент на диплом.
Существенным ограничением этой атаки выглядит необходимость доступа к загрузочным интерфейсам FPGA и к зашифрованному битстриму. Во многих случаях это означает физический доступ к портам плисины и внутренностям системы, что ограничивает размах устройствами, до которых сможет дотянуться и разобрать атакующий. Скорее всего поэтому в упомянутом выше ответе Xilinx считает эту атаку одного уровня с DPA.
Эта особенность 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. Эти алгоритмы порождают серию допущений и предположений, на которых строится вся дальнейшая реализация. Поэтому возможно на других допущениях такая производительная вещь не соберётся.
Кроме того, этот процессор многими вещами заточен на высокую производительность, есть ощущение, что его целиком выстрадали под эту цель, на всех уровнях. Переделка под другие цели даст что-то среднее.
В статье много недосказанного, похоже на вредные советы. Про клоковые ресурсы вообще ни слова. Затактировать внешнее устройство на килогерцы такой поделкой ещё наверно можно, но не более того. Попытка затактировать таким внутреннюю логику ПЛИС наверно будет неплохим упражнением на знакомство с клоковой инфраструктурой и констрейнтами.
В чём недобросовестность? Идёт конкуренция на уровне экосистем. AMD и Intel хотят сфокусировать свою экосистему. Это должно повысить пользу их продуктов для конечных юзеров.
Консолидация может решить все эти вопросы для x86.
Кроме того, происходящее потребует от участников экосистемы ARM дополнительных усилий для повышения пользы от своих продуктов.
В целом, от разгорающейся конкурентной борьбы будет профит как конечным пользователям, так и участникам этой борьбы. Как минимум будет стимул улучшать продукты.
"Искусство войны" достаточно сухой и сжатый трактат, эдакая имперская методичка Древнего Китая. Имхо, шикарной исторической иллюстрацией очень многих концептов из неё является "Троецарствие" Ло Гуаньчжуна.
Кстати, у римлян была своя подобная имперская методичка "Стратагемы. Военные хитрости" С. Фронтина.
В Alveo и прочих подобных карточках для датацентров широко используется эта тема. Например Amazon F1 такое юзает.
В плисине организуется фиксированный регион shell с системной логикой и реконфигурируемый регион для пользовательской логики. В частности это используется например, чтобы сдавать подобные инстансы в аренду -- пользователь арендует на пару часов такое и гоняет образы, не влияя на других. В одной физической плисине могут бегать ядра разных пользователей.
Это уже ближе к Artix7-200, такое определенно интереснее в контексте скоростей EDA.
Так ведь и размеры оптимизационных задач, которые решают EDA в обоих случаях отличаются во много раз. На нексусе заведомо более мощные и навороченные плисины -- artix 50 или artix 100, которые содержат 32000 или 64000 6-входовых LUT, 240 DSP-слайсов, а на gowin-e всего порядка 8000 4-входовых LUT и 20 DSP-слайсов.
Соглашусь, что с прошиватором атака выглядит проще чем с DPA и осциллографом.
Есть несколько успешных атак, упомянутая с Usenix выглядит самой простой по оборудованию и квалификации. Пожалуй, такое сможет студент на диплом.
Существенным ограничением этой атаки выглядит необходимость доступа к загрузочным интерфейсам FPGA и к зашифрованному битстриму. Во многих случаях это означает физический доступ к портам плисины и внутренностям системы, что ограничивает размах устройствами, до которых сможет дотянуться и разобрать атакующий. Скорее всего поэтому в упомянутом выше ответе Xilinx считает эту атаку одного уровня с DPA.
Да. И она экономит много времени имплементации, иногда процентов 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, которые на наших глазах творят революцию в ИИ.