Я предложил концепт, как получить UID для FPGA, в которой нет заводского UID.
Простите, может чего пропустил или не понял. Было интересно почитать конечно, но похожие вещи в зарубежной литературе уже 15 лет известны.
Но никто не спросил, как привязать его к определённому участку кремния для QUARTUS
Это вполне тривиальные вещи, location constraints похожи у разных вендоров +-.
Никто не спросил, сколько займёт ячеек в FPGA PUF, скажем, на 64 пары кольцевых генераторов с шифрованием
Такие вопросы конечно были, сколько оверхеда именно в вашей реализации добавляете конечно же интересно. Но примерно всё же порядок величин понятен. Кроме плисины интересно также сколько оверхеда требуется на весь обвес вне плисины: ethernet и прочий обвес для общения с сервером. Также интересно, сколько оверхеда на софт для этого всего обвеса -- это ведь тоже объем работ и деньги.
Я вообще не уверен, что описанное в статье можно отреверсить за приемлемое время, а если можно, то не ясно, как запатчить.
В датацентрах, где есть возможность арендовать FPGA-инстансы, существует задача обнаружения зловредных вещей в пользовательском битстриме. В частности, обнаружения PUF. Это надо, потому что такие PUF могут идентифицировать конкретную плисину, на которой крутятся прошивки нескольких пользователей (multi-tenant platform), а также вносить глитчи и/или перегревать/выводить из строя оборудование. Для решения этой задачи существуют тулзы типа FPGADefender. Т.е. в целом PUF в битстриме вполне себе ищутся. Обратите внимание, что это вещи из далёкого 2020 года, когда ещё не было вездесущего ИИ.
Также например здесь упоминаются атаки на PUF с навешиванием сотни Flip-flop, с помощью которых получалось предсказать ответ PUF-а.
Наконец, есть тузлы типа BITMAN, с помощью которых можно патчить битстримы плисин уровня UltraScale.
Имхо, технически это вполне решаемая задача, все компоненты с большего существуют.
Если копнуть, неподалёку от закона Ома будет Elmore delay, про которую можно узнать факультативно, чтобы представлять, как для этих облачков будут считаться тайминги и как работали EDA-тулы на низком уровне. Детишкам при знакомстве с RTL об этом точно знать не надо.
А случаем не в кэше использовали ее, до всей этой ИИ эпопеи?
Нет, HBM медленная для кэша, latency у неё так себе. До эпопеи её использовали в высокопроизводительных роутерах и в высокопроизводительных ПЛИС. Т.е. при решении достаточно нишевых задач.
Тема интересная и сложная. Если следите за историей, был когда-то стартап DeePhi. Там выпускники Стэнфорда и Цинхуа сделали компилятор, оптимизатор, квантизатор и прунер нейронок и раскладывали это всё на свое настраиваемое ядро DPU в FPGA. Фактически сделали полный стэк нейронок для FPGA с оптимизацией на всех уровнях. Потом их купил Xilinx за $250млн.
Для стран такой дефект становится фатальным: в одной стране происходит засилье импорта и студенты превращаются в продавцов в компьютерных магазинах, а в другой стране происходит массовый завоз инженеров из других стран, и местное население вытесняется работать в макдональдс.
В минском БГУИР (МРТИ) порядок преподавания этих тем правильный и давно, следовательно в РБ очень сильные инженеры-микроэлектронщики/программисты. Есть пул компетентных кадров, так сказать. Подскажите, когда в Минске откроются центры разработки Samsung, Nvidia и AMD? А то пока за таким крупняком людям приходится в Польшу ездить или дальше.
hardware долгое время развивалась вокруг инженерного и производственного подхода, где важны были точные расчеты, этапность и предсказуемость сроков. Software, наоборот, быстрее пришла к гибким методологиям, где важнее скорость изменений и возможность постоянно пересобирать приоритеты. Для меня это тоже хороший индикатор того, что даже язык планирования в двух мирах разный. Значит, и управлять ими одинаково нельзя.
Напомню, гибкие методологии пришли в software из отрасли производства автомобилей. Производственная система Toyota (TPS) -- это идейный предок kanban, agile, lean и прочего.
Вроде и в исходной постановке ("блок умножения, который может принимать данные каждый такт") она решаема, только блоков деления надо будет 2N и кода раза в два больше. На первой стадии вычислять res1=1/B, на второй вычислять А/res1.
“You should not look into the code AI generated; just verify it in the functional testbench and check the metrics, area and frequency.”
Вроде Anthropic и OpenAI готовятся к IPO в этом году. Так что у проповедников ИИ могут быть свои причины для таких высказываний. До IPO смотреть в генерируемый код слишком пристально должно быть не модно, чтобы не испортить оценки стоимости уважаемым джентльменам, а после это будет уже не важно.
Понятно, что Samsung осторожничает с чрезмерными инвестициями в расширение производственных мощностей, чтобы не попасть под удар прогнозируемого спада.
Кстати, Micron активно инвестирует в расширение производственных мощностей ($25 млрд в 2026 фискальном году), а подстраховывается долговременными контрактами с клиентами. В частности, недавно они подписали первое 5-летнее стратегическое соглашение с клиентом. Это большой шаг по сравнению с их стандартными 1-летними соглашениями. Ведут переговоры и по другим долговременным.
У него есть 32 тапа, а самое ценное в нем то, что он очень компактен. Он заменяет собой 32 регистра, но реализуется всего лишь на одном аппаратном LUT. Наш доработанный код подразумевает, что если входной параметр N больше 32, то, соответственно, в цепочке будет инстанциировано несколько SRL32.
Извините, что опять с вопросами, тема интересная. Если ваш элемент задержки построен на SRL32 и имеет размеры 32x128, то на него по идее надо 32*(128/32)=32*4=128 элементов SRL32. Однако на фото в отчете по использованным ресурсам показано, что LUTRAM=32. В чём фокус?
Мы видим, что вариант на SRL32 занимает гораздо меньше площади на кристалле. Больше нет проблемы в том, что эти модули мешают развестись другим блокам на ПЛИС.
Не пробовали ли BRAM для этих целей? При ширине 32 и глубине 128 уже может быть не жаль брамку на такое потратить.
У вас много SRL32 в проекте, если не секрет, не встретили ли проблем при более полном заполнении кристалла? В старых версиях vivado при подобном использовании большого числа SRL32 был опыт, когда place & route могли уйти в дзен на часы и вылететь с системными ошибками.
Интересные эксперименты! Кстати, буквально вчера Sharada Yeluri, известный дизайнер чипов из Juniper, на Linkedin разбирала как ИИ решает её задачку по RTL -- пишет Buffer Manager. Говорит, в этот раз ИИ справилось и чип дизайнерам можно начинать волноваться)
Индустрия слишком динамична. Профильные специалисты вовсю обсуждают возможные замены HBM, которую так долго ждать. Например HBF (High-Bandwidth Flash), а также вариации ускорения SSD. Если что-то из этого быстро выстрелит, вложения Hynix в заводы для HBM могут превратиться в тыкву. Исторически, много контор по производству памяти и жестких дисков подобным образом разорились в своё время, не рассчитав объем производства.
Простите, может чего пропустил или не понял. Было интересно почитать конечно, но похожие вещи в зарубежной литературе уже 15 лет известны.
Это вполне тривиальные вещи, location constraints похожи у разных вендоров +-.
Такие вопросы конечно были, сколько оверхеда именно в вашей реализации добавляете конечно же интересно. Но примерно всё же порядок величин понятен.
Кроме плисины интересно также сколько оверхеда требуется на весь обвес вне плисины: ethernet и прочий обвес для общения с сервером. Также интересно, сколько оверхеда на софт для этого всего обвеса -- это ведь тоже объем работ и деньги.
del
В датацентрах, где есть возможность арендовать FPGA-инстансы, существует задача обнаружения зловредных вещей в пользовательском битстриме. В частности, обнаружения PUF. Это надо, потому что такие PUF могут идентифицировать конкретную плисину, на которой крутятся прошивки нескольких пользователей (multi-tenant platform), а также вносить глитчи и/или перегревать/выводить из строя оборудование. Для решения этой задачи существуют тулзы типа FPGADefender. Т.е. в целом PUF в битстриме вполне себе ищутся. Обратите внимание, что это вещи из далёкого 2020 года, когда ещё не было вездесущего ИИ.
Также например здесь упоминаются атаки на PUF с навешиванием сотни Flip-flop, с помощью которых получалось предсказать ответ PUF-а.
Наконец, есть тузлы типа BITMAN, с помощью которых можно патчить битстримы плисин уровня UltraScale.
Имхо, технически это вполне решаемая задача, все компоненты с большего существуют.
Если копнуть, неподалёку от закона Ома будет Elmore delay, про которую можно узнать факультативно, чтобы представлять, как для этих облачков будут считаться тайминги и как работали EDA-тулы на низком уровне. Детишкам при знакомстве с RTL об этом точно знать не надо.
Нет, HBM медленная для кэша, latency у неё так себе.
До эпопеи её использовали в высокопроизводительных роутерах и в высокопроизводительных ПЛИС. Т.е. при решении достаточно нишевых задач.
Тема интересная и сложная. Если следите за историей, был когда-то стартап DeePhi. Там выпускники Стэнфорда и Цинхуа сделали компилятор, оптимизатор, квантизатор и прунер нейронок и раскладывали это всё на свое настраиваемое ядро DPU в FPGA. Фактически сделали полный стэк нейронок для FPGA с оптимизацией на всех уровнях. Потом их купил Xilinx за $250млн.
В минском БГУИР (МРТИ) порядок преподавания этих тем правильный и давно, следовательно в РБ очень сильные инженеры-микроэлектронщики/программисты. Есть пул компетентных кадров, так сказать. Подскажите, когда в Минске откроются центры разработки Samsung, Nvidia и AMD? А то пока за таким крупняком людям приходится в Польшу ездить или дальше.
После негативного фидбека пользователей, AMD всё же вернули поддержку Linux в бесплатной (BASIC) версии Vivado. И табличку обновили.
Напомню, гибкие методологии пришли в software из отрасли производства автомобилей. Производственная система Toyota (TPS) -- это идейный предок kanban, agile, lean и прочего.
Вроде и в исходной постановке ("блок умножения, который может принимать данные каждый такт") она решаема, только блоков деления надо будет 2N и кода раза в два больше. На первой стадии вычислять res1=1/B, на второй вычислять А/res1.
Вроде Anthropic и OpenAI готовятся к IPO в этом году. Так что у проповедников ИИ могут быть свои причины для таких высказываний. До IPO смотреть в генерируемый код слишком пристально должно быть не модно, чтобы не испортить оценки стоимости уважаемым джентльменам, а после это будет уже не важно.
Кстати, Micron активно инвестирует в расширение производственных мощностей ($25 млрд в 2026 фискальном году), а подстраховывается долговременными контрактами с клиентами. В частности, недавно они подписали первое 5-летнее стратегическое соглашение с клиентом. Это большой шаг по сравнению с их стандартными 1-летними соглашениями. Ведут переговоры и по другим долговременным.
За вашу статью на стр. 75 спасибо, такое было интересно почитать.
Теперь понятно, спасибо.
Она шикарные статьи по теме проектирования чипов и систем периодически выкладывает, делится опытом. Всегда интересно почитать.
Извините, что опять с вопросами, тема интересная. Если ваш элемент задержки построен на SRL32 и имеет размеры 32x128, то на него по идее надо 32*(128/32)=32*4=128 элементов SRL32. Однако на фото в отчете по использованным ресурсам показано, что LUTRAM=32. В чём фокус?
Ясно, спасибо.
К этому не призываю. Только для достаточно широких и достаточно глубоких сдвиговых структур, 32 на 128 как раз уже где-то такие.
Не пробовали ли BRAM для этих целей? При ширине 32 и глубине 128 уже может быть не жаль брамку на такое потратить.
У вас много SRL32 в проекте, если не секрет, не встретили ли проблем при более полном заполнении кристалла? В старых версиях vivado при подобном использовании большого числа SRL32 был опыт, когда place & route могли уйти в дзен на часы и вылететь с системными ошибками.
Интересные эксперименты!
Кстати, буквально вчера Sharada Yeluri, известный дизайнер чипов из Juniper, на Linkedin разбирала как ИИ решает её задачку по RTL -- пишет Buffer Manager. Говорит, в этот раз ИИ справилось и чип дизайнерам можно начинать волноваться)
Индустрия слишком динамична. Профильные специалисты вовсю обсуждают возможные замены HBM, которую так долго ждать. Например HBF (High-Bandwidth Flash), а также вариации ускорения SSD. Если что-то из этого быстро выстрелит, вложения Hynix в заводы для HBM могут превратиться в тыкву. Исторически, много контор по производству памяти и жестких дисков подобным образом разорились в своё время, не рассчитав объем производства.