?

Log in

No account? Create an account
Повторение поста про SystemC - Юрий Панчул [entries|archive|friends|userinfo]
Money can buy bandwidth. Latency requires bribing God.

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Повторение поста про SystemC [Jun. 18th, 2015|09:08 am]
Yuri Panchul
В комментариях предыдущего поста зашла дискуссия о SystemC, по поводу чего я хочу повторить свой пост 2012 года про SystemC. Глядя назад, пост слишком энтузиастичен по поводу UVM, но мое мнение про SystemC сейчас то же, что и в 2012 году:

http://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 критикуют за излишнюю сложность, эта все еще открытая ниша может эксплуатироваться как университетскими группами, так и небольшими компаниями.


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 (c), 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, посколько про него есть куча текстов а интернете,например на http://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. Хотя такое трудно расширить или сделать гибким, но для локальной задачи это может подойти.



P.S. У меня еще была задумка рассказать подробно про (хмм даже не могу подобрать правильный саркастический эпитет) историю компании Celoxica и её креативных маркетеров, а также высказать аргументы в пользу постепенного перехода с преподавания VHDL к преподаванию Verilog и SystemVerilog, но имхо на сегодня хватит. Celoxica после череды приключений занялась ... хардверной акселерацией торговли на бирже 8-) А насчет VHDL versus Verilog - спор этого типа не способствет просветлению, так как учить писать RTL можно и на Verilog, и на VHDL.


Узнали ли вы в моем посте что-то для себя полезное?

Да, узнал
12(92.3%)
Я это и раньше знал
0(0.0%)
Панчул просто клевещет на западную Технологию, в которой на самом деле все идеально!
1(7.7%)
Я не согласен с постом (пояснить в комментариях)
0(0.0%)
Из-за бугра плюете?
0(0.0%)
LinkReply

Comments:
[User Picture]From: oppad1
2015-06-18 04:53 pm (UTC)
по-моему все проще : гиганты (Синопсис/Каденс/Ментор) посоветовались и решили, что больше денег загребут с пропиентарного (не открытого языка), а то иш чего удумали - бесплатным gcc делать то, на что можно годовую лицензию на место за 100к продавать

я пописываю и на С++ и малость на SystemC писал - мне очевидно, что SV и всяческие UVM-ы это убогая подделка под ООП, которое нахаляву было доступно из С++

RTL никто на SC писать не заставляет - как и сейчас - для RTL верилог, для верификации SV, но при этом SV нужны всякие костыли в виде DPI, имеются проблемы с производительностью и т.д. SC - это более высокоуровневые модели, и, прежде всего, верификация.

в 2005 кстати DesignCompiler поддерживал синтез RTL SC, был мануал на синтезируемое подмножество и т.д.

и SC (говорим SC подразумеваем С++) оно просто очень круто, так как позволяло glueless склеивать исполнение кода, TLM модели (причем не обязательно SC-шные) и вплоть до RTL
возможно, что RTL описания были слегка геморнее верилоговских, но если чё - можно с VHDL сравнить :)



Edited at 2015-06-18 04:55 pm (UTC)
(Reply) (Thread)
[User Picture]From: panchul
2015-06-18 05:32 pm (UTC)
*** по-моему все проще : гиганты (Синопсис/Каденс/Ментор) посоветовались и решили, что больше денег загребут с пропиентарного (не открытого языка), а то иш чего удумали - бесплатным gcc делать то, на что можно годовую лицензию на место за 100к продавать ***

Я не согласен, я просто лично участвовал в ряде таких совещаний (был членом комитета Accelerra, работал в обсуждаемый момент Principal Engineer в группе Synopsys VCS, а также обсуждал вопрос с VP Mentor Graphics Serge Leef, участвовал в конференции DVCon). Из данного опыта я знаю, что ваша интерпретация событий - это примерно 10%, максимум 20% реальности. Т.е. такое было - группы VCS и DC действительно вели политическую вендетту против группы SC в Синопсисе, но это не главная причина неуспеха SC).

БОльшая часть реальности - это неприятие технологии уже существующими пользователями верилога, причем по перечисленным мною выше причинам.

*** SC - это более высокоуровневые модели, и, прежде всего, верификация ***

В SystemVerilog есть удобный constrained random generation, coverage bins, concurrent assertions. Покажите (с примерами кода) эквивалентные и при этом удобные штуки в SystemC.

(Reply) (Parent) (Thread)
[User Picture]From: oppad1
2015-06-18 07:16 pm (UTC)
ну ведь UVM полна темплейтов и макросов со скрытым поведением, то есть для hdl-разработчика это такая же хрень как и SC

а описать в C++ класс, который делал бы констрейн-рандом, вобщем-то не проблема.
солвер в SV слабый - как пример, давал ему (VCS/QUESTA/NC) задачку по расстановке ферзей на доске (чтоб они не били друг друга), нифига не решает, хотя и думает долго

хочу еще отметить pyHDL (upd: myHDL) я сам его не пользовал и считаю детской забавой, но даже из этого можно сделать годный HDL, а уж из C++ только интриги могли помешать :) (btw, python я очень люблю)

я когда-то участвовал в писании homebrew транслятора из Verilog нетлиста в С++ (идея и концепция не мои, я кодил немножко), потом С++ компилился gcc, было это во времена VerilogXL и по скорости симуляции его били

-------

естественно привести аналог всех возможностей UVM и SV на SC я не могу - проект фактически похоронен

но могу еще порассуждать (мне реально было сильно обидно за SС в 200х) - большинство проектов чипов (не по количеству чипов, а по количеству дизайнов), по-моему, это всякие baseband-ы: Wi-Fi, BT, 3G, GPS, всякие модемы и т.п., а не процессоры
то есть идея начинается не с конвеера, а с ЦОС, и ее проще всего описать на С++ (ну или на Матлабе, но матлаб тормозной и не труЪ), и соответственно этот С++ код и будет IP, а доводить его можно либо сопроводив документацией и передав специально обученным hdl-кодерам (что тоже вопрос, так как требуется обычно понимание) или же потихоньку переделывая куски С++ на более низкий уровень
и в эту методологию SC вписывалось хорошо. мы (я сам то не алгоритмист) имели модели на С++/SC делали косимуляции и доводили RTL-верилог до ума, но если бы SC развивалась дальше, то можно было бы и без верилога обойтись



Edited at 2015-06-18 07:20 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: panchul
2015-06-18 07:40 pm (UTC)
*** ну ведь UVM полна темплейтов и макросов со скрытым поведением, то есть для hdl-разработчика это такая же хрень как и SC ***

Согласен, мое мнение про UVM за 3 года ухудшилось.

*** а описать в C++ класс, который делал бы констрейн-рандом, вобщем-то не проблема ***

Конечно не проблема, просто он будет менее читабелен чем SV конструкции.

*** солвер в SV слабый - как пример, давал ему (VCS/QUESTA/NC) задачку по расстановке ферзей на доске (чтоб они не били друг друга), нифига не решает, хотя и думает долго ***

Это непрактичный пример. В реальной жизни оптимизации солвера на такую задачу не нужно.

*** хочу еще отметить pyHDL ***

Менее читабелен чем SV.

*** мне реально было сильно обидно за SС в 200х ***

А мне наоборот, реально обидно НА SC в 1998-2000. Потому что их маркетинг громогласно заявлял "Вся Индустрия Выстроилась За SystemC!!!" а на деле, когда я уже стал работать в Synopsys, я узнал, что в это время у них никто SystemC не покупал (revenue за это период было 0, пользовались только за бесплатно), но этим громом вранья они удушили не менее 5 стартапов, некоторые из которых (например мой) имели revenue в несколько миллионов.
(Reply) (Parent) (Thread)
[User Picture]From: oppad1
2015-06-18 05:23 pm (UTC)
добавлю еще сепаратный коммент (более прочитал статью)
в дистрибутиве модельсима идет gcc - то есть sc он наверняка поддерживает (ну квеста поддерживает)

тут еще вопрос с untimed кодом
я сам этим не пользовался, но подозреваю важность этой технологии - это тот же Matlab, который имеет генераторы HDL из своих моделей (simulink наверно все-таки таймед изначально)
еще слышал про Catapult от Mentora - там тоже какое-то псевдо С описание

вся эта активность, имхо, не для больших контор: большая контора там может нанять труЪ хдл-щиков, которые вручную отпарсят алгоритм в HDL, большая контора тут сделает тоже самое - так как нет сроков и инженеры дешевы

а вот маленький стартап, который придумал идею, описал ее (на С++ - таких ведь программистов гораздо больше чем HDL) и хочет сделать чип - вот для них как раз и делался весь этот behavioral / untimed synthesis
я так понимаю, что и SC было расчитано для этих же стартапов, но сразу увы не взлетело, а сейчас уже затоптано SV и вряд ли взлетит.


Edited at 2015-06-18 05:27 pm (UTC)
(Reply) (Thread)
[User Picture]From: panchul
2015-06-18 05:35 pm (UTC)
*** а вот маленький стартап, который придумал идею, описал ее (на С++ - таких ведь программистов гораздо больше чем HDL) и хочет сделать чип - вот для них как раз и делался весь этот behavioral / untimed synthesis ***

Я такие стартапы наблюдал среди клиентов своего стартапа ( http://en.wikipedia.org/wiki/C_Level_Design ) а именно стартапы в области сетевых процессоров в 1999-2001 годах.

(Reply) (Parent) (Thread)
[User Picture]From: andrey_yurin
2015-06-19 05:28 am (UTC)
Юрий! Если бы я носил шляпу, то я бы её перед вами снял. Прочитал взапой. Потом задумался. Некоторые вещи стали гораздо более понятны. А после прочтения пункта 4 понял, что как только появится свободное время - осилю "System Verilog for Verification". Что-то у меня закралось подозрение, что то, что я называю "TestBench" надо писать совсем по другому.

Добавлю от себя следующее (вернее - выплесну мысль изнутри). Довелось мне как-то участвовать в семинаре по XilinX для их платформы Zynq7000. И вот там парни аккурат рассказывали про HDL-транслятор из Simulinc. А я смотрел на это дело и опять меня одолевал какой-то скепсис. С виду - красиво. Десяток строчек в MathLab одним щелчком мыши превращается в гору HDL кода, готового к исполнению. А мне при взгляде на это вспомнился 2010 год, когда довелось мне делать ТВ-камеру для определения координат наблюдаемых ей звёзд. Так вот делалось это всё совместно с коллегой. Моя часть была не сложной - тайминги для ПЗС-матрицы, оцифровка сигнала, перепаковка его в нужный формат, Ethernet-управление. Все расчёты делал модуль, написанный коллегой. После компиляции, утряски и утрамбовки всё это едва-едва запаковалось в Stratix-II на 60 тысяч LUT. Вот не знаю кому как, но что по мне, то основное в FPGA это не LUT, а on-chip memory. А on-chip memory эту жрут все - начиная от embedded microprocessors и заканчивая буферами HDL-модулей обработки данных. Вообщем память там очень быстро подошла к концу, коллега дембельнулся, а изделие работало криво. Всё это разгребать пришлось мне. Внутрь модуля коллеги я залезть не мог. Исходники-то у меня были (Altera-HDL, ага. А от этого языка я открестился сразу же), но вот что-то там поменять... Короче память я искал везде. Урезал буфера, применял кэширование, оптимизировал процессорную часть. Сколько раз тогда я задавался вопросом: "как так?. Я трачу уйму времени на поиск лишнего блока памяти в 4096 бит, а рядом на плате стоит SDRAM на 128 мегабайт. Какого хрена этот обработчик зажирает только On-chip memory и не использует внешнюю память? Для кого и зачем люди изобрели кэширование?". Вообщем помудился, поставил кое-как костыли и всё. А потом, когда через год тема вновь всплыла то я плюнул и переписал весь этот долбаный обработчик на новый лад. Только при этом применил кэширование данных и добавил в pcb часть проекта ещё и SRAM-память (ох, как она мне жизнь облегчила. С произвольным-то доступом к данным.) Вообщем увязал pcb часть под алгоритм, а алгоритм спроектировал (вернее - видоизменил) специально с учётом pcb особенностей. После этого проект стал сильно меньше.
Так вот пока я сидел и смотрел на этот чудо HDL-транслятор меня брал скепсис. Вот как? Вот берём какую-то стандартную обработку сигнала в MathLab. Она явно жрёт память. Откуда она её берёт? Дык явно из on-chip. Больше неоткуда. Иначе там должна тогда сразу оговариваться куча таких вещей, как интерфейс к внешней памяти, её объём, её разрядность, тип этой памяти. Ничего подобного я там не видел. Просто текст и кнопка "транслировать". Странно? Что по мне - очень странно. Может для верификации или чего-то там ещё оно и ок, но вот для синтезатора-фиттера... Не знаю, не знаю.
Или вот, например, поддержка типа float/real. Вот как оно работает? Схемотехника конвейера данных вообще совсем другая. Одно дело целочисленные типы, совсем другое типы дробные. Вон взять какой-нибудь Q1.15. Дык там совсем всё по другому по сравнению с обычным сумматором. Вообщем вопросов у меня к подобным штукам очень много, есть огромные сомнения в эффективности их работы, хотя с виду всё очень заманчиво.
(Reply) (Thread)
[User Picture]From: panchul
2015-06-19 05:48 am (UTC)
Да, это все интересно. Кстати, а Xilinx DSP48 для Q1.15 помогает или это к нему ортогонально?
(Reply) (Parent) (Thread)
[User Picture]From: andrey_yurin
2015-06-19 05:55 am (UTC)
>Кстати, а Xilinx DSP48 для Q1.15 помогает или это к нему ортогонально?
Вот чего не знаю того не знаю. Среду разработки XilinX и её toolkits я знаю лишь по описаниям. Сам ни разу не использовал, ибо у нас в конторе правит бал AlterA, а когда я заикнулся про другие FPGA (мне, например, очень сильно Acronix понравился на презентации с его несколькими гигагерцовыми аппаратными DDR контроллерами) то мне руководство задало один вопрос: "за чей счёт ты сейчас пол года потратишь, а выхлопа за это время не принесёшь?". Я не нашёлся что ответить.
(Reply) (Parent) (Thread)
From: friend_or_foe
2015-06-19 05:59 am (UTC)
C, C++ императивные языки, они для процессора, HDL ближе к декларативным, они для регистров, зачем смешивать теплое с мягким? Знание С++ никак не поможет в понимании HDL, гораздо важнее знание цифровой схемотехники.
Это мое мнение, С и прочие ассемблеры знаю давно, Verilog начал осваивать полгода назад.
(Reply) (Thread)