Проект LLHD — универсальный язык описания аппаратуры

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


Говоря простыми словами — это новый язык описания аппаратуры, лишенный недостатков его предшественников и уже сейчас демонстрирущий приличную производительность, гибкость и совместимость с существующей инфраструктурой. Приятным моментом является то, что код основных инструментов написан на языке Rust.


Предлагаемая иерархия инструментов (здесь и далее изображения из оригинальной статьи)


У проекта есть все шансы стать тем же, чем GCC и LLVM в свое время стали для мира открытого программного обеспечения. Сложно даже представить, насколько это может изменить ситуацию вокруг разработки железа.


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


Введение


Очень долгое время разработка аппаратуры оставалась уделом махровой проприетарщины, где все разработки и взаимодействие тотально обложены NDA, да и патентами тоже особо никто делиться не собирается. Все начало меняться с появлением серии проектов, ставящих своей целью обратную разработку архитектуры и формата прошивок ПЛИС и создания полностью открытого тулчейна, позволяющего выполнять все этапы разработки прошивки для поддерживаемых ПЛИС: от парсинга HDL до симуляции, формальной верификации, размещения компонентов и маршрутизации связей и синтеза образа (bitstream), который загружается в ПЛИС. Благодаря этому сейчас возможно создание прошивок целиком с помощью открытого тулчейна для ПЛИС Lattice iCE40 (проект iCE Storm), ECP5 (проект Trellis) и, частично, для Xilinx 7 серии (проект X-Ray).


Однако, по-прежнему масла в огонь подливает весьма своеобразная иерархия инструментов. По факту, существует два основных языка описания аппаратуры: Verilog и VHDL. Оба родом из восьмидесятых и, на современный взгляд, чрезмерно многословны и негибки. Разработчикам приходится с этим мириться, ибо альтернатив в общем-то и нет: мало просто разработать новый язык описания аппаратуры, нужно еще интегрировать его в весьма консервативное окружение. Поэтому даже современные языки, такие как Chisel, вынуждены транслироваться в Verilog и VHDL. То есть, результатом работы компилятора будет не конечный код, а все тот же Verilog, который будет заново транслироваться и использоваться другими инструментами на каждом этапе разработки и тестирования.



Существующая иерархия инструментов


Проблема такого подхода не только в удобстве. Дело в том, что и Verilog и VHDL — очень большие и сложные. Спецификации этих языков буквально содержат тысячи страниц текста. По этой причине они крайне неудобны как формат промежуточного представления.


На схеме выше видно, что каждый из инструментов вынужден независимо реализовывать парсер входного языка и необходимые оптимизации, что при таком объеме спецификации означает неминуемые разночтения, ошибки и в итоге — проблемы совместимости инструментов.


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


Имеющиеся различия в интерпретации входных языков разными инструментами приводят к тому, что разработчики оказываются вынужденными придерживаться строгих (хотя и трудно формализуемых) правил, какие языковые конструкции использовать и как добиться того, чтобы и симулятор, и синтезированный прототип на ПЛИС, и конечное устройство работали одинаково и предсказуемо.


На деле же получается, что симулятор выполняет код на основании одной интерпретации, формальный верификатор — второй, синтезатор — третьей. А программист, глядя на все это великолепие должен полагать, что наверное, дизайн все же верный, раз все инструменты «договорились».


Промежуточное представление


Идея промежуточного представления (Intermediate Representation, IR) давно применяется и хорошо себя зарекомендовала в компиляторах. К примеру, и LLVM и GCC используют промежуточные представления LLVM IR и GIMPLE. Функциональные языки часто используют представление CPS. Байткод JVM тоже можно отнести к IR. Авторы применили тот же подход к языкам описания аппаратуры.


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


Надо сказать, что на данный момент уже существует с десяток промежуточных представлений для языков описания аппаратуры, но по словам авторов, ни одно из них не может выступать в роли универсального:


image

Можно выделить несколько уровней описания архитектуры: поведенческий (behavioral), структурный (structural) и уровень сетей и вентилей (netlist):


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

