1. Пожалуйста аргументируйте ваше решение.

[Escorial 0]

Хотелось бы узнать, в какую сторону склонились участники форума в своем выборе методологии верификации и почему.

 

По моему мнению, VMM стартовав раньше теперь будет всегда опережать OVM на пару шагов вперед. Это связано как с первоначальным лидерством (VMM появилась раньше AVM/UVM), так и с людьми, вовлеченными в ее развитие - например Janick Bergeron из Synopsys прекрасный тому пример.

 

Преимущества VMM на мой взгляд:

1. RAL (Register Abstraction Layer) - был впервые предложен в VMM, появился только в OVM 2.0. Глубина поддержки не известна (поддерживается ли автоматический анализ функционального покрытия, формируются ли автоматически тесты для всех регистров, доступных через RAL - все это уже есть в VMM).

2. HAL (Hardware Abstraction Layer) - для работы с ускорителями.

3. Анализ загруженности ресурсов для анализа потенциальных узких мест в проекте.

4. Встроенные в базовые классы callback -методы.

 

Возможно нижеперечисленные фичи VMM можно найти и в OVM, а может и нет:

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

 

 

Буду признателен, если меня кто поправит/дополнит.

[des00 27]

Хотелось бы узнать, в какую сторону склонились участники форума в своем выборе методологии верификации и почему.

 

По моему мнению, VMM стартовав раньше теперь будет всегда опережать OVM на пару шагов вперед. Это связано как с первоначальным лидерством (VMM появилась раньше AVM/UVM), так и с людьми, вовлеченными в ее развитие - например Janick Bergeron из Synopsys прекрасный тому пример.

 

Проясните немного истории, насколько я понял из тех источников что у меня есть, AVM появилось с введением поддержки SystemC и уходом в TLM моделирование. А VMM стало разрабатываться с появлением SytemVerilog. Или я ошибаюсь?

 

О преимуществах спорить не могу, т.к. не смотря на использование OVM в своих проектах и обзорном знании VMM о тонкостях судить не могу. В свое время когда я выбирал между этими двумя методологиями, VMM была закрыта. Я не смог найти ее сорцы, несмотря на то, что в сети было полно книг о ней и примеров ее использования. от AMM сам ментор отказывался и потому я выбрал OVM, несмотря на то что книг по ней тогда не было вообще (UserGuide появился только в 2.0 версии.). Сейчас ее открыли и желание поковыряться есть, но времени на это нет :(

 

Возможно нижеперечисленные фичи VMM можно найти и в OVM, а может и нет:

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

 

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

[Doka 5]

>> Какая методология верификации на ваш взгляд более перспективна сегодня?

 

при прочих равных - кроссплатформенная)))

тут совсем недавно писали про сравнение по этому критерию.

[Escorial 0]

По поводу истории: концепции VMM на 90 процентов были обкатаны еще в RVM, которая создавалась когда стандарта TLM еще не было. Это, кстати, рассматривается OVM-пользователями как один из недостатков, т.к. собственная версия реализации TLM через класс vmm_channel потенциально может вылиться в проблемы со стыковкой с SystemC - окружением. Я этим не занимался, поэтому сложно судить.

 

 

>> Какая методология верификации на ваш взгляд более перспективна сегодня?

 

при прочих равных - кроссплатформенная)))

тут совсем недавно писали про сравнение по этому критерию.

 

Понимаете, т.к. обе методологии заточены под стандартизованный язык, то со временем они обе будут полностью поддерживаться всеми производителями САПР. Свидетельством тому и VIP Technical Standart Commitee в Accellera. Пока, насколько мне известно все проблемы с переносимостью были вызваны плохой поддержкой стандарта языка отдельными производителями САПР (Cadence здесь, похоже, сильнее всех отстает). Знаю, что сегодня VMM работает на QuestaSim, по IUS нет данных.

Единственное, где на мой взгляд могут возникнуть проблемы - это заточенность специальных вспомогательных тулзов под конкретную методологию. Т.е. в пакет Incisive могут включить графический инструмент для построения RAL-модели устройства для OVM, ясно что Synopsys под OVM ничто подобное никогда не выпустит.

[SM 15]

Пока ответил "затрудняюсь". Сам стою перед выбором. Склоняюсь к однозначному решению в пользу "что лучше поддержано синопсисом". Но пока что не доконца понимаю ситуацию, поэтому не использую ни того, ни этого.

[yes 27]

как кажется, vmm проще owm (по объему кода вдвое меньше)

тем более vmm использует более "простое" подмножество SV - плюс это или минус - непонятно

 

собственно есть compatibility layer-ы с vmm на owm, а обратно нет и вряд ли будут в ближайшее время

http://www.ovmworld.org/contributions-details.php?id=30#

http://www.ovmworld.org/contributions-details.php?id=24

 

но у owm по-моему субъективному ощущению больше прямоты (хотя построение иерархии соединенй на основе ООП надстройки для HDL языка выглядит весьма маразменно :) )

 

по моим предпочтениям я склоняюсь к owm, но кончился временной слот для освоения "нового", поэтому пока отложил

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

[Escorial 0]

Думаю важно функции сравнивать, а не объем кода.

 

Пока добавил файлик с базовыми классами, буду признателен если кто подхватит инициативу и дополнит его.vmm_vs_ovm.txt

[des00 27]

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

 

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

 

Спасибо.

[cms 0]

Hi All,

 

Я выбрал VMM по следующим причинам:

 

1. Наличие материалов для изучения:

- отличная книга Бергерона ""VMM for SystemVerilog" была уже в 2006

- Synopsys VMM_TUTORIAL_SV лабы (с тех же времен)

- несколько хороших статей в сети, например "VMM For Dummies" от XtreameEDA на SNUG'2006

 

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

По OVM до последнего времени были только списки классов и невнятные общие статьи. Хотя у AVM тоже был нормальный юзер гайд.

 

2. Обозначился переход на синопсисовский софт.

 

 

В общем же, проникнувшись одной методологией, освоить вторую ИМХО будет уже делом техники. К концу 2008 и по OVM появились книги. Можно изучать.

Мне вот например импонирует в OVM то что у них есть класс-прародитель ovm-void. Смысла никакого, зато выстраивается логически целостное дерево.

Так что если качнет в сторону Кейденс/Ментор, будем писать по OVMовски.

[des00 27]

По OVM до последнего времени были только списки классов и невнятные общие статьи. Хотя у AVM тоже был нормальный юзер гайд.

К концу 2008 и по OVM появились книги. Можно изучать.

 

OVM апгрейтнутый AVM, я его изучал по докам на AVM.

 

У вас случайно книг по OVM не завалялось ?

 

 

ЗЫ. а понятие фабрики в OVM вам не импонирует ? :)

[Escorial 0]

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

 

Спасибо.

 

Здраствуйте, похожая задача стояла.

 

В данном классе (vmm data stream scoreboard) есть методы:

expect_in_order (ожидать пакет в том же порядке в котором был положен в скоребоард)

expect_out_of_order (пакеты не по порядку).

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

 

Могу порекоммендовать зайти на сайт vmmcentral.org и скачать там руководство vmm scoreboarding от Janick Bergeron.

[yes 27]

чем больше имею опыта работы с VCS, тем мне он больше нравится в плане поддержки SV

там более жесткие ограничения (то есть поддерживается меньше фич), но достаточно часто когда глюки невразумительные в квесте идут (квеста обязательно по договоренности), компилю/прогоняю под vcs

nc толи криво сломан, то ли у меня кривые руки, но валится (internal error практически все время :) как 32 разрядный, так и 64х), ну и там каких-то маразматических ограничений много - типа .* нельзя использовать в generate и т.п.

 

то есть склоняюсь к использованию VMM

[des00 27]

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

ovm_know_how.txt

[yes 27]

вот некоторое сравнение от парней из ментора (типа нахваливают OVM)

 

по прочтении мои замечания:

 

Multi-vendor support – The OVM was co-developed and is fully supported by both Mentor and

Cadence.

 

но то что она на VCS не работает, имхо, все плюсы нафиг зануляет

тем более VMM для NC/Questa есть

 

Next-generation technology – The OVM leverages the full power of the SystemVerilog standard and is

unencumbered by legacy technology.

 

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

 

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

1

VCS claims support for parameterized classes beginning with version 2008.03. The current VMM open-source kit

нифига он не поддерживает параметризированные классы

 

Commitment to open-source community – The OVM was the first SystemVerilog library

 

это че спорт? VMMCentral тоже есть, и литературы там гораздо больше, что имхо, важно

 

Port-based communication and standard TLM interfaces – The OVM provides the most effective

 

ну по-моему дилетанскому разумению и параметризированный mailbox замечательно решает вопросы передачи транзакций

а вопросы "супер защиты" кода от дурака кажутся не столь выжными (по крайней мере в моем случае) для тестбенча, это же не пользовательское приложение

 

Hierarchy and Connection Infrastructure The OVM was designed to scale from the smalles

 

но зато сложно, VMM вобщем-то я уже подцепил к своим примитивным девайсам, а с OVM как-то побольше требуется понимания "деталей"

QUESTA.pdf

[Escorial 0]

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

 

Понравилась идея портов для всех компонентов тестбенча, причем правильность их соединения проверяется во время компиляции, в то время как за то, что попадает в vmm_channel отвечает сам пользователь и проблемы вылезут только на этапе runtime.

 

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

 

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