2 CaPpuCcino


взято http://www.ovmworld.org/forums/showthread.php?t=85

вот маленький учебник

http://www.doulos.com/knowhow/sysverilog/ovm/

спасиб, Денис! первую видел, вторую ещё нет - будем почитать

приятный тюториал по SystemVerilog http://www.electrosofts.com/systemverilog/index.html

Оффтопик был выделен в отдельную тему http://electronix.ru/forum/index.php?showtopic=46081
Убедительная просьба, будьте внимательнее при создании новых тем/сообщений.

Динамическая реконфигурация тестового окружения может быть использована для случайного формирования тестового окружения. Например у коммутатора к каждому порту может быть прицеплен endpoint или другой коммутатор. У USB-хост контроллера вообще может быть очень разнообразная обвязка - 8 уровней на которых могут быть как хабы так и функции до 255 устройств в общей сложности. Перебрать все варианты вручную через `ifdef `endif - врагу не пожелаешь.

Добрый день господа!!!

Наконец то докурил до конца доку по VMM, последние главы SYSTEM-LEVEL VERIFICATION и PROCESSOR INTEGRATION VERIFICATION вводят в основы технологии XVС (EXTENSIBLE VERIFICATION COMPONENTS).

И если с софтовой частью все более, менее понятно, то раздел HARDWARE-ASSISTED VERIFICATION ставит
в тупик. А именно как модель для моделирования переноситься в железо?

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

Разбирался ли ли кто нибудь с технологиями XVC ? Если да то не могли бы прояснить технологию предлагаемую авторами данной методики от синопсиса ?

Спасибо.

доки от CADENCE

особо интересны, имхо, sysverilog.pdf и abv*

интересно мнение знающих, про эти доки

http://electronix.ru/forum/index.php?showtopic=50571

в продолжение темы про OVM


http://www.mentor.com/products/fv/questa_e...ation_tech_news



таки дождались встроенной поддержки.

ждем 6.4 квесту

Я извиняюсь, а чего ждать-то? В известном месте лежит.

да и как-то к документации по SystemVerilog-у слабо относится

2 Vadim

нда, старею. надо было сначала известное место проверить %)



Ну если подходить с такой точки зрения, то разговорам о VMM/OVM/AVM не место в этой теме, больше о подходах к верификации на SV здесь писать не буду %)

Хотел подвести черту к недавнему диалогу о выборе между OVM/AVM, как и планировалось менторовцы переходят на OVM, оставляя для AVM только саппорт.

по-моему слишком ёмкая тема. лучше выносить в отдельный топик, иначе структурированность потеряем - получится "все-обо-всём"

Момент синтаксиса: поддерживает ли SV вложенные (через import) пакеты? По БНФ-синтаксису, вроде не обязан (однажды так обжёгся на вложенных generate) - но это было бы так удобно... Пример:

m0 и m2 (!) компилируются, а m1 - нет; используется Quartus 7.2.

http://www.asic-world.com/systemverilog/index.html

http://www.asic-world.com/systemverilog/tutorial.html

по OVM появился тьюториал:
http://www.doulos.com/knowhow/sysverilog/ovm/

очень недурственный учебный ресурс (тьюториалы) по SystemVerilog - http://testbench.in/
помимо прочего рассматриваются такие вопросы как:
классы СВ, рандомизация в СВ, утверждения (SVA), DPI, управление с помощью событий (events)
приводятся примеры верификации проекта как на чистом SV, так и построенных по методологии VMM, AVM

у Doulos появилась в открытом доступе очень недурственная бумажка на тему процесса перехода от TLM модели к RTL (рекоммендую любителям пректирования больших систем по принципу "сверху-вниз"):
Seamless Refinement from Transaction Level to RTL Using SystemVerilog Interfaces (http://www.doulos.com/knowhow/sysverilog/ тамнайдёте)

обнаружил интерсную бумажку по интеграции SystemVerilog и SystemC через DPI (интересно что в списке публикаций она на сайте Сузерленда не числится, хотя на сервере лежит)
http://www.sutherland-hdl.com/papers/2004-...ith_SystemC.pdf

господа, может ли функция SV возвращать непакованный массив не через список параметров а через собственное имя? например:

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

или я чего-то не доглядел в нынешнем стандарте?
спс

ИМХО вы поняли все правильно, только через введение нового типа %)

Я тут слепил PDFник с этой ссылки, пока tutor потом остальные слеплю, выложу. Так наверное
лучше будет.