Из таблицы выше видно, что существующие IR в основном используются для структурного описания и синтеза. В то же время LLHD поддерживает все уровни описания и является полным по Тьюрингу. LLHD позволяет в точности передать все аспекты языков высокого уровня, включая конструкции для симуляции, верификации и тестирования. Все вместе это позволяет использовать LLHD на всех этапах разработки.


От LLVM к LLHD


LLVM — это универсальный фреймворк разработки компиляторов, позволяющий сравнительно легко реализовать поддержку своего языка путем трансляции его в специальное промежуточное представление — IR код LLVM. Вопреки названию, он не имеет отношения к виртуальным машинам, хотя и может использоваться для их создания. Почитать про LLVM можно на Википедии или здесь на Хабре. В качестве введения могу порекомендовать один из моих докладов с конференции С++ Siberia и статьи на тему разработки JIT VM для языка Smalltalk.


Важно отметить, что трансляцию в IR код нужно сделать только один раз после разбора входного языка. Дальше LLVM будет работать сама. При этом программист концентрируется на семантике своего языка, тогда как LLVM берет на себя всю грязную работу по преобразованию IR кода в инструкции процессора конечной архитектуры и сопутствующим оптимизациям: инлайнингом функций, удалением «мертвого» кода, разворачиванием и векторизацией циклов, аллокацией регистров, выбором инструкций и т.п. Прелесть в том, что единожды реализовав транслятор нашего языка в IR код, мы бесплатно и «из коробки» получаем поддержку всех целевых архитектур и форматов исполняемых файлов, с которыми LLVM умеет работать.


В основе лежит нотация SSA и разделение кода на т.н. базовые блоки, тело каждого из которых не содержит ветвления, но оканчивается инструкцией перехода. Такая организация кода здорово упрощает анализ и позволяет эффективно выполнять трансформации.


Процесс обработки IR кода в LLVM выглядит как серия проходов трансформации. На каждом проходе выполняется та или иная операция над IR кодом. Существует большое количество стандартных проходов трансформаций, общих для всех языков, которые позволяют оптимизировать код или подготовить его к трансляции в инструкции:


  • Inlinine Expansion — внедряет тело вызываемой функции вместо инструкции вызова; часто открывает дорогу другим оптимизациям
  • Dead Code Elimination — удаляет из IR кода недостижимые базовые блоки
  • Loop Invariant Code Motion — выносит за пределы цикла блоки, инвариантные по отношению к переменным индукции
  • Loop Unrolling — разворачивает несколько итераций цикла для лучшей утилизации ресурсов процессора и удобства векторизации
  • Constant Folding и Constant Propagation — проталкивают константы «вниз» по графу, заменяя арифметические подвыражения на статически вычисленный результат
  • Loop Autovectorization — автоматически векторизует скалярные циклы
  • и многие другие

LLHD унаследовал структуру IR кода LLVM, дополнив ее своими инструкциями и трансформациями, специфичными для разработки аппаратуры. В то же время, многие существующие конструкции и проходы трансформаций остались практически неизменными.


LLHD позволяет использовать один и тот же IR код и для симуляции и для синтеза.


Для симуляции дизайна IR код выполняется интерпретатором, либо средствами LLVM производится JIT-компиляция IR кода в нативные инструкции процессора с последующим их выполнением.


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


IR код LLHD


По аналогии с другими HDL языками в LLHD существует три вида компонентов: функции, процессы и сущности.


Функции отображают 0 или больше входных значений на 0 или 1 выходное значение. Функции используются для тестирования и переиспользования логики в других компонентах. Функции могут вызывать другие функции, содержать рекурсию и позволяют сформулировать действие входов на выход в терминах SSA. Функции не могут быть синтезированы непосредственно, поскольку не имеют прямых аппаратных аналогов. С точки зрения времени симуляции функции исполняются мгновенно и не могут взаимодействовать с сигналами или приостанавливать выполнение.


