посмотрел файл. это не новый стандарт - это его свежая электронная публикация. (стандарт преждний 1800-2005; с какого перепугу ему в предыдущей ссылке новую цифру приписали я не понял)

Добрый день!

5 ый день копания в AVM/OVM.

Первое ощущение : мракобесие, особенно после того, как доверяя издательству Springer и Янику Бергерону, смотришь их VMM (synopsys) в поиске функциональных аналогов.

Такое ощущение что господа из каденсе и ментор не долго думая, тупо переписали классы с SC на SV. При этом внеся ИМХО С++ сумятицу в стройный SV.

Господа кто работает по "пАцАнСкИ", объясните зачем в SV был введен геморой с типами портов для транзакций, и необходимостью их регистрировать и конектить?

В SC это понятно. там это вызвано самой концепцией языка языка, но в SV уже есть необходимый объект синхронизации mailbox (типизированый и не типизированый), зачем его нужно было обвешивать кучей портов и функций ?

Почему в AVM/OVM практически не используются callback, а предлагается использование analisys_* компонентов? Некоторые их которых содержат в себе объекты синхронизации(analisys_port например)?

Тогда как в SV for Ver не рекомендуется использовать активные scoreboard/monitor и т.д. А делать все на очередях callback классов.

VMM выглядит более простой и понятной, AVM/OVM как темный лес, здесь зарегистриуем, здесь экспортнем конекторы портов, тут импортнем их и т.д. Ведь по сути это обычная передача указателей на объекты синхронизации.

В итоге в тестбенче на основе AVM все закопано так, что почти теряется сам смысл использования SV перед SC.

Если не сложно объясните чайнику зачем это было сделано так ?

Спасибо.


Денис.

привет! недавно тоже поглядел на OVM библиотеку плюс описалово классов, но не для анализа подхода, а для поверхностного ознакомления - впечатление так же хуже чем от VMM. OVM кажется менее развитой иерархией. (кстати сразу же возник вопрос, а если у них какая-нибудь обясняющая записка обосновывающая их модель на подобие Яниковского VMM for Ver? на сайте OVM нашёл ток описание класов, но ничего особенного по методике)

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

у Бергерона, как я разумею, есть та же концепция обозначенная как vmm_channel. и обе эти реализации находятся в согласии с концепцией СЦ(и TLM на базе объектов). в общем случае приследуются те же цели что и в концепции ООП - инкапсулировать потроха объекта и обезопасить их от неправильного или несанкционированного использования.
вспомните концепцию интерфейса в СЦ (абстрактный класс), вот обвешивание mailbox функциями приследует ту же цель (vmm_channel тоже строится на mailbox)- обезопасить объект, обеспечить возможность повторного использования компонентов и их заменяемость

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

Думал над вопросами. Мой вариант объяснения:

У OVM тестбенч не статический. Он строится программой тестирования (в OVM понятие теста и тестбенча разнесены), динамически создающей инстансы модулей и динамически их коннетящей - также как это делается в ООП программах при сборке алгоритма из классов. Динамическое создание тестбенча как раз и требует тех усложнений, которые Вы перечислили: регистрация и коннект портов (ака COM интерфейсы), работа только через указатели и специальные синхрообъекты.

Все это сделано для того, чтобы можно было программно менять тест-бенчи.

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

В OVM есть классы ovm_env, ovm_test, ovm_factory. Они позволяют динамически менять компоненты (override), структуру и параметры тестбенча. Плюс в классах компонент предусмотрены методы для внешней конфигурации типа set_config. Все заточено на reuse и инкапсуляцию.



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

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

извините за придирки, но всё-таки эти примеры не подходят под динамически-изменяемую структуру тестбенча (понимаю конечно, что детально продумывать ответ вы не старались, но всё же): для вспрыска ошибок нет необходимости менять структуру тестбенча (пояснять наверное нет необходимости: ошибочный источник от неошибочного отличается только потоком данных им создаваемым, а изменение потока данных не нуждается в изменении компонентной/структурной/ конфигурации тестбенча); изменение схемы подключения никак не влияет на шинный интерфейс - тут хоть точка - многоточка, хоть многоточка-многоточка разницы для объекта тестирования никакой, тем более если смотреть с точки зрения размножения DUT, то это вообще невозможно динамически, так как module - статический объек и динамически размещаться не может и удалятся тоже, если даже представить что мы моделируем коммутатор и хотим посмотреть как он будет вести себя в зависимости от количества каналов им обслуживаемых и захотим сделать это динамически - то у нас тоже ничего не получится: interface в СВ тоже статический объект и кроме как через изменение parameter или define c последующей перекомпиляцией нам такую ситуацию не отверефицировать. так что ничего естественного в динамической пересборке инфраструктуры отсюда не вытекает

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

Изменение схемы подключения несет существенную разницу для DUT, так как позволяет выявить ошибки арбитража. Размножения DUT динамически вожможно, так как размножается не модуль, а его обертка - класс ovm_object. То же и для interface - создаются и уничтожаются классы, их инкапсулирующие.

Задача OVM - продвинуть возможности верификации дальше 'define/parameter. Если Вы лично пока не видите в этом необходимости, это не значит, что её нет. Это вопрос Вашего личного круга задач.

P.S. Ответы продумывать я стараюсь детально. Могу ошибаться, но не преднамеренно.

все мы смертны : )

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

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

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

2 cms и CaPpuCcino

Спасибо за ответы. Кое о чем я интуитивно догадывался, но кое что по прежнему темный лес:



Нет не нашел, только референс и примеры. Но т.к. ее сделали на основе AVM то думаю что обоснование AVM очень близко по духу.





вот как раз в VMM мне больше понятно, что, куда и зачем. Но когда я копался в описании AVM/OVM и сорцах либ, меня удивляло большое количество объектов типа порт(!!!), через которые по сути и идет передача указателя на один единственный мелбокс, хотя по сути мейлбокс это и есть уже готовый объект и для передачи его указателя достаточно просто присвоить чиселки.

Или в объектах типа порт скрыт сакральный смысл проверки, правильности коннектов на этапе построения окружения (enviroment eleboration ) ?

Еще вот что сильно не понятно. В VMM рекомендуют именно callback и для этого у них есть специальный класс vmm_xactor_callbacks и методы класса vmm_xactor prepend_callback/append_callback. А в OVM callback есть только в hook функциях классов для вывода логов.

Управляя очередями callback функций можно так же на лету менять функциональность объекта. В том числе кстати вносить ошибки в уже сформированные правильные данные, без создания объекта потомка с другими алгоритмами, а с регистрацией класса callback с описанной callback функцией.

А если быть в концепции OVM то что бы сделать например 2 монитора (например для SDRAM контроллера scoreboard + bandwidth measurement) к классу драйвера, мне потребуется 2 analysy_port с analysy_fifo. Что потянет за собой 2 mailbox с кучей объектов портов. Тогда как в VMM концепции всего 2 вызова callback функций.



Скажите а чем это будет отличаться от случая если я создам несколько enviroment с разной функциональностью и в главной программе будет следующее



Или всегда должен быть только один enviroment, а разные тесты должны перебираться на основе объектов ovm_test?




думаю это разрешимо если сразу вставить несколько DUT, к ним массив интерфейсов а коммутацию уже производить в программе на лету. Отключение холостых DUT можно сделать просто зафорсив тактовую в 0 а ресет в активное состояние.



тоже блуждаю в грамотной реализации подобной обработки. Делал и разные классы и наследуемые, у каждой концепции есть свои + и -, но думаю что использование базового avm_transaction/ovm_transaction решит часть проблем.

А по сабжу думаю тут нужно ввести классификацию ошибок.

Если требуется ввести ошибки в посылку правильных данных, то это делается легко и просто. Можно как на наследуемом классе, так и ввести в этот же класс. Но когда требуется внести интерфейсную ошибку (например в драйвере сформировать ошибку системной шины) то тут я вижу 2 варианта :

1. Модифицировать базовые классы драйвера и транзактора и ввести в них интерфейс управления вставкой ошибок. При этом не потребуется менять enviroment на верхнем уровне.

2. Наследовать классы драйвера и транзактора добавив логику вставки ошибок, но потом на верхнем уровне потребуется либо сделать 2 конфигурации (нормальный тест, тест с ошибками) либо сделать совершено другой enviroment?

Хотелось бы знать как это правильно делается и почему ?

Спасибо!


Перед тем как править свой тестбенч для свича потоков, решил немного покурить ovm и

2 CaPpuCcino

ovm-1.0.1\examples\basic_examples\module\test.sv

похоже вот про какие dut идет разговор. Это behavor модели ovm_object, завернутые в ovm_object_wrapper, которые завязаны на ovm_factory.

Т.е. как я понимаю к отладке RTL это имеет малое отношение.


ЗЫ. 2 cms как по вашему на чем лучше остановиться на ovm или avm ? (vmm как я понял закрыта и в сорцах не поставляется %( ). Даже если не брать все из ovm/avm использование avm_transaction, avm_named_component, avm_treaded_component, avm_reporter сильно упрощает жизню %)


Нашел ответ

http://www.ovmworld.org/forums/showpost.ph...amp;postcount=8



Понятно куда двигаться.

Спасибо

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 - врагу не пожелаешь.