Документация на System Verilog, Сбор документации на SVerilog. И обсуждение тонких моментов синтаксиса Опции

[dimasen]

Ищу документацию на System Verilog.
Нашёл всяческие презантации и "перечни" отличий от Verilog'a (назовём ANSI Verilog )
А нормальной доки так и не нашёл.

[des00]

Добрый день!

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.

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

Спасибо.


Денис.

[cms]

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

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

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

Добрый день!

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.

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

Спасибо.
Денис.

[des00]

2 cms и CaPpuCcino

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

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

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

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

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

вот как раз в 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 функций.

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

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

Код

  prj_env_0 env0;
  prj_env_1 env1;
  prj_env_2 env2;

  initial begin
    env0 = new ("test normal", dut_if);
    env0.do_test();

    env1 = new ("test error", dut_if);
    env1.do_test();

    env2 = new ("test shock", dut_if);
    env2.do_test();

  end

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

вот как раз размножение DUT меня смущает: ведь DUT - это module, а модуль объект статический, а если даже представить что вы можете размножать указатель на модуль

думаю это разрешимо если сразу вставить несколько 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

Hi Sarath,
Thank you for your kind words about OVM. Our view has always been that the OVM is the next logical step in AVM development. So, new testbench features will be developed collaboratively with Cadence and put into OVM.

As for AVM, we will continue to support AVM-3.0 for the foreseeable future. This support will include bug fixes and ongoing support for future releases of Questa.
__________________
Tom Fitzpatrick
Verification Technologist
Mentor Graphics Corp.

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

Спасибо