Процессы, напротив, могут взаимодействовать со временем. Так же как и функции, процессы формулируются в терминах потока управления. Процессы представляют собой полные по Тьюрингу подпрограммы, описывающие состояние и поведение цифровой схемы. Каждый процесс представляет собой схему с 0 или больше входами и выходами. И входы и выходы должны быть заданы сигналами. При инициализации управление передается на первый базовый блок и, так же как в функциях, продвигается в соответствии с инструкциями управления. Дополнительно, процессы могут приостанавливать выполнение на определенный промежуток времени, до смены сигнала или навечно. В отличие от функций, процессы существуют все время жизни схемы и никогда не возвращают управление.


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


Размер статьи не позволяет подробно рассмотреть структуру и синтаксис IR кода LLHD. Поэтому мы кратко пробежимся по основным моментам на примере реализции простейшего синхронного аккумулятора, который получает входное значение и выставляет сумму на выходной защелке:



Здесь объявляется сущность acc с тремя входными сигналами (однобитный синхросигнал clk, 32-битный инкремент x и однобитный разрешающий сигнал en) и одним 32-битным выходным сигналом (q). В теле сущности объявляется два сигнала d и q, с помощью которых связываются инстанции триггерного и комбинационного процессов, реализующих логику аккумулятора. Начальное состояние сигналов после сброса задается константой zero.



Триггерный процесс acc_ff задает условия срабатывания схемы по отношению к фронту синхросигнала clk. Инструкция prb получает текущее значение сигнала в данный квант времени; wait приостанавливает выполнение процесса до наступления события (времени либо изменения состояния какого-либо сигнала) и передает управление по указанной метке; neq и and реализуют операторы "не равно" и "логическое и"; в зависимости от параметров br совершает условную или безусловную передачу управления в указанные базовые блоки; drv задает будущее значение сигнала в последующем кванте.



Комбинационный процесс acc_comb получает на вход текущее значение аккумулятора q, инкремент x и сигнал разрешения en. В зависимости от значения сигнала разрешения, процесс либо выставляет на выход текущее значение без изменений, либо численно складывает (add) прочитанные значения qp и xp.


В приведенном виде код может использоваться для верификации дизайна и для симуляции. Однако, аппаратура ничего не знает о квантах времени и не может напрямую реализовывать инструкции потока управления. Поэтому для преобразования кода к удобному для синтеза виду, производятся следующие трансформации:



Проходы трансформации LLHD


  • Сокращается комбинационная сложность операций: выполняется свертка констант (CF), удаление мертвого кода (DCE) и локальные peephole оптимизации инструкций (IS)
  • Арифметика вытесняется «наверх» из базовых блоков и циклов (ECM)
  • Инструкции доступа к сигналам вытесняются из базовых блоков (TCM)
  • Удаляются инструкции потока управления и phi заменяются на мультиплексоры (TCFE)
  • Тривиальные процессы заменяются на сущности
  • Происходит определение триггеров и защелок

После указанных трансформаций IR код принимает следующий вид:



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


Оценка производительности


Авторы провели серию тестов в которых сравнили производительность эталонного интерпретатора LLHD, ускоренного JIT-симулятора LLHD и неназванного проприетарного HDL симулятора. Все три инструмента получали на вход один и тот же HDL дизайн, который исполнялся на проприетарном симуляторе непосредственно, а для LLHD был предварительно оттранслирован без оптимизаций с помощью разработанного авторами компилятора Moore.



В своей статье авторы утверждают, что все три варианта демонстрировали одинаковые результаты симуляции цикл-в-цикл. При этом на некоторых из дизайнов прототип JIT-симулятора LLHD показал производительность в 2.4 раза лучше, чем десятилетиями полируемый проприетарный симулятор, хотя на полномасштабной симуляции ядра RISC-V проприетарный симулятор заметно вырвался вперед.


Авторы считают, что это очень хороший результат и объясняют отставание последнего теста кумулятивным эффектом отсутствия оптимизаций в Moore. В будущем можно ожидать сокращения разрыва и еще большей производительности по мере реализации оптимизаций. Главное по их мнению то, что уже сейчас LLHD позволяет достоверно передать все детали дизайна и симуляции даже для такого крупного проекта как RISC-V.