Достойное дело. Только вот отступы (indent'ы) в коде не присутствуют, что весьма снижает читабельность примеров.

Вот еще слепил, более наглядный тутор, только в плане корректности не проверял, да и концовка
я у них что-то не понял. Гипперссылки отсутствуют.

Подскажите пожалуйста где можно скачать IEEE 1800-2007.

Не находил ли кто стандарт IEEE-P1800-2008 - говорят в начале 2008 объединили предыдущий 1800-2005 и верилоговский 1364 в один документ. Любопытно было бы его почитать.

Digitally yours,
cms




Digitally yours,
cms

новости по стандарту обсуждаются здесь: http://electronix.ru/forum/index.php?showtopic=49689
2008 ещё не опубликован, скорее всего только весной след. года

вопросы приобретения материалов не подлежащих свободному распространению в данной ветке не обсуждаются

столкнулся с занятной баго фичей.

Итак господа что по вашему должно быть выведено в консоль в данном коде



Занятные результаты получаются у меня в квесте 6.4а



А у вас ?

ЗЫ: это баг квесты, а не нюанс СВ
ЗЗЫ: в службу поддержки написал. ЗЗЗЫ: при этом баг проявляется только при передачи типа через список параметров модуля, если напрямую объявить пипу как logic[0:0], то всё ок

ок, Ментор ошибку признал. Временное решение проблемы в использовании ключа -vopt.
ЗЫ:желательно проблемы ментора обсуждать в разделе по средствам разработки, чтоб не мешать приятное с полезным .

Должна ли в SV работать такая конструкция:


module a;

parameter param_a = 128;

endmodule


module b;

parameter param_b = a.param_a;

initial $display("param_a = %d", a.param_a);

endmodule

Т.е. можно ли использовать при определении параметра в модуле параметр из другого модуля и как?

Удивительно, но VCS параметр из внешнего модуля видит по иерархическому (?) пути без инстанса, $display его отображает правильно.
Правда при назначении параметра VCS уже сообщает что a.param_a неконстантное выражение и не компилит его.

QuestaSim сразу говорит что не находит в иерархии.

тут на мой взгляд не всё так однозначно. то, что написано, синтаксически правильно (НО). т.е. во втором модуле параметр через иерархическую ссылку должен быть виден (здесь в СВ аналогия с пакетом, да и вообще с любым пространством имён). другое дело как компилятор относится к этому пространству: включает ли он его при компиляции как подиерархию $root или как совершенно отдельное пространство имён (в случае с пакетом здесь было бы всё точно - пакет компилировался бы в единую подиерархию "рут")... и тут всплывает то самое "НО": какое практическое значение имеют 2 модумя никак не связанные в проекте (да и вообще никак синтаксически не связанные)? какой смысл им делить единое пространство имён?

Модули связанные: инстанциированные параллельно в топе или вложены друг в друга. Например модуль b инстанциирует а в зависимости от значения param_a.

P.S. Synopsys ответил, что эта фича еще не заимплеменчена, и что они отправили мой вопрос VCS R&D рассмотреть на предмет включения её в будущих релизах.

но это не соответствует тому, что вы написали (?). здесь же нет условного инстанцирования - если б был, компилёр должен видеть соседнее(связанное) пространство имён! ЗЫ: а если, как вы говорите, они инстанциированы в топе параллельно, то связи между ними я не вижу. там есть условный генерэйт?

Вот как раз иерархия интсансов в данном случае значения не имеет. Рассматриваем compilation unit Согласно п.19.3 IEEE 1800-2005(E)

tools shall provide use models that allow both of the following cases:
a) All files on a given compilation command line make a single compilation unit (in which case the
declarations within those files are accessible anywhere else within the constructs defined within
those files).
Each file is a separate compilation unit (in which case the declarations in each compilation-unit
scope are accessible only within its corresponding file).

Т.е. если два модуля описаны в одном файле, то они находятся в одном пространстве имен $unit, независимо как они с друг другом соотносятся или инстанциируются где бы то ни было. Или вообще не инстанциируются.

VCS в соответствии с этим правилом позволяет видеть соседние модули, и даже позволяет спускаться во внутренности этих модулей. Правда при этом где-то теряет признак константности.

Схожая бага была в квесте 6.3, когда $clog2 от константы почему-то воспринимался как переменная и не давал использовать результат в определении векторов. В 6.4 это пофиксили и теперь наконец можно писать

logic [$clog2(1024)-1:0] a;

выложил доки из синопсиского VCS (vmm+fssertions)
/upload/DOCs/SystemVerilog/synopsys/

вроде бы не встречал такого на сайте

в SOLD-е много еще всего, примеры, туториалы, всякие методологии типа RVM, OVA и т.д.
если нет линукса или лень распаковывать весь солд, могу дозалить

А VCS-то хоть "берет" эти мудрые конструкции, от которых плохеет ментору?

