Добрый день! SystemVerilog -- это замечательно, но причины путаете и передёргиваете. В РБ в БГУИР существовала сильная школа работы с памятью. Коды коррекции ошибок, надёжность, самотестирование, низкоуровневое программирование, математика и тому подобное. Люди из неё хорошо шарили в разработке прошивок для контроллеров Flash, SSD и всякой прочей памяти. Довелось учиться у этих людей. Некоторые специалисты оттуда осели в SanDisk, а из некоторых вышла сильная команда работы с памятью у Softeq. Подразделение Softeq по работе с памятью и купил SK Hynix. Набор знаний и навыков, который привлёк SK Hynix, был гораздо шире, чем верификация асиков на SystemVerilog, преуменьшать и скромничать не надо.
Судя по картинкам, Groq интегрировали в инфру Nvidia, в вычислительный узел, где есть своя системная DRAM, завязанная на CPU и доп. DRAM, завязанная на логику расширения коммутационной фабрики (fabric expansion logic). Логика расширения (плисина) связывает Groq с сетью и внешней памятью DRAM для хранения данных при коммутации и передаче между Groq и прочими узлами инфры. Вроде ничего экстраординарного.
Нет, в Groq вычисления вокруг обычной SRAM на кристалле, а в PIM вычисления в DRAM. DRAM дешёвая, большая и с большой latency, SRAM дорогая, небольшая и с малой latency. PIM должен уменьшить влияние latency DRAM, перенеся часть вычислений к месту хранения и уменьшив внешний трафик к DRAM. Идею PIM обсуждают и пробуют давно, поглядим очередную реализацию.
я могу сказать совершенно определенно - и альфа, и latch-based design были тогда экзотикой
Если экзотика, тогда ошибка отменяется.
В d-latch based дизайне вы теряете половину такта - зачем?
Из попадавшихся кейсов Alpha, PowerPC, Intel P6 выходит, что тогда в индустрии некоторое время latch-based design был жизнеспособным способом выжать самую высокую тактовую частоту. Может это было историческое сочетание факторов.
Одна из фич книги Петзольда — он сначала вводит D‑защелки (level‑triggered D‑latch), комбинирует их с сумматорами и только потом вводит D‑триггер (D‑flip‑flop). Что «естественно» для программиста (Петзольд прославился в конце 1980-х как автор книги по программированию Windows), но не соотвествует реальному проектированию в современных электронных компаниях (99%+ элементов состояния — это D‑триггеры, а D‑защелки используются в основном для clock gaters (такая штука для экономии энергопотребления), очень редко для latch arrays и time borrowing (неактуально для новичков).
Вроде в этом утверждении есть логическая ошибка. Книжка не соответствует современным трендам, потому что когда она писалась в 1999-2000, тренды были другими. Поправьте, если ошибаюсь, в конце 90-х самые топовые, высокопроизводительные процессоры (например, DEC Alpha) разрабатывались широко опираясь на D-latch и full custom design. Позже простота разработки и изготовления, развитие EDA и прочие вещи перевесили и со временем все стали использовать D-триггеры.
Поясню, почему так случается. Заметьте, что авторы подобных книг -- программисты/системные программисты/писатели операционных систем.
Книги типа "Код" Петцольда, "Архитектура компьютера" Танненбаума (которую Вы тоже как-то тут критиковали), как и "Компьютерная архитектура. Количественный подход" Хеннесси и Паттерсона рассчитаны на более широкую аудиторию, чем малочисленные проектировщики цифровых устройств. Эти книги дают перспективу проектировщикам вычислительных систем (программистам, системным программистам и железячникам). Они расширяют контекст студентам-программистам, чтобы те не улетели в облака абстракций, а могли писать hardware-friendly софт и понимали, где в системе узкие места. Такие книжки дают представление, как проектировать эффективный на разных уровнях стек датацентров типа как у NVIDIA, Google, а не отдельные супер-сверх-быстрые GPU. Имхо, с точки зрения программистов тот же Харрис & Харрис слишком сосредоточен на деталях реализации и выцеживать из него общие принципы для программеров -- это пустая трата времени.
По поводу цифрового проектирования и связанных тем, имхо, на постсоветском пространстве есть острый дефицит доступных современных книжек. В этом случае, имхо, надо переводить современные, а не бороться с ветряными мельницами позапрошлых десятилетий. Не переводят наверно потому, что покупателей подобных книжек здесь совсем мало, не окупишь труд. Петцольда оставьте программистам.
Зачем ругать калькулятор, изобличая его неспособность вести бухгалтерский баланс целой компании?
Конвейеризация -- это тривиальная задача в данной предметной области, как проводка в бухгалтерии. Инженерам (например мне) хочется, чтобы ИИ или любая другая технология могла эту рутину брать на себя, автоматизировать. И чтобы этой автоматизации можно было доверять без оглядки и без проверки, чтобы она облегчала жизнь.
Это же субъективный вопрос, вам не кажется? Это вопрос можно ли относить FPGA проектирование к программированию, или нет, правильно?
А в чём субъективность? При программировании создаётся программа, набор инструкций, которая будет выполняться на какой-то вычислительной машине. При FPGA проектировании создаётся вычислительная машина.
Я предложил концепт, как получить 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 смотреть в генерируемый код слишком пристально должно быть не модно, чтобы не испортить оценки стоимости уважаемым джентльменам, а после это будет уже не важно.
Добрый день!
SystemVerilog -- это замечательно, но причины путаете и передёргиваете. В РБ в БГУИР существовала сильная школа работы с памятью. Коды коррекции ошибок, надёжность, самотестирование, низкоуровневое программирование, математика и тому подобное. Люди из неё хорошо шарили в разработке прошивок для контроллеров Flash, SSD и всякой прочей памяти. Довелось учиться у этих людей. Некоторые специалисты оттуда осели в SanDisk, а из некоторых вышла сильная команда работы с памятью у Softeq. Подразделение Softeq по работе с памятью и купил SK Hynix. Набор знаний и навыков, который привлёк SK Hynix, был гораздо шире, чем верификация асиков на SystemVerilog, преуменьшать и скромничать не надо.
Судя по картинкам, Groq интегрировали в инфру Nvidia, в вычислительный узел, где есть своя системная DRAM, завязанная на CPU и доп. DRAM, завязанная на логику расширения коммутационной фабрики (fabric expansion logic). Логика расширения (плисина) связывает Groq с сетью и внешней памятью DRAM для хранения данных при коммутации и передаче между Groq и прочими узлами инфры. Вроде ничего экстраординарного.
Нет, в Groq вычисления вокруг обычной SRAM на кристалле, а в PIM вычисления в DRAM. DRAM дешёвая, большая и с большой latency, SRAM дорогая, небольшая и с малой latency. PIM должен уменьшить влияние latency DRAM, перенеся часть вычислений к месту хранения и уменьшив внешний трафик к DRAM. Идею PIM обсуждают и пробуют давно, поглядим очередную реализацию.
Если экзотика, тогда ошибка отменяется.
Из попадавшихся кейсов Alpha, PowerPC, Intel P6 выходит, что тогда в индустрии некоторое время latch-based design был жизнеспособным способом выжать самую высокую тактовую частоту. Может это было историческое сочетание факторов.
Вроде в этом утверждении есть логическая ошибка. Книжка не соответствует современным трендам, потому что когда она писалась в 1999-2000, тренды были другими. Поправьте, если ошибаюсь, в конце 90-х самые топовые, высокопроизводительные процессоры (например, DEC Alpha) разрабатывались широко опираясь на D-latch и full custom design. Позже простота разработки и изготовления, развитие EDA и прочие вещи перевесили и со временем все стали использовать D-триггеры.
Поясню, почему так случается. Заметьте, что авторы подобных книг -- программисты/системные программисты/писатели операционных систем.
Книги типа "Код" Петцольда, "Архитектура компьютера" Танненбаума (которую Вы тоже как-то тут критиковали), как и "Компьютерная архитектура. Количественный подход" Хеннесси и Паттерсона рассчитаны на более широкую аудиторию, чем малочисленные проектировщики цифровых устройств. Эти книги дают перспективу проектировщикам вычислительных систем (программистам, системным программистам и железячникам). Они расширяют контекст студентам-программистам, чтобы те не улетели в облака абстракций, а могли писать hardware-friendly софт и понимали, где в системе узкие места. Такие книжки дают представление, как проектировать эффективный на разных уровнях стек датацентров типа как у NVIDIA, Google, а не отдельные супер-сверх-быстрые GPU. Имхо, с точки зрения программистов тот же Харрис & Харрис слишком сосредоточен на деталях реализации и выцеживать из него общие принципы для программеров -- это пустая трата времени.
По поводу цифрового проектирования и связанных тем, имхо, на постсоветском пространстве есть острый дефицит доступных современных книжек. В этом случае, имхо, надо переводить современные, а не бороться с ветряными мельницами позапрошлых десятилетий. Не переводят наверно потому, что покупателей подобных книжек здесь совсем мало, не окупишь труд. Петцольда оставьте программистам.
Конвейеризация -- это тривиальная задача в данной предметной области, как проводка в бухгалтерии. Инженерам (например мне) хочется, чтобы ИИ или любая другая технология могла эту рутину брать на себя, автоматизировать. И чтобы этой автоматизации можно было доверять без оглядки и без проверки, чтобы она облегчала жизнь.
А в чём субъективность? При программировании создаётся программа, набор инструкций, которая будет выполняться на какой-то вычислительной машине. При FPGA проектировании создаётся вычислительная машина.
Это надо, чтобы в констрейнтах плисины человек мог описать пины.
Простите, может чего пропустил или не понял. Было интересно почитать конечно, но похожие вещи в зарубежной литературе уже 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 смотреть в генерируемый код слишком пристально должно быть не модно, чтобы не испортить оценки стоимости уважаемым джентльменам, а после это будет уже не важно.