Выводы


Авторы показали, что техники, традиционные для компиляторов языков программирования, могут с успехом быть применены и для языков описания аппаратуры. Был разработан новый промежуточный язык описания аппаратуры, прототипы транслятора из SystemVerilog, эталонный интерпретатор и JIT-симулятор LLHD, показавшие хорошую производительность.


Авторы отмечают следующие достоинства такого подхода:


  • Существующие инструменты могут быть значительно упрощены путем перевода на LLHD в качестве рабочего представления
  • Разработчикам новых языков описания аппаратуры достаточно один раз оттранслировать код программы в IR LLHD и бесплатно получить все остальное, включая оптимизации, поддержку целевых архитектур и окружения разработки
  • Исследователи, занимающиеся алгоритмами оптимизации логических схем или размещения компонентов на ПЛИС могут сконцентрироваться на своей основной задаче не тратя время на реализацию и отладку парсеров HDL
  • Вендоры проприетарных решений получают возможность гарантированно-бесшовной интеграции с другими инструментами экосистемы
  • Пользователи получают уверенность в корректности дизайна и возможность прозрачной отладки по всему тулчейну
  • Впервые появляется реальная возможность реализации полностью открытого стека разработки аппаратуры, отражающего последние новшества и эволюцию современных компиляторов

От себя добавлю, что я давно ждал подобного события и очень рад, что ситуация таки сдвинулась с мертвой точки. Очень надеюсь, что этот проект повлечет за собой заметное оживление в сообществе и, наконец, позволит снизить порог вхождения в разработку на ПЛИС посредством реализации новых языков и эргономичных инструментов.


Сомневаюсь, что язык Rust стал бы тем, чем он есть сейчас, не будь у него за спиной миллионов строк кода LLVM и опыта десятилетий открытой разработки компиляторов. Возможно, подобное произойдет и в случае LLHD.

