Предыстория

Захотелось мне как-то перевести управление станком на ПЛИС, а для этого понадобилось ядро процессора. Поиск на opencores не особо помог, x86 лицензированный, ARM лицензированный, NIOS… ну, вы поняли. Если выдумывать свою систему команд, может получиться криво, и главное, где брать компилятор. В общем, всё было сложно, так что на время идею пришлось отложить.
С недавних пор ситуация изменилась, архитектура RISC-V пошла в массы.

В прошлой статье приделали конвейер и теперь можно запускать программы, расположенные в локальной памяти процессора. Но с одной лишь локальной памятью далеко не уедешь, у маленького ПЛИСа её жалких 50 кБ, поэтому надо делать небольшое локальное хранилище, синхронизируемое с внешней памятью, то есть кэш. Есть отладочная плата с SD RAM, в идеальном случае хорошо бы добавить её поддержку, но для начала внешнюю память будет изображать внутренняя. Дополнительным эффектом от добавления кэша оказалось увеличение доступной памяти, потому что для чтения параллельно с двух адресов создавалось два набора памяти, а теперь чтение за один такт делается только с одного адреса.
Ветка реализации проекта лежит на гитхабе.

Готовим процессор к добавлению суперскалярности - переделываем 3-х этапный конвейер RISC-V в 5-этапный и попутно измеряем производительность.

Вероятно, вам уже попадались подобные руководства по CUDA: хрестоматийный пример «Hello World», в котором перемешан код для ЦП и графического процессора. Всё это сложено в один гетерогенный файл с исходниками на CUDA C++, а для запуска ядра применяется синтаксис NVCC с тройными угловыми скобками <<<>>>, который уже стал культовым:

В прошлой части добавили расширение M (умножение и деление), теперь будем собирать под ПЛИС Cyclone IV. При попытке собрать проект Quartus говорит, что с асинхронной памятью работать не будет, поэтому заменяем её на синхронную, и это сразу приводит к серьёзным последствиям.

Когда студент устраивается на работу в электронную компанию, очень здорово, если он уже умеет строить одну и ту же электронную схему разными способами, в зависимости от требований пропускной способности, максимальной тактовой частоты, размера и энергопотребления.

Как натренировать такое умение? Для новых домашних работ в программе Школы Синтеза Цифровых Схем мы решили разодрать на блоки реальный процессор и дать студентам задачу собирать разные специализированные вычислительные устройства из этих блоков, примерно как герои фильма "Безумный Макс: Дорога ярости" собирали свои боевые драндулеты из частей реальных автомобилей.

По каким-то причинам (sic!), японский язык хочет выучить ужасающее количество программистов. Реально, мой любимый японский подкастер Тэппей говорит, что у него девять из десяти учеников что‑нибудь кодят. Поэтому у нас нет недостатка в отличном софте. Буду рассказывать про кучу инструментов, позволяющих погрузиться в закорючки и взаимодействовать с нативным контентом с первых дней. Японофилы узнают что‑нибудь, о чем они еще не слышали, а если вы учите другой язык — возможно захотите сделать что-то похожее для него.

В этом руководстве я расскажу, как я создаю инструменты для поиска уязвимостей в видеоиграх для программ вознаграждений за баги. В частности, я сосредоточусь на моих исследованиях игры Sword of Convallaria.

Весь исходный код доступен на GitHub.

Детали игры

Sword of Convallaria доступна на платформках PC и мобильных устройствах, и на данный момент имеет около 2,000 активных пользователей одновременно на Steam (источник: SteamDB). Игра монетизируется через микротранзакции с системой "плати, чтобы победить" и включает PvP-режим. Учитывая ее размер, разработчики должны беспокоиться о возможных уязвимостях, однако у них нет формальной программы вознаграждений за баги.

Игра построена на Unity и использует Lua для большей части игровой логики и обработки. Сетевой протокол использует HTTPS для процесса аутентификации/входа и UDP-пакеты с сообщениями protobuf для общения внутри игры.

Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

Осенью стартовал новый поток Школы синтеза цифровых схем — нашей бесплатной образовательной программы о современных приемах проектирования цифровых микросхем. От серийных ASIC и микропроцессоров общего назначения до реконфигурируемых FPGA и специализированных вычислителей. По этим и связанным темам выпущено немало профессиональной литературы. Мы попросили преподавателей Школы — Юрия Панчула и Александра Рябова — выбрать книги, которые помогут при обучении в школе и самостоятельном освоении синтеза цифровых схем.

Сменив недавно работу, перейдя с языка VHDL на язык SystemVerilog и оказавшись в команде, где есть отдельная группа верификаторов, я осознал, что сильно отстал в верификации. На VHDL ранее мной писались лишь простые тесты разработчика, которые показывали, что блок выполняет требуемую функцию и ничего более. Каждый тест писался с нуля и не было повторного использования кода. Решив исправить эту проблему, я погрузился в чтение SystemVerilog for Verification A Guide to Learning the Testbench Language Features за авторством Chris Spear, Greg Tumbush. Прочитав книгу, понял, что нужно написать какой-то тестовый проект, дабы закрепить полученную информацию. Вспомнил, что видел на хабре цикл статей по верификации от @pcbteach, написанный на verilog, и решил написать тест для сумматора с интерфейсами AXI-Stream на SystemVerilog.