Комментарии 50
Отличная статья!
Все закончится тем, что на fpga портируют Electron.
Ценю ваш юмор, поэтому и отвечу симметрично: да я обеими руками за, если это привлечет в разработку аппаратуры столько же новых рук, сколько сейчас пишет HTML/CSS/JS.
Если каждый школьник сможет поморгать лампочкой, написав программу на Scratch, а в каждой машине по умолчанию будет FPGA, то жить станет намного веселее.
Может хоть тогда запилят нормальные интерфейсы, вместо хтонического ужаса из 90х, с которым сейчас приходится иметь дело.
Если каждый школьник сможет поморгать лампочкой, написав программу на Scratch, а в каждой машине по умолчанию будет FPGA, то жить станет намного веселее.
Может хоть тогда запилят нормальные интерфейсы, вместо хтонического ужаса из 90х, с которым сейчас приходится иметь дело.
На llhd.io уже засунули транслятор SystemVerilog'а в браузер. Так что не за горами.
Дело в том, что и Verilog и VHDL — очень большие и сложные
Про VHDL полностью согласен, но на то есть свои причини (жёсткая типизация).
Про Verilog же категорически не соглашусь, а если быть точнее про его надстройку SystemVerilog. Он максимально гибок и предельно оптимизирован, если участь, что разработчик должен заниматься построением иерархических структурных моделей, а не лепить всю схему в один файл.
Опять таки структурное описание (на более высоком уровне) обусловлено как минимум двумя факторами:
1. Наличие проприетарных/авторских/встроенных IP ядер, которые часто и являются средством передачи различных технологий сторонним производителям без открытия «фирменных фишек»/патентов.
2. Более понятное с точки зрения електроники распределённое проектирование параллельных систем. Что также упрощает глобальное восприятие сложных проектов.
Так что приведённый пример нового языка физически плюсов никаких не приносит (если сравнивать по простоте с SV), а упрощение моделирования выглядит достаточно спорно как со стороны соответствия моделируемой конструкции реальному проекту, так и в дальнейшем применении (настоящие проблемы начинаются в месте когда виртуальные данные переходят в «железо»).
Опять же всё бы хорошо, если бы отраслевые предприятия (от Xilinx и Altera/Intel до Lattice и Gowin) стремились внедрить что-то новое. А так не все синтезаторы поддерживают стандарт VHDL-2002 (правила 2002 года) и весь функционал SystemVerilog. Что тогда говорить про кардинально новый язык.
P.S. Не подумайте я не злой хомяк, который отрицает всё новое. Просто мне кажется, что пройдёт ОЧЕНЬ много времени когда поддержу предложенного языка только начнут обговаривать. А до тех пор может случится так, что он уже и не понадобится ибо проектирование на HDL будет полностью вытеснено HLS'ами как это случилось с Ассемблером и его потомками
Спасибо за развернутый комментарий! Постараюсь ответить вмеру своего понимания ситуации.
С моей точки зрения, промежуточный формат должен быть максимально детерменированным, компактным и допускать возможность безболезненных преобразований. И удобство работы с ним не должно содержать никаких «если» и «мелкого шрифта под звездочкой».
В существующих условиях отраслевые предприятия могут продолжать делать то что и делают. Фокус в том что параллельно с титанами сейчас развивается альтернативная экосистема вокруг open source.
Про Verilog же категорически не соглашусь, а если быть точнее про его надстройку SystemVerilog. Он максимально гибок и предельно оптимизирован, если участь, что разработчик должен заниматься построением иерархических структурных моделей, а не лепить всю схему в один файл.Меня, как разработчика компилятора, «несколько» смущают 1275 страниц спецификации. Я не спорю, возможно гибкость действительно существует, но тот факт, что каждый проприетарный инструмент так или иначе реализует свой IR для работы намекает, что как машиночитаемый промежуточный формат Verilog не подходит.
С моей точки зрения, промежуточный формат должен быть максимально детерменированным, компактным и допускать возможность безболезненных преобразований. И удобство работы с ним не должно содержать никаких «если» и «мелкого шрифта под звездочкой».
Опять таки структурное описание (на более высоком уровне) обусловлено как минимум двумя факторамиТак никто же не отрицает! Если вы могли заметить LLHD IR на структурном уровне повторяет HDL. Разве что от генераторов отказались посчитав, что этим должен заниматься фронтенд входного языка.
Наличие проприетарных/авторских/встроенных IP ядерНе совсем понимаю, как тут может помочь или помешать высокоуровневый или промежуточный язык. Надо отдать IP — отдается netlist без каких либо пояснений кроме интерфейса.
Более понятное с точки зрения електроники распределённое проектирование параллельных систем. Что также упрощает глобальное восприятие сложных проектов.Возможно вы не поняли суть предлагаемого. LLHD это не «еще один новый язык, который всех порвет». Это промежуточное представление в которое может быть оттранслирован один из существующих или новых языков описания аппаратуры. Пользователю с ним работать не надо. Разработчики могут все так же писать свои дизайны на верилоге как и раньше. Выигрывает здесь в первую очередь экосистема: сокращаются издержки на поддержку новых платформ, уменьшаются баги.
Опять же всё бы хорошо, если бы отраслевые предприятия (от Xilinx и Altera/Intel до Lattice и Gowin) стремились внедрить что-то новое.Мой акцент был в первую очередь не на отраслевых предприятиях, а на open source. Ведь ровно то же самое проходили с языками программирования лет сорок назад. Был большой и серьезный фортран, были проприетарные компиляторы Си, были полностью закрытые до последнего транзистора архитектуры. Компиляторы писали разработчики самой платформы, а сторонние энтузиасты в лучшем случае были вынуждены писать трансляторы в Си, потому что иначе поддержать целевую архитектуру было нереально. А потом появились GCC и LLVM. Результат мы все знаем. Apple почему-то предпочитает делать процессоры сама, но в то же время для Clang и Swift использует и поддерживает LLVM, хотя у нее есть средства на самые радикальные меры.
В существующих условиях отраслевые предприятия могут продолжать делать то что и делают. Фокус в том что параллельно с титанами сейчас развивается альтернативная экосистема вокруг open source.
А так не все синтезаторы поддерживают стандарт VHDL-2002 (правила 2002 года) и весь функционал SystemVerilog.Ну вот вы же сами пишете, что «гибкий и предельно оптимизированный» язык оказывается полностью не поддерживается. Один вендор поддержал то, другое это. В итоге имеем войну браузеров со вкусом железа.
Просто мне кажется, что пройдёт ОЧЕНЬ много времени когда поддержу предложенного языка только начнут обговаривать.Если это будет выгодно, обговорят и применят. Как сейчас происходит с WebAssembly. Но фокус в том, что для совместного существования этого и не надо. При необходимости LLHD IR можно транслировать обратно в Verilog и скормить не поддерживающему LLHD инструменту. Страдает от этого только производительность которая будет уж точно не хуже текущего варианта когда каждое из звеньев вынуждено этим заниматься.
А до тех пор может случится так, что он уже и не понадобится ибо проектирование на HDL будет полностью вытеснено HLS'ами как это случилось с Ассемблером и его потомкамиРазве одно другому мешает? По моему как раз наоборот. Если будет универсальная и стандартная среда (как WebAssembly) в котороую можно транслировать любой входной язык и которую поддерживают все участники экосистемы, то в конечном итоге выживет самый приспособленный. JavaScript стал так популярен в вебе (и не только) не потому, что он самый быстрый или самый продуманный язык.
Вы смешиваете сложность языка в целом с тем подмножеством, которое используется для машинной генерации нетлистов. Все что там есть (особенно для чистого верилога-95, на котором их обычно и лепят) можно описать на 10 страницах и еще останется место.
Если LLVM нужно какое-то внутреннее представление в собственном формате — ну пожалуйста, не жалко. Но так-то этот IR выглядит какой-то нечитаемой версией тех же классических HDL.
Если LLVM нужно какое-то внутреннее представление в собственном формате — ну пожалуйста, не жалко. Но так-то этот IR выглядит какой-то нечитаемой версией тех же классических HDL.
И тем не менее, почему по-вашему, ещё живёт и процветает VHDL? Причём он занимает чуть ли не половину проектов большой двойки. Всё потому что он настолько однозначен, что любая разработка на нём не принесёт двуякой трактовки и скрытых объявлений. А это зачастую решающий фактор в ответственных системах.
Ну и действительно, как сказал nerudo синтезируемые подмножество языка невелико. А вот разные примитивы для тестирования — они то и создают зачастую ненужные страницы описания.
Про перевод с HDL в LLHD не знал/недопонял. Идея неплохая, но ещё один слой в цепочке преобразований — ИМХО не самая лучшая идея. Опять таки повторюсь до момента получения синтезированного не листа — это лишь чрезвычайно малая доля разработки. Процентов этак 10-15 от силы. Самый большой геморрой начинается на уровне имплементации с констрейнами и плясками вокруг кривизны инструментов. Чего нельзя избежать ввиду проприетарности финальных этапов (P&R) для конкретного разработчика кристаллов
Субъективно, VHDL сейчас «живёт и процветает» только лишь из-за уже существующей базы IP, которую никто не захочет переписывать. Все клиенты, с которыми общались на тему разработки цифровых частей ASIC, запрашивают исключительно Verilog, все синтезаторы заточены под Verilog, а про использование хоть где-то хотя бы половины всего нового из VHDL-2008 (стандарту уже 12 лет!) я ни разу не слышал; SystemVerilog при этом реализовал всё то же самое и намного больше.
На VHDL много пишут (и продолжают писать) в консервативных отраслях типа оборонки и космоса.
На хабре была статья, где упоминалось исследование, в котором говорилось, что плисоводы очень любят VHDL (62% проектов в мире), а ещё больше его любят европейские плисоводы (79% проектов).
100% знакомых мне плисоводов пишет на SV и пытается узнать, кто вообще пишет на VHDL.
Это интересно, если не секрет, чем они это мотивируют, особенно в контексте железа, не верификации? Я как раз плисовод на VHDL, отрасль подходит под определение консервативной. SV щупаю сейчас на досуге. В SV смущает обилие синтаксического сахара и возможность простреливать себе ноги в самых неожиданных местах, где синтезатор VHDL давно бы ругался.
Так что ж, теперь можно ждать реализацию хардверного языка на Rust?
И хардварную реализацию WebGPU.
Тут проще брать OpenCl и один из существующих проектов от вендоров: SDaccel или Vitis от Xilinx и Intel FPGA SDK.
Не, я имею ввиду полностью открытый GPU, который реализует в первую очередь спецификацию WebGPU. Текущие реализации WebGPU уже реализованы над существующими GAPI. В плане кроссплатформенности самая продвинутая реализация: wgpu/wgpu-rs. Умеет работать поверх DX/Metal/Vulkan, а в будущем даже поверх OpenGL ES 3 (но это не точно). В ночных сборках браузеров (надо включить опции) оно тоже местами есть. В Firefox Nightly тоже с самых недавних пор.
Полностью хардварная реализация тут скорее как ачивка. И в данном случае тут будет важно иметь очень лёгкий порог вхождения (может быть даже целый туториал о создании собственного GPU).
Я скорее всего буду исследовать эту тему ближе к концу года, но никаких обещаний дать не могу.
Если вас интересует именно разработка GPU то можете посмотреть вот на этот проект: opencores.org/projects/flexgripplus
Не знаю правда в чем будет практический смысл. Реализация на ПЛИС будет в десятки раз дороже чем сравнимая по мощности видеокарта прошлых лет.
Но как исследовательский проект конечно интересно.
Не знаю правда в чем будет практический смысл. Реализация на ПЛИС будет в десятки раз дороже чем сравнимая по мощности видеокарта прошлых лет.
Но как исследовательский проект конечно интересно.
Это собственно одна из тем моих исследований. Я пытаюсь понять, можно ли реализовать язык описания аппаратуры так, чтобы он был органичной частью Rust и чтобы система типов не позволяла стрелять себе по ногам. То есть что-то вроде Chisel но на базе Rust.
Так то уже сейчас есть проект Kaze, который позволяет делать что-то подобное, но я хочу сделать это уровнем выше.
Так то уже сейчас есть проект Kaze, который позволяет делать что-то подобное, но я хочу сделать это уровнем выше.
Вот я тоже на Кейз смотрю.
А может ещё понадёргать идей и из Julia, на котором сделана Modia.
А может ещё понадёргать идей и из Julia, на котором сделана Modia.
Справедливости ради, название читается как ка-зэ. Это японское слово 風 означающее «ветер».
Спасиб!
Надо бы в статьях сразу давать такие транскрипции.
Надо бы в статьях сразу давать такие транскрипции.
Хех…
([Владимир Савченко, «Похитители сутей»])
Семен Семенович досконально изучил эту сторону психики проксимцев, беседуя с Христианом Христофоровичем Казе, академиком и главным инженером (пси)-ВМ. (На самом деле он был не Христиан Христофорович, а суть кристаллоида высшей сложности и надежности, не меняющая свои качества в любых нагрузочных режимах, от холостого хода до короткого замыкания — от х.х. до к.з. на языке электриков).
([Владимир Савченко, «Похитители сутей»])
Зачем это надо? Раст, скала, пайтон, С++ — напридумывали уже черт знает чего. После этого любая ошибка в коде превращается в дамп на пятьдесят строк, говорящий не о том, где ошибка, а о том, что в какой-то библиотеке, вызванной из какой-то другой библиотеки, что-то отстрелилось в строке 17296.
Справедливости ради, так же как в LLVM, LLHD IR предоставляет возможности внедрения метаинформации, которая не теряется при преобразованиях. Собственно это одна из причин, по которой разумно иметь единое рабочее представление по всему тулчейну.
То есть при первичной трансляции входного языка (Verilog) в IR прописывается метаинфа соответствия конструкций IR кода и элементов входного языка. Оное соответствие потом сохраняется вплоть до конечного синтеза.
Поэтому, если, скажем, роутер не может развести сигнальную линию, он будет ругаться по-человечески, мол, не могу развести такой-то сигнал, объявленный на такой-то строке такого-то вашего файла, а не потоком сознания на два экрана с идентификаторами по 200 символов.
По поводу еще одного языка: считаю, что это имеет смысл, если автору есть что сказать. Каждый новый язык должен иметь какую-то нетривиальную фишку или решать какую-то известную проблему. Иначе это бессмысленно.
То есть при первичной трансляции входного языка (Verilog) в IR прописывается метаинфа соответствия конструкций IR кода и элементов входного языка. Оное соответствие потом сохраняется вплоть до конечного синтеза.
Поэтому, если, скажем, роутер не может развести сигнальную линию, он будет ругаться по-человечески, мол, не могу развести такой-то сигнал, объявленный на такой-то строке такого-то вашего файла, а не потоком сознания на два экрана с идентификаторами по 200 символов.
По поводу еще одного языка: считаю, что это имеет смысл, если автору есть что сказать. Каждый новый язык должен иметь какую-то нетривиальную фишку или решать какую-то известную проблему. Иначе это бессмысленно.
НЛО прилетело и опубликовало эту надпись здесь
Ну… может быть потому, что мне это интересно? LLHD написан на расте и тривиально интегрируется. У раста очень толковая система процедурных макросов. Наконец, раст — системный язык который позволяет делать реализацию с минимальными накладными расходами, а его система типов позволяет аккуратно управлять ресурсами.
Соответственно я могу представить прошивку для какого-нибудь Xilinx Zynq или Intel Xeon Scalable, где программная часть крутится на процессорных ядрах, а логическая часть на ПЛИС. При этом получаем один целостный проект, где типы согласованы а компилятор следит за тем чтобы все билось.
Использовать для тех же целей Haskell или Scala можно конечно, но это уже не будет иметь особых конкурентных преимуществ.
Соответственно я могу представить прошивку для какого-нибудь Xilinx Zynq или Intel Xeon Scalable, где программная часть крутится на процессорных ядрах, а логическая часть на ПЛИС. При этом получаем один целостный проект, где типы согласованы а компилятор следит за тем чтобы все билось.
Использовать для тех же целей Haskell или Scala можно конечно, но это уже не будет иметь особых конкурентных преимуществ.
Есть одна большая проблема с выдумыванием новых HDL. Внутреннее представление схемы в тулах — формат netlist, он же structural verilog. Чем дальше уходит язык RTL модели от верилога, тем сложнее потом дебажить результат (нетлист). На это постоянно налетают поклонники SV. А про чизел и т.п. я вообще молчу. С точки зрения управления проектом, разумнее долго писать на верилоге, но быстро дебажить, чем быстро писать на чем то вроде чизела, а потом погрязть в его отладке. Разумнее, потому что риски стараются сдвинуть в начало проекта, а не в конец. По этой причине верилог останется в лидерах еще очень долго.
Другое дело верификация. Если цель создания нового HDL — упростить верификацию, то почему бы и нет
Другое дело верификация. Если цель создания нового HDL — упростить верификацию, то почему бы и нет
Нет. Это то же самое, что сказать, что софт надо писать на ассемблере, потому что иначе тяжело отлаживать. Если у вас верилога на 100 тысяч строк, как в каком-нибудь среднего пошиба проце, то удобность отладки верилога будет скомпенсирована количеством багов, которые вы понаделаете в этой вермишели. Не надо кривобокость инструментов приравнивать к недостаткам методологии.
Ассемблер в вашей аналогии — gate level structural verilog. На гейт-уровне, действительно, мало кто сейчас пишет. А вот параллель между ассемблером и верилогом я никак не могу провести, уж извините.
Далее, по поводу тулов. У тулов есть свое, внутреннее представление схем, это структурированная база данных. Структура сооответствует наиболее удобному представлению схемы в виде графа — блоки, выходы, выходы, провода, ассайны. Этот же граф и для STA используется. Сделано так, чтобы тул работал правильно, чтобы тулу было удобно на всех этапах, коих в маршруте множество. Совпадение или нет, но это внутреннее представление один в один транслируется в нетлист (который structural verilog), ни дать, ни отнять. И чтобы передать дизайн из одного тула в другой, верилог-нетлист подходит оптимальным образом. Альтернатива — передавать напрямую базу данных (open access, к примеру). Но никак не sv, чизел, vhdl или что то еще из известного мне. Конечно, наверное, все же можно и такие форматы сделать, но это существенно усложнит тулы (придется добавлять входной транслятор), так что нафига? Нет здесь никакой кривобокости. И нет потребности что то менять.
Далее, по поводу тулов. У тулов есть свое, внутреннее представление схем, это структурированная база данных. Структура сооответствует наиболее удобному представлению схемы в виде графа — блоки, выходы, выходы, провода, ассайны. Этот же граф и для STA используется. Сделано так, чтобы тул работал правильно, чтобы тулу было удобно на всех этапах, коих в маршруте множество. Совпадение или нет, но это внутреннее представление один в один транслируется в нетлист (который structural verilog), ни дать, ни отнять. И чтобы передать дизайн из одного тула в другой, верилог-нетлист подходит оптимальным образом. Альтернатива — передавать напрямую базу данных (open access, к примеру). Но никак не sv, чизел, vhdl или что то еще из известного мне. Конечно, наверное, все же можно и такие форматы сделать, но это существенно усложнит тулы (придется добавлять входной транслятор), так что нафига? Нет здесь никакой кривобокости. И нет потребности что то менять.
LLVM-ом, увы, не станет. Причина — максимальная закрытость вендоров железа. Более того, закрыта она именно для того, чтобы продавать софт, сопутствующий железу. Quartus, Vivado, you name it. Вендорам максимально не выгодно поддерживать обобщенные проекты.
А выбор конкретного HDL — это, по сравнению с тулами, как симулирующими закрытые/зашифрованные IP блоки от вендоров, так и работающие непосредственно с железом — ну это уже мелочи. В мире софта перейти с одного языка на другой — не проблема. В мире железа точно так же.
А выбор конкретного HDL — это, по сравнению с тулами, как симулирующими закрытые/зашифрованные IP блоки от вендоров, так и работающие непосредственно с железом — ну это уже мелочи. В мире софта перейти с одного языка на другой — не проблема. В мире железа точно так же.
При этом на простых дизайнах прототип JIT-симулятора LLHD показывал производительность в 2.4 раза лучше, чем десятилетиями полируемый проприетарный симулятор, и только на масштабной симуляции ядра RISC-V проприетарный симулятор заметно вырвался вперед.
Ну по табличке это совсем не так. То же пересечение тактовых доменов симулируется почему-то в 1.5x раза медленнее. Хотя там нет особого простора для оптимизации, имхо.
Да, действительно, я невольно исказил смысл. Хотел написать, что на простых дизайнах нет драматического отставания, а получилось, что будто бы везде быстрее. Сейчас поправлю, спасибо.
В оригинальной статье смысл был не в том, что на всех дизайнах быстрее, а что даже прототип умудрился на некоторых дизайнах показать в разы лучшую производительность. Я так понял, что авторы этого не ожидали и отставание в десятки раз на неоптимизированном прототипе считают нормальным, тем более по сравнению с инструментом, который вылизывали десятки лет.
По поводу отставания авторы еще пишут следующее:
В оригинальной статье смысл был не в том, что на всех дизайнах быстрее, а что даже прототип умудрился на некоторых дизайнах показать в разы лучшую производительность. Я так понял, что авторы этого не ожидали и отставание в десятки раз на неоптимизированном прототипе считают нормальным, тем более по сравнению с инструментом, который вылизывали десятки лет.
По поводу отставания авторы еще пишут следующее:
Note that the lines of SystemVerilog code and simulation cycles do not always fully portray the complexity of a design: some SystemVerilog constructs can produce significantly more LLHD code than others, leading to significant differences in simulation time. Much of the complexity and engineering effort of our work lies in Moore, the HDL compiler frontend, which tackles the extensive SystemVerilog standard. Further extensions of Moore to implement additional SystemVerilog constructs can vastly increase the scope of designs that can be mapped to LLHD. Once a design is in LLHD, simulating it correctly is trivial.
(del)
Было бы замечательно, если бы разработчики наших ПЛИС делали бы под свои проекты компилятор с подобного IR, а не использовали чужие решения с отдельными программками перепланировщиками выводов в бинарнике. Может хоть тогда мы наконец то будем работать в нормальной поддерживаемой среде, а не пиратских устаревших версиях проприетарных IDE…
Кстати мне кажется IR прекрасно бы встроился в технологическую цепочку разработки ПО для параллельных вычислителей с перестраиваемой архитектурой (https://parallel.ru/fpga/spo.html)
Кстати мне кажется IR прекрасно бы встроился в технологическую цепочку разработки ПО для параллельных вычислителей с перестраиваемой архитектурой (https://parallel.ru/fpga/spo.html)
А какие альтернативные языки (Chisel, Clash, ...) уже поддерживают LLHD?
Почитаю повнимательнее, но на первый взгляд основная проблема современных языков описания не решена. А проблема эта — искусственное разделение функционального описания и констрейнов. Не должно быть никаких Verilog + SDC + UPF, это должен быть один язык.
А зачем constraints впихивать в язык? В FPGA свои, попроще; в ASIC другие, с паразитными емкостями и пр.
Затем, что можно описать логику, которая не будет работать без констрэйнов. Даже если констрэйны есть, они могут быть неправильные и не совпадать с дизайном. Поэтому в нормальном языке дизайнер описывал бы требуемое поведение, а транслятор потом мог бы генерить LLHD IR, верилог, SDC и черта в ступе. Но для этого надо, чтоб люди сняли шоры, которые нацепили 30 лет назад, а это никому не надо. Проще респин чипа сделать :D
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проект LLHD — универсальный язык описания аппаратуры