то о чем мы говорим (2008.9 mx) берет (но ментор их тоже берет), но VCS не глючит
ну и работает на порядки быстрее (позже попытаюсь пустить нетлист с SDF, и померить с каденсом, ментор то на этом вообще сосет)

но у VCS-а есть проблемы с начальной инициализацией и параметрами (это я изложу отдельным топиком)
то есть полного счастья нет

зато гораздо внятней становится структура сборки (всякий маразм типа mfcu, sfcu отсутствует) и судя по всему все книжки по SV, написаны на основе VCS-а
ну и доки и примеров полно
ну и VMM там есть (вроде как прямее OVM, хотя я не копенгаген, чтоб их сравнивать)

таки яник и сотоварищи признали что не правы, правда косвенно.

http://synopsysoc.org/insideprotocolverification/?p=40



вот что интересно, открытый VMM может и не подняться на других симуляторах

SystemVerilog Assertions

Author(s): Srikanth Vijayaraghavan
Publisher: Springer
Date : 2005
Pages : 334
Format : PDF

/upload/DOCs/SystemVerilog

пришло от ментора письмо. говорят, что фича исправлена в 6.5. поверил наслово.

Нашел вот это:
http://www.pdf-search-engine.com/system-verilog-rtl-pdf.html
Сейчас буду рыться...

Ищу книгу
Verilog and SystemVerilog Gotchas:101 Common Coding Error and How to Avoid Them
by Stuart Sutherland and Don Mills
Пожалуйста, Не могли бы вы помочь?

не подскажет ли уважаемая публика, можно ли паковать интерфейсы в пакеты
спб

если я правильно понял вопрос -

нельзя - вроде бы где-то явно написано
так ткнулся в стандарт

Types, variables, tasks, functions, sequences, and properties may be
declared within a package. Such declarations may be referenced within modules, macromodules, interfaces,

то есть то что инстанциируется в хиерархию в пакадж нельзя

спб! тоже где-то в стандарте видел фразочку, типа, всё что может быть с hierarchical reference в пакет нельзя - но немного смутил доступ к полям классов, структур, объединений.

уважаемые, стоит такая задача:
есть массив интерфейсов типа if_t из n элементов -
if_t if_array[n]();
есть набор интерфейсов в количестве n того же типа никак не объединённых -
if_t if_a();
if_t if_b();
...
if_t if_n();
необходимо однозначно связать весь набор из разрозненных интерфейсов с каждым интерфейсом массива.
кто и как изящно решал эту задачу, поделитесь мудростью. я думаю, что нужно смотреть в сторону собственной функции интерфейса типа
interface if_t();
...
function automatic if_t if_assign(if_t interface_bind);
endinterface
но есть сомнения что это реализуемо;
другой вариант - делать модуль-заглушку, но это не изящно.
что посоветуете?

ЗЫ: вообще в последнее время некоторые участники форума стали говорить, что n мало, и лучше k, поэтому если будет k, я не возражаю

Что значит "связать"? Присвоить элементам одного интерфейса значения другого? Или нужно, чтобы было взаимное переприсваивание?
В первом случае всё просто: на уровне environment-та приассайнить нужный интерфейс из массива к интерфейсу из набора. Остальную часть проекта можно не менять. При желании это же
можно сделать на верхнем уровне-

Если в каждый момент времени нужно управлять механизмом присваивания, тоесть необходима уметь присваивать как из массива к набору, так и обратно, то изящнее всего было бы воспользоваться
следующим: в нужном блоке кода определить присваивание в `ifndef а, а на верхнем уровне либо определять`define а 16, либо нет. Тем самым будет происходить выбор направления присваивания.

Надеюсь правильно понял вопрос.

извините за нечёткость формулировки. имеется ввиду второй случай, т.е. интерфейс сигнального уровня. во избежании ложной интерпритации опишу проблему подробнее:
на сигнальном уровне интерфейс подразумеваю как набор сигналов, т.е. аналогия структуры, с тем исключением, что в общем случае сигналы в интерфейсе имеют ещё и направление, таким образом оператор присваивания по аналогии со структурами здесь применять невозможно:
typedef struct {bit a;bit b;} struct_t;
struct_t x; struct_t y;
x=y; (эквивалентно x.a=y.a; x.b=y.b;)
таким образом если учесть направление сигналов в интерфейсе, то необходимо писать нечто например такое: x.a=y.a; y.b=x.b; (или наоборот в зависимости от направления сигналов).
таким образом для повторного использования кода необходимо вводить нечто на подобие метода класса, внутри которого происходит присваивание с учётом направления. кто-нибудь эксперементировал с подобным?
вариант с прекомпилятором использовать не хочется, хотчется языковыми средствами.
спб

загружать можно от суда:
http://www.systemverilogtestbench.org/books/