Программирование ПЛИС (FPGA) считается высшим пилотажем в мире цифрового DIY аудио.
Вы можете реализовывать FIFO буферы, которые накапливают аудиоданные и устраняют джиттер, а также создавать собственные цифровые фильтры с характеристиками, заметно превосходящими то, что доступно в серийных ЦАП (или DAC) микросхемах.
Есть только одна проблема, зато существенная.
Нужно научиться программировать на Verilog или VHDL, то есть на языках описания аппаратуры. Их логика сильно отличается от привычных языков программирования и даже от программирования микроконтроллеров.
Если вы занимаетесь этим в качестве хобби и вам уже не двадцать, порог входа может показаться очень высоким. Именно поэтому, хотя я купил отладочный комплект Spartan 6 почти десять лет назад, до дела у меня так и не дошло.
Перенесемся в 2026 год, когда ИИ уже считается «вроде как зрелой» технологией.
Вся молодежь сейчас занимается вайб‑кодингом: просто обсуждает с ИИ, что хочет реализовать, а затем позволяет искусственному интеллекту написать весь код.
После нескольких итераций такого процесса обычно получается что‑то работающее. Возможно, это не элегантно, не оптимизировано и не безопасно, но по крайней мере работает. Сам факт того, что человек без навыков программирования может создать рабочую и, предположительно, полезную программу, выглядит почти невероятно.
И я подумал: а что, если применить этот подход к проектированию на ПЛИС?
Так что я взялся за работу, точнее, за переписку с Gemini Pro 3.1.
Прежде чем продолжить, небольшое замечание. Не все ИИ одинаково способны. Если вы думаете, что сможете провернуть нечто подобное на «бесплатных / быстрых» моделях, вы сильно ошибаетесь. Вам понадобится вся доступная вычислительная мощность. Я справился с базовой подпиской Gemini Pro примерно за 20 долларов в месяц, но доступ к топовым моделям Claude сэкономил бы мне много времени. Для проекта уровня хобби это не такая уж большая проблема, но все же.
Вернемся к делу.
Получив от Gemini подтверждение, что он действительно может написать за меня большую часть кода на Verilog, и осознав, что Spartan 6 уже изрядно устарел, я начал подбирать подходящую ПЛИС.
Главное требование: ее должно быть реально запаять вручную. Я должен был иметь возможность припаять ее к печатной плате (PCB), не заказывая производство уже собранной платы. Это означало: никаких BGA‑корпусов.
Я подумал и остановился на Intel / Altera MAX 10. У нее есть достаточно мощные варианты в корпусе EQFP на 144 вывода, который можно паять вручную. Отлично.
Отладочную плату 10M08 можно купить на Mouser примерно за 60 долларов.
Правда, программатор, который вам тоже понадобится, USB Blaster, на самом деле стоит чуть дороже самой отладочной платы. У вас может возникнуть соблазн купить клон программатора на eBay. Не покупайте такое устройство. Оно не заработает, даже если ИИ будет утверждать обратное. Я купил такой, попытался заставить его работать и это с треском провалилось. Я спросил у ИИ, почему у меня ничего не получается, и ответ был примерно таким: «А, у тебя тот самый, китайский? Извини, это хлам, он никогда не заработает, просто отдай 60 долларов за нормальный программатор».
В общем, когда у меня на руках оказался рабочий программатор, я открыл Quartus, написал свою первую «мигалку» на Verilog и загрузил ее на отладочную плату. Светодиод начал мигать. Прекрасно.
Следующий шаг: сделать что‑нибудь полезное. С помощью Gemini я начал писать, ладно, на самом деле копипастить фрагменты кода, которые должны были реализовать приемник I2S, FIFO с двумя тактовыми доменами и передатчик I2S, пока только для частоты дискретизации 44,1 кГц и разрядности 32 бита. Предполагалось, что PLL‑блоки будут генерировать необходимые сигналы BCLK, LRCLK и DATA из системной тактовой частоты 50 МГц. Часть процесса свелась к борьбе с ошибками Quartus, особенно при попытках генерировать IP‑ядра и при появлении битых экранов в интерфейсе. Здесь ИИ очень помогал: предлагал решения и обходные пути для ошибок.
Когда тестовый проект был собран, я подключил Amanero как источник I2S, а небольшой ЦАП (цифро‑аналоговый преобразователь) на базе ES9023 как приемник I2S. Аналоговый выход ЦАП я подключил к осциллографу и загрузил код в ПЛИС. Затем воспроизвел тестовый файл с синусоидой 10 кГц и получил… мусор на осциллографе.
Ну а чего я ожидал? Это была практически «слепая» попытка ПЛИС программирования.
Но затем началась магия искусственного интеллекта. Я описал ИИ, что именно делаю и что вижу на осциллографе, и после нескольких вопросов и ответов он точно понял, что происходит. Он предложил внести в код несколько изменений, и, о чудо, я увидел на осциллографе чистый сигнал 10 кГц.
Так у меня появилась система, которая принимала сигнал I2S, буферизовала его в FIFO и выводила через передатчик I2S. Это был первый и самый важный шаг к тому, что я хотел реализовать, и все заработало спустя пару часов работы.
И все это без необходимости написать хоть одну строку кода на Verilog. Сплошная победа.
Дальше проект развивался естественным образом.
Мне удалось заставить работать счетчики битов, чтобы определять частоту дискретизации входящих сигналов.
Я запустил внешний MCLK (опорный тактовый сигнал), чтобы выход ПЛИС работал синхронно с ЦАП.
Я запустил двунаправленный UART (универсальный асинхронный приёмопередатчик), чтобы видеть, что происходит внутри ПЛИС, и отдавать ей команды: например, переключить вход или сообщить мне частоту дискретизации.
Но не все заработало сразу. У меня появилась идея реализовать тестовую процедуру PRBS-15 для проверки побитовой точности, чтобы визуально убедиться, что ПЛИС ничего не портит в моем сигнале. Gemini 3.1 Pro не смог понять, почему она не работает. Claude Sonnet 4.6 тоже. Claude Opus 4.7 тоже. Так что я отказался от PRBS и перешел на алгоритм распознавания «известного шаблона». Он заработал сразу, и этого было вполне достаточно.
Затем я добавил совместимость с DSD с автоматическим определением типа сигнала.
И декодер DoP.
И защиту DSD от залипших битов.
И полноценный детектор разрядности.
И светодиоды, которые показывают состояние FIFO‑буфера, а также побитовую точность и приглушение DSD.
И несколько I2S‑входов.
И приемник с декодером S/PDIF, реализованные внутри ПЛИС.
Искусственный интеллект также очень помог с созданием SDC‑файла (Synopsys Design Constraints, файл ограничений для проекта) для проекта. Такой файл обязателен, когда вы работаете с высокочастотными сигналами, чувствительными к джиттеру.
Во время наших обсуждений ИИ приходилось напоминать, что мы уже реализовали, из‑за ограниченного размера контекстного окна. Но в целом он справлялся очень неплохо.
Бывали и случаи, когда он галлюцинировал, из‑за чего я уходил по ложному пути и терял время.
Но настоящая проверка возможностей ИИ, а заодно и моего терпения, началась, когда я дошел до добавления микросхемы PSRAM (псевдостатическая оперативная память) для увеличения времени буферизации.
Это оказалось серьезным испытанием. ИИ написал набор процедур, которые управляли обменом с PSRAM по шине QSPI, обработкой и упаковкой данных, псевдопараллельным чтением и записью в память и еще множеством всего.
Разумеется, с первого раза это не заработало.
И со второго тоже.
И с третьего.
Примерно в этот момент я понял, что смотреть на размытое изображение на экране осциллографа, описывать ИИ, что я вижу, и ждать, что он сам поймет, где именно проблема, уже недостаточно.
Поэтому я попросил ИИ разбить архитектуру ПЛИС на более мелкие части, которые можно тестировать по отдельности. Он назвал это хорошей идеей и именно так и сделал. Мы написали процедуры, которые проверяли данные в PSRAM на повреждения, использовали светодиоды для диагностики и UART для получения большого объема отладочной информации. Но дальше определенного предела это все равно не продвинулось.
В итоге мне пришлось достать логический анализатор Saleae и заняться классической отладкой: подавать известные сигналы и смотреть, что код с ними делает. Это сработало. Вскоре моя ПЛИС уже успешно использовала PSRAM как буфер на 64 Мбит и работала с побитовой точностью.
Вот чем я занимался последние двадцать дней.
Было очень интересно на практике понять, на что именно способны ПЛИС. Например, настоящим открытием стало осознание, что создаваемые мной функциональные блоки по сути работают параллельно, а никакого «процессорного времени», которое делится между компонентами, здесь нет. Такова детерминированная природа этих устройств. Сигнал с заданными характеристиками всегда будет обрабатываться с одной и той же скоростью, какой бы сложной ни становилась остальная часть проекта. Я могу просто добавлять модули, которые «подключаются» к тому же сигналу и что‑то с ним делают, без каких‑либо последствий для исходной обработки сигнала.
Должен сказать, давно мне не было так интересно разбираться с «новой технологией». Было крайне приятно осознавать, что проект такой сложности действительно можно навайбкодить. Хотя в итоге я все же немного выучил Verilog. Не потому что пришлось, а потому что захотел.
Итак, может ли любой человек просто взять отладочную плату и получить рабочий FIFO‑реклокер?
Это зависит от того, насколько хорошо вы понимаете архитектуру ЦАП.
Вам придется объяснять ИИ, чего именно вы хотите добиться, и шаг за шагом направлять его к цели. Но нельзя просто сказать ему: «Сделай мне ПЛИС, которая выполняет FIFO‑буферизацию сигналов I2S и DSD», и ожидать, что он справится. Если вы дадите один‑единственный запрос с описанием всей задумки, даже максимально подробный, он с вероятностью 100% не заработает, а вам потом придется мучительно разбираться, что именно сломалось.
Так что процесс займет время.
Но если проявить настойчивость и иметь под рукой логический анализатор, в конце концов у вас получится, как получилось у меня.
Следующим шагом будет разработка собственной печатной платы для ПЛИС и необходимого каскада реклокинга, который должен идти после нее.
А пока я буду ждать изготовления печатной платы, займусь кодом для повышения частоты дискретизации и цифровой фильтрации.
Потенциал здесь огромный.
P. S. При написании этого текста ИИ вообще не использовался. В отличие от кода для ПЛИС.
Так что, если вам тоже стало интересно, где заканчивается «просто попросить ИИ написать код» и начинается настоящая инженерная работа, можно продолжить эксперимент уже на открытых уроках OTUS.
Там не будут обещать, что один промпт заменит вам архитектуру, отладку и понимание предметной области. Зато можно разобраться, как на практике работают LLM, ИИ‑агенты и инженерные workflow, почему модели иногда уверенно ведут не туда и как использовать их так, чтобы в конце все‑таки получить не мусор на осциллографе, а что‑то работающее.
Ближе всего к теме этой истории:
20 мая в 20:00 — «Что надо знать про работу LLM моделей». Записаться
27 мая в 20:00 — «Мифы про ИИ‑агентов: что реально работает в 2026 году». Записаться
15 июня в 20:00 — «Интеграция ИИ‑агентов в рабочую разработку: обвязка агента навыками и MCP». Записаться
Уроки бесплатные, проходят в рамках онлайн‑курсов, и ведут их преподаватели‑практики. Можно прийти, посмотреть, задать вопросы и понять, где ИИ действительно помогает инженеру, а где по‑прежнему нужны логический анализатор, терпение и способность не верить модели на слово.
📌 Подписывайтесь на блог OTUS, чтобы не пропускать разборы про ИИ, разработку и инженерную практику без магического мышления.