Комментарии 50

    +5
    Отличная статья!
      +4
      Спасибо за теплые слова :)
      +3
      Все закончится тем, что на fpga портируют Electron.
        +2
        Ценю ваш юмор, поэтому и отвечу симметрично: да я обеими руками за, если это привлечет в разработку аппаратуры столько же новых рук, сколько сейчас пишет HTML/CSS/JS.

        Если каждый школьник сможет поморгать лампочкой, написав программу на Scratch, а в каждой машине по умолчанию будет FPGA, то жить станет намного веселее.

        Может хоть тогда запилят нормальные интерфейсы, вместо хтонического ужаса из 90х, с которым сейчас приходится иметь дело.
          +2
          а в каждой машине по умолчанию будет FPGA
          FPGA слишком дороги для крупносерийных проектов, там стояли и будут стоять ASIC. Впрочем, embedded FPGA уже вот-вот станут мейнстримом.
          +2

          На llhd.io уже засунули транслятор SystemVerilog'а в браузер. Так что не за горами.

          +3
          Дело в том, что и Verilog и VHDL — очень большие и сложные

          Про VHDL полностью согласен, но на то есть свои причини (жёсткая типизация).
          Про Verilog же категорически не соглашусь, а если быть точнее про его надстройку SystemVerilog. Он максимально гибок и предельно оптимизирован, если участь, что разработчик должен заниматься построением иерархических структурных моделей, а не лепить всю схему в один файл.
          Опять таки структурное описание (на более высоком уровне) обусловлено как минимум двумя факторами:
          1. Наличие проприетарных/авторских/встроенных IP ядер, которые часто и являются средством передачи различных технологий сторонним производителям без открытия «фирменных фишек»/патентов.
          2. Более понятное с точки зрения електроники распределённое проектирование параллельных систем. Что также упрощает глобальное восприятие сложных проектов.
          Так что приведённый пример нового языка физически плюсов никаких не приносит (если сравнивать по простоте с SV), а упрощение моделирования выглядит достаточно спорно как со стороны соответствия моделируемой конструкции реальному проекту, так и в дальнейшем применении (настоящие проблемы начинаются в месте когда виртуальные данные переходят в «железо»).
          Опять же всё бы хорошо, если бы отраслевые предприятия (от Xilinx и Altera/Intel до Lattice и Gowin) стремились внедрить что-то новое. А так не все синтезаторы поддерживают стандарт VHDL-2002 (правила 2002 года) и весь функционал SystemVerilog. Что тогда говорить про кардинально новый язык.
          P.S. Не подумайте я не злой хомяк, который отрицает всё новое. Просто мне кажется, что пройдёт ОЧЕНЬ много времени когда поддержу предложенного языка только начнут обговаривать. А до тех пор может случится так, что он уже и не понадобится ибо проектирование на HDL будет полностью вытеснено HLS'ами как это случилось с Ассемблером и его потомками
            +2
            Спасибо за развернутый комментарий! Постараюсь ответить вмеру своего понимания ситуации.

            Про 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 стал так популярен в вебе (и не только) не потому, что он самый быстрый или самый продуманный язык.
              +1
              Вы смешиваете сложность языка в целом с тем подмножеством, которое используется для машинной генерации нетлистов. Все что там есть (особенно для чистого верилога-95, на котором их обычно и лепят) можно описать на 10 страницах и еще останется место.
              Если LLVM нужно какое-то внутреннее представление в собственном формате — ну пожалуйста, не жалко. Но так-то этот IR выглядит какой-то нечитаемой версией тех же классических HDL.
                +3

                И тем не менее, почему по-вашему, ещё живёт и процветает VHDL? Причём он занимает чуть ли не половину проектов большой двойки. Всё потому что он настолько однозначен, что любая разработка на нём не принесёт двуякой трактовки и скрытых объявлений. А это зачастую решающий фактор в ответственных системах.
                Ну и действительно, как сказал nerudo синтезируемые подмножество языка невелико. А вот разные примитивы для тестирования — они то и создают зачастую ненужные страницы описания.
                Про перевод с HDL в LLHD не знал/недопонял. Идея неплохая, но ещё один слой в цепочке преобразований — ИМХО не самая лучшая идея. Опять таки повторюсь до момента получения синтезированного не листа — это лишь чрезвычайно малая доля разработки. Процентов этак 10-15 от силы. Самый большой геморрой начинается на уровне имплементации с констрейнами и плясками вокруг кривизны инструментов. Чего нельзя избежать ввиду проприетарности финальных этапов (P&R) для конкретного разработчика кристаллов

                  0
                  Субъективно, VHDL сейчас «живёт и процветает» только лишь из-за уже существующей базы IP, которую никто не захочет переписывать. Все клиенты, с которыми общались на тему разработки цифровых частей ASIC, запрашивают исключительно Verilog, все синтезаторы заточены под Verilog, а про использование хоть где-то хотя бы половины всего нового из VHDL-2008 (стандарту уже 12 лет!) я ни разу не слышал; SystemVerilog при этом реализовал всё то же самое и намного больше.
                    0
                    На VHDL много пишут (и продолжают писать) в консервативных отраслях типа оборонки и космоса.
                      0
                      На хабре была статья, где упоминалось исследование, в котором говорилось, что плисоводы очень любят VHDL (62% проектов в мире), а ещё больше его любят европейские плисоводы (79% проектов).
                        0

                        100% знакомых мне плисоводов пишет на SV и пытается узнать, кто вообще пишет на VHDL.

                          0
                          Это интересно, если не секрет, чем они это мотивируют, особенно в контексте железа, не верификации? Я как раз плисовод на VHDL, отрасль подходит под определение консервативной. SV щупаю сейчас на досуге. В SV смущает обилие синтаксического сахара и возможность простреливать себе ноги в самых неожиданных местах, где синтезатор VHDL давно бы ругался.
                            +1
                            В SV как раз добавлены некоторые конструкции, специально предназначенные как предохранители от стрельбы в неподходящие места (always_ff/latch/comb, unique/priority case, .*). Большую свободу самовыражения предоставляет предшественник Verilog.
                              0
                              Вас понял, благодарю.
              0
              Так что ж, теперь можно ждать реализацию хардверного языка на Rust?
                0

                И хардварную реализацию WebGPU.

                  0
                  Тут проще брать OpenCl и один из существующих проектов от вендоров: SDaccel или Vitis от Xilinx и Intel FPGA SDK.
                    +1

                    Не, я имею ввиду полностью открытый GPU, который реализует в первую очередь спецификацию WebGPU. Текущие реализации WebGPU уже реализованы над существующими GAPI. В плане кроссплатформенности самая продвинутая реализация: wgpu/wgpu-rs. Умеет работать поверх DX/Metal/Vulkan, а в будущем даже поверх OpenGL ES 3 (но это не точно). В ночных сборках браузеров (надо включить опции) оно тоже местами есть. В Firefox Nightly тоже с самых недавних пор.


                    Полностью хардварная реализация тут скорее как ачивка. И в данном случае тут будет важно иметь очень лёгкий порог вхождения (может быть даже целый туториал о создании собственного GPU).


                    Я скорее всего буду исследовать эту тему ближе к концу года, но никаких обещаний дать не могу.

                      0
                      Если вас интересует именно разработка GPU то можете посмотреть вот на этот проект: opencores.org/projects/flexgripplus

                      Не знаю правда в чем будет практический смысл. Реализация на ПЛИС будет в десятки раз дороже чем сравнимая по мощности видеокарта прошлых лет.

                      Но как исследовательский проект конечно интересно.
                  0
                  Это собственно одна из тем моих исследований. Я пытаюсь понять, можно ли реализовать язык описания аппаратуры так, чтобы он был органичной частью Rust и чтобы система типов не позволяла стрелять себе по ногам. То есть что-то вроде Chisel но на базе Rust.

                  Так то уже сейчас есть проект Kaze, который позволяет делать что-то подобное, но я хочу сделать это уровнем выше.
                    0
                    Вот я тоже на Кейз смотрю.
                    А может ещё понадёргать идей и из Julia, на котором сделана Modia.
                      +1
                      Справедливости ради, название читается как ка-зэ. Это японское слово 風 означающее «ветер».
                        0
                        Спасиб!
                        Надо бы в статьях сразу давать такие транскрипции.
                          0
                          Хех…

                          Семен Семенович досконально изучил эту сторону психики проксимцев, беседуя с Христианом Христофоровичем Казе, академиком и главным инженером (пси)-ВМ. (На самом деле он был не Христиан Христофорович, а суть кристаллоида высшей сложности и надежности, не меняющая свои качества в любых нагрузочных режимах, от холостого хода до короткого замыкания — от х.х. до к.з. на языке электриков).

                          ([Владимир Савченко, «Похитители сутей»])
                        –2
                        Зачем это надо? Раст, скала, пайтон, С++ — напридумывали уже черт знает чего. После этого любая ошибка в коде превращается в дамп на пятьдесят строк, говорящий не о том, где ошибка, а о том, что в какой-то библиотеке, вызванной из какой-то другой библиотеки, что-то отстрелилось в строке 17296.
                          +2
                          Справедливости ради, так же как в LLVM, LLHD IR предоставляет возможности внедрения метаинформации, которая не теряется при преобразованиях. Собственно это одна из причин, по которой разумно иметь единое рабочее представление по всему тулчейну.

                          То есть при первичной трансляции входного языка (Verilog) в IR прописывается метаинфа соответствия конструкций IR кода и элементов входного языка. Оное соответствие потом сохраняется вплоть до конечного синтеза.

                          Поэтому, если, скажем, роутер не может развести сигнальную линию, он будет ругаться по-человечески, мол, не могу развести такой-то сигнал, объявленный на такой-то строке такого-то вашего файла, а не потоком сознания на два экрана с идентификаторами по 200 символов.

                          По поводу еще одного языка: считаю, что это имеет смысл, если автору есть что сказать. Каждый новый язык должен иметь какую-то нетривиальную фишку или решать какую-то известную проблему. Иначе это бессмысленно.
                          0

                          Почему раст? Есть другие языки, где на уровне типов не стрелять по ногам куда проще и выразительнее.

                            0
                            Ну… может быть потому, что мне это интересно? LLHD написан на расте и тривиально интегрируется. У раста очень толковая система процедурных макросов. Наконец, раст — системный язык который позволяет делать реализацию с минимальными накладными расходами, а его система типов позволяет аккуратно управлять ресурсами.

                            Соответственно я могу представить прошивку для какого-нибудь Xilinx Zynq или Intel Xeon Scalable, где программная часть крутится на процессорных ядрах, а логическая часть на ПЛИС. При этом получаем один целостный проект, где типы согласованы а компилятор следит за тем чтобы все билось.

                            Использовать для тех же целей Haskell или Scala можно конечно, но это уже не будет иметь особых конкурентных преимуществ.
                              0

                              Хаскель, при всей моей любви, тоже так себе для задачи выражения сложных вещей в типах. Я скорее о языках вроде агды или идриса (или кока, если вы в душе француз). Причём в Idris 2 куда более интересная система субструктурной типизации, на мой взгляд.


                              Но интерес, конечно, тут важнее, спору нет.

                                0
                                Ну так то да, можно на идрисе и хоть на чем похлеще. Но наверное смысл в практичности? Proof assist-ы конечно неимоверно круты но специалистов по ним еще меньше, чем HDL разработчиков.
                                  0
                                  Но наверное смысл в практичности?

                                  Скорее всего, я вас изначально не так понял, когда вы говорили о запрете стрельбы по ногам на уровне типов. Просто для меня это сразу означает какую-то верификацию довольно хардкорного уровня — сильнее, чем то, что может дать раст (или хаскель). Ну и тогда практично было бы это делать на тех языках, которые могут позволить это выразить.

                                  0
                                  Если уж говорить о хардкоре, то надо брать ATS :)

                                  Немного жести

                                    0

                                    Про ATS я слышал, но там же завтипы так себе, скорее пародия на них почти как в том же современном хаскеле :]


                                    Но да, единственный более-менее императивный язык с хоть каким-то закосом под них.

                          0
                          Есть одна большая проблема с выдумыванием новых HDL. Внутреннее представление схемы в тулах — формат netlist, он же structural verilog. Чем дальше уходит язык RTL модели от верилога, тем сложнее потом дебажить результат (нетлист). На это постоянно налетают поклонники SV. А про чизел и т.п. я вообще молчу. С точки зрения управления проектом, разумнее долго писать на верилоге, но быстро дебажить, чем быстро писать на чем то вроде чизела, а потом погрязть в его отладке. Разумнее, потому что риски стараются сдвинуть в начало проекта, а не в конец. По этой причине верилог останется в лидерах еще очень долго.

                          Другое дело верификация. Если цель создания нового HDL — упростить верификацию, то почему бы и нет
                            +1
                            Нет. Это то же самое, что сказать, что софт надо писать на ассемблере, потому что иначе тяжело отлаживать. Если у вас верилога на 100 тысяч строк, как в каком-нибудь среднего пошиба проце, то удобность отладки верилога будет скомпенсирована количеством багов, которые вы понаделаете в этой вермишели. Не надо кривобокость инструментов приравнивать к недостаткам методологии.
                              0
                              Ассемблер в вашей аналогии — gate level structural verilog. На гейт-уровне, действительно, мало кто сейчас пишет. А вот параллель между ассемблером и верилогом я никак не могу провести, уж извините.

                              Далее, по поводу тулов. У тулов есть свое, внутреннее представление схем, это структурированная база данных. Структура сооответствует наиболее удобному представлению схемы в виде графа — блоки, выходы, выходы, провода, ассайны. Этот же граф и для STA используется. Сделано так, чтобы тул работал правильно, чтобы тулу было удобно на всех этапах, коих в маршруте множество. Совпадение или нет, но это внутреннее представление один в один транслируется в нетлист (который structural verilog), ни дать, ни отнять. И чтобы передать дизайн из одного тула в другой, верилог-нетлист подходит оптимальным образом. Альтернатива — передавать напрямую базу данных (open access, к примеру). Но никак не sv, чизел, vhdl или что то еще из известного мне. Конечно, наверное, все же можно и такие форматы сделать, но это существенно усложнит тулы (придется добавлять входной транслятор), так что нафига? Нет здесь никакой кривобокости. И нет потребности что то менять.
                            0
                            LLVM-ом, увы, не станет. Причина — максимальная закрытость вендоров железа. Более того, закрыта она именно для того, чтобы продавать софт, сопутствующий железу. Quartus, Vivado, you name it. Вендорам максимально не выгодно поддерживать обобщенные проекты.

                            А выбор конкретного HDL — это, по сравнению с тулами, как симулирующими закрытые/зашифрованные IP блоки от вендоров, так и работающие непосредственно с железом — ну это уже мелочи. В мире софта перейти с одного языка на другой — не проблема. В мире железа точно так же.
                              +1
                              При этом на простых дизайнах прототип JIT-симулятора LLHD показывал производительность в 2.4 раза лучше, чем десятилетиями полируемый проприетарный симулятор, и только на масштабной симуляции ядра RISC-V проприетарный симулятор заметно вырвался вперед.

                              Ну по табличке это совсем не так. То же пересечение тактовых доменов симулируется почему-то в 1.5x раза медленнее. Хотя там нет особого простора для оптимизации, имхо.

                                +5
                                Да, действительно, я невольно исказил смысл. Хотел написать, что на простых дизайнах нет драматического отставания, а получилось, что будто бы везде быстрее. Сейчас поправлю, спасибо.

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

                                По поводу отставания авторы еще пишут следующее:
                                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.
                                0
                                (del)
                                  +4
                                  Было бы замечательно, если бы разработчики наших ПЛИС делали бы под свои проекты компилятор с подобного IR, а не использовали чужие решения с отдельными программками перепланировщиками выводов в бинарнике. Может хоть тогда мы наконец то будем работать в нормальной поддерживаемой среде, а не пиратских устаревших версиях проприетарных IDE…
                                  Кстати мне кажется IR прекрасно бы встроился в технологическую цепочку разработки ПО для параллельных вычислителей с перестраиваемой архитектурой (https://parallel.ru/fpga/spo.html)
                                    0
                                    А какие альтернативные языки (Chisel, Clash, ...) уже поддерживают LLHD?
                                      0
                                      Из альтернативных полагаю что никаких. Пока знаю только о компиляторе Moore, который транслирует SystemVerilog в LLHD IR.

                                      Оригинальная статья была опубликована всего десять дней назад. Люди вероятно просто еще не в курсе.
                                      +1
                                      Почитаю повнимательнее, но на первый взгляд основная проблема современных языков описания не решена. А проблема эта — искусственное разделение функционального описания и констрейнов. Не должно быть никаких Verilog + SDC + UPF, это должен быть один язык.
                                        0
                                        А зачем constraints впихивать в язык? В FPGA свои, попроще; в ASIC другие, с паразитными емкостями и пр.
                                          +1
                                          Затем, что можно описать логику, которая не будет работать без констрэйнов. Даже если констрэйны есть, они могут быть неправильные и не совпадать с дизайном. Поэтому в нормальном языке дизайнер описывал бы требуемое поведение, а транслятор потом мог бы генерить LLHD IR, верилог, SDC и черта в ступе. Но для этого надо, чтоб люди сняли шоры, которые нацепили 30 лет назад, а это никому не надо. Проще респин чипа сделать :D
                                            0
                                            Я не представляю как constraints внедрять в код, ну не каждом же process/always их ставить?

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое