Документация на 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.

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

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

[CaPpuCcino]

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

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

[cms]

поясните пожалуйста что значит нестатический тестбенч? и что вы имеете ввиду под тест и тестбенч-понятия разнесены?

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

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

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

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

[CaPpuCcino]

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

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

[cms]

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

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

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

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

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

[CaPpuCcino]

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

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

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

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

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

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

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

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