FPGA *

Ребята из FPGA комунити каждый день делают небольшую подборку новостей из мира FPGA и решили поделиться ею с читателями хаба FPGA. На этой неделе ~90 ссылок. Внимание: возможны повторы!

"Напишите на доске код на верилоге для FIFO" - это популярный вопрос во время интервью в компании типа Apple и AMD, причем у него есть вариации для всех уровней инженеров, так как существуют десятки типа реализаций FIFO: на D-триггерах, встроенной SRAM памяти или на массиве D-защелок; с одном или двумя тактовыми сигналами; с одним, двумя или N вталкиваниями / выталкиваниями в одном такте; с разделяемой несколькими FIFO общей памятью; с парой указателей для записи/чтения и с хранением элементов в виде связанного списка; FIFO позволяющее undo; FIFO позволяющие потери данных; всякая экзотика типа FIFO шириной ноль итд.

Если человек не в теме или не понял вопроса, он может начать "запускаем GUI от Xilinx, вносим параметры и инстанциируем сгенерированный код". Это вызывает реакцию, как если бы школьная учительница геометрии спросила "найдите гипотенузу" и школьник бы ткнул пальцем в гипотенузу и с улыбкой ответил "вот она!"

Прошло всё отлично, 35 человек собралось, 7 докладов выслушано, 12 человек осталось на афтерпати.

Следующее мероприятие пройдет в Москве, Минске, Томске и Санкт-Петербурге в апреле-мае, подробности тут.

Все материалы собраны в отдельные плейлисты - встреча в Москве // слёт в Санкт-Петербурге, под каждым из видео ссылка на презентацию докладчика.

Под катом ссылки на видео и презентации

Я долго придумывал вступление к теме FPGA-реимплементации в контексте ретро, но это сложнее чем кажется. Давайте попробуем издалека. Сейчас электроника довольно неплохо стандартизирована, но ведь 40-50 лет назад ситуация была гораздо сложнее. То, что мы сейчас принимаем как должный и абсолютный незыблемый стандарт, когда-то таковым не являлось. Как, например, то, что в 1 байте 8 бит. Были машины и с 6 и с 9 битными байтами и много чего еще. Тем собственно старая техника и интригует. Сколько человекочасов было убито на её проектирование, какие гениальные и не очень решения принимались. И всё это будет утеряно? Да и просто - как это всё работало? Вопрос, который, думаю, интересовал многих ретро-энтузиастов ещё с детства.

В 2015 году скачивания первого русского издания учебника Харрис & Харрис завалили сайт британской компании Imagination Technologies. Книгу стали использовать в МФТИ, ВШЭ МИЭМ, МГУ, МИЭТ, ИТМО и других вузах. С тех пор вышло еще два издания - для ARM и для MIPS, и вот в январе 2022 года выходит новое - для RISC-V и оно уже доступно для предзаказа.

"Цифровая схемотехника и архитектура компьютера: RISC-V" вероятно станет стандартным учебником в российских вузах, как и источником информации для тех, кто хочет попроектировать процессоры на ПЛИС. Ничего лучшего на рынке нет. Паттерсон-Хеннесси не привязан к курсам по языкам описания аппаратуры и не обсуждает тайминг цифровой логики, а Таненбаум устарел.

Кроме этого, архитектура RISC-V становится билетом в будущее для российских процессорных компаний - Ядро купило Syntacore, Байкал Электроникс инвестировал в CloudBear, Миландр выпустил микроконтроллер с архитектурой RISC-V.

Если же вы не хотите работать в российских компаниях, а хотите пройти интервью на проектировщика чипа в Apple, Intel, NVidia, то и в таком случае учебник Харрисов - это самый эффективный способ начать этот путь.

В предыдущей статье мы начали осваивать построение шинно-ориентированных систем на базе среды Litex (которая всё делает на Питоне) с внедрением собственных модулей на Верилоге. Статья так разрослась, что практические опыты мы оставили на потом. Пришла пора провести их. Сегодня мы подключимся к VGA-монитору и поуправляем изображением, которое выдаёт модуль gpu, описанный в файле gpu.v, то есть, реализованный на языке Verilog. Управлять мы им будем через регистр команд, расположенный в блоке CSR, спроецированном на шину Wishbone. Все эти сущности, в свою очередь относятся к среде Litex. Инструменты для опытов мы тоже будем использовать штатные, Litex-овские. Приступаем!

Ребята из FPGA комунити каждый день делают небольшую подборку новостей из мира FPGA и решили поделиться ей с читателями хаба FPGA. Внимание: возможны повторы!

Прошло всё отлично, 60 человек собралось, 7 докладов выслушано, 20 человек осталось на афтерпати.

Следующее мероприятие пройдет в Москве, Минске, Томске и Санкт-Петербурге в апреле-мае, подробности тут.

Записи выступлений и презентации под катом

Что общего между популярным у хоббистов компьютером Синклер ZX Spectrum и космической станцией Juno, которая сейчас вращается вокруг Юпитера? И на одном, и на другом стоит процессор с архитектурой Zilog. На Синклере просто Z80, а на Juno - радиационно стойкий Y180-S. Y180-S спроектировал Монте Далримпл (Monte J. Dalrymple), выпускник Беркли, который проработал 16 лет в Zilog, после чего сделал собственный бизнес, компанию под названием Systemide.

Мы связались с Монте и он согласился выступить перед российскими слушателями, рассказать о всяких занятных ситуациях при проектировании процессоров.

В предыдущей паре статей я рассуждал про ПЛИС Lattice. Давайте сегодня поговорим об эффективной разработке под них. Один наш крупный руководитель уверяет, что из разговоров с иностранными Заказчиками, он выяснил, что российских разработчиков считают пишущими классные вещи, но делающими это крайне медленно. Ну, разумеется, по сравнению с разработчиками из других стран. И разумеется, «классные» идёт на первом месте.

Один из методов обхода проблемы скорости разработки – использование готовой инфраструктуры для проектов. Я делал цикл статей про комплекс Redd, где продвигал использование готовой шинной инфраструктуры в среде разработки Quartus. Сначала это была честная процессорная система, потом – процессор мы изъяли, а шины – оставили.

Затем я делал пару циклов, где активно использовал данный подход. Мне приходилось дописывать только проблемно-ориентированные модули, остальное — среда разработки создавала за меня.

Есть ли что-то подобное для Lattice в частности и сцепки Yosys/NextPNR в целом? Вы не поверите! Решение не просто есть, но оно ещё и настолько кроссплатформенное, что подойдёт и для Yosys/NextPNR, и для Quartus, и для Vivado! И называется оно Litex. Итак, давайте попробуем поэкспериментировать с ним для подхода, который я уже давно продвигаю: «делаем штатную основу, а на неё нанизываем свои целевые блоки».

1. Запустим Design Rule Check, чтобы проверить возможность произвести нашу схему
2. Запустим Device Extraction для сравнения нашего Layout с целевой схемой.
3. Произведём сравнение наших компонентов из Layout и нашей схемы, которую мы нарисовали в XSCHEM.
4. Сгенерируем netlist с паразитными конденсаторами и резисторами (PEX).
5. Просимулируем netlist с паразитными конденсаторами и резисторами.
6. Сгенерируем LEF файл.
7. Подведём итоги этой серии статей.

1. Будем рисовать схему, используя XSCHEM
2. Произведём симуляцию нашей схемы, используя NGSPICE
3. Поймём цикл производства микросхемы
4. Нарисуем Layout, используя KLayout

ПЛИС и Verilog - естественная платформа для обучения будущего проектировщика процессоров, так же как Си и микроконтроллеры - естественная платформа для обучения будущего программиста встроенных систем.

И один, и другой путь начинается с мигания огоньками на недорогой плате, но дальше пути расходятся. Встроенный программист смотрит в сторону самоуправляющихся авто, с задачами на RTOS и распознаванием ситуации с помощью AI в GPU. Проектировщик микросхем на уровне регистровых передач смотрит в сторону групп, разрабатывающих CPU, GPU, NPU и сетевые чипы, но какие упражнения он может делать между миганием огоньками и трудоустройством в Интел?

После небольшого (нет) перерыва в изучении Zynq и очередного прочтения своей предыдущей статьи, я отметил для себя очень важный момент - практически не отражено никаких результатов тестирования полученного поделия, кроме базовой проверки работоспособности. Во время подготовки материала для предыдущей статьи - я конечно же все проверял перед публикацией, что всё работает как надо (на первый взгляд), но из-за получившегося объема статьи вся информация о процессе проверки осталась за кадром. Именно поэтому я решил сделать отдельную статью, в которой я расскажу о том, как я проверил, то, что результат, достигнутый в предыдущей статье, соответствует (полностью или частично) заявленным требованиям. Много интересного выяснилось по хоу тестирования, я вам скажу...

Всем интересующимся - добро пожаловать под кат! 

В предыдущей статье я поделился опытом работы с ПЛИС фирмы Lattice через инструменты с открытым исходным кодом Yosys и NextPNR. Как я отмечал, освоить их меня заставило не столько любопытство, сколько требования Заказчика. В том проекте у меня просто не было выбора. И та статья, скорее, была написана в помощь для быстрого старта тем, кого тоже заставят. А можно ли использовать эту сцепку для дома, для семьи? Для этого она должна быть удобной.

Как мы обсудили в комментариях к прошлой статье, в минусы этой сцепке можно записать отсутствие такого полезного инструмента, как SignalTap (Altera) или ChipScope (Xilinx). Замену этой парочке пока что удалось найти только в виде физического анализатора. Так себе замена, но хоть что-то.

Более серьёзная трудность заключалась в том, что все примеры, которые я находил, были реализованы на чистом Верилоге. А я уже не могу писать автоматы, не используя такой механизм, как enum. Меня каждый раз злит необходимость перенумеровывать состояния, если я правлю автомат по ходу разработки. Но чтобы был enum, надо пользоваться более прогрессивным стандартом языка, который уже называется SystemVerilog.

На странице Yosys  YosysHQ/yosys: Yosys Open SYnthesis Suite (github.com) описано, что данный язык ограниченно поддерживается синтезатором, и даже указана опция для его использования. А именно сказано, что команде read_verilog надо добавить ключ –sv. Но попытки найти в сети готовую инструкцию для новичков, как её активировать, я не нашёл, потому что если кто-то и пользуется этой командой, то для одного файла, а не для списка.

Наконец, я разобрался, поэтому делаю такую инструкцию, чтобы любой желающий смог быстро найти готовое решение.

В чем главное отличие между FPGA-хоббистом, ностальгирующим по КР580ИК80 на пенсии - и начинающим микроархитектором, ориентированным на будущее трудоустройство в передовую процессорную компанию или сфинансированный венчурными капиталистами стартап?

Три слова: понимание концепции конвейера. Молодым профессионалом, не старым хоббистом.

Это наглядно видно, если вы погуглите тексты про FPGA для начинающих. Если текст пишет программист, которому захотелось потрогать FPGA чисто для разнообразия, он как правило до конвейера не доходит. Помигает лампочками, поговорит про конечные автоматы и может начнет встраивать какую-нибудь FPGA-реализацию старого 8-битного процессора.

(Некоторые из таких людей даже пишут книги - вот некий Роберт Дунне реализовал процессор конечным автоматом с состояниями fetch/decode/execute, но до конвейера не дожал)

Все это происходит потому, что понимание работы конвейера как правило требует некоего мозгового усилия, типа толчка штанги. И если мозг уже поставлен десятилетиями программирования на Си и ассемблере, он упирается, потому что это ему контринтуитивно.

Но это надо преодолеть, поскольку если вы прийдете интервьироваться в какой-нибудь AMD на позицию юного проектировщика, вас будут спрашивать не как помигать лампочками и засунуть Радио РК-86 в Xilinx, а как стоя перед интервьирующим написать на доске на языке описания аппаратуры Verilog - конвейерную реализацию какого-нибудь умножения со сложением. Или сделать это на компьютере отрезанном от интернета, так что вы даже не cможете нагуглить решение - вот садисты, а?

Именно этому вопросу будет посвящено следующее занятие Сколковской Школы Синтеза Цифровых Схем.

Однажды я решил ответить на сообщения в LinkedIn от рекрутерши безосовской компании Blue Origin, которая занимается разработкой и запуском космических аппаратов. Затем я прошел два раунда интервью: скрининг и 6-часовой марафон с дюжиной инженеров и менеджеров. Я не могу рассказать вопросы или описать диалоги с интервьирующими, потому что я подписал бумагу что не буду этого делать, но покажу пару вещей, о которых зашла речь еще до подписания бумаги, а также дам совет тем, кто хочет это повторить (совет кстати может быть применим не только при устройстве к Безосу, но и к Маску или Рогозину).

Одновременно с Blue Origin я интервьировался в другую компанию, интервью в которую по времени было такое же - час скрининга с инжиниринг-менеджером и шесть часов детальное интервью - но содержание было соовсем другое. Вообще обычно в электронных компаниях такое интервью - это просто марафон задачек на микроархитектуру (всякие извращенные FIFO, арбитры, кэши, кредитные счетчики), каверзные вопросы про тайминг (доходит до time stealing/time borrowing), пересечение тактовых доменов, дюжина способов оптимизации динамического энергопотребления при проектирования на уровне регистровых передач итд.

Но в компании Безоса все было по другому. Сначала нужно было написать эссе на тему "Что я думаю о космических кораблях бороздящих просторы Вселенной". Я написал следующее: