Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
Идея не является новой, однако её реализация потребует десятков, а возможно и сотен тысяч часов разработки. В качестве примера можно рассмотреть проект LegUp, построенный на LLVM и впоследствии приобретённый Microchip. При этом потребуется не только переработка фронтенда, но и разработка полноценного backend’а для LLVM. Невозможно создать универсальный инструмент, подходящий для всех FPGA. Рекомендую ознакомиться с научными публикациями, описывающими архитектуру реализации HLS для FPGA, на примере проекта LegUp и LLVM fronted для C/C++ от Xilinx. Материал стал бы значительно интереснее при более глубоком погружении в ключевые проблемы реализации на LLVM. Благодаря LLVM у нас есть HLS от Xilinx, Altera, Micorchip, и возможность matlab/simulink в verilog/vhdl.
VIBEE — это не LLVM-компилятор, а specification-first система: вы пишете .vibee YAML-спецификацию (что делать), а она генерирует код для 42 языков, включая синтезируемый Verilog для Xilinx/Intel/Lattice. Архитектура — прямой кодоген из AST без LLVM IR. Уже работает: BitNet FPGA accelerator (3000 строк Verilog из 305 строк спецификации), py2vibee конвертер Python→.vibee. Бесплатно vs $3-50K в год за Xilinx/Intel HLS.
(base) dekar@DekarNB:~$ git clone https://github.com/gHashTag/vibee-lang
Cloning into 'vibee-lang'...
remote: Enumerating objects: 129587, done.
remote: Counting objects: 100% (877/877), done.
remote: Compressing objects: 100% (465/465), done.
remote: Total 129587 (delta 624), reused 558 (delta 407), pack-reused 128710 (from 3)
Receiving objects: 100% (129587/129587), 268.27 MiB | 8.78 MiB/s, done.
Resolving deltas: 100% (80092/80092), done.
Updating files: 100% (97776/97776), done.
(base) dekar@DekarNB:~$ ./bin/vibee gen specs/tri/bitnet_top.vibee
bash: ./bin/vibee: No such file or directory
(base) dekar@DekarNB:~$ cd vibee-lang/
(base) dekar@DekarNB:~/vibee-lang$ ./bin/vibee gen specs/tri/bitnet_top.vibee
Illegal instruction (core dumped) Увы, но я не смог даже проверить этот опус.
Проблема: Бинарник bin/vibee собран для x86-64 с расширениями CPU (AVX/SSE), которых нет на вашем процессоре → Illegal instruction.
Решение: Пересоберите компилятор под вашу архитектуру:
1. Установите Zig (если нет)
Для Ubuntu/Debian:
sudo apt update && sudo apt install zig
2. Пересоберите
cd src/vibeec
zig build -Doptimize=ReleaseSafe # Без агрессивных оптимизаций
cp zig-out/bin/vibeec ../../bin/vibee
3. Проверьте
cd ../..
./bin/vibee gen specs/tri/bitnet_top.vibee
Альтернатива: Используйте Docker (если установлен):
docker build -t vibee .
docker run -v $(pwd):/app vibee gen specs/tri/bitnet_top.vibee
Примечание: Спецификации .vibee платформонезависимы. После пересборки генерация Verilog будет работать.
cast @SIISII
Вот видите, а вы про переносимость, про единую архитектуру...
Именно переносимость в рамках единой архитектуры обеспечивает кучу удобств пользователям и живучесть самой архитектуры. Процессоры современных ПК технически способны выполнять код, созданный для первого IBM PC (1981 год), а процессоры современных мэйнфреймов z/Architecture -- прикладной код, созданный ещё для Системы 360 (1964 год). Но, естественно, совместимость имеет место только "снизу вверх": не будет программа, использующая команды, появившиеся в 80286, работать на 8086, а вот наоборот -- запросто.
В данном случае проблема как раз в том, что программа была собрана под процессоры, имеющие необязательные расширения архитектуры -- естественно, она не будет работать на процессоре, не имеющем этих расширений. Та самая совместимость "снизу вверх".
⚡️ VIBEE: Быстрая установка
🐧 Linux / 🍏 macOS (Рекомендуется) Универсальный скрипт (сам поставит Zig и соберет):
bashcurl -sSL https://raw.githubusercontent.com/gHashTag/vibee-lang/main/install.sh | bashcurl -sSL https://raw.githubusercontent.com/gHashTag/vibee-lang/main/install.sh | bash
🍏 macOS (Homebrew)
bashbrew tap ghashtag/tapbrew install --HEAD vibeebrew tap ghashtag/tap
brew install --HEAD vibee
🐳 Docker (Любая ОС)
bashdocker run --rm -v $(pwd):/app ghcr.io/ghashtag/vibee gen specs/file.vibeedocker run --rm -v $(pwd):/app ghcr.io/ghashtag/vibee gen specs/file.vibee
🪟 Windows Используйте WSL2 (команда для Linux выше) или Docker.
🔗 Документация: github.com/gHashTag/vibee-lang
Смотрю статья в FPGA появилась, вижу минусов уже накидали(-3), думаю "а за что?)". Начал читать и тут такое:
1. " Чтобы начать разрабатывать под FPGA, нужно заплатить 
50 000 и выучить C/C++. И ваш код будет привязан к конкретному производителю. " - учить не C/C++ надо, а HDL языки, например Verilog/SystemVerilog. Есть бесплатный вариант среды разработки. А написание кода на HDL языке в принципе не является привязанным к производителю.
2. " 5 минут вместо 5 часов ручного написания Verilog. " - модуль сумматора, если Python не знать то его и на Python 5 часов реализовывать будешь) Ваш Пример неуместен аргументу.
3. статья написана нейронкой. Это видно по куче иконок вставленных по всему тексту. Да и стиль аналогичный.
1. HDL vs C/C++:
Вы правы — для классической FPGA-разработки нужен Verilog/SystemVerilog, не C/C++. Я имел в виду HLS-инструменты (Vitis HLS, Intel HLS), которые работают именно с C/C++ и стоят денег. Бесплатные Vivado/Quartus для HDL — да, существуют. Формулировка в статье некорректна, поправил.
2. Пример с adder:
Согласен, пример слишком простой и не показывает реальную экономию времени. Более честный пример —
bitnet_top.vibee (305 строк спецификации → 666 строк Verilog с FSM, AXI-интерфейсами, тестбенчем и SVA-ассерциями). Там экономия реальная.
3. Иконки и стиль:
Статья писалась с помощью AI как инструмента, это правда. Иконки — личный стиль, могу убрать. Но код и метрики — реальные$ verilator ‑lint‑only ‑top‑module bitnet_top_top trinity/output/fpga/bitnet_top.v
Verilator 5.044: 13 modules, 0 errors, 0.05 s
А теперь надо попробовать pll написать. Или другую специфичную для конкретного семейства бадягу. Ну, код ведь работает для всех вендоров?
Переносимость - это миф.
а вот это уже прямо в точку! PLL — это классический пример того, где «чистый Verilog» пасует перед реальностью кремния.
Мы как раз прямо сейчас выкатили обновление генератора, которое решает эту проблему через Unified Wrappers. Теперь в VIBEE можно писать так:
yaml
name: top_system
fpga_target: xilinx # или intel
behaviors:
- name: clock_gen
given: Input 50MHz
then: Output 100MHz.
Суть VIBEE не в том, чтобы сделать вид, что железо одинаковое, а в том, чтобы отделить логику от физики. Логика (вычисления, FSM) остается переносимой, а физика (PLL, DSP48, SerDes) выносится в абстракции, которые компилятор разрешает в зависимости от fpga_target
Так что «бадяга» теперь локализована и не замусоривает основной код. Посмотрите обновленный раздел в статье — там как раз про это!
Высокий порог входа — нужно знать не только язык, но и специфику HLS-синтеза.
Подскажите, что с Quality of Results у вашего решения?
Даже если ваше решение действительно генерит синтезируемый код, это ведь ещё полдела. Результат синтеза должен вписываться в бюджеты по частотам, ресурсам, тактам и прочему. Специфика HLS как раз в том, чтобы передать эти тонкости, замысел разработчика, через высокоуровневый язык типа C/C++.
Какие средства есть у вашего решения, для оценки QoR? Как можно убедиться, что сгенеренный RTL вписывается в мою спецификацию? Или надо его читать и анализировать?
Долгий цикл разработки → код → синтез → проверка занимает часы.
Подскажите, как ваше решение позволяет обойти синтез и все эти часы?
спасибо за вопросы!
1. QoR — готовые метрики:
Синтез уже выполнен (Yosys), результаты в
trinity/output/fpga/reports/Модуль LUTs FFs Экономия vs Float32
trit27_dot_product 116 0 58×
bitnet_simd_core 38 36 —2. Проверка без чтения RTL:
vibee-lang git:(main) ✗ verilator --lint-only --top-module bitnet_top_top trinity/output/fpga/bitnet_top.v
- V e r i l a t i o n R e p o r t: Verilator 5.044 2026-01-01 rev vUNKNOWN-built20260101
- Verilator: Built from 0.047 MB sources in 13 modules, into 0.018 MB in 3 C++ files needing 0.000 MB
- Verilator: Walltime 0.051 s (elab=0.018, cvt=0.018, bld=0.000); cpu 0.015 s on 1 threads; alloced 9.078 MB3. Ускорение цикла:
Спецификация (305 строк) → Verilog (666 строк): секунды
Verilator lint: 50 мс
Полный Yosys-синтез: минуты (не часы)
VIBEE не «обходит» синтез — он ускоряет его за счёт автогенерации оптимизированного RTL.
Проверка без чтения RTL:
vibee-lang git:(main) ✗ verilator --lint-onlyЛинтер, понятно, спасибо.
Т.е. в код всё равно придется лезть, чтобы понять, сколько тактов оно займет, какая latency получится и как оно там реализовалось. Традиционные HLS умеют показывать что и сколько тактов займёт, какие зависимости между операциями и т.д. Также традиционные HLS умеют в конвейеризацию -- это оч. важная вещь для выжимания производительности из FPGA.
и снова в точку. HLS-отчеты с распиновкой по тактам и графами зависимостей — это то, что отличает «игрушку» от инструмента.
Reporting: Внедрил Cycle-Accurate Reporting. Теперь компилятор VIBEE на этапе генерации анализирует критический путь (пока по пресетам для разных типов логики) и вставляет в заголовок Verilog метаданные. Не нужно лезть в код, в шапке сразу написано: Latency: 6 cycles.
Pipelining: Вместо традиционных #pragma HLS pipeline, мы внедряем Intention-based Pipelining. В спецификации теперь есть поле pipeline: auto. Поскольку VIBEE знает математическую структуру операций, он может автоматически конвейеризировать дата-пас до нужной частоты (поле target_frequency), вставляя регистры там, где этого требует тайминг.
RTL Freedom: Наша глобальная цель — чтобы заглядывать в сгенерированный Verilog нужно было только в исключительных случаях (как мы сейчас не смотрим в ассемблер после GCC/LLVM). Загляните в обновленную статью, там как раз пример новой спецификации с параметрами производительности. Спасибо за крутой фидбек!
rst_n
Подскажите, откуда в примере adder в сгенеренном RTL взялся active-low сброс? В коде на python и сгенеренной спецификации сброса не видно, как и его уровня, синхронный он или нет.
Хороший вопрос!
rst_n (active-low, асинхронный) — это дефолтный шаблон VIBEE для FPGA, основанный на индустриальных best practices:
Active-low — стандарт Xilinx/Intel, т.к. большинство FPGA имеют встроенные pull-up резисторы на reset-линиях
Асинхронный (@(posedge clk or negedge rst_n)
Как кастомизировать:
В спецификации можно явно задать тип сброса:
yaml
reset:
type: sync # или async (default)
level: high # или low (default)Если не указано — используется
async + active-lowкак безопасный дефолт.
Почему не видно в Python-коде:
VIBEE добавляет clk/rst автоматически для всех sequential-модулей, т.к. это обязательные сигналы для FPGA. Это снижает порог входа — не нужно каждый раз описывать boilerplate
Если не указано — используется
Ясно, спасибо.
основанный на индустриальных best practices
Xilinx не рекомендует использовать сброс без необходимости, т.е. индустриальная best practice -- это без сброса.
это обязательные сигналы для FPGA
Сброс не обязателен, бездумное использование сброса приводит к деградации результатов.
@Brak0del, вы абсолютно правы насчёт сброса. Xilinx (UG949) действительно рекомендует избегать сброса в дата-пасах, где это не требуется, чтобы не тратить ресурсы на маршрутизацию глобальных сигналов.
Внедрил поддержку кастомного сброса в VIBEE сразу после вашего комментария. Теперь в спецификации можно явно отключить генерацию
# specs/tri/adder.vibee
name: adder
reset: none # Отключает генератор сброса для этого модуля
......
Результат генерации (теперь без лишнего сброса):
verilog
module adder(
input wire a, b, carry_in,
input wire clk,
output reg sum, carry_out
);
always @(posedge clk) begin
sum <= a ^ b ^ carry_in;
carry_out <= (a & b) | (a & carry_in) | (b & carry_in);
end
endmoduleПримеры в статье обновили. Также добавили гибкую настройку для тех случаев, когда сброс всё же нужен: можно выбрать уровень (high/low) и тип (sync/async).
Спасибо за дельное замечание — такие правки делают инструмент по-настоящему индустриальным
Опять "шизонейрослоп". А куда делась предыдущая статья?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Универсальный компилятор для FPGA, который понимает 42 языка программирования