Комментарии 63
Есть ли симуляторы, непосредственно поддерживающие Chisel? Или все работает только через генерацию hdl?
Есть библиотеки Chisel, позволяющие моделировать относительно простые блоки прямо на Chisel с использованием verilator. Там тоже происходит генерация, но она скрыта от пользователя. Иногда этот инструмент даже более удобен чем стандартные симуляторы, так как он понимает Scala и интегрирован с библиотеками Scala для запуска юнит-тестов. Можно запустить один тест, а можно много и в параллель и выдать общий отчет - все это идет из коробки. Очень удобно для тестирования маленьких компонент проекта со сложной логикой работы (декодеры, арбитры, алгоритмы обработки данных и т п).
Прошу прощения, что значит "относительно простые" ??? Я замотался серьёзные тесты на верилоге писать. Если бы была нормальная интеграция со скала, мне это было бы очень интересно.
Если Вы хотите тестировать большую процессорную систему, то это лучше делать на SystemVerilog/UVM и т. п. Если в составе Вашего большого дизайна есть относительно небольшой блок, который реализует сложный алгоритм, то его можно быстро и легко покрыть тестами на 100% прямо в Chisel. Основные проблемы сложных тестов: ресурсы Chisel в плане тестирования очень ограничены (в сравнении с возможностями Verilog), в версиях ниже 6.0 использовался какой-то безумно медленный симулятор. Сейчас его заменили на verilator, но первая проблема осталась, и не думаю, что в ближайшее время что-то изменится.
Основные проблемы сложных тестов: ресурсы Chisel в плане тестирования очень ограничены (в сравнении с возможностями Verilog)
Строго наоборот! Chisel и его основной язык Scala позволяют писать очень сложные тесты, строить мат.модели взаимодействующие по распределенной сети. На Verilog-е Вы такого никогда не напишите. К Verilog-у всегда прилагается что-то еще: SystemC, Tcl, Perl, Python, Bash. В результате получается эдакий винегрет.
Может в SpinalHDL иначе, или я что не так делал, но peek/poke - явно не располагает к чему-то сложному. sequencer - неплох, но после перевода Chisel на verilator он пропал. С multi-clock domains какой-то огород нужно городить. VCD - не лучший формат для больших тестов. Та и большие монолитные дизайны JVM не очень любит.
Вы не правы. Вы путаете верификационное окружение и модель. Согласен для описания моделей все что нужно в chisel как dsl на scala есть. А если рассмотреть требования к покрытию тестами rtl то тут возможностей а самое главное интеграции с инструментами симуляции у chisel нет.
Чтобы написать тоже окружение в концепции Constraint Random Verification возможностей сейчас нет.
К слову про верификацию "моделей" на Scala. Как-то начал писать на Scala поведенческую модель относительно сложного алгоритма, проверить разные реализации, потом взять лучшую и перенести ее в RTL. Поведенческую модель ведь писать быстрее чем RTL. Когда закончил отладку "модели", внезапно осознал, что это уже тот самый RTL, который без каких-либо изменений пойдет на кристалл :) и верификация на Verilog уже особо не нужна.
Отличная история! Согласен такое тоже может быть.
Кстати это хороший пример преимуществ chisel/spinal. На самом деле ускорение в разработке на них достигается не при первичной разработке дизайна, а при его доработке и модификации. Когда трудоёмкость модификации стандартного sv кода большая по сравнению с проектированием изменений.
Моё глубокое убеждение, что это хороший инструмент для повышения производительности разработчиков, которые хорошо умеют проектировать и писать rtl. Когда возможности systemverilog уже ограничивают их возможности.
Но для начинающих разработчиков или тех кто переходит из мира разработки ПО это пленительный но отравленный "плод". Когда есть все возможности языков программирования, но нет понимания rtl-проектирования. И результат вроде бы есть, но скорость разработки невысокая из-за множества ошибок и результат так себе по характеристикам.
Если бы была нормальная интеграция со скала, мне это было бы очень интересно.
Не требуется никакой интеграции со Scala. Chisel и SpinalHDL это библиотеки написанные на Scala, или "фреймворк". Вы просто пишите на Scala то, что Вам надо иcпользуя соответствующий API. :)
Смотрел видео. Спасибо за текстовую версию ! Сам сейчас хочу переписать на Chisel (с существенными улучшениями !) один свой старый проект на верилоге.
Следующий шаг: https://veryl-lang.org/
Каждый модуль, каждая шина и проводок Chisel — это класс. Объявляя сигналы и провода, мы используем существующие классы Chisel, а в случае с модулем создаем собственный класс my_module (первая строка) и наследуем его из класса Module в Chisel. Clock и reset мы автоматически наследуем из базового класса, поэтому дополнительно объявлять их не требуется.
Как быть, если в модуль заходят два клока? Как в этом случае описывать регистры, когда часть тактируется одним клоком, а часть другим? Возможно ли такое описать на Chisel?
На SpinalHDL (младший брат Chisel-а) описывают два тактовых домена, потом две области в этих доменах. Пример:
val dviClockDomain = ClockDomain(
clock = pixclk,
config = ClockDomainConfig(resetKind = BOOT),
frequency = FixedFrequency(25.0 MHz)
)
val tmdsClockDomain = ClockDomain(
clock = io.pixclk_x10,
config = ClockDomainConfig(resetKind = BOOT),
frequency = FixedFrequency(250.0 MHz)
)
val dvi_area = new ClockingArea(dviClockDomain) {
// implement DVI logic clocked by 25.0 MHz pixclk
...
}
val tmds_area = new ClockingArea(tmdsClockDomain) {
// implement TMDS logic clocked by 250.0 MHz pixclk_x10
...
}Из одной области можно легко пересылать данные в другую через BufferCC(), FIFO или двухпортовую память. Всё это делается одной-двумя строками кода.
То есть Chisel не позволяет описать в одном модуле два регистра, так чтобы они тактировались разными клоками? Например, я хочу описать True Dual Port FIFO, это возможно на Чизеле или нет?
Вот для VHDL пример двух D-триггеров на разных клоках:
process(clk1, clk2)
begin
-- 1
if rising_edge(clk1) then
reg1 <= in1;
end if;
-- 2
if rising_edge(clk2) then
reg2 <= in2;
end if;
end process;Как такое будет выглядеть на Chisel?
То есть Chisel не позволяет описать в одном модуле два регистра, так чтобы они тактировались разными клоками?
Позволяет. Если Вы хотите писать на Chisel как на Verilog/VHDL, то для Вас имеется конструкция вида:
withClock (io.clockA) {
// Code below clocked by io.clockA
val regA = RegNext(io.somestuff)
}
withClock (io.clockB) {
// Code below clocked by io.clockB
val regB = RegNext(io.otherstuff)
}Это буквально калька с VHDL. В SpinalHDL такой конструкции нет, так как она противоречит замыслу создателя. А замысел такой: сначала описываются области тактирования, потом внутри этих областей размещается код (объявляются регистры, ведется работа с ними). Всё, что объявлено внутри такой области тактируется от её клока. Это несколько дисциплинирует разработчика - заставляет его держать код относящийся к одному домену в одном месте, а не размазывать его по поверхности модуля. :-)
Полный код такого модуля можно посмотреть тут: https://github.com/pointcheck/KarnixSOC/blob/KarnixSOC/src/main/scala/mylib/CGA4HDMI.scala. У этого модуля три домена - один дефолтный (тактируется вместе с ядром микропроцессора) и два специфичных: dviClockDomain и tmdsClockDomain, у каждого свой клок. Чуть более подробно можно прочесть тут: https://habr.com/ru/articles/855718/#6.4
Например, я хочу описать True Dual Port FIFO, это возможно на Чизеле или нет?
Возможно конечно, но не нужно. :-) В Chisel и SpinalHDL уже есть готовые удобные классы для работы с FIFO разных видов. В SpinalHDL это классы StreamFifo и StreamFifoCC. Вот пример того, как выглядит работа с FIFO на SpinalHDL при передачи данных из одного домена в другой:
val clockA = ClockDomain(???)
val clockB = ClockDomain(???)
val streamA,streamB = Stream(Bits(8 bits))
// ...
val myFifo = StreamFifoCC(
dataType = Bits(8 bits),
depth = 128,
pushClock = clockA,
popClock = clockB
)
// ...
myFifo.io.push << streamA
myFifo.io.pop >> streamBВ этом примере streamA и streamB - обьекты (регистры), для которых нужно организовать взаимодействие через FIFO. Здесь они обьявлены в текущем тактовом домене. В случае с двумя тактовыми доменами, streamA и streamB будут обьявлены в соответствующей области относящейся к нужному домену. Больше ничего не требуется, вся работа по управлению потоком с кодами Грея и прочими делами скрыта в имплементации операторов << и >> класса StreamFifoCC. На Chisel есть аналогичные конструкции. Оба языка активно используют фичи ООП, в том числе переопределение операторов.
Большое спасибо за ответы!
Если я правильно понял, то Chisel и SpinalHDL - это основном для описания соединений модулей на верхнем уровне. Сами модули, например упомянутое "StreamFifoCC", используются уже готовые, вручную их не пишут. И скорей всего "StreamFifoCC" написан на SV. Если нужно что-то оптимизировать по ресурсам и быстродействию, то для этого нужно использовать классические языки описания SV и VHDL для написания модулей.
StreamFifoCC также написан на SpinalHDL, просто он есть готовый и хорошо отлаженный. Но Вы можете написать свой со своими куртизанками и преферансом. :)
На счет эффективности Verilog/VHDL вопрос спорный. Ядро VexRiscv полностью написано SpinalHDL, является очень гибко конфигурируемым и легко расширяемым. На данный момент оно считается самым эффективным из доступных опенсорсных ядер в плане требуемых ресурсов ПЛИС. Поэтому говорить, что на SpinalHDL ваши цифровые схемы будут неэффективны нельзя. Всё зависит от навыков разработчика. Но писать HDL код на Chisel и SpinalHDL существенно проще. Код получается более читаемым и понятным, так как эти языки позволяют оперировать абстрациями более высоких порядков. У меня возникла такая ассоциация: Verilog/VHDL по отошению к SpinalHDL/Chisel это как ассемблер и C++. Последний позволяет создавать очень сложные приложения, которые на асме написать невозможно. Но при желании можно использовать одновременно и то и другое для эффективности или совместимости. Я иногда скачиваю с Github-а готовые блоки написанные на SystemVerilog и подключаю их в SpinalHDL, делаю обертку и далее оперирую ими как готовыми компонентами.
В статье было совершенно справедливо замечено, что производительность труда одного человек пишущего на Chisel равняется команде из десятка крутых спецов пишущих на Verilog/VHDL. Я в одинокого пишу свою синезируемую СнК на SpinalHDL взяв за основу VexRiscv и не особо озадачиваюсь тем, в какие регистры оно в конечном счете синтезируется. Как давно не вдаюсь в подробности того, какой машинный код мне генерирует компилятор GCC. :)
В статье было совершенно справедливо замечено, что производительность труда одного человек пишущего на Chisel равняется команде из десятка крутых спецов пишущих на Verilog/VHDL
Спорить не буду, но уж очень сомнительно звучит)
Ну тут еще вопрос задач. Я сейчас занимаюсь обработкой видео в реальном времени. Например у меня есть сделанный мною оконный фильтр 5x5, работающий на проходе. Там буферы строк, ими нужно управлять, читать и писать с точностью до такта. Переключаться между буферами, добавлять дополнительные 'пустые' пиксели и строки по краям кадра. В общем продумывать каждый такт, иначе всё сломается. И всё это с учетом относительно небольшого количества блоков памяти в используемой микросхеме. Мне сложно представить, чем мне поможет ООП подход Чизела.
Но в любом случае, у каждого свои задачи, может быть под ваши Чизел и более удобен. Но как некое универсальное средство для всех задач - пока сомневаюсь.
Если в этом году буде конфа по FPGA, было бы интересно встретиться и обсудить различные подходы за рюмочкой чая)
P.S. Кстати, надо предложить проводить конференции не по субботам, а по пятницам. Мы ведь не для развлечения встречаемся, а по работе. А работать надо в будни))
Я сейчас работаю над реализацией контроллера USB 1.0 на SpinalHDL и мне тоже приходится выверять всё до такта. Я написал четыре примитива (класса) для передачи/приема пакетов нескольких видов, выверил их до такта с помощью анализатора, убедился что правильно рассчитываются контрольные суммы. Дальше я легко и непринужденно описываю очень сложные автоматы оперируя абстракциями более высокого уровня. USB даже первой версии - дико сложный протокол. В сети есть несколько реалиаций на SystemVerilog, но там кода - десятки тысяч строк. Я пока что еще за первую тыщу не вышел. :)
Как я написал выше - у каждого свои задачи. Но раз уж зашел разговор про передачу данных... То у меня есть MAC-ядро для 10Gig Ethernet, там тоже не самый простой протокол ;) И это даже не просто MAC-ядро, а MAC-маршрутизатор. Так вот в чем дело, меня никогда особо не интересовал объем получившегося кода. Мне важны только два параметра - Fmax и объем задействованных ресурсов (в основном bram). И даже на относительно не быстром MAX10, это ядро вполне соберется на 170 МГц причем при балансной разводке. А сколько там в итоге строк кода? Да какая разница! Мне же не за строки деньги платят)
И основная идея для меня следующая:
Код - это не цель, это средство решения поставленной задачи. И красота и объем кода имеют второстепенное значение. Сравнение языков и исходных кодов должно осуществляться не по количеству написанных строк, а по быстродействию и аппаратным ресурсам, требуемым при имплементации этого кода.
Размер кода имеет значение тогда, кода им пользуются другие люди - пытаются дописать новый функционал или устранить Вашу ошибку. А еще, через пару лет Вам будет катастрофически сложно понять то, что Вы сами когда-то написали. И чем меньше кода и чем более понятным языком он написан сейчас, тем легче Вам будет в будущем. Как-то так.
Уважаемый коллега, давайте не будем обсуждать кто какие ошибки делает, как их исправляет, и через сколько десятилетий перестает понимать свой код. Это не инженерный подход)
И еще хочу заметить, что понимание или не понимание кода - вещь субъективная, сложно её оценить. А вот Fmax - он объективен. Так что давайте в инженерной работе будем использовать линейку, а не чувство прекрасного :)
Коллега, максимизация Fmax и "чувство прекрасного" это ортогональные вещи. Нужно стараться достигать и того и другого показателя одновременно. :-)
Если серьезно, то я за собой уже неоднократно замечал, как мои мозги стремительно окирпичиваются - я не могу разобраться в том, что я написал 3-4 года назад и просто переписывал куски кода.
Рюмка чая это замечательно, только до Москвы мне 2000 км самолётом. Может быть удастся выбраться на очередное заседание FPGA Systems. :)
Не подумайте, что я вам не верю или хочу поспорить. Просто на SV и VHDL люди пишут код уже десятилетиями. И что самое главное он работает. И тут появляется новый язык, про который утверждается, что он в 10 раз лучше. Я вот сомневаюсь, имею право)
Спорить не буду, пустое это занятие. Но пока остаюсь при своём мнении - нужны объективные количественные оценки.
Может быть удастся выбраться на очередное заседание FPGA Systems. :)
Главное, чтобы оно состоялось)
Если на Chisel и на SystemVerilog описывать одну и ту же схему, то результирующая логика будет иметь одну частоту и прочие характеристики (схема-то одна и та же). Просто описание на Chisel будет проще, его напишут быстрее и оно быстрее заработает. Вот и вся разница. И чем сложнее схема тем больше эта разница.
Да я подтверждаю, разрабатывал сложный multiband CPFSK трансивер на SpinalHDL, ушло 6 месяцев вместо 4х лет предыдущей команды из 3х человек, причем покрытие тестами было в разы более сложным и гибким
Код получается более читаемым и понятным
Не соглашусь, и приведу пример. В спинале нет соглашения о том, где должны декларироваться порты ввода/вывода. Есть только рекомендация использовать io в качестве имени бандла, но порты можно объявить где угодно в теле класса, чем нередко пользуются разработчики. Т.е. получается, что нет вменяемой декларации аппаратного интерфейса, и без подробной документации бывает сложно найти концы. А документация даже к самому спиналу весьма скудная (в т.ч. scaladoc к API, который для контраста можно сравнить с javadoc для java.*), не говоря о производных либах.
У меня возникла такая ассоциация: Verilog/VHDL по отошению к SpinalHDL/Chisel это как ассемблер и C++.
Не согласен. Я думаю это как Си и ... смесь С++, Go и Ocaml. Причём, нужно понимать все три :)
производительность труда одного человек пишущего на Chisel равняется команде из десятка крутых спецов пишущих на Verilog/VHDL
Раза в полтора. Ну может быть с натяжкой в два. Но не в 10 - это совершенно точно.
Я не против спинала и чизела, они мне самому нравятся (хотя, можно было сделать и лучше), но это далеко не серебряная пуля.
Ну, на том и сойдемся. Ведь существуют десятки (если не сотни) языков программирования, так почему бы не быть такому же количеству HDL языков. :)
смесь С++, Go и Ocaml. Причём, нужно понимать все три :)
Это миф. Чтобы писать на Chisel, достаточно освоить 20% книги "Scala для чайников" + сам Chisel.
Чем больше пишешь на Chisel, тем больше отношение к старым HDL именно как к assembler. На них пишутся только небольшие низкоуровневые участки кода, которые на Chisel написать нельзя. Например, тех ячейки, ассерции, модели памятей и аналоговых блоков.
Всё, что объявлено внутри такой области тактируется от её клока. Это несколько дисциплинирует разработчика - заставляет его держать код относящийся к одному домену в одном месте, а не размазывать его по поверхности модуля. :-)
Что мешает для каждого клокового домена держать код в своем process/always? Все-таки доводы должны опираться не на вкусовщину, а на объективные критерии - результаты синтеза и имплементации. Кому-то избыточность синтаксиса нечитабельна, а кому-то избыточность абстракций. А уж не представлять, во что эта ооп-красота будет синтезироваться - это вообще за гранью. В таком случае вся отладка сводится к шаманству с констрэйнами, игрой в стратегии или еще хлеще - топологи разрулят.
Года три пишу на SpinalHDL - это ответвление Chisel, тоже опенсорсное, но больше заточеное для синтеза под ПЛИС, в то время как Chisel - для ASIC. На SpinalHDL написаны самые популярные (и самые производительные) на данный момент опенсорсные ядра RISC-V - VexRiscv и NaxRiscv, их сейчас поголовно используют в опенсорсных проектах предварительно обворачивая в питоновые фреймворки, чтобы не пугать неофитов. :) На SpinalHDL очень удобно обращаться со сложными интерфейсами, сложными структурами данных и сложными подсистемами. То, что на Verilog занимает несколько страниц текста, на SpinalHDL делается двумя строками. Синтаксис очень понятный, даже не зная Cкалы можно смело начинать работать и познавать в процессе. С Verilog-ом такой фокус не прокатывает. Имеются встроенные конструкции для решения проблем пересечения тактовых доменов. Обширная библиотека готовых компонентов (интерфейсы, шины, кросконнекты, fifo, кодеры/декодеры и т.д.). Легко подключаются внешние модули написанные на Verilog или VHDL как Blackbox.
SpinalHDL защищает от многих неочевидных ошибок, обнаруживает и сообщает об оразовывашихся петлях и защелках, от не соответствия типов и размерностей сигналов/шин.
Симуляция встроеная, под капотом там Verilator. Все тесты пишутся в том же файле, что и реализация компонента (модуля), на Scala. Тесты могут быть сколь угодно сложные. Как было сказано в статье - Скала позволяет подтянуть сюда всю огневую мощь экосистемы Java.
Вот с этим так и не разобрался. Смотрел дискуссию https://www.reddit.com/r/FPGA/comments/106jcff/which_you_woukd_choose_between_spinalhdl_chisel/ , но там так и не пришли к определенному выводу. К тому же это два года назад, так что аргументы участников могли и устареть. Тот же SpinalHDL, последний релиз 17.12.2024. Возможно стоит попробовать оба.
Для меня выбор был очевиден - VexRiscv + куча готовых функциональных блоков в составе библиотеки. Я просто начал дописывать свои блоки чтобы сделать свой СнК на VexRiscv, так и втянулся. Автор SpinalHDL всем отвечает на вопросы по почте, в Discord и на IRC, что не может не радовать. У Chisel весь комьюнити вращается вокруг SiFive и их продукции, и сосредоточен на разработке ASIC, более "закрыт" что ли (бизнес).
Синтаксис очень понятный, даже не зная Cкалы можно смело начинать работать и познавать в процессе.
Только если не использовать сторонних библиотек. Разобраться в коде того же VexRiscv без знания скалы вообще нереально. А впихнуть его в свой проект можно только тупой копипастой из примеров (коих, кстати, очень немного).
И, собственно, такой чисто программистски-энтерпрайзный подход, когда нужно заставить себя не задумываться о том, что под капотом у абстракции - это нормально для спинала и чизела. Но у разработчиков, которые привыкли видеть проект "насквозь", он вызывает сильную когнитивную ломку.
У меня сложилось впечатление, что Chisel - это для соединения уже готовых модулей на верхнем уровне. То есть язык для некой интеграции уже готовых блоков. Сами же модули пишутся по-старинке, на SV или VHDL. Особенно если важно быстродействие и оптимизация по ресурсам.
Да и вообще, мне кажется несколько сомнительным использовать ООП подход для описания цифровых схем. Ведь код на ПЛИС, это именно что описание схемы, а не набор команд.
Да и вообще, мне кажется несколько сомнительным использовать ООП подход для описания цифровых схем. Ведь код на ПЛИС, это именно что описание схемы, а не набор команд.
Вот тут, как мне кажется, кроется большая проблема при изучении чизела опытным rtl-щиком. Очень трудно перестроиться с восприятия проекта как схемы, на восприятие как взаимодействующих абстракций. Особенно если не писал чего-то более-менее большого на обычных высокоуровневых языках программирования.
Вот это совершенно верное замечание. Chisel/SpinalHDL хорошо зайдут программистам перешедшим в дизайнеры цифровых схем. Для RTL-щиков старой закалки эти новые языки будут восприниматься тяжело.
Тут есть еще какой момент. RTL-щиков в мире не так много, и спрос на них постоянно растет (в том числе и в России). Переквалификация программиста в дизайнера схем является вполне естественным процессом. Более того, опытный программист, на мой взгляд, может привнести в процесс разработки схем много новых и полезных идей и подходов, которые давно устоялись в софтверной индустрии. Например, использование Git-а зашло в эту тему относительно недавно, но уже прочно обосновалось и мало кто представляет как работать иначе. Внедрение ООП подходов это следующий этап "софтверизации" железа. :)
Verilog прежде всего разрабатывался для моделирования аппаратуры. Лишь со временем инженеры осознали, что некоторые описания на Verilog можно синтезировать в логическую схему.
На самом деле, Verilog с самого начала разрабатывался как язык, который будет использоваться как для синтеза, так и для симуляции (пруф, стр. 17).
Полагаю, причина подобного заблуждения в том, что сначала была реализована несинтезируемая часть, а потом синтезируемая (стр. 35). Но это был просто такой порядок реализации задумки, а не что-то в духе: "Давайте реализуем язык для моделирования. Ого, а ведь он неплохо подходит и для описания аппаратуры".
На самом деле, Verilog с самого начала разрабатывался как язык, который будет использоваться как для синтеза
Википедия не согласна: Originally, Verilog was only intended to describe and allow simulation; the automated synthesis of subsets of the language to physically realizable structures (gates etc.) was developed after the language had achieved widespread usage. Собственно, поэтому 90% стандарта посвящено не синтезируемым конструкциям, ну а те 10% которые синтезируется, видно, что они изначально были про что-то другое (всякие RS-триггеры и т п).
Что там авторы указывали в своих маркетинговых документах - это уже десятое.
Какой-то фрагмент страницы из википедии без каких-либо ссылок перекрывает 90 страничный документ по истории языков описания аппаратуры написанный среди прочего автором Verilog, а также первый публичный документ, где вообще рассказывается о Verilog? Сомнительно, но ок.
Маркетинговые документы выглядят вообще не так. Вот например маркетинговый документ.
Честно говоря, глядя в верилог, который мне приходится имплементировать (asic), там такое огромное количество кастома, заточенного специально для имплементации (бекенд), что я просто не представляю как это можно было бы писать на чизеле. Т.е. в чизеле надо делать так, чтобы весь этот кастом попадал в сгенерированный верилог, что это едва ли возможно при использовании высокоуровневых конструкций. Чизел как бы избавляет от одних проблем но добавляет другие, что в общем то звучит логично для языка-обертки или надстройки. Поэтому в публикации хотелось бы увидеть какую то статистику, какие и/или сколько компаний используют чизел для разработки чипов. Чтобы видеть, ушел ли чизел в мейнстрим, а не остается инструментом для энтузиастов-радиолюбителей
Чизел как бы избавляет от одних проблем но добавляет другие
Все верно. Но они все решаемы.
Chisel больше подходит для крупных IP, которые не зависят от технологии и должны легко портироваться с технологии на технологию. Те, части IP которые зависят от технологии, как правило лежат отдельно, и пишутся на том же System Verilog, при этом основная логика IP остается на Scala/Chisel.
Тогда перефразирую: было бы неплохо увидеть какую то статистику, небольшой обзор, или хоть пару примеров коммерческих айпи, написанных на чизел.
Непонятно, как позиционировать чизел: это нечто для исследователей / универов и энтузистов, либо что то вполне уже годное для ПЛИСоводов, либо используется в индастри. Последний пункт можно было бы разделить из серии - используется в мейнстрим, только для айпи, или казуально для внутренних нужд. В общем, не хватает статистики использования. Ядра риск-5, с которых все началось, на мой взгляд слишком частный и узкий пример, мизерная доля от всего того что дизайнится и производится.
Хотя наверное сам себе и отвечу. Как тут уже было сказано, чизел - опен сорс язык. А коммерческие фирмы опенс сорс стараются не использовать ввиду очевидных рисков. Так что, как бы ... вопрос снимается
Ядра риск-5, с которых все началось, на мой взгляд слишком частный и узкий пример, мизерная доля от всего того что дизайнится и производится
Ядра RISC-V это верхушка айсберга. Там вокруг них столько всего, что само ядро это менее 10% от аппаратуры современного микропроцессора. Берклийская группа (SiFive) которая начала применять и продвигать Chisel делает это не потому, что это "модно и молодежно", а потому, что Chisel позволяет контролировать всю ту с ложность с которой им приходится сталкиваться.
Chisel позволяет существенно сократить сроки разработки и отладки, при этом оставаясь в рамках одного языка. Те, кто пишут на SV, как правило должны знать еще кучу сопутствующих языков - Tcl, Perl, Bash, Python, потому как в SV очень ограниченные возможности по кастомизации, всё это делается внешними средcтвами. Такая жуткая взрывная смесь очень сложна в сопровождении. Если Вы используете Chisel, то Вам, теоритически, достаточно знать один язык. Проблема лишь в том, что всё вокруг Вас написано на SV и VHDL и на интеграцию с этим "легаси" приходится тратить много времени и строк кода различных оберток.
Тогда вопрос про чизел. Вот вы пишете, что он может заменить Tcl, Perl, Bash, Python. Ну, скажем, Tcl заменить не получится, поскольку коммерческие тулы (для фронтенда это синтез и lec) именно в Tcl и работают. Остальное используется как минимум в флоу, а флоу скрипты должен (уметь) писать каждый разработчик. Отсюда вопрос: чизел годится для флоу и может заменить все перечисленное?
Все он кончено же не заменит, но жизнь упростит. Более того сама привязка к этим всем legacy "Tcl, Perl, Bash, Python, Verilog" нередко неплохо так тянет назад, так как в Chisel/Scala можно сделать многие вещи проще. Так, чтобы дизайнер фокусировался на разрабатываемом функционале, а не на конфигурации и запуске зоопарка из кустарных скриптов на всевозможных языках. Никто не говорит о полном отказе от Bash и даже от Python, но вызывать Bash для того, что легко сделать прямо из Chisel - тоже как-то странно.
Вы синопсис DC (или генус) тоже прямо из чизела вызываете? А если надо запустить флоу, к примеру, цепочку синтез+lec+dft+saif(симуляция) - тоже все на чизеле напишете?
Как можно отказаться от баш, если это дефолтная консоль в линуксе, где альтернатива разве что csh? Про тикль уже писал выше. Питону нет альтернативы для статистической обработки репортов. Итого, заменить можно разве что флоу и парсинг репортов, об этом и был мой вопрос.
Дерево сравнения можно довольно лаконично описать в виде рекурсивного модуля, синтезаторы такое уже понимают.
Дерево сравнения и без рекурсий на SV будет "лаконичным". Просто на Chisel я написал reduceTree и пошел дальше, так как оно гарантировано работает, а на SV эту штуку предстоит еще отлаживать.
Ну, и в маршруте ASIC: synthesis tool - далеко не единственный инструмент, которому на вход передается RTL.
Более того, если Вы пишете универсальный IP на продажу, а не под конкретный набор САПР, метод с рекурсией заблокируют уже на этапе code review.
И вот какой момент, почему мне не очень нравится ООП подход для ПЛИС. Если взять классическое ООП, то оно используется там, где огромные излишки ресурсов. Например в современных ПК имеются десятки гигабайт памяти. Фактически память там очень дешевая, ею можно разбрасываться не задумываясь.
А вот в ПЛИС ситуация иная. Даже в топовых микросхемах, блочной памяти не так и много - десятки мегабит (даже не байт, а бит). Но эти микросхемы и стоят по несколько тысяч долларов. Если же брать lowcost сегмент - то бывает, что и мегабита то и нету. И здесь уже приходится экономить память, и делать всё ручками, иначе алгоритмы не влезут.
И вот эта неэкономность ресурсов в современном ООП меня и отталкивает.
Программы, в основе которых лежит ФП, тоже очень требовательны к ресурсам процессора и памяти. Думаю, это одна из причин его ограниченного использования. Но мы же не программу в итоге получаем, а схему. Для нас все эти ООП и ФП - это не более чем дополнительные инструменты, чтобы быстрее получить нужную нам схему в кристалле.
В статье была затронута тема генерации SDC и UPF. Возникает вопрос -это фича чизела, транслировать констрейнты уровня чизела в констрейнты выходного верилога?
Либо это требует ручного кодинга: как констрейнты верхнего уровня сконвертировать до уровня верилога, да так чтобы это еще и работало/конвертировалось в констрейнты нетлиста (пост-синтез)?
Под констрейнтами я имею ввиду и SDC и UPF.
Дело в том, что это ручной и кропотливый труд - писать констрейнты, которые годятся для RTL, да еще и годятся (либо легко конвертируются) в констрейнты постсинтез. С добавлением чизела сложность как будто возрастает еще на одну ступень, отсюда и вопрос.
SDC и UPF. Возникает вопрос -это фича чизела,
Chisel не имеет инструментов для генерации SDC и UPF. А вот в ChipYard (на основе Chisel) есть инструментарий для генерации и этих штук и еще много чего. Можно для своих нужд подобный упрощенный фреймворк сделать.
Как выглядит процесс отладки написанного на зубиле (==chisel)? Ну вот сунули мы сгенерённый верилог-дизайн в симулятор вместе с тестбенчем, который ловит баг, а дальше? Какие сигналы в вейвы добавлять, что на них смотреть?
Как например делать правки в гейтах, если уж речь об АСИКах? С верилогом vs нетлистом (на верилоге же) примерно понятно как, а с зубилом?
Нельзя их к сожалению сравнивать, SystemVerliog это всетаки стандарт, как и Verilog. Но 1364 гораздо проще поддерживать, чем 1800, что для опенсорса очень важно , поэтому лучше сделать фрейморк типа Chisel который никому ничего не долженн и который будет все транслировать в 1364
Напишите 3 причины использовать ООП в HDL. Все эти "упрощения" кода ведут к трудно отлаживаемым конструкциям, которые тянут баги тоннами.
Это не ООП а более правильно называть программирование с использованием статического полиморфизма и функционального программирования.
Для людей знакомых с данными концептами, большой код на самом деле значительно проще поддерживать и развивать.
В сложных проектах плотность ошибок меньше, чисто за счет того, что сложные конструкции выражены гораздо лаконичнее.
Кроме того гигантскую помощь оказывают ИДЕ которые на лету разбирают код (вплоть до детализации type tratis) и помогают писать без ошибок гораздо быстрее (JetBrains IntelliJ)
Как пример, попробуйте описать AXI cross-bar для 5-6 slaves и 2 masters на верилоге или systemverilog, на spinal это примерно 40-60 строк кода с использованием строго типизированных библиотечных блоков и работает в сложной SOC системе с первого раза.
Scala/Chisel против SystemVerilog: генерируем сложные цифровые схемы