Привет, Хабр! На связи Михаил Степанов, инженер в группе функциональной верификации YADRO. Еще в прошлом году мы с моим коллегой Романом Казаченко участвовали в хакатоне по разработке микропроцессоров как студенты, а сейчас — помогаем с задачами для SoC Design Challenge как сотрудники компании-организатора. В статье расскажем, что ждет участников трека «Системная верификация СнК» в этом году и как подготовиться к этому испытанию.
Если вы не планируете участвовать в хакатоне, но вам интересно, как инженеры тестируют системы на кристалле перед запуском в производство, эта статья тоже будет вам полезна. На примере заданий хакатона я кратко объясню, что такое системная верификация, из каких блоков состоят СнК и какие инструменты используются для их тестирования.
Инженерный хакатон SoC Design Challenge от НИУ МИЭТ и YADRO пройдет 18–20 апреля. Если вы студент очной формы обучения, то проверить свои знания и получить новые навыки можно в треках «Топологическое проектирование», «UVM-верификация», «Системная верификация СнК» и «RTL-проектирование». Хакатон — это отличная возможность пообщаться со специалистами «железной» индустрии, продемонстрировать им свои знания и получить классные подарки. Присоединяйтесь, заявки принимаются до 18 марта.
Как попасть на хакатон
В прошлом году мы с Ромой были студентами выпускного курса «Информатика и вычислительная техника» в ИТМО и решили испытать себя на хакатоне SoC Design Challenge. Тогда у нас было немного опыта в разработке системного ПО, поэтому мы выбрали трек «Системное программирование». В этом году его переименовали в «Системную верификацию СнК», что точнее отражает суть задания.
Путь истового инженера начинается с несложного отборочного теста. Обычно, чтобы его успешно пройти, достаточно знаний на уровне второго и третьего курсов. Самое сложное — успеть ответить на все вопросы за отведенные четверть часа. В интернете искать ответы можно, но мы не рекомендуем — можете впустую потратить драгоценные минуты.
Рекомендуем сразу оценить, сколько времени вы сможете потратить на каждый вопрос. Если над каким-то из них нужно поломать голову, лучше его пропустить и попробовать сделать следующее задание. Так вы успеете больше за отведенное время и не потеряете потенциальные баллы.
Если вы пройдете отбор, то вас пригласят на основной этап в Зеленоград и поселят в классном отеле с трехразовым питанием. На решение кейса у вашей команды будет три дня. Первые два дня работать придется с утра до вечера, можете ориентироваться на восемь часов в день. В последний день времени будет меньше из-за подведения итогов. Рекомендуем быть готовыми трудиться над заданием по вечерам, но не в ущерб сну. Отдых — залог эффективной работы и вашей победы.
На SoC Design Challenge 2025 несколько треков с соответствующими заданиями: «Топологическое проектирование», «UVM-верификация», «Системная верификация СнК» и «RTL-проектирование». Описания заданий с прошлогоднего хакатона можно посмотреть в анонсе хакатона. В этой статье я делюсь опытом нашей команды в треке по системной верификации и даю подробные советы по работе с инструментами, которые пригодятся вам в этом году. Также, как участник процесса подготовки заданий, рассказываю об изменениях по сравнению с прошлым годом.
Про задание трека «Системная верификация СнК»
Нам нужно было провести верификацию аппаратного блока в косимуляционном окружении. Давайте разберемся, что это значит.
Системы на кристалле состоят из логических и функциональных блоков. Такое деление позволяет независимо разрабатывать разные части системы, а затем модульно отлаживать их в изолированном окружении. Функциональная верификация — это процесс тестирования таких блоков по спецификации. Она проводится перед отправкой чипа на завод и называется pre-silicon стадией. Без этой процедуры велик шанс получить нерабочий чип, причем в объемах всей произведенной партии.
Проводить тесты можно при помощи таких инструментов, как:
Функциональные симуляторы (например, QEMU) — работают очень быстро, но в отличие от других инструментов не предоставляют достоверной информации о работе устройства. Зато QEMU может почти молниеносно осуществить подачу требуемых данных и выдать результат в виде «прошел» или «не прошел», а также некоторые логи.
Потактовые симуляторы (например, VCS) — у них есть внутренняя система планирования времени, но скорость работы низкая. Они нужны для сбора трассировочных файлов, по которым можно восстановить состояние любого регистра и провода в любой момент.
ПЛИС — специальные вычислительные платформы, на которые можно загрузить и запустить «образ» своей микросхемы, будто это уже готовое физическое устройство. ПЛИС значительно быстрее потактовых симуляторов, но при этом дает представление о реальном поведении системы на кристалле.
У каждого решения есть плюсы и минусы, и не всегда очевидно, какое лучше подходит для решения конкретной задачи. Именно поэтому придумали концепцию косимуляции, при которой микросхема делится на небольшие логические части, каждая из которых запускается в отдельном окружении. Наша задача как инженеров верификации — настроить бесшовное соединение этих частей. Так мы заметно ускоряем работу потактового симулятора, потому что распределяем его нагрузку на другие элементы системы.
На хакатоне участникам предложили поработать с небольшим DUT-устройством (Device Under Test): UART 16650. Нам нужно было найти спецификацию блока, внимательно ее изучить и составить тестовый план, который покрывает все основные главы спецификации. После составления тестового плана и написания тестов нужно прогнать их в двух разных конфигурациях интерфейса:
c обратной петлей — UART соединен сам с собой,
с подключением к термодатчику — интерфейс подключен к устройству, взаимодействие с которым также можно протестировать.
Успеть за три дня
Задание сначала может показаться сложным и не очень понятным. Но если грамотно разбить его на подзадачи, а затем постепенно двигаться к решению, то вам вполне хватит трех дней на успешную реализацию.
В первый день мы решили засесть за изучение материалов и спецификаций, а не бросаться судорожно писать тесты. Самой большой проблемой для нас тогда был страх перед непонятным и незнакомым заданием. Но он быстро прошел — заботливые инженеры YADRO снабдили нас исчерпывающей документацией. В ней описано, что и как устроено, а также в каком порядке выполнять работу.
В общем, не старайтесь в первый день стать самыми быстрыми системными программистами на хакатоне. Как показала практика — медленный, но осознанный подход приводит к лучшим результатам в ограниченное время. Так проще выходить из тупиков, в которых вы наверняка окажитесь, а их может быть много.
Если на какую-то подзадачу вы безрезультатно потратили много времени, то попросите помощи у менторов. Штрафные баллы за это не начислят, а вы быстрее выйдите из сложной ситуации.
Отметим, что задание и исходный код могут быть неидеальны. Мы, например, нашли несоответствие спецификации RTL-коду. Но не стоит сразу же писать об этом во всех чатах хакатона — лучше несколько раз проверить найденную ошибку и записать ее в отчет по верификации.
Поспешайте медленно
Правильно презентовать результаты перед жюри так же важно, как и решить саму задачу. В некоторых заданиях нужно предоставить результат в конкретном формате, например:
корректно сформировать план тестирования,
прогнать все тесты через CI,
нарисовать все нужные схемы и таблицы,
добавить текстовое пояснение к каждому тесту.
Не рекомендуем гнаться за объемом написанного кода и количеством тестов — можете не успеть привести код в порядок и потерять заветные баллы.
Распределите роли в команде, а работу разбейте на микроспринты. Задач и аспектов много, их надо учитывать на каждом этапе выполнения: поработали, обменялись кодом, провели кросс-ревью, позапускали на регрессе, записали проблемы и баги, задали вопросы ментору, повторили.
Залог вашего успеха — баланс скорости и осознанности. Если наброситься на выполнение заданий, то можно упустить важные моменты и прийти к финишу в аутсайдерах после спринтерского старта. Однако излишняя медлительность может заставить вас потратить время на задачи, которые для победы попросту не нужны.
На этом мы заканчиваем с вьетнамскими флешбэками нашим опытом на SoC Design Challenge 2024 и переходим к хакатону этого года, но уже с другой стороны — специалистов, которые помогают организаторам. Спойлеров не будет, а вот о критериях оценки ваших работ и инструментах с конкретными примерами кода с удовольствием расскажем.
Что будет на SoC Design Challenge 2025
Расскажем, что ждет участников трека «Системная верификация СнК» в апреле. Вы снова будете работать с DUT, для которого нужно провести верификацию. Но на этот раз не UART. А что именно — узнаете на самом хакатоне, всех секретов раскрывать не будем. Для DUT нужно будет разработать тестовый план и сами тесты.
В чем отличия от задания прошлого года:
Участникам больше не придется копаться в самом RTL-коде. Мы решили, что концепция «черного ящика» лучше подходит под формат проведения. К тому же не все участники в прошлом году были хорошо знакомы с SystemVerilog, что стало для них дополнительной сложностью.
Само задание не будет запускаться с целью проверки, что все работает. Мы планируем намеренно добавить некоторое количество неисправностей, чтобы участники выявили ситуации, в которых эта неисправность проявляется, и описали ее.
Зафиксированных тестовых данных не будет. Участники должны сами разобраться в том, как лучше представить входные данные и подготовить несколько шаблонов.
Надеемся, что изменения сделают хакатон еще более привлекательным для молодых специалистов.
Как подготовиться к хакатону
Далее поделимся критериями оценки работ участников, а также подробно разберем инструменты QEMU и Verilator, без которых на хакатоне не обойтись. Устраивайтесь поудобнее, будет много кода.
На что обращают внимание судьи
Как судьи выбирают победителей — наверное, самая важная информация. Поделимся основными критериями оценки:
Качество кода. Здесь будут приветствоваться проверка с помощью статических анализаторов, логичные и понятные названия переменных и функций, лаконичность самого кода и интересные входные данные.
Тестовое покрытие. Судьи соберут процент покрытых строчек кода с DUT и узнают, насколько хорошо вы справились с написанием тестов.
Количество найденных ошибок. Как уже говорилось, мы намеренно добавим несколько ошибок. Чем больше ошибок вы найдете, тем больше баллов получите.
Тестовый план. Он должен быть подробным и понятным.
Обзор инструментов с примерами кода: QEMU и Verilator
Мы также решили немного изменить нашу систему косимуляции. В распоряжении участников будет два инструмента: QEMU и Verilator. Займемся разработкой небольшой библиотеки rtl-bridge для Verilator — она будет отвечать за коммуникацию двух частей системы. Давайте разберемся, что это за инструменты.
QEMU
В косимуляции QEMU в основном нужен для управления тестом: передавать и считывать данные, а также проверять результаты на корректность.
Компания Xilinx уже задумывалась о создании подобных систем косимуляции, поэтому они разработали Remote Port — протокол передачи данных через сокеты. Чтобы этот протокол работал в реальных условиях, Xilinx создала свою версию QEMU и устройство с поддержкой взаимодействия по Remote-Port. Именно ее мы возьмем для небольшого примера.
Для начала надо скачать и собрать QEMU из официального репозитория. Процесс описан в файле README, поэтому подробно разбирать его не будем. Отметим, что не обязательно собирать все таргеты QEMU. Для это во время конфигурирования замените команду на такую:
configure --target-list=riscv32-softmmu,riscv64-softmmuРекомендуем использовать версию g++ 11.4.0, так как на более старых версиях могут возникнуть проблемы со сборкой.
Выбираем машину для запуска будущего теста с помощью команды:
qemu-system-riscv32 --machine ?Получаем такой список:
Поскольку мы проводим косимуляцию, выбираем virt-cosim.
Напишем простой тест, чтобы отправить строчку «Hello world!» на сторону RTL-кода. Мы планируем писать bare metal-тест, который запускается на «голом железе», то есть без операционной системы. Поэтому нужно узнать регистры и области памяти, в которые будет записываться информация.
Сначала нам нужны регистры UART, чтобы тест мог вывести информацию в консоль QEMU. Открываем файл /hw/riscv/virt.c и находим таблицу virt_memmap. В ней указаны адреса, по которым находятся виртуальные устройства:
UART находится по адресу 0x10000000. Затем ищем вхождение строки «UART» в файле и находим следующий блок кода. Он показывает, что это устройство соответствует спецификации ns16650a:
Документацию к устройству можно прочитать самостоятельно, поэтому приводим уже готовый код:
#define UART0_BASE 0x10000000
#define REG(base, offset) ((*((volatile unsigned char *)(base + offset))))
#define UART0_DR REG(UART0_BASE, 0x00)
#define UART0_FCR REG(UART0_BASE, 0x02)
#define UART0_LSR REG(UART0_BASE, 0x05)
#define UARTFCR_FFENA 0x01 // UART FIFO Control Register enable bit
#define UARTLSR_THRE 0x20 // UART Line Status Register Transmit Hold Register Empty bit
#define UART0_FF_THR_EMPTY (UART0_LSR & UARTLSR_THRE)
void uart_putc(char c) {
while (!UART0_FF_THR_EMPTY); // Ждем, пока UART не освободится
UART0_DR = c; // Пишем символ в регистр UART
}
void uart_puts(const char *str) {
while (*str) { // Цикл для всех символов строки
uart_putc(*str++); // Пишем очередной символ
}
}Функция uart_putc нужна для вывода в консоль одного символа, а uart_puts — для вывода строки.
Теперь пишем тело теста. Для этого выясним, по каким адресам расположено косимуляционное устройство. В таблице virt_memmap указано, что устройство находится по адресу 0x28000000. Тело нашего теста выглядит так:
void write_mem_32(int addr, int value) {
volatile int *const __ptr = (volatile int *)(addr);
*__ptr = value;
};
int read_mem_32(const int addr) {
const volatile int *const __ptr = (const volatile int *)(addr);
const int __value = *__ptr;
return __value;
};
void main(){
UART0_FCR = UARTFCR_FFENA;
uart_puts("main start\n");
const char *str = "Hello World!";
while(*str) {
uart_puts("Send char: "); uart_putc(*str); uart_putc('\n');
write_mem_32(0x28000000, *str++);
}
write_mem_32(0x28000004, 1);
while (1);
}Отметим три важных момента:
Мы добавили шаблонные функции для записи в память. Формально это не обязательно, но позволяет отделить использование обычной памяти от обращения к устройствам.
В конце присутствует бесконечный цикл, чтобы машина QEMU не завершала свое выполнение на некотором адресе — это может привести в непредвиденной ошибке. При желании вы можете организовать штатное завершение выполнения.
Перед бесконечным циклом мы пишем в адрес, отличный от адреса для записи строки. Эта условность нужна, чтобы мы могли завершить симуляцию.
Для сборки нам нужные специальные компиляторы, которые умеют собирать код под платформу RISC-V. Рекомендую использовать инструменты Syntacore.
Перед сборкой лучше написать код на ассемблере, чтобы установить корректный указатель на стек и линковочный файл для правильного расположения секций:
.global _start
.section .text._start
_start:
la sp, __stack_top
add s0, sp, zero
jal zero, main
loop: j loop
.section .data
.space 1024*8
.align 16
__stack_top:DRAM_BASE = 0x80000000;
DRAM_SIZE = 0x20000000;
MEMORY {
DRAM (rwx): ORIGIN = DRAM_BASE, LENGTH = DRAM_SIZE
}
SECTIONS
{
. = DRAM_BASE;
.text : {
KEEP(*(.text._start));
*(.text*);
}
. = ALIGN (CONSTANT (COMMONPAGESIZE));
.data : {
*(.data*)
}
}Пришло время заняться сборкой с помощью инструментов от Syntacore. Makefile будет состоять из четырех этапов:
Сборка кода на C.
Сборка ассемблера.
Компоновка всего этого добра в elf-файл.
Запуск самого QEMU.
.PHONY: all QEMU dir
all: dir QEMU
dir:
mkdir build/
build/test.o: src/test.c
riscv64-unknown-elf-gcc -c -g -O0 -Iinclude/ -ffreestanding -march=rv32i -mabi=ilp32 -o build/test.o src/test.c
build/start.o: asm/start.s
riscv64-unknown-elf-as -g -march=rv32i -mabi=ilp32 -o build/start.o asm/start.s
build/hello.elf: build/test.o build/start.o
riscv64-unknown-elf-ld -T ld/baremetal.ld -m elf32lriscv -o build/hello.elf build/test.o build/start.o
QEMU: build/hello.elf
${XILINX_QEMU}/QEMU-system-riscv32 -M virt-cosim -chardev socket,id=cosim,path=/tmp/cosim.sock,server=on -nographic -machine-path /tmp/machine-riscv32 -bios build/hello.elfРазберемся, как запустить QEMU:
Укажем cosim-машину, чтобы создалось устройство cosim.
В качестве используемого сокета укажем UNIX-сокет по пути /tmp/cosim.sock.
Укажем директорию для создания записей о работе машины.
Выключим графику.
Передадим elf-файл под видом BIOS.
Поясним последний пункт: в линковочном файле указан 0x80000000 — это стандартный адрес расположения BIOS. Поэтому передаем elf-файл под видом BIOS. Если мы захотим запустить программу на другом адресе, сначала запустится OpenSBI, который проверит подключенные устройства и передаст управление прикладной функции. Тогда нужно указать другой адрес и запускать QEMU с параметром loader.
Verilator
Приступаем к созданию второй части системы. Для этого устанавливаем Verilator версии 5 и выше. Это потактовый симулятор для языка Verilog, которым можно управлять при помощи программы на C++.
Чтобы разобраться, как работает система Verilator, напишем такую программу:
#include "Vtestbench.h"
#include "verilated.h"
int main(int argc, char** argv) {
VerilatedContext* contextp = new VerilatedContext;
contextp->commandArgs(argc, argv);
Vtestbench* top = new Vtestbench{contextp};
while (!contextp->gotFinish()) {
top->eval();
contextp->time(top->nextTimeSlot());
}
delete top;
delete contextp;
return 0;
}В программе создаем экземпляр класса, который отвечает за логику нашего Verilog-кода. Пока симуляция не закончится, в цикле производим подсчет новых значений регистров и проводов, а также двигаем время симуляции. Можно считать, что top->eval() передает управление коду на verilog, а contextp->time(top->nextTimeSlot()) изменяет значение clk.
Для написания testbench нужно понять концепцию DPI-функций. Фактически это функции, которые позволяют передавать данные и поток управления между кодом на C++ и кодом на Verilog. Такой подход позволит выполнять логику RTL-кода и при этом предоставлять интерфейс для Remote-Port.
Для косимуляции нам понадобится несколько функций, которые передают управление из C++ кода и обратно:
sv_write — функция из C++ сообщает Verilog, что пришла транзакция на запись,
c_write_resp — Verilog сообщает C++, что транзакцию обработали,
accept_transaction — Verilog опрашивает код на C++ на предмет пришедших транзакций,
sv_finish — функция из C++ завершает симуляцию.
Схема вызовов Verilog из кода C++ и обратно:
Теперь напишем Testbench (пока только базовую часть) и объявим все необходимые функции. Про особенности объявления DPI-функций можете почитать на официальном сайте Verilator.
`timescale 1ns / 1ps
import "DPI-C" context task c_write_resp;
import "DPI-C" context task accept_transaction;
module testbench;
export "DPI-C" task sv_write;
export "DPI-C" task sv_finish;
reg rst_n;
reg clk;
always begin
#5 clk= ~clk;
endДопишем часть опроса на наличие транзакций и сами DPI-функции:
initial begin
rst_n = 0;
clk = 0;
#10;
rst_n = 1;
end
task sv_write;
input int addr;
input int data;
$display("Get on addr %d char %c", addr, data); // Получаем адрес и данные и выводим их в консоль
c_write_resp();
endtask
always @(posedge clk) begin
if (rst_n) begin
accept_transaction();
end
end
task sv_finish;
$finish();
endtaskТеперь нужно обеспечить работу всех вызовов на стороне C++. Для этого создадим структуру, которая будет хранить данные о пришедшей транзакции, и напишем функции подключения и отключения сокета:
static struct {
int value; // Значение
bool enable; // Транзакция действительно пришла
long addr; // Адрес
volatile bool ping; // Для опроса, действительно ли транзакция была обработана
} transaction;
void sk_close() {
shutdown(fd, SHUT_RDWR);
close(fd);
}
void sk_connect() {
int fd_ = socket(AF_UNIX, SOCK_STREAM, 0);
struct sockaddr_un addr_;
addr_.sun_family = AF_UNIX;
strcpy(addr_.sun_path, "/tmp/cosim.sock");
connect(fd_, (sockaddr*)&addr_, sizeof(addr_));
fd = fd_;
std::thread(&readSerializer).detach();
}В нашем случае readSerializer — это поток, который все время читает сокет и сохраняет полученные пакеты Remote-Port. Код этой функции выглядит так:
static void readSerializer() {
while (1) {
std::vector<uint32_t> packet;
packet.resize(30, 0);
if (readPacket((uint8_t*)packet.data())) {
handleRequest(packet.data());
}
}
}
static int readSocket(uint8_t* data, size_t size) {
int ret = read(fd, data, size);
if (ret <= 0)
exit(1);
return be32toh(((uint32_t*)data)[1]);
}
static int readPacket(uint8_t* packet) {
int ret = readSocket(packet, 20);
readSocket(packet + 20, ret);
uint32_t* p = (uint32_t*)packet;
return ret;
}Для обработки транзакций напишем функцию handleRequest. Рекомендуем почитать документацию к протоколу Remote-Port, чтобы разобраться с кодом.
Обратите внимание, что все данные приходят в обратной последовательности байт, поэтому необходимо использовать функцию be32toh. Она возвращает байтам правильную последовательность. Также научимся обрабатывать sync-пакеты для корректной работы с QEMU.
Пример кода, который обрабатывает sync-, write- и read-пакеты:
void handleRequest(uint32_t* data) {
switch (be32toh(data[0])) { // Проверяем поле command в пакете
case 4: // Если команда write
onWriteOperation((be32toh(data[9]) << 32) + be32toh(data[10]),
((uint32_t*)(((uint8_t*)data) + 2))[14]); // Сохраняем адрес и данные из пакета, ждем ответ от verilog
data[1] = be32toh(be32toh(data[1]) - 4); // уменьшаем поле длины
data[3] = be32toh(2); // Выставляем бит response
writePacket(data); // Отправляем ответ
break;
case 6: // Если команда sync
data[3] = be32toh(2); // Выставляем бит response
writePacket(data); // Отправляем ответ
break;
default:
return;
}
}
void onWriteOperation(long addr, int value) {
transaction.value = value;
transaction.addr = addr;
transaction.ping = false;
transaction.enable = true;
while (!transaction.ping) {} // Ждем, пока не придет ответ от Verilog
}
void writeSocket(uint8_t* data, size_t size) { write(fd, data, size); }
void writePacket(uint32_t* data) {
writeSocket((uint8_t*)data, 20 + be32toh(data[1]));Осталось написать функцию опроса из Verilog, она совсем простая:
int accept_transaction() {
if (transaction.enable) {
transaction.enable = false;
sv_write(transaction.addr, transaction.value);
}
return 0;
}Доработаем main, чтобы он создавал сокет:
#include "Vtestbench.h"
#include "svdpi.h"
#include "verilated.h"
void sk_connect();
void sk_сlose();
int main(int argc, char** argv) {
VerilatedContext* contextp = new VerilatedContext;
contextp->commandArgs(argc, argv);
Vtestbench* top = new Vtestbench{contextp};
sk_connect();
while (!contextp->gotFinish()) {
top->eval();
contextp->time(top->nextTimeSlot());
}
void sk_close();и
delete top;
delete contextp;
return 0;
}Теперь можно запускать тест в косимуляции. Приведу пример своего Makefile:
.PHONY: all clean sim
all: sim
TARGET = main
TOP_MODULE = testbench
BUILD_DIR = build
SIM_DIR = $(BUILD_DIR)/simulation
SRC_DIR = rtl-bridge
SRCS := $(shell find ./$(SRC_DIR) -name '*.cpp')
VERILATOR_FLAGS = --trace --exe --cc --build --timing -Wno-PINMISSING -Wno-IMPLICIT -Wno-WIDTHEXPAND -Wno-INITIALDLY -Wno-CASEINCOMPLETE -Wno-WIDTHTRUNC --Mdir $(SIM_DIR)
TARGET = main
$(TARGET): $(SRCS) $(SRC_DIR)/$(TOP_MODULE).sv
mkdir -p $(SIM_DIR)
verilator $(VERILATOR_FLAGS) -o V$(TOP_MODULE) $(SRC_DIR)/$(TOP_MODULE).sv $(SRCS)
make -C $(SIM_DIR) -f V$(TOP_MODULE).mk
ln -sf $(SIM_DIR)/V$(TOP_MODULE) $(TARGET)
sim: $(TARGET) Makefile
./$(TARGET)
clean:
rm -rf $(BUILD_DIR) $(TARGET)В окне с QEMU:
В окне с Verilator:
Общая схема полученной системы:
Ждем на хакатоне
Еще есть время разобраться с инструментами и поработать с исходниками, которые мы упомянули в статье. Всех студентов, которым интересно проверить свои силы и пообщаться с профессионалами рынка системного программирования, ждем на инженерном хакатоне SoC Design Challenge 2025. Главное — верить в свои силы и не пасовать перед вызовами. Желаем удачи!
