Комментарии 28
Хабр снова торт! Спасибо большое за статью.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.
Ряд мыслей по поводу сравнения:
- Всю семантику процессов/списков чувствительности/блокирующих-неблокирующих пришлось перенести, переписав другими словами
- Пользовательские типы и операторы — это все есть в VHDL с самого рождения. То, что в веририлоге не осилили — печально
- Последовательные автоматы. Чисто теоретически ничто (и никто) не запрещает синтезировать конструкцию вида
always begin @(posedge clk) out <= 1; @(posedge clk); // ожидание события не синтезируется out <= 2; @(posedge clk); out <= 42; end
Жаль, что нынешние синтезаторы не умеют (а может какие-нибудь продвинутые умеют?), иногда это было бы удобно. Сами же возможности языков что verilog, что VHDL подобную возможность не ограничивают
- Да, весь этот инструментарий используется в SystemC для написания различных signal-level интерфейсов.
- К сожалению я видел своими глазами, как людей заставляли переписывать VHDL в SystemVerilog, чтобы соответсвовать корпоративным стандартам. VHDL сложнее чем Verilog, поэтому Verilog программисты плодятся быстрее и постепенно убивают VHDL. А разработчиков на SystemC можно получать путём тренировки хороших C++ программистов.
- Да, сами языки не ограничивают возможость высокоуровневого синтеза с них. Один из первых HLS — behavioral compiler синтезировал Verilog и VHDL. Но не взлетел. Синтез с C/C++ завоевал себе небольшой рынок прежде всего потому, что алгоритмические модели часто пишутся на C/C++. Поэтому можно к примеру какой-нибудь VP9 кодек переписать из софта в хард не меняя языка разработки. Я читал что Google ровно так и делал, используя Catapult C для синтеза
А подскажите, какую литературу порекомендуете по SysC. в сети лишь примитивное описание, вроде «создадим вентиль или-не»
Лучше всего начать с изучения C++ и основ Verilog (Verilog всё равно вам пригодится). А потом просто заказать тренинг от SystemC вендора. После тренинга можно пользоваться стандартом SystemC как референсом.
Ну, мне как любителю пишущему на плюсах это немного затратно, кмк. Мне систС нужен как конструктор для симуляторов, с удобным интерфейсом на TLE2.0. Через скрипты и прочее. Для того, чтобы не изобретать свои примитивы. А использовать удобную библиотеку.
Понятно, т.е. вас прежде всего интересует вопрос создания виртуальных прототипов как хобби. В таком случае SystemC вам возможно не нужен, можете всё писать на чистом C++.
SystemC+TLM2.0 превращается в конструктор симуляторов только если у вас есть доступ к готовым блокам. А бесплатно эти блоки увы никто не раздает.
Если в ваших проектах вы дойдете до уровня когда вам потребуется моделировать систему с несколькими активными сущностями (Несколько процессоров, процессор и видеокарта, процессор и DMA контроллер) тогда да, есть смысл взглянуть на SystemC. Возможно где-то в сети есть готовая opensource платформа на SystemC, тогда можно было бы разобраться на готовом примере. Не знаю правда есть ли что-то подобное в сети.
В комплекте с коммерческими EDA пакетами такие примеры есть (например в Virtualizer), я разбирался в TLM2.0 на этих примерах.
Про TLM-2.0 есть tutorial в открытом доступе. Его правда достаточно сложно понять. Он скорее подходит для того чтобы освежить всё в памяти, а не для обучения с нуля.
www.doulos.com/knowhow/systemc/tlm2/tutorial__1
SystemC+TLM2.0 превращается в конструктор симуляторов только если у вас есть доступ к готовым блокам. А бесплатно эти блоки увы никто не раздает.
Если в ваших проектах вы дойдете до уровня когда вам потребуется моделировать систему с несколькими активными сущностями (Несколько процессоров, процессор и видеокарта, процессор и DMA контроллер) тогда да, есть смысл взглянуть на SystemC. Возможно где-то в сети есть готовая opensource платформа на SystemC, тогда можно было бы разобраться на готовом примере. Не знаю правда есть ли что-то подобное в сети.
В комплекте с коммерческими EDA пакетами такие примеры есть (например в Virtualizer), я разбирался в TLM2.0 на этих примерах.
Про TLM-2.0 есть tutorial в открытом доступе. Его правда достаточно сложно понять. Он скорее подходит для того чтобы освежить всё в памяти, а не для обучения с нуля.
www.doulos.com/knowhow/systemc/tlm2/tutorial__1
Мне тоже всегда хотелось написать свою модель процессора на C++. Но, к сожалению, не хватает на всё времени.
спасибо огромное за столь развернутое объяснение. Я лишь пишу модели для Proteus на Lua, и хотел прикрутить SystemC ради более выразительного описания процессоров, нежели разрозненные модули выдумывая каждый раз что-то новое.
Я обратил внимание на QBox, он имеет уже интерфейс к Qemu, TLM 2.0
И вот даже готовые модули, к примеру, Cortex-M3
У меня всё очень любительское, но эту тема мне очень интересна
Я обратил внимание на QBox, он имеет уже интерфейс к Qemu, TLM 2.0
И вот даже готовые модули, к примеру, Cortex-M3
У меня всё очень любительское, но эту тема мне очень интересна
Спасибо, интересная статья! Хотелось бы добавить, что в Vivado HLS от Xilinx большую роль играют директивы, с помощью которых можно получать те или иные результаты по пропускной способности, максимальной задержке и ресурсам. Сначала отлаживается алгоритм в чистом виде, без привязки к железу, а затем путем вставки директив в нужные места, идет борьба за ресурсы и скорость. Насчет handshake/axi вы правы, Xilinx может создать монстрообразную конструкцию с кучей лишних портов, которые потом придется на RTL уровне соединять. Но весь этот процесс можно обуздать. В любом случае, вендоры правильно поступают, привклекая Сишников в разработку на FPGA, особенно с учетом того, что современные кристаллы настолько огромные, что забить его чистым RTL-кодом не так-то и просто :)
Толково написано, спасибо.
Как один из разработчиков Simics хочу уточнить это утверждение.
Действительно, функциональные (т.е. не потактовые) модели устройств в Simics пишутся на языке DML (device modeling language), который наиболее хорошо выражает типичные функциональные особенности (банки регистров, порты, карты памяти и т.п.). Однако существующую огромную IP-базу моделей, написанных на SystemC, нельзя игнорировать. Поэтому существует возможность интеграции такого кода в модели Simics. Самое интересное при этом — это сопряжение различий в парадигмах моделирования времени в SystemC и Simics.
При этом нельзя сказать, что SystemC на этом рынке является доминирующим решением: существуют и продукты, SystemC не использующие, например WindRiver Simics.
Как один из разработчиков Simics хочу уточнить это утверждение.
Действительно, функциональные (т.е. не потактовые) модели устройств в Simics пишутся на языке DML (device modeling language), который наиболее хорошо выражает типичные функциональные особенности (банки регистров, порты, карты памяти и т.п.). Однако существующую огромную IP-базу моделей, написанных на SystemC, нельзя игнорировать. Поэтому существует возможность интеграции такого кода в модели Simics. Самое интересное при этом — это сопряжение различий в парадигмах моделирования времени в SystemC и Simics.
Можно ли запускать Simics как slave в SystemC симуляции? В этом случае мы могли бы например использовать софт бегущий на simics для тестирования RTL. К примеру, использовать драйвер сетевой карты для тестирования RTL модели сетевой карты :)
Я не уверен насчёт деталей master-slave отношений, которые сейчас доступны в Simics. Текущие усилия по интеграции всё-таки были сконцентрированы на переиспользовании существующего кода, чтобы максимально быстро получить модель полной платформы. Хотя нужно понимать, что производительность при этом будет страдать. SystemC модели слишком точные и медленные по сравнению с «родными» функциональными.
> К примеру, использовать драйвер сетевой карты для тестирования RTL модели сетевой карты
Чаще бывает наоборот — драйвер к моменту наличия модели (SystemC/DML — неважно) ещё не готов или совсем ещё плох. Но в принципе, я думаю, и Ваш сценарий на практике кем-то жа был уже опробован.
> К примеру, использовать драйвер сетевой карты для тестирования RTL модели сетевой карты
Чаще бывает наоборот — драйвер к моменту наличия модели (SystemC/DML — неважно) ещё не готов или совсем ещё плох. Но в принципе, я думаю, и Ваш сценарий на практике кем-то жа был уже опробован.
По поводу слишком медленных и точных SystemC моделей: всё зависит от того как писать. По хорошему, Untimed модель должна быть на 99% на чистом C++ и минимально использовать фукнции SystemC вызывающие переключение контекста. В идеальном случае переключение контекста нужно только для того чтобы сгенерировать прерывание.
Ну идея в том чтобы писать железку и драйвер одновременно. Hardware/Software Codesign, о необходимости которого всё время говорили большевики.
Мы сейчас пытаемся вставить в RTL симуляцию C++ную модель процессора на которой бежит реальное firmware.
Чаще бывает наоборот — драйвер к моменту наличия модели (SystemC/DML — неважно) ещё не готов или совсем ещё плох. Но в принципе, я думаю, и Ваш сценарий на практике кем-то жа был уже опробован.
Ну идея в том чтобы писать железку и драйвер одновременно. Hardware/Software Codesign, о необходимости которого всё время говорили большевики.
Мы сейчас пытаемся вставить в RTL симуляцию C++ную модель процессора на которой бежит реальное firmware.
Хотел кстати спросить, многопроцессорные системы в Symics симулируются в одном треде операционной системы, или можно запустить каждый процессор в отдельном треде?
В последней версии Simics 5 некоторые модели архитектур ЦПУ x86, ARM, ppc могут исполняться параллельно даже при работе с общей памятью. Если общей памяти не шарится (например, моделируются несколько плат, соединённых по сети ), то такие части можно запускать в параллель, и это работает уже давно.
Гриша Atakua а зачем в одной конфигурации замешивать x86, arm или powerpc? Был реальный usage-case?
Я имел в виду, что если в модели есть несколько ядер x86, то в пятой версии симулятора они могут быть помещены в домен с общей памятью и при этом симулироваться параллельно. Не для всех моделей разных архитектур эта возможность сейчас поддерживается, т.е. скажем, модель процессора от MMIX (гипотетическая многоядерная) в Симиксе из коробки будет работать только в квотированном режиме на одном хозяйском процессоре. Добавление возможности параллельной симуляции для нового процессора — непростая вещь, и, что немаловажно, далеко не все сценарии симуляции получат от этого выигрыш. Например, при работе системного кода (UEFI, firmware, ...) часты доступы к устройствам, код IO-bound, и от параллелизации толку нет.
> зачем в одной конфигурации замешивать x86, arm или powerpc? Был реальный usage-case?
В современных платформах очень часто вместе с центральным процессором от IA-32 идут контроллеры (security, сенсоры, управление питанием) от иных вендоров или не с архитектурой x86.
> зачем в одной конфигурации замешивать x86, arm или powerpc? Был реальный usage-case?
В современных платформах очень часто вместе с центральным процессором от IA-32 идут контроллеры (security, сенсоры, управление питанием) от иных вендоров или не с архитектурой x86.
Так и не нашел для себя ответ на вопрос:
Вы описываете как аналогичные конструкции SV выглядят на SystemC, но при этом этом для синтеза все равно используется HLS-синтезатор.
Это выглядит как прослойка в виде SystemC, чтобы иметь возможность написать SV код в C++ для синтеза.
Почему от этого не отказываются в пользу чистого HLS-синтеза с директивами (или OpenCL), но без специальных классов SystemC, которые опускают программистов на низкий уровень абстракции SV?
Вы описываете как аналогичные конструкции SV выглядят на SystemC, но при этом этом для синтеза все равно используется HLS-синтезатор.
Это выглядит как прослойка в виде SystemC, чтобы иметь возможность написать SV код в C++ для синтеза.
Почему от этого не отказываются в пользу чистого HLS-синтеза с директивами (или OpenCL), но без специальных классов SystemC, которые опускают программистов на низкий уровень абстракции SV?
Вы правы, в одном из юзкейсов SystemC можно рассматривать как прослойку, позволяющую написать SV код в C++ для синтеза. Это нужно для того чтобы склеивать HSL блоки с SV модулями. Альтернативный подход — использовать некоторый стандартный набор сигнальных интерфейсов в HLS, а в случае если нужен нестандартный интерфейс, конвертор можно написать в SV. Vivado HLS как раз поддерживает такой подход.
Но у синтезируемого SystemC есть еще одна важная область использования: спецификация параллелизма на уровне процессов. SystemC это как pthreads для моделирования аппаратуры.
Проще всего объяснить на примере: представьте что вам нужно написать out-of-order процессор. Тогда у вас есть процесс который накачивает данные, есть процесс-плнировщик, набор процессов для исполнения (integer и floating point), процесс с reorder buffer'ом и сохранением результатов. Исполняться они будут параллельно. SystemC позволяет явно специфицировать каждый процесс и соединить их с помощью каналов. Причем с нулевыми накладными расходами (всё как в SV).
Но у синтезируемого SystemC есть еще одна важная область использования: спецификация параллелизма на уровне процессов. SystemC это как pthreads для моделирования аппаратуры.
Проще всего объяснить на примере: представьте что вам нужно написать out-of-order процессор. Тогда у вас есть процесс который накачивает данные, есть процесс-плнировщик, набор процессов для исполнения (integer и floating point), процесс с reorder buffer'ом и сохранением результатов. Исполняться они будут параллельно. SystemC позволяет явно специфицировать каждый процесс и соединить их с помощью каналов. Причем с нулевыми накладными расходами (всё как в SV).
Напишу свой пост 2012 года с критикой SystemC. Глядя назад, пост слишком энтузиастичен по поводу UVM, но мое мнение про SystemC сейчас то же, что и в 2012 году:
panchul.livejournal.com/203346.html
Вот позавчера мне пришло письмо от джентлемена из одного российского университета, который занимается верификацией дизайнов на VHDL с помощью тестов, написанных на SystemC. Джентлемен спрашивает, имеет ли смысл транслировать тесты из SystemC в VHDL с помощью какого-нибудь third-party тула, наподобие тула от британской компании Celoxica, который использовали его коллеги. В качестве симулятора они, насколько я понял, используют ModelSim, который входит в состав Altera Quartus.
Мой ответ:
1. Disclaimer
Я обычно пишу такие ответы довольно уверенным тоном, но мой тон не означает, что я пытаюсь навязать свое мнение как истину в последней инстанции. Вашему научному руководителю может быть виднее, а для студентов полезно экспериментировать с разнообразными технологиями, даже если подобные эксперименты были не очень удачны в прошлом. Тем не менее, мое мнение может быть для вас полезным, так как я в свое время заседал на заседаниях, на которых присутствовали и маркетеры SystemC, которые потом перестали со мной здороваться. Кроме этого, я должен предупредить, что так как я пишу блогпост в Живом Журнале, а не статью для СМИ, я не буду перепроверять все свои утверждения, а также не буду делать расследование текущего состояния тех технологий, за которыми я перестал следить. Учитывая, что речь пойдет о развитии языковых средств за последние 15 лет, я могу запросто сказать что-нибудь не то.
2. Кратко
С моей точки зрения, SystemC всегда был и остается неудачной технологией, подерживаемой на плаву маркетингом различной степени недобросовестности. Несмотря на то, что некоторые группы в Европе в начале 2000-х годов стали использовать SystemC для системного моделирования, сейчас многие индустриальные команды стараются избавиться от кода, написанного на SystemC и перевести всю верификацию на SystemVerilog. Это связано с тем, что SystemC не ликвидировал неудобства, связанном с его использованием (см. ниже), а также не смог накопить критическую массу средств для functional-coverage based constraint random verification methodology — методологии, которая появилась в языках для верификации e/Specman, OpenVera и SystemVerilog, и которая стала в последние годы мейнстримом. Кроме этого, сейчас в индустрии приобретает все большую популярность Universal Verification Methodology (UVM), основанная на SystemVerilog. Так как эта методология еще год назад считалась нестабильной, существует множество мелких возможностей для создания разнообразных стредств автоматической верификации и тулов для верификационных инженеров на платформе UVM. Несмотря на то, что UVM критикуют за излишнюю сложность, эта все еще открытая ниша может эксплуатироваться как университетскими группами, так и небольшими компаниями.
<lj-cut text=«Дальше»>
3. История и проблемы с SystemC
3.1 Начало
В начале 1990-х годов произошло распостранение С++. После этого в середине 1990-х годов одновременно у нескольких людей возник зуд имплементировать HDL в виде библиотеки С++ классов, используя переопределение операций (overloading), чтобы обыкновенное присваивание вызывало скрытое обращение к event-driven simulation engine. Этот зуд возник у партнера (забыл имя) Джона Сангвинетти, двух немецких студентов, джентльменов из бельгийского исследовательского центра IMEC и лично меня.
Лично у меня идею идти этим путем обломал некий маркетер в Mentor Graphics, где я в то время работал, и я написал впоследствие свой тул для трансляции из С в Verilog, используя другую идею, а также сделал технологию CycleC, которая строилась на cycle-driven simulation, а не на event-driven simulation, как у SystemC (см. http://en.wikipedia.org/wiki/C_Level_Design).
Джон Сангвинетти и компания создали компанию C2DA / CynApps, которая впоследствие слилась с Forte. Сначала C2DA сделали библиотеку классов, которая напоминала SystemC, но была более элегантной. Впоследствие им пришлось под давлением от индустриальной политики отказаться от своей библиотеки и использовать SystemC в качестве входного языка.
Джентлемены из IMEC создали странную технологию, при виде которой у хардверных инженеров соловели клаза и они погружались в кому. Классы в C++ вообще вызывали у хардверных инженеров отторжение, но в случае с IMEC-ом они еще и как-то хитро генерировали HDL код во время симуляции, или что-то в таком духе, забыл идею.
Двое немецких студентов решили реализовать VHDL в C++. У маркетинга Синопсиса сработал условный рефлекс на слово «Си» и SystemC был рожден.
Кроме вышеперечисленных, в период 1996-1999 в мире появилось еще пара компаний, которые разными способами транслировали (или делали вид, что транслировали) С в хардвер — Handel-C/Embedded Solutions/Celoxica и Frontier Design. У всех претендентов были похожие слайды и похожий объем венчурного финансирования, хотя продавали все компании разное. Ни у одной из компаний не было уверенного успеха. У C Level лицензии приобрели Hitachi и Fujitsu, у CynApps и Frontier — еще кто-то, ESL/будущая Celoxica выпустила прес-релизы, что они «разослали свой С-подобный продукт в 50 университетов». Мнение индустрии (точнее, слухи, распускаемые Синопсисом) были «это все фигня, вот сейчас выйдет Синопсис и всех уроет».
3.2 Выход в свет и первые реакции
И вот в начале 1999 года Synopsys выкатил на обозрение то, чем они собирались всех урыть — первой версией библиотеки классов SystemC, которая реализовала классы, имплементирующие модули, порты и сигналы. Несмотря на то, что перед презентацией был огромный ажиотаж, показанное вызвало разочарование у многих инженеров.
Дело в том, что большинство хардвер-инженеров в 1999 году под словом «C» имело в виду тот ANSI C, который им когда-то преподали в коледже для писания простых алгоритмов, а не C++ с классами, темплейтами, виртуальными функциями и overloading. Все эти красоты хардверные инженеры видали в гробу, посколько это не входило в сферу их проблем — как организовать конвейер, оптимизировать тайминг и т.д. До презентации многие хардверные инженеры думали, что Synopsys покажет им тул, который магически траслирует untimed алгоритмы, написанные на бедненьком простеньком С в отпимизированных хардвер. В Synopsys верили — ведь за 10 лет до этих событий они организовали революцию в области логического синтеза.
«Прохладная встреча — ну и ладно», — подумали синопсоиды. «Мы сейчас как рррразвернем нашу маррркетинг-мышцу и заставим инженеров принять наш тул через их головы, впаривая его их менеджерам».
Это план не прошел. Инженеры реагировали так, как будто их пробует изнасиловать представитель несовместимой с ними сексуальной ориентации. «Ни за какие деньги!!!»
Причин у такой реакции было несколько:
1. Без хорошего понимания C++ пользователи SystemC постоянно налетали на ошибки компиляции, связанные с overloading в сложноустроенных templated классах для сигналов и портов разной ширины. Эти ошибки были так же далеки от их жизни, как general protection fault от феминистических статей Натальи Радуловой. Хардверные инженеры не собирались ради этой хрени учить нюансы C++ и тем более разбираться с кишками библиотеки SystemC. Чтобы бороться с таким явлением, всевозможные SystemC консультанты стали предлагать писать конструкции с аксессорами типа вместо «a = b + c» писать «a.write (b.read () + c.read ())». Это выглядело неубедительно, особенно для пользователей Verilog-а, хотя пользователи VHDL уже были в прошлом слегка изнасилованы конструкциями типа «a <= std_logic_vector (resize (signed (b), 9) + resize (signed , 9))», поэтому им было не впервой.
2. Еще более сильное неприятие происходило, когда пользователи (хардверные инженеры) получали GPF внутри SystemC библиотеки. Они потом бежали обратно в их родной Верилог и VHDL так, что только пятки сверкали.
3. Код на C++ очень медленно компилировался, особенно без precompiled headers, которые были в Microsoft DevStudio под Windows, но не были в GCC на Sun Solaris (тогдашней главной EDA платформе).
4. Интерфейс между SystemC и HDL не был продуман; даже много лет спустя он выключает кучу оптимизаций в Synopsys VCS и замедляет смешанное выполнение
5. Код на SystemC симулировался медленнее (а не многократно быстрее, как ожидалось и обещалось ранее), чем аналогичный код на HDL для компилирующего симулятора — Synopsys VCS или Cadence NC.
6. Особо долдонистые синопсоидные маркетеры придумали Гениальную Идею — они решили сделать компилятор с SystemC как прибамбасу поверх так называемого Behavioral Compiler — тула для высокоуровневого синтеза, который позволял писать «С-образный» алгоритмический код, разбавляя его явными указаниям «f (a, b); @ (posedge clock); g (b.c)» (в VHDL — wait). Реальные инженеры середины 1990-х рассматривали Behavioral Compiler как дорогую игрушку, которой было трудно управлять (раскладывать арифметические операции по разным clock cycles и т.д.)
7. Короче говоря, синопсоиды скомбинировали два непопулярных тула и получили что-то невероятно отвращающее! (И это сделал индустриальный лидер!)
3.3 Что делать?
Несмотря на такую реацию первых пользователей, синопсоидный маркетинг не моргнув глазом объявил «Ну вот и вышел Стандарт! Вся индустрия Выстраивается за Нами!» То, что они объявили себя стандартом в момент, когда они не заработали на SystemC ни цента, их не смущало.
Тем не менее, так как у Synopsys-а была на кону репутация, им нужно было придумать, как выкрутится из ситуации. Прежде всего они объявили, что этот тул не для RTL designers, а для system designers. Так как system designers в десять раз меньше, чем RTL designers, это вывело тул из прямого огня критики.
Потом они сказали, что симуляция медленная, потому что типа так и нужно — у симуляции низкий RTL уровень и «его нужно повысить». Что такое «уровень выше, чем RTL», не совсем понятно даже сейчас, поэтому под «повышением уровня» они решили в SystemC чего-нибудь добавить. Добавить получилось за счет технологий, придуманных стартапами. Пришел бельгийский Frontier Design и принесли в общую копилку библиотеку классов для fixed-point арифметики, сделанную для DSP-приложений (Digital Signal Processing).
Потом пришла компания CoWare (тоже с корнями из Бенилюкса) и внесла в копилку свои идео о «высокоуровневых каналах», которые эта компания пробовала внедрить в индустрию с помощью странного тула, который назывался чего-то типа «от салфетки — к системе». Идея была в том, что люди рисуют какую-то фигню на салфетке, сидя в ресторане (iPad-ов в 1998 году еще не было), и тул магически превращает это в дизайн. На самом деле, называть то, что у них было «тулом» — это преувеличение, CoWare продавала не тул, а сервис — их инженеры шли в компании типа Sony, которым объясняли, как делать интерфейсы для их систем.
Синопсису удалось втянуть в консорциум и Джона Сангвинетти с его CynApps-ом.
Также оставался мой стартап C Level Design, который умудрился заработать около 3 миллионов на конкурирующей технологии CycleC, когда большая компания Synopsys не заработала ничего. Это попало в прессу — известный техноблоггер John Cooley написал:
Там по ссылке еще много интересных мнений.
Из-за этого в конце 2001 года, когда в C Level Design закончились деньги, а Бин Ладен разрушил финансовые рынки, Synopsys купил assets C Level Designs, придушив заодно неприятный для них источник шума.
Пиар пиаром, но еще через несколько месяцев до менеджемента Synopsys-а дошло, что с SystemC они крупно проиграли. В 2002 году синопсисовская команда SystemC была расформирована, инженеры разошлись в группы Design Compiler, VCS и другие, и знамя SystemC подхватил Cadence.
3.4. SystemC после Synopsys
После 2002 года с SystemC произошло несколько изменений.
1. Появились некие группы людей, которые стали использовать SystemC в системном моделировании, в частности в Европе. Возможно сыграло роль обстоятельство, что конкурирующая технология (SystemVerilog) в начале 2000-х была неразвита. Возможно, пользователи оказались привлечены возможностью использования сложных структур данных (struct, class, mailbox, queue), полная поддержка которых не сразу была добавлена в SystemVerilog для Synopsys VCS, Cadence NC-Verilog и Mentor ModelSim. Сейчас сложные структуры данных адекватно поддерживаются во всех основных симуляторах, включая вероятно и бесплатеный урезанный ModelSim, поставляемый с Altera Quartus II (мне нужно проверить).
2. Появилась технология TLM (Transaction Level Modeling). TLM 2.0 — одна из самых странных технологий, которых я видел в жизни. Я так и не понял, кому и зачем она нужна. Её корни произошли вероятно от CoWare и Synopsys и родились от желания «а давайте придумаем новый уровень (level), чтобы объявить SystemC более высоким уровнем». В TLM 1.0 сигналы группируются в «каналы», а в TLM 2.0 вводятся некие транзакции, которые по факту являются просто структурами а-ля C struct или С++/SystemVerilog class, но эдакими «непростыми» структурами. То есть, для того, чтобы добавить в структуру «generic payload» поле, нужно не добавить поле и даже не создать inhereted class, а использовать какой-то тягомотный API. Причем это перенесли из SystemC в SystemVerilog. При виде такого я долго гадал, зачем это может быть нужно и решил, что такие структуры можно наверное автоматически перемещать между симуляторами (SystemC -> SystemVerilog и наоборот). Год назад на конференции в Сан-Хозе ( http://dvcon.org/ ) я узнал, что они это собирались сделать, но так и не сделали.
3. Появилась библиотека классов SystemC Verification Standard (SCV), авторы которой по-видимому решили имплементировать в SystemC всякие технологии из SystemVerilog, но потом мне сказали, что SCV больше не поддерживается
3.5. А все-таки, для чего нужен SystemC?
Вообще у меня сложилось впечатление, что SystemC принес больше пользы не реальным командам по дизайну электроники, а всевозможным консультантам по его использованию. При наличии доступа к симулятору, который адекватно поддерживает SystemVerilog, я не вижу реальных причин для использования SystemC для чего бы то ни было. Тем не менее, мелкие причины существовали:
1. Уже упомянутые сложные структуры данных — проблема разрешена
2. Возможность «невидимого» интерфейса C и Verilog в виде instantiation модуля на SystemC внутри SystemVerilog. ИМХО для большинства задач, где нужно сделать интерфейс между C и Verilog, гораздо проще использовать интерфейс DPI, в котором данные просто передаются с помощью вызова функции. Это гораздо проще, чем организовать код для модуля SystemC. Более того, насколько я понимаю, внутри интерфейса SystemC — SystemVerilog используется все тот же DPI.
3. Возможность вставить в код на C аналог верилоговского "#delay" или VHDL-ного «wait», используя SC_THREAD. Эта сильная feature, и её использую для некоторых применений даже я сам, при всей нелюбви к SystemC. Тем не менее, её использовать необязательно — при правильно организации кода для смешанной симуляции C / Verilog можно обойтись просто вызовами DPI функций.
4. Отсутствие доступа к симулятору, адекватно поддерживающему SystemVerilog. Нужно проверить, поддерживает ли SystemVerilog урезанный ModelSim, поставляемый с Altera Quartus II. Если нет, можно сконтактировать российские представительства Synopsys, Cadence и Mentor Graphics или например http://univeda.ru/node/4
5. Может быть соображение «Ну мы же работаем с VHDL, зачем впрягать для верификации модулей на VHDL — SystemVerilog?» Почему бы и нет? На конференции DVCon в 2011 году выступал военный контрактор (а VHDL является стандартом для Пентагона) и высказывал ровно то, что так как в VHDL нет всяких штучек для верификации, которые есть в SystemVerilog, то он использует именно такую комбинацию.
Отступление: Еще встречается комбинация VHDL + e/Specman. Specman — средство для верификации, которое любимо своими пользователями. К сожалению, судя по динамике киг в книжном магазине «Digital Guru» в Саниивейл, Specman потихоньку сходит со сцены — если книги по SystemVerilog быстро и уверенно расходятся, то пара книг по Specman стоят месяцами. Такое впечатление, что народ читает их в книжном магазине и кладет на полку, отчего одна книга стала засаленной.
4. Альтернатива — SystemVerilog и UVM
Я не буду особенно долго агитировать за SystemVerilog, посколько про него есть куча текстов а интернете, например на testbench.in. Тем не менее, я скажу, зачем нужна ключевая для SystemVerilog технология functional-coverage based constraint random verification.Эта технология, несмотря на то, что в её названии есть слово «случайная» — приносит в процесс тестирования плановость и предсказуемость. До тестирования verification engineer описывает сценарии, которые должен покрыть тест, используя coverage bins и другие стредства. Потом он определяет правила, по которым устройство (Device Under Test — DUT) бомбардируется псевдослучайными транзакциями (которые включают и направленные тесты — direct tests) в testbench, в которую также встроены средства для самопроверки. В процессе тестирования симулятор проверяет, были ли покрыты все интересные сценарии, описанные на своеобразном под-языке для спецификации coverage bins. Дальше симулятор составляет интерактивный report. При правильном применении, технология позволяет рационально ответить на вопрос «достаточно ли мы тестировали устройство»? Закончили ли мы?
Вот несколько книжек по теме SystemVerilog и Verification:
Очень хорошая книжка — SystemVerilog for Verification: A Guide to Learning the Testbench Language Features by Chris Spear and Greg Tumbush
Нудная, но есть полезные моменты — Writing Testbenches using SystemVerilog by Janick Bergeron
Хорошая книжка, но про верификацию там нет, и все это можно выучить их стандарта — SystemVerilog for Design Second Edition: A Guide to Using SystemVerilog for Hardware Design and Modeling by Stuart Sutherland, Simon Davidmann, Peter Flake, P. Moorby
5. А если все-таки транслировать тесты из SystemC в VHDL?
Если бы по тем или иным причинам мне бы понадобилось делать именно это, я бы не использовал тул общего назначения. За текущим состоянием конкретно этих тулов я не слежу, а тулы этого типа из прошлого обычно генерировали кучу ненужных вещей. Я бы написал скрипт на скриптовом языке, который транслирует именно данный конкретный формат тестов из SystemC в VHDL. Хотя такое трудно расширить или сделать гибким, но для локальной задачи это может подойти.
panchul.livejournal.com/203346.html
Вот позавчера мне пришло письмо от джентлемена из одного российского университета, который занимается верификацией дизайнов на VHDL с помощью тестов, написанных на SystemC. Джентлемен спрашивает, имеет ли смысл транслировать тесты из SystemC в VHDL с помощью какого-нибудь third-party тула, наподобие тула от британской компании Celoxica, который использовали его коллеги. В качестве симулятора они, насколько я понял, используют ModelSim, который входит в состав Altera Quartus.
Мой ответ:
1. Disclaimer
Я обычно пишу такие ответы довольно уверенным тоном, но мой тон не означает, что я пытаюсь навязать свое мнение как истину в последней инстанции. Вашему научному руководителю может быть виднее, а для студентов полезно экспериментировать с разнообразными технологиями, даже если подобные эксперименты были не очень удачны в прошлом. Тем не менее, мое мнение может быть для вас полезным, так как я в свое время заседал на заседаниях, на которых присутствовали и маркетеры SystemC, которые потом перестали со мной здороваться. Кроме этого, я должен предупредить, что так как я пишу блогпост в Живом Журнале, а не статью для СМИ, я не буду перепроверять все свои утверждения, а также не буду делать расследование текущего состояния тех технологий, за которыми я перестал следить. Учитывая, что речь пойдет о развитии языковых средств за последние 15 лет, я могу запросто сказать что-нибудь не то.
2. Кратко
С моей точки зрения, SystemC всегда был и остается неудачной технологией, подерживаемой на плаву маркетингом различной степени недобросовестности. Несмотря на то, что некоторые группы в Европе в начале 2000-х годов стали использовать SystemC для системного моделирования, сейчас многие индустриальные команды стараются избавиться от кода, написанного на SystemC и перевести всю верификацию на SystemVerilog. Это связано с тем, что SystemC не ликвидировал неудобства, связанном с его использованием (см. ниже), а также не смог накопить критическую массу средств для functional-coverage based constraint random verification methodology — методологии, которая появилась в языках для верификации e/Specman, OpenVera и SystemVerilog, и которая стала в последние годы мейнстримом. Кроме этого, сейчас в индустрии приобретает все большую популярность Universal Verification Methodology (UVM), основанная на SystemVerilog. Так как эта методология еще год назад считалась нестабильной, существует множество мелких возможностей для создания разнообразных стредств автоматической верификации и тулов для верификационных инженеров на платформе UVM. Несмотря на то, что UVM критикуют за излишнюю сложность, эта все еще открытая ниша может эксплуатироваться как университетскими группами, так и небольшими компаниями.
<lj-cut text=«Дальше»>
3. История и проблемы с SystemC
3.1 Начало
В начале 1990-х годов произошло распостранение С++. После этого в середине 1990-х годов одновременно у нескольких людей возник зуд имплементировать HDL в виде библиотеки С++ классов, используя переопределение операций (overloading), чтобы обыкновенное присваивание вызывало скрытое обращение к event-driven simulation engine. Этот зуд возник у партнера (забыл имя) Джона Сангвинетти, двух немецких студентов, джентльменов из бельгийского исследовательского центра IMEC и лично меня.
Лично у меня идею идти этим путем обломал некий маркетер в Mentor Graphics, где я в то время работал, и я написал впоследствие свой тул для трансляции из С в Verilog, используя другую идею, а также сделал технологию CycleC, которая строилась на cycle-driven simulation, а не на event-driven simulation, как у SystemC (см. http://en.wikipedia.org/wiki/C_Level_Design).
Джон Сангвинетти и компания создали компанию C2DA / CynApps, которая впоследствие слилась с Forte. Сначала C2DA сделали библиотеку классов, которая напоминала SystemC, но была более элегантной. Впоследствие им пришлось под давлением от индустриальной политики отказаться от своей библиотеки и использовать SystemC в качестве входного языка.
Джентлемены из IMEC создали странную технологию, при виде которой у хардверных инженеров соловели клаза и они погружались в кому. Классы в C++ вообще вызывали у хардверных инженеров отторжение, но в случае с IMEC-ом они еще и как-то хитро генерировали HDL код во время симуляции, или что-то в таком духе, забыл идею.
Двое немецких студентов решили реализовать VHDL в C++. У маркетинга Синопсиса сработал условный рефлекс на слово «Си» и SystemC был рожден.
Кроме вышеперечисленных, в период 1996-1999 в мире появилось еще пара компаний, которые разными способами транслировали (или делали вид, что транслировали) С в хардвер — Handel-C/Embedded Solutions/Celoxica и Frontier Design. У всех претендентов были похожие слайды и похожий объем венчурного финансирования, хотя продавали все компании разное. Ни у одной из компаний не было уверенного успеха. У C Level лицензии приобрели Hitachi и Fujitsu, у CynApps и Frontier — еще кто-то, ESL/будущая Celoxica выпустила прес-релизы, что они «разослали свой С-подобный продукт в 50 университетов». Мнение индустрии (точнее, слухи, распускаемые Синопсисом) были «это все фигня, вот сейчас выйдет Синопсис и всех уроет».
3.2 Выход в свет и первые реакции
И вот в начале 1999 года Synopsys выкатил на обозрение то, чем они собирались всех урыть — первой версией библиотеки классов SystemC, которая реализовала классы, имплементирующие модули, порты и сигналы. Несмотря на то, что перед презентацией был огромный ажиотаж, показанное вызвало разочарование у многих инженеров.
Дело в том, что большинство хардвер-инженеров в 1999 году под словом «C» имело в виду тот ANSI C, который им когда-то преподали в коледже для писания простых алгоритмов, а не C++ с классами, темплейтами, виртуальными функциями и overloading. Все эти красоты хардверные инженеры видали в гробу, посколько это не входило в сферу их проблем — как организовать конвейер, оптимизировать тайминг и т.д. До презентации многие хардверные инженеры думали, что Synopsys покажет им тул, который магически траслирует untimed алгоритмы, написанные на бедненьком простеньком С в отпимизированных хардвер. В Synopsys верили — ведь за 10 лет до этих событий они организовали революцию в области логического синтеза.
«Прохладная встреча — ну и ладно», — подумали синопсоиды. «Мы сейчас как рррразвернем нашу маррркетинг-мышцу и заставим инженеров принять наш тул через их головы, впаривая его их менеджерам».
Это план не прошел. Инженеры реагировали так, как будто их пробует изнасиловать представитель несовместимой с ними сексуальной ориентации. «Ни за какие деньги!!!»
Причин у такой реакции было несколько:
1. Без хорошего понимания C++ пользователи SystemC постоянно налетали на ошибки компиляции, связанные с overloading в сложноустроенных templated классах для сигналов и портов разной ширины. Эти ошибки были так же далеки от их жизни, как general protection fault от феминистических статей Натальи Радуловой. Хардверные инженеры не собирались ради этой хрени учить нюансы C++ и тем более разбираться с кишками библиотеки SystemC. Чтобы бороться с таким явлением, всевозможные SystemC консультанты стали предлагать писать конструкции с аксессорами типа вместо «a = b + c» писать «a.write (b.read () + c.read ())». Это выглядело неубедительно, особенно для пользователей Verilog-а, хотя пользователи VHDL уже были в прошлом слегка изнасилованы конструкциями типа «a <= std_logic_vector (resize (signed (b), 9) + resize (signed , 9))», поэтому им было не впервой.
2. Еще более сильное неприятие происходило, когда пользователи (хардверные инженеры) получали GPF внутри SystemC библиотеки. Они потом бежали обратно в их родной Верилог и VHDL так, что только пятки сверкали.
3. Код на C++ очень медленно компилировался, особенно без precompiled headers, которые были в Microsoft DevStudio под Windows, но не были в GCC на Sun Solaris (тогдашней главной EDA платформе).
4. Интерфейс между SystemC и HDL не был продуман; даже много лет спустя он выключает кучу оптимизаций в Synopsys VCS и замедляет смешанное выполнение
5. Код на SystemC симулировался медленнее (а не многократно быстрее, как ожидалось и обещалось ранее), чем аналогичный код на HDL для компилирующего симулятора — Synopsys VCS или Cadence NC.
6. Особо долдонистые синопсоидные маркетеры придумали Гениальную Идею — они решили сделать компилятор с SystemC как прибамбасу поверх так называемого Behavioral Compiler — тула для высокоуровневого синтеза, который позволял писать «С-образный» алгоритмический код, разбавляя его явными указаниям «f (a, b); @ (posedge clock); g (b.c)» (в VHDL — wait). Реальные инженеры середины 1990-х рассматривали Behavioral Compiler как дорогую игрушку, которой было трудно управлять (раскладывать арифметические операции по разным clock cycles и т.д.)
7. Короче говоря, синопсоиды скомбинировали два непопулярных тула и получили что-то невероятно отвращающее! (И это сделал индустриальный лидер!)
3.3 Что делать?
Несмотря на такую реацию первых пользователей, синопсоидный маркетинг не моргнув глазом объявил «Ну вот и вышел Стандарт! Вся индустрия Выстраивается за Нами!» То, что они объявили себя стандартом в момент, когда они не заработали на SystemC ни цента, их не смущало.
Тем не менее, так как у Synopsys-а была на кону репутация, им нужно было придумать, как выкрутится из ситуации. Прежде всего они объявили, что этот тул не для RTL designers, а для system designers. Так как system designers в десять раз меньше, чем RTL designers, это вывело тул из прямого огня критики.
Потом они сказали, что симуляция медленная, потому что типа так и нужно — у симуляции низкий RTL уровень и «его нужно повысить». Что такое «уровень выше, чем RTL», не совсем понятно даже сейчас, поэтому под «повышением уровня» они решили в SystemC чего-нибудь добавить. Добавить получилось за счет технологий, придуманных стартапами. Пришел бельгийский Frontier Design и принесли в общую копилку библиотеку классов для fixed-point арифметики, сделанную для DSP-приложений (Digital Signal Processing).
Потом пришла компания CoWare (тоже с корнями из Бенилюкса) и внесла в копилку свои идео о «высокоуровневых каналах», которые эта компания пробовала внедрить в индустрию с помощью странного тула, который назывался чего-то типа «от салфетки — к системе». Идея была в том, что люди рисуют какую-то фигню на салфетке, сидя в ресторане (iPad-ов в 1998 году еще не было), и тул магически превращает это в дизайн. На самом деле, называть то, что у них было «тулом» — это преувеличение, CoWare продавала не тул, а сервис — их инженеры шли в компании типа Sony, которым объясняли, как делать интерфейсы для их систем.
Синопсису удалось втянуть в консорциум и Джона Сангвинетти с его CynApps-ом.
Также оставался мой стартап C Level Design, который умудрился заработать около 3 миллионов на конкурирующей технологии CycleC, когда большая компания Synopsys не заработала ничего. Это попало в прессу — известный техноблоггер John Cooley написал:
http://www.deepchip.com/items/dac01-08.html
( DAC 01 Item 8 ) — [ 7/31/01 ]
Subject: Forte/CynApps, C-Level, CoWare, SystemC, Frontier, Y Explorations
THE NEXT GENERATION: On two levels, Synopsys has been horribly embarrassed
in pioneering SystemC as the «wave of the future». The first embarrassment
came from the poltical fiasco around getting SystemC out as a supposedly
«independent» standard. Too many people kept walking out loudly saying
SystemC was a Synopsys scam. And this happened multiple times! Ouch. The
second embarrassment for Synopsys here is, after all this grief, C-Level's
«System Compiler» is beating the crap out of Synopsys's «SystemC Compiler»!!!
Three months ago at SNUG'01, Dan Joyce of Compaq reported the first C-Level
tape-out. Below, I have 6 more designers reporting either that they're
using C-Level «System Compiler» for current designs or that they've already
taped out with C-Level. In contrast, there's only 1 guy around talking
about using Synopsys «SystemC Compiler» for a design *plus* a lot of other
user letters saying how they tried but couldn't get SystemC to work! Ouch!
Forte/CynApps' special CynLibs flavor of C classes seems to be capitulating
to the massive marketing arm of Synopsys SystemC. They're talking about
'merging' their CynLibs with SystemC.
Frontier, Y Explorations, and CoWare seem to be forgotten sideshows here.
Out of the 182 customer responses I got for this report, these 3 companies
were only mentioned once (each).
Там по ссылке еще много интересных мнений.
Из-за этого в конце 2001 года, когда в C Level Design закончились деньги, а Бин Ладен разрушил финансовые рынки, Synopsys купил assets C Level Designs, придушив заодно неприятный для них источник шума.
Пиар пиаром, но еще через несколько месяцев до менеджемента Synopsys-а дошло, что с SystemC они крупно проиграли. В 2002 году синопсисовская команда SystemC была расформирована, инженеры разошлись в группы Design Compiler, VCS и другие, и знамя SystemC подхватил Cadence.
3.4. SystemC после Synopsys
После 2002 года с SystemC произошло несколько изменений.
1. Появились некие группы людей, которые стали использовать SystemC в системном моделировании, в частности в Европе. Возможно сыграло роль обстоятельство, что конкурирующая технология (SystemVerilog) в начале 2000-х была неразвита. Возможно, пользователи оказались привлечены возможностью использования сложных структур данных (struct, class, mailbox, queue), полная поддержка которых не сразу была добавлена в SystemVerilog для Synopsys VCS, Cadence NC-Verilog и Mentor ModelSim. Сейчас сложные структуры данных адекватно поддерживаются во всех основных симуляторах, включая вероятно и бесплатеный урезанный ModelSim, поставляемый с Altera Quartus II (мне нужно проверить).
2. Появилась технология TLM (Transaction Level Modeling). TLM 2.0 — одна из самых странных технологий, которых я видел в жизни. Я так и не понял, кому и зачем она нужна. Её корни произошли вероятно от CoWare и Synopsys и родились от желания «а давайте придумаем новый уровень (level), чтобы объявить SystemC более высоким уровнем». В TLM 1.0 сигналы группируются в «каналы», а в TLM 2.0 вводятся некие транзакции, которые по факту являются просто структурами а-ля C struct или С++/SystemVerilog class, но эдакими «непростыми» структурами. То есть, для того, чтобы добавить в структуру «generic payload» поле, нужно не добавить поле и даже не создать inhereted class, а использовать какой-то тягомотный API. Причем это перенесли из SystemC в SystemVerilog. При виде такого я долго гадал, зачем это может быть нужно и решил, что такие структуры можно наверное автоматически перемещать между симуляторами (SystemC -> SystemVerilog и наоборот). Год назад на конференции в Сан-Хозе ( http://dvcon.org/ ) я узнал, что они это собирались сделать, но так и не сделали.
3. Появилась библиотека классов SystemC Verification Standard (SCV), авторы которой по-видимому решили имплементировать в SystemC всякие технологии из SystemVerilog, но потом мне сказали, что SCV больше не поддерживается
3.5. А все-таки, для чего нужен SystemC?
Вообще у меня сложилось впечатление, что SystemC принес больше пользы не реальным командам по дизайну электроники, а всевозможным консультантам по его использованию. При наличии доступа к симулятору, который адекватно поддерживает SystemVerilog, я не вижу реальных причин для использования SystemC для чего бы то ни было. Тем не менее, мелкие причины существовали:
1. Уже упомянутые сложные структуры данных — проблема разрешена
2. Возможность «невидимого» интерфейса C и Verilog в виде instantiation модуля на SystemC внутри SystemVerilog. ИМХО для большинства задач, где нужно сделать интерфейс между C и Verilog, гораздо проще использовать интерфейс DPI, в котором данные просто передаются с помощью вызова функции. Это гораздо проще, чем организовать код для модуля SystemC. Более того, насколько я понимаю, внутри интерфейса SystemC — SystemVerilog используется все тот же DPI.
3. Возможность вставить в код на C аналог верилоговского "#delay" или VHDL-ного «wait», используя SC_THREAD. Эта сильная feature, и её использую для некоторых применений даже я сам, при всей нелюбви к SystemC. Тем не менее, её использовать необязательно — при правильно организации кода для смешанной симуляции C / Verilog можно обойтись просто вызовами DPI функций.
4. Отсутствие доступа к симулятору, адекватно поддерживающему SystemVerilog. Нужно проверить, поддерживает ли SystemVerilog урезанный ModelSim, поставляемый с Altera Quartus II. Если нет, можно сконтактировать российские представительства Synopsys, Cadence и Mentor Graphics или например http://univeda.ru/node/4
5. Может быть соображение «Ну мы же работаем с VHDL, зачем впрягать для верификации модулей на VHDL — SystemVerilog?» Почему бы и нет? На конференции DVCon в 2011 году выступал военный контрактор (а VHDL является стандартом для Пентагона) и высказывал ровно то, что так как в VHDL нет всяких штучек для верификации, которые есть в SystemVerilog, то он использует именно такую комбинацию.
Отступление: Еще встречается комбинация VHDL + e/Specman. Specman — средство для верификации, которое любимо своими пользователями. К сожалению, судя по динамике киг в книжном магазине «Digital Guru» в Саниивейл, Specman потихоньку сходит со сцены — если книги по SystemVerilog быстро и уверенно расходятся, то пара книг по Specman стоят месяцами. Такое впечатление, что народ читает их в книжном магазине и кладет на полку, отчего одна книга стала засаленной.
4. Альтернатива — SystemVerilog и UVM
Я не буду особенно долго агитировать за SystemVerilog, посколько про него есть куча текстов а интернете, например на testbench.in. Тем не менее, я скажу, зачем нужна ключевая для SystemVerilog технология functional-coverage based constraint random verification.Эта технология, несмотря на то, что в её названии есть слово «случайная» — приносит в процесс тестирования плановость и предсказуемость. До тестирования verification engineer описывает сценарии, которые должен покрыть тест, используя coverage bins и другие стредства. Потом он определяет правила, по которым устройство (Device Under Test — DUT) бомбардируется псевдослучайными транзакциями (которые включают и направленные тесты — direct tests) в testbench, в которую также встроены средства для самопроверки. В процессе тестирования симулятор проверяет, были ли покрыты все интересные сценарии, описанные на своеобразном под-языке для спецификации coverage bins. Дальше симулятор составляет интерактивный report. При правильном применении, технология позволяет рационально ответить на вопрос «достаточно ли мы тестировали устройство»? Закончили ли мы?
Вот несколько книжек по теме SystemVerilog и Verification:
Очень хорошая книжка — SystemVerilog for Verification: A Guide to Learning the Testbench Language Features by Chris Spear and Greg Tumbush
Нудная, но есть полезные моменты — Writing Testbenches using SystemVerilog by Janick Bergeron
Хорошая книжка, но про верификацию там нет, и все это можно выучить их стандарта — SystemVerilog for Design Second Edition: A Guide to Using SystemVerilog for Hardware Design and Modeling by Stuart Sutherland, Simon Davidmann, Peter Flake, P. Moorby
5. А если все-таки транслировать тесты из SystemC в VHDL?
Если бы по тем или иным причинам мне бы понадобилось делать именно это, я бы не использовал тул общего назначения. За текущим состоянием конкретно этих тулов я не слежу, а тулы этого типа из прошлого обычно генерировали кучу ненужных вещей. Я бы написал скрипт на скриптовом языке, который транслирует именно данный конкретный формат тестов из SystemC в VHDL. Хотя такое трудно расширить или сделать гибким, но для локальной задачи это может подойти.
Спасибо за ответ, было интересно узнать про историю SystemC подробнее. Ведь я во время описываемых событий ещё учился в школе!
Попытаюсь выступить в роли адвоката SystemC и ответить на критику:)
1. Про сложность SystemC для среднестатического хардверщика: полностью согласен. С точно такой же критикой C++ выступают программисты на Си. C++ это наверное один из самых сложных языков программирования. Поэтому большинство инженеров использующих SystemC, которых я знаю, имеют C++ный бэкграунд (неторые даже не знают Verilog/VHDL).
2. Про время компиляции: какое оно имеет значение если время симуляции на порядок больше? Если говорить про простейшие модули, то на моём десктопе и SystemC и Verilog компилируются меньше секунды, без precompiled headers.
3. SystemC симулируется медленнее чем Verilog в компилирующем симуляторе.
Простой ответ: это проблема компилятора, а не SystemC. Технически, ничто не мешает сделать компилирующий симулятор для SystemC.
Правильный ответ: не нужно писать RTL на SystemC. На SystemC нужно стараться использовать untimed код и TLM интерфейсы.
Пример из жизни: занимаюсь сейчас обработкой видео: Синтезируемый SystemC обрабатывает один кадр примерно за 30 секунд, полученный из него RTL на Verilog — около 10 минут.
4. Про медленное смешанное исполнение SystemC и HDL. Не знаю, может и так. Но мы верифицируем SystemC без HDL примесей. А Full-chip симуляцию проводим на SystemVerilog, без SystemC.
5. TLM 2.0 — странная технология. Может быть. Но сама идея обмена данными через function-call'ы очень правильная. Никто вас не заставляет использовать TLM2.0, можно придумать свой велосипед с похожим функционалом.
Как мне кажется история с TLM2.0 ровно такая же как c UVM: они облегчают торговлю IP. В случае TLM-2.0 это IP для виртуальных прототипов. В случае UVM — это IP для верификации.
6. Альтернатива SystemC — SystemVerilog и UVM. Это мне кажется вопрос привычки: на SystemC вполне можно написать testbench в UVM стиле. Европейцы уже даже запилили UVM на SystemC. Рандомизировать пакеты тоже можно, и функциональный coverage мерить, и code-coverage тулы для C++ тоже есть.
Но на деле часто получается что пока ты пишешь свой суперрандомизированный тест, парни в соседней комнате уже подняли FPGA эмулятор и ОС запускают. А дальше приходится уже трейсы с железа снимать и писать директед тесты, чтобы понять почему оно повисло.
Но это конечно зависит от проекта. Не знаю как у вас всё устроено. Наверное в MIPS вы одно ядро можете десяток лет продавать и поддерживать, поэтому можете даже формальную модель написать, чтобы она вам без симуляции всё доказала.
Попытаюсь выступить в роли адвоката SystemC и ответить на критику:)
1. Про сложность SystemC для среднестатического хардверщика: полностью согласен. С точно такой же критикой C++ выступают программисты на Си. C++ это наверное один из самых сложных языков программирования. Поэтому большинство инженеров использующих SystemC, которых я знаю, имеют C++ный бэкграунд (неторые даже не знают Verilog/VHDL).
2. Про время компиляции: какое оно имеет значение если время симуляции на порядок больше? Если говорить про простейшие модули, то на моём десктопе и SystemC и Verilog компилируются меньше секунды, без precompiled headers.
3. SystemC симулируется медленнее чем Verilog в компилирующем симуляторе.
Простой ответ: это проблема компилятора, а не SystemC. Технически, ничто не мешает сделать компилирующий симулятор для SystemC.
Правильный ответ: не нужно писать RTL на SystemC. На SystemC нужно стараться использовать untimed код и TLM интерфейсы.
Пример из жизни: занимаюсь сейчас обработкой видео: Синтезируемый SystemC обрабатывает один кадр примерно за 30 секунд, полученный из него RTL на Verilog — около 10 минут.
4. Про медленное смешанное исполнение SystemC и HDL. Не знаю, может и так. Но мы верифицируем SystemC без HDL примесей. А Full-chip симуляцию проводим на SystemVerilog, без SystemC.
5. TLM 2.0 — странная технология. Может быть. Но сама идея обмена данными через function-call'ы очень правильная. Никто вас не заставляет использовать TLM2.0, можно придумать свой велосипед с похожим функционалом.
Как мне кажется история с TLM2.0 ровно такая же как c UVM: они облегчают торговлю IP. В случае TLM-2.0 это IP для виртуальных прототипов. В случае UVM — это IP для верификации.
6. Альтернатива SystemC — SystemVerilog и UVM. Это мне кажется вопрос привычки: на SystemC вполне можно написать testbench в UVM стиле. Европейцы уже даже запилили UVM на SystemC. Рандомизировать пакеты тоже можно, и функциональный coverage мерить, и code-coverage тулы для C++ тоже есть.
Но на деле часто получается что пока ты пишешь свой суперрандомизированный тест, парни в соседней комнате уже подняли FPGA эмулятор и ОС запускают. А дальше приходится уже трейсы с железа снимать и писать директед тесты, чтобы понять почему оно повисло.
Но это конечно зависит от проекта. Не знаю как у вас всё устроено. Наверное в MIPS вы одно ядро можете десяток лет продавать и поддерживать, поэтому можете даже формальную модель написать, чтобы она вам без симуляции всё доказала.
А BlueSpec Вы не видели? Интересно с ним сравнить.
Видел, но не пробовал. Хотя знаю людей которые его использовали для быстрого прототипирования архитектуры на FPGA. Отзывались положительно.
Насколько я понимаю язык BlueSpec либо умер, либо умирает. Сейчас просто невозможно заставить кого-то изучать язык не выкладывая при этом тулы в опенсорс.
Я читал спеку на язык. BSV это описание аппаратуры в стиле функционального программирования c системой типов из Haskell. Как мне кажется, идея в целом правильная. Функциональное программирвоание хорошо ложится на вычислительную среду в виде массива триггеров/вентилей.
Насколько я понимаю язык BlueSpec либо умер, либо умирает. Сейчас просто невозможно заставить кого-то изучать язык не выкладывая при этом тулы в опенсорс.
Я читал спеку на язык. BSV это описание аппаратуры в стиле функционального программирования c системой типов из Haskell. Как мне кажется, идея в целом правильная. Функциональное программирвоание хорошо ложится на вычислительную среду в виде массива триггеров/вентилей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка цифровой аппаратуры на C++/SystemC глазами SystemVerilog программиста