Comments 36
Странно, конечно, столько всего упомянуто, а SystemC не упомянут, хотя казалось бы он максимально сильно распространён в сравнении с альтернативами опирающимися на C/C++.
ИРИС надо понимать в рамках импортозамещения задуман, т.к. всё остальное иностранное (C++, конечно тоже иностранный, но "это другое", "тут понимать надо").
Да, разумеется, просто SystemC настолько известен, что я его пропустил. Сейчас добавлю. При этом в SystemC event queue есть, то есть это не просто update каждый такт старого значения на новое и перевычисление нового.
Да, разумеется, просто SystemC настолько известен, что я его пропустил. Сейчас добавлю. При этом в SystemC event queue есть, то есть это не просто update каждый такт старого значения на новое и перевычисление нового.
Про SystemC у меня есть отдельная заметка - https://panchul.livejournal.com/473865.html
Прочитал, спасибо. Мне потребовалась одна ночь повозиться с SystemC чтобы понять, что это полный фуфел. Оказывается мировой индустрии потребовалось не менее 10 лет чтобы прийти к тому же заключению. :)
Дизайнеры матюкались на SystemC сразу в 1998-1999, когда менеджеры просили их попробовать то, что им впаривали продажники Synopsys. Поэтому продажники стали пробовать другие категории пользователей, но я знаю абсолютно точно, что они не продали ничего за деньги, потому что в 2002 году шел по коридору, заглянул на презентацию продажников и увидел там жирный ноль. То есть до этого они четыре года пытались, чтобы клиенты пользовали это бесплатно, но те отбрыкивались даже так. При этом синопсис в статьях говорили "вся индустрия выстроилась за нами". Потом они нашли писателей моделей в Европе и смогли продать им историю про "более высокий уровень моделирования" используя абстракции для интерфейсов от CoWare.
Юрий, если SystemC так плох (и я поддерживаю это мнение), то что же тогда используют для создания моделей? Допустим, в телекоме используют Matlab/Simulink, но это тоже довольно плохо работает, особенно при росте проекта и команды. Я вот так и не нашел пока какой-то внятной альтернативы SystemC, хотя очень бы хотелось. Можете что-нибудь посоветовать?
В больших компаниях чаще всего С++ модели на самопальных библиотеках, которые общаются с верилогом тремя способами:
Verilog wrapper + DPI интерфейс + Bus Functional Model (BFM) для преобразования транзакций в модели на изменение сигналов на враппере.
SystemC wrapper на верхнем уровне модели + BFM. У SystemC есть нативная интеграция с Xcelium и VCS поэтому не нужно возиться с DPI.
C++ модель пишет в текстовый лог/ dump, который потом в отдельной симуляции подают через чтение этого лога в верилог.
Таким образом можно моделировать все: сетевые, графические чипы и CPU.
При этом процессорные компании (CPU) еще используют для верификации Instruction Set Simulators типа Imperas, с которым они делают сравнение следующим макаром: при каждом instruction retire / instruction graduation в RTL (котороче когда инструкция заканчивает исполнение и обновляет архитектурные регистры), проверяется что в регистрах модели те же значения (тут есть нюансы сравнения). В принципе в качестве такой модели можно использовать и QEMU, но в нем слишком много несоответствий с архитектурными спецификациями, поэтому это идея так себе.
В приципе последние 15-20 лет транзакционные модели можно писать на SystemVerilog не хуже чем на C++, а лучше (это то что я рекомендую, если вы используете быстрый симулятор - Cadence или Synopsys), но в больших компаниях как правило код этих C++ моделей тянется из 1990-х или нулевых, плюс на рынке больше программистов на C++ чем на SystemVerilog c advanced modeling skills.
Есть всякие стартапы которые пишут модели на питоне, но это пока они маленькие - потом это превращается в регрессии на несколько дней вместо часов.
использует подход, при котором они создают C++ классы для reg и wire (внутри которых вероятно старое и новое значение для такта), потом переопределяют операции, и таким образом реализуют функционал верилога в C++
Такое ощущение что это так завернуто чтобы никто не придирался, на самом деле, если выражаться максимально просто, суть в том что это просто попытка
писать дизайн (цифровую схему) на С++, вместо того чтобы писать ее на верилоге (VHDL-е?)
Естественно на С++ приходится оперировать классами которые в свою очередь должны как-то отображаться на объекты предметной области, то есть на reg и wire объекты.
Проблема в том что номенклатура объектов предметной области которые действительно будут аддекватно решать задачи автоматизации разработки дизайна, тестирования готовых схем, генерации сигналов для тестирования, ... , эта номенклатура гораздо шире и не вполне очевидна с точки зрения привычного взгляда на предметную область просто как на проэктирование дизайна.
При таком узком понимании задачи вряд ли получится что-то из этой попытки. Я так думаю.
Мне тоже показалось, что разработка ИРИС сродни внутренним DSL больших компаний-разработчиков железа. И основное его преимущество — автором языка так писать удобней.
От меня: понятно, что ИРИС заточен на перенос в hardwar'ные ядра функциональных описаний вычислительных алгоритмов ( в виде, например, С-кода). То что в ИРИС невыразимы клоковые домены ярко это подчеркивает.
SystemC с точки зрения синтаксиса и семантики - полное и бесповоротное г@вно! Писать нанём что либо можно только со страшной скуки или за катастрофически большие деньги.
На счет ИРИС. Докладчик почти не привел никаких примеров. Хочется посмотреть как выглядят на ИРИС типовые вещи, тот же FIFO с кодом Грея, какой нибудь конвейер. Так же хочется посмотреть на исходник какого нибудь серьезного пректа (например вычислительного ядра). После можно будет сказать лучше это или хуже для разработки сложных проектов. В больших проектах скорость симуляции это второстепенный показатель (Verilator решает и эту проблему, так как транслирует Verilog в Си), а первостепенным является локаничность кода, его прозрачность и незамутненность всякими прагмами и прочей управляющей шелухой, а также понятный вывод сообщений об ошибках. В этом смысле SpinalHDL и Chisel очень хороши. Если этим парням из МГУ удастся сделать что-то близкое на C++, то это будет хорошо. Еще лучше если они снабдят свой язык библиотекой классов для типовых задач, перепишут на ИРИС ходовые IP блоки (I2C, SPI, AXI, MAC, DDR), опубликуют под опенсорсной лицензией и будут поддерживать даже если финансирование от Минпромторга иссякнет. А пока что это выглядит так: "мы тут сидим, лудим, паяем, примус починяем, и тут к нам приходит Минпромторг...".
Такие будут мои пять копеек.
SystemC изначально написали вроде два каких-то студента из Германии в 1996 году и у меня ощущение, что они вдохновлялись вышедшей в том время библиотекой Микрософта для Windows MFC. А Synopsys взяли это под крылышко чтобы вытянуть другой непопулярный продукт (Behavioral Compiler) и вероятно под влиянием маркетеров. Там много стремных вещей, например возможность дедлоков если использовать не SC_THREAD, а SC_METHOD (долго рассказывать). Кое-что есть в моем посте https://panchul.livejournal.com/473865.html
Судя по докладу, ИРИС подходит больше для реализации алгоритмов, чем для интерефесов.
А в чем классность Spinal HDL? На первый взгляд куча лишнего синтаксиса:
Chisel используют только в Беркли и SiFive, причем в SiFive новых инженеров ему месяца три учат. То есть я не вижу смысла использовать его в образовательных программах - он отберет время от микроархитектуры и не поможет в трудоустройстве в подавляющее большинство компаний на рынке.
Юрий, приведенный пример не очень репрезентативен. На самом деле в SpinalHDL/Chisel кода получается как раз меньше чем на Verilog-е и он более логично организован: нет блоков always() которые сильно режут код на части и затрудняют понимание; семантика оператора присваивания зависит от типа сигнала; сбросы и клоки скрыты и их не нужно таскать с собой как чемодан без ручки и выполнять над ними ритуальные действия, и много еще разных мелки удобств. Единственное, что меня сейчас напрягает в SpinalHDL это то, что часто приходится явно приводить типы (или размеры) сигналов, а это дополнительный код (пролоема решается созданием совего класса для сигнала и переопределением соответствующих операторов). Но с другой стороны, сразу видно что и во что преобразуется, а не как в Verilog-е где одна и та же константа может синтезироваться во что угодно. ;-) Короче, более сложные вещи получается существенно короче и понятней. Тут не попробуешь - не поймешь. :)
На счет востребованности специалистов. Разумеется это не мейнстрим и спрос на спецов знакомых с этими языками ничтожно мал. Но опять же, в 90-х подавялющее большинство программистов писали на C/C++ и никто даже не считал нужным преподавать что-то иное, а сейчас все пишут на Python потому что это существенно проще и не заставляет программиста заморачиваться проблемами распределения памяти. В таких высокоуровневых HDL как Spinal и Chisel все то же самое - разрабочик сосредотачивается на задаче (на микроархитектуре как Вы говорите), а не на тонкостях компиляции/синтеза.
И еще. То, что приследовали разработчики ИРИС - моделирование, верификация и синтез в одном и том же коде. Мне хотелось бы видеть ИРИС как вариант SpinalHDL, но на C++.
"Попробуйте - узнаете" я не принимаю. Всегда должен быть пример кода, в котором получается более кратко, чем с SystemVerilog generate например. Мне такое показывали с строенным в верилог перлом и пример когда Chisel генерит интерконнект для большого количества регионов памяти.
Ну вот из приведенного Вами примера, строка на SpinalHDL:
val register = Reg(UInt(width bits)) init(0)будет преобразована в Verilog:
logic [width - 1:0] register;
always_ff @ (posedge clk or posedge rst)
if (rst)
register <= '0;Или вот другой пример, из моей статьи.
Код на SpinalHDL:
case class MyTopLevel() extends Component {
val io = new Bundle {
val cond0 = in Bool()
val cond1 = in Bool()
val flag = out Bool()
val state = out UInt(8 bits)
}
val counter = Reg(UInt(8 bits)) init 0
when(io.cond0) {
counter := counter + 1
}
io.state := counter
io.flag := (counter === 0) | io.cond1
}Выдаст код на Verilog вида:
module MyTopLevel (
input wire io_cond0,
input wire io_cond1,
output wire io_flag,
output wire [7:0] io_state,
input wire clk,
input wire reset
);
reg [7:0] counter;
assign io_state = counter;
assign io_flag = ((counter == 8'h00) || io_cond1);
always @(posedge clk or posedge reset) begin
if(reset) begin
counter <= 8'h00;
end else begin
if(io_cond0) begin
counter <= (counter + 8'h01);
end
end
end
endmoduleЗдесь код на SpinalHDL понятен даже для человека ранее не сталкивавшегося с HDL. А вот код на Verilog понятен только для посвященных.
А зачем использовать выдачу автоматического конвертера для сравнения? В причесанном виде этот код выглядит так. И я вообще не покупаю аргумент что Spinal якобы понятнее. Для Scala - программиста - может быть, но я знаю 1 Scala программиста и сотни Verilog пользователейю
module MyTopLevel
(
input io_cond0,
input io_cond1,
output io_flag,
output logic [7:0] io_state,
input clk,
input reset
);
assign io_flag = io_state == '0 | io_cond1;
always_ff @(posedge clk or posedge reset)
if (reset)
io_state <= '0;
else if (io_cond0)
io_state <= io_state + 1'b1;
endmoduleЮрий, ну Вы же не станете отрицать, что код на Scala понятен даже питонисту, ибо синтаксис тривиален (на самом деле нет, но на первый взгляд кажется таким) и общепринят во многих других языках. В то время как код на Verilog-е понятен только пользователю Verilog.
А теперь вернемся к "устоявшейся традиции" описывать отдельный блок always для каждого регистра и мы получаем страшную портянку на Verilog испещренную кусками текста вида away / if(reset).
А теперь вернемся к "устоявшейся традиции" описывать отдельный блок always для каждого регистра
Нет такой устоявшейся традиции. Просто нет. То есть абсолютно. Я не видел ни в одной компании. Есть компании (Интел, MIPS), где в некотором старом коде были instances для регистров и куча assigns, и есть компании, где бОльшую часть комбинационной логики описывают в always_comb и потом небольшое количество кода в always_ff обновляет регистры, но так чтобы на каждый регистр - отдельно always-блок - такого не видел. Отдельные блоки для resettable flip-flops и не-resettable - да, бывают. Но не always на каждый регистр.
Юрий, я не хочу продолжать этот спор потому как у меня просто не хватает квалификации - Вы всё равно меня обставите со всех сторон. :) Но глядя на всё это дело со стороны, я вижу, что писать на SpinalHDL существенно проще и понятней.
Вообще, я смотрю на это дело так: Verilog это своего рода хардверный ассемблер, в то время как Spinal/Chisel/Amaranth это "C++" или даже "Python". Как человек выросший на ассемблерах и "голом Си" я предпочту писать низкоуровневый код на Verilog, но всю обвязку, архитектуру и тестбенчи я предпочту сделать на Spinal.
Кстати, в SpinalHDL очень просто интегрируются готовые блоки на Verilog. Пример:
case class TMDS_encoder() extends BlackBox{
val clk = in Bool()
val VD = in Bits(8 bits)
val CD = in Bits(2 bits)
val VDE = in Bool()
val TMDS = out Bits(10 bits)
}При компиляции подкидываем файл .v (.vs) содержащий модуль TMDS_encoder и весь сказ.
Я ровно такой же пример написал, но только на C++ , аж в 1996 году. Тоже class counter : module { Input<4> a; итд. Пошёл к Расселу Клайну, маркетеру в Mentor Graphics. Он мне сказал: это очень мило, но рынок хочет другого. И он был прав. Это вообще первая идея, которая приходит каждому ООП программисту при виде верилога (переписать verilog или vhdl на c++ или джаву)
Про скалу - слова class, extends, new не дают никакой информации для схемы и являются артифактами OOP. Не покупаю такое.
Человеку впервые читающему код неочевидно, почему инит0 сделал асинхронный сброс по ресету, а не инит регистра, хотя про ресет вообще нет ни буквы в описании.
Это самая первая фича, откройте документацию и прочтите.
Добавлю.
Инициализация в цифровых схемах делается именно по асинхронному сбросу, об этом знаю все разработчики цифровых схем, и эта первая фича SpinalHDL которая существенно упростила ритуал.
Да, во многих ПЛИСа сейчас имеется возможность проинитить геристры при конфигурировании, но это НЕ работает с ASIC-ами и не стоит к этому привыкать. :)
На моих последних трех работах сброс был синхронный, а не асинхронный. См. дискуссию в статье Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use? Clifford E. Cummings Don Mills.
Про отсутствие инициализации в ASIC-ах (только сброс) согласен.
Дык не кто не мешает сделать его синхронным.
Вот кусок документации на тему клоковых доменов и сбросов.
Часто не нужно тащить асинхронный ресет по всей схеме и достаточно синхронного. Роутинг так тоже упрощается емнип.
И да, как вы заметили, не все работают с асиками, а может быть даже большинство с ними не работает. И слепо не использовать что-то потому-что в других местах это использовать не могут тоже неправильно.
В Questa Visualizer есть хождение по Drivers / Loads. И кидать сигналы из кода на диаграмму тоже можно. И ходить прям в коде по drivers/loads можно. Без этого по-моему такого рода тулы сегодня бесполезны.
Там есть скажем особенности в тулах для верификации, но в части отладки я бы не сказал что там чего-то фундаментально не хватает.
Мысли по поводу доклада на FPGA-Systems про маршрут ИРИС из МГУ