[CaPpuCcino 0]

что если потом все вызовы транзакторов подменять на код ГЕНЕРИРУЮЩИЙ HDL описание (т.е. фактически программа при моделировании будет генерировать себя на HDL) :)

на вскидку, будет гемор с проектированием этих ХДЛ-билдеров и в общем случае неоптимальное управление потоком данных в интерфейсе (однако это уже из области фантазии - не хотелось бы развивать дискуссию поводом для которой является "а что если" - было бы какое-то готовое решение или подход - обсудили бы).

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

[9.9 0]

CaPpuCcino

Спасибо за разъяснение :) Только начинаю работать с SoC. За раз свалилось море интересной информации...теперь разгребаюсь потихонечку :)

[WARri0r 0]

а вот интересно, ПОЯВИТСЯ ЛИ вообще когда-нибудь вновь возможность синтезировать системС?

сам я схемотехник по сути. дали мне комплексное задание изучить системС! и я начал это изучение так сказать с другой стороны:)

нет, я конечно имею представление о программировании, но опыта работы с ВХДЛ значительно больше. и вот по прошествию некоего времени я уже поднаторел в разработке ТЛМ моделей! сразу скажу, что для всей организации я съэкономил этим кучу времени! ведь при помощи ТЛМ модели я мог протестировать ВХДЛ модель намного полнее, нежели просто набор входных и выходных данных от программиста на С++. но вот хочется перейти на новый уровень - попытаться синтезировать модели! и тут - на тебе - отказ от синтеза системС большинством гигантов-производителей синтезаторов.

что делать? менять язык? но на системВерилоге фактически нет возможности ТЛМ моделирования!

вот такая проблемма.

нет, ну конечно можно выучить ВСЁ, и спокойно рботать, но на сколько это серьёзно - я судить не берусь!

отписался, кажется, в тему. жду выших мыслей, уважаемые!

[CaPpuCcino 0]

но на системВерилоге фактически нет возможности ТЛМ моделирования!

учите Олбанский, товарищ, и не говорите глупостей

[gserdyuk 0]

ИМХО есть возможность поднять скорость моделирования в разы, только непонятно почему производители симуляторов на это не идут.

....

вместо компиляции HDL кода в объектный код исполняемый ядром симулятора, сделать что-то вроде кросс-компилятора HDL ну пусть в тот же SC.

 

Похоже есть то о чем Вы говорите.

"It compiles synthesizable Verilog (not test-bench code!), plus some PSL,

SystemVerilog and Synthesis assertions into C++ or SystemC code."

http://www.veripool.com/verilator.html

[des00 25]

Похоже есть то о чем Вы говорите.

"It compiles synthesizable Verilog (not test-bench code!), plus some PSL,

SystemVerilog and Synthesis assertions into C++ or SystemC code."

http://www.veripool.com/verilator.html

 

Классно, надо попробывать. правда насторожила фраза :

 

Verilog 2005 support added as users request them.

 

попробую, на своих проектах, надеюсь что классы и рандомное тестирование там поддерживается.

 

ЗЫ. нашел на сайте

 

http://www.veripool.com/verilog_sim_benchmarks.html

 

Verilator is 90x faster than Icarus Verilog.

Verilator is 10-40x faster than Modelsim SE.

Verilator is 3x faster than NC-Verilog.

Verilator is 1.5x faster than VCS.

VTOC is 4x faster than Verilator.

VTOC is 50x faster than NC-Verilog.

[/b]VCS is 3x faster than Verilator. [/b]

VCS is 3x faster than NC-Verilog.

VCS is 10x faster than NC-Verilog.

VCS is the same speed as NC-Verilog.

CVer is the same speed as Icarus Verilog

 

 

аааа, хачу VCS %)))))))))

[CaPpuCcino 0]

Похоже есть то о чем Вы говорите.

а разве Синопсис не компилит в исполняемый код вместо объектного?

[yes 5]

сунусь я в эту тему со своей проблемой (жалобой на врагов :) переставших поддерживать SC):

 

в системе есть некая задача обработки сигналов

 

модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре)

 

после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов)

 

на HDL верифицируется (пишутся тестбенчи, проверяется их совпадение с С++ моделью и т.п.) затем синтезируется, верифицируется, изготовляется чип, плата...

 

при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками.

 

========================

 

как может помочь SV - я не понимаю.

требуется переписать модель на SV, но 1) требуется обучить программистов, 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода)

 

------------------------------------------

 

обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте)

 

------------------------------------------

 

некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка

 

-----------------------------------------

 

собственно - мое мнение, что по этой причине SV значительно хуже SC.

то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари)

 

а SV требует переноса моделей с С++ (что опять же нагрузка на HDL-щиков), а результат потребует обратной трансляции в C++

 

----------------------------------------

[oval 0]

сунусь я в эту тему со своей проблемой (жалобой на врагов :) переставших поддерживать SC):

 

в системе есть некая задача обработки сигналов

 

модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре)

 

после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов)

 

на HDL верифицируется (пишутся тестбенчи, проверяется их совпадение с С++ моделью и т.п.) затем синтезируется, верифицируется, изготовляется чип, плата...

 

при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками.

 

========================

 

как может помочь SV - я не понимаю.

требуется переписать модель на SV, но 1) требуется обучить программистов, 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода)

 

------------------------------------------

 

обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте)

 

------------------------------------------

 

некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка

 

-----------------------------------------

 

собственно - мое мнение, что по этой причине SV значительно хуже SC.

то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари)

 

а SV требует переноса моделей с С++ (что опять же нагрузка на HDL-щиков), а результат потребует обратной трансляции в C++

 

----------------------------------------

 

Присоединяюсь к мнению уважаемого yes. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. :) Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится.

 

SV безусловно хорош, практически все, чего не хватало в Verilog добавлено + развитые средства верификации. Еще не один год пройдет, пока SV начнут реально использовать, ибо такого рода внедрение стоит очень дорого...

[CaPpuCcino 0]

Присоединяюсь к мнению уважаемого yes. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. :) Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится.

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

[des00 25]

Позвольте вмешаться в спор :)

 

2 yes и oval

 

Не могу считать себя гуру SV, но немного SV опыта есть. И хотел бы вынести его на рассмотрение. Сам полез в систем верилог, по сути ради развлечения.

 

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

 

но сделав на нем 3 проекта (один из них вы скоро увидите в исходниках), покурив литературу и начав вкуривать его философию : ртл там не сильно изменился, а вот верификация....

 

могу заключить :

 

1. Основной концепцией является ООП. Не хотите его использовать ? тогда толку от SV будет не более чем от vhdl.

 

2. SV очень удобен для отладки НЕ ДСП систем. Используя рандомные подходы с ограничениями, на которые еще можно натравить и языковые средства по мониторингу функционального покрытия можно очень просто, используя настраиваемые констрейны или наследование классав перебрать очень много вариантов работы окружения тестируемой системы.

 

Например как выглядит у меня тестбенч сдрам контроллера :

1. интерфейс с клокинг секциями (убиваем проблему гонок на корню).

2. класс - драйвер - вся работа с интефейсами контроллера

3. класс - callback к этому драйверу - scoreboard, performance monitor

4. класс - агента драйвера - API по работе с драйвером

5. класс - транзактор . рандомный с программируемыми ограничениями.

 

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

 

на чистом верилоге описывать это - застрелиться можно. Да тут возникает проблема начальных затрат на разработку классов, но для этого и существует vmm/amm (у ментора) технологии (это я еще не освоил). по сути базовые классы для создания драйверов, агентов, скоребордов, транзакторов и т.д.

 

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

 

3. для отладки ДСП систем выскажу мнение в комментариях к посту уважаемого yes :

 

 

модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре)

 

не вижу никаких проблем как для SC так и для SV.

 

После того как есть модель, ее можно легко, используя технологию DPI, импортировать ее в SV, так и обратно (!!!) импортировать SV в C++. Тут опять уместно использовать концепцию драйверов, основанных на классах.

 

Т.е. можно изначально сделать разделение софтваре, хардваре. и не моделировать хард на SC, а потом переводить его. А сразу делат хард на уровне модулей с заглушками - программами.

 

после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов)

 

вы сами пишете что потом следует переписывание кода на HDL. Причем этот сегмент есть как SC так и в SV маршрутах. При этом для SC нужно знать : vhdl/verilog + PSL + C++(на уровне SC), для его аналогичного маршрута достаточно знать только SV.

 

при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками.

 

Ошибки в алгоритме никуда не денутся, но ошибки проектирования структуры харда будут пройдены 1 раз. (ну кроме изначального просчета архитектуры)

 

как может помочь SV - я не понимаю.

 

вашему текущему проекту никак, если вы его начали в текущем маршруте, его и продолжайте.

 

1) требуется обучить программистов,

 

без этого никуда, даже в жизни.

 

2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода)

 

см. выше. повторное использование остается, если грамотно сделано разделение софта и харда.

 

обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте)

 

никаких проблем, если делать все не на plain c, то все решается на уровне объектов-драйверов (причем вы даже можете передать в С++ программу задержки моделирования (!!!!)) .

 

некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка

 

Если это маленькая заплатка, тогда зачем технология Direct-C в вхдл введена ? :)

 

собственно - мое мнение, что по этой причине SV значительно хуже SC.

 

Вы гуру, вам виднее.

 

то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари)

 

Синтеза нормально с SC свет так и не увидел. А нормально, грамотно развести софтваре и хардваре на модели в SV достаточно просто.

 

Даже если не пользовать DPI технологию, свои "софт" функции написанные на SV переносятся в C копи пастом (!!!). ну единственно что нужно это заменить begin end на {} и убрать endfunction.

 

Хотя простота DPI подкупает, что и смысла так делать нет.

 

Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. smile.gif Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится.

 

как раз сквозного проектирования то и не было. Да были попытки синтезировать SV, но качество синтеза ... Его конвертировали в вхдл, верилог. Но выхлоп с такой конвертации тоже был не сахар. SC

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

 

Все вышесказанное мое ИМХО. я глупый, местами даже тупой, так что могу ошибаться :)

 

Еще не один год пройдет, пока SV начнут реально использовать, ибо такого рода внедрение стоит очень дорого..

 

хмм у меня переход на SV. еще на старушке квесте 6.2ф занял 1 месяц, а постижение его философии еще 3. все.

 

теперь обратного пути нет. ну если только ОБЭП ко мне домой не заявиться и не присудит мне срок лет 5 за использование софта от ментора, т.к. к сожалению бесплатного симулятора SV, на том уровне что нужен мне, пока нет

[yes 5]

Позвольте вмешаться в спор :)

----------

 

большое спасибо, за комментарии.

я вообще-то и хотел услышать в ответ, что-то подхожее: "если разобраться, то SV тоже рулит"

ну и ключевые слова :)

 

мне понятно, что классическая DSP задача (dataflow или как ее правильно назвать) и подход с моделированием транзакций не совсем соответствуют, но кроме DSP есть куча задач системного уровня, (которые из-за спешки были совершенно опущены в настоящем проекте) : моделирование памятей (например, размер и организация кэша), SDRAM контроллер, внутренние памяти с арбитражем, обмен DSP-процессор и т.п.

конфигурация была сделана методом "экспертных оценок" (в основном - так делали раньше, так сделаем и сейчас)

 

то есть оптимизировать систему можно, вот пытаюсь понять как :)

 

---------------------------------

 

а с использованием assertion-ов (PSL) кто-нибудь продвинулся?

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

 

мы пытались шину в АЗИКе описать, но кривовато вышло (неполное описание)

[des00 25]

я вообще-то и хотел услышать в ответ, что-то подхожее: "если разобраться, то SV тоже рулит"

 

Джа даст нам все. это будет лучше ? :)

 

мне понятно, что классическая DSP задача (dataflow или как ее правильно назвать) и подход с моделированием транзакций не совсем соответствуют, но кроме DSP есть куча задач системного уровня, (которые из-за спешки были совершенно опущены в настоящем проекте) : моделирование памятей (например, размер и организация кэша), SDRAM контроллер, внутренние памяти с арбитражем, обмен DSP-процессор и т.п.

конфигурация была сделана методом "экспертных оценок" (в основном - так делали раньше, так сделаем и сейчас)

 

то есть оптимизировать систему можно, вот пытаюсь понять как :)

 

думаю тут как раз и можно заняться системным моделированием. это можно делать как на уровне SV, так и на уровне SC. в

Springer - Verification Methodology Manual for SystemVerilog - Bergeron 2005

Springer - SystemVerilog for Verification

 

хорошо расписано про моделирование. причем яник не мог не упомянуть очередную ревизию (самую понятно читаемую) ATM свитча который он приводит в своих книгах.

 

 

а с использованием assertion-ов (PSL) кто-нибудь продвинулся?

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

 

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

 

PSL ем не пользовался, да и сам подход асеров в комментариях мне не нравиться. в SV ассерты входят как языковые конструкции. что очень удобно, для "компилирующих" разработчиков (коим являюсь я).

ибо в подобных конструкциях можно и запутаться

 

    property access_cycle_prop (clk, reset, sop, eop, vld); 
      @(posedge clk) disable iff (reset) 
       $rose(vld) |-> (sop & ~eop) ##1 (vld & ~sop & ~eop)[->cPktBitSize-2] ##1 (vld & ~sop & eop) ##1 ~vld;
    endproperty

 

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

 

Но все же некоторые ассерты лучше пишутся комбинированным способом : процедурный код + ассерты.

Это также подробно рассматривает яник.

 

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

 

Кстати в vmm технолгии созданы специальные шаблоны для задания асертов, там даже не нужно сильно разбираться как их описывать.

 

Удачи.

[CaPpuCcino 0]

Позвольте вмешаться в спор :)

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

ну а СВ конечно рулит :)

[oval 0]

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

 

Двигали :) , только в определенный момент, закрыли, ибо очевидно, что все остальное в этом случае просто бы вымерло... опять же, не я придумал, знаком с людьми, которые занимались написанием средств синтеза SC, но поступил приказ работы свернуть, финансирование прекратить...

 

Что касается возможностей верификации и самых современных тенденций, то в SC, аналогично SV, все это также реализовано: библиотеки SCV (SC verification), TLM и т.д. Вообщем, для полноты не хватает только нормальной поддержки синтеза...

 

Против SV ничего не имею, все достойно :)