[Tpeck 0]

4 minutes ago, RobFPGA said:

Сейчас нет  - года 3-4 назад были попытки  освоить.  Но  не потянули. :(.   Но  некоторые идеи UVM  используем в своих  тестах.  

Спасибо.

[one_eight_seven 6]

3 minutes ago, Tpeck said:

А что понимается в индустрии под рандомизированными воздействиями?

Воздействие (все настройки, данные и т.п.) описывается в виде класса транзакции (uvm_sequence_item).

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

[Tpeck 0]

1 minute ago, one_eight_seven said:

Воздействие (все настройки, данные и т.п.) описывается в виде класса транзакции (uvm_sequence_item).

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

Ну а если у меня входное воздействие - это зашумленное кодовое слово.

Допустим шум добавить - без проблем на SV. А формировать кодовое слово мне тоже надо на SV, чтобы следовать концепции UVM?

[one_eight_seven 6]

4 minutes ago, AntonB said:

Вообще мне кажется что через всякие FLI, VPI и DPI верификация уже должна переходить на C++, C и тд

Так это используется в полный рост в т.ч. и в SV-UVM. Только вот непонятно почему "должна"? Возможность есть. А дальше - кому как удобнее. Есть куча наследия с C/C++ - пожалуйста, есть вам интерфейс с C. Вообще, если вы сравните код на SV и код на SystemC (как раз C++) - то читаемость явно не в пользу последнего.

[RobFPGA 28]

Приветствую!

4 minutes ago, one_eight_seven said:

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

А сверху  всего этого интересного  громоздят  вишенку - систему автоматического анализа контроля покрытия  и управления  такими ограничениями для минимизации времени верификации.  

8 minutes ago, AntonB said:

Вообще мне кажется что через всякие FLI, VPI и DPI верификация уже должна переходить на C++, C и тд

Это как бы для другого предназначено.  Но верификацию так тоже делают,  но часто по бедности  - софт  с полноценной  поддержкой UVM стоит немало.  :(

Удачи! Rob.

[one_eight_seven 6]

1 minute ago, Tpeck said:

А формировать кодовое слово мне тоже надо на SV, чтобы следовать концепции UVM?

Нет. Конечно, оно должно быть переведено в тот язык, для которого у вас UVM (он есть на e, SV, SystemC, может ещё на каких, я лично работаю с SV), чтобы дальше работал тестбенч, но само формирование воздействий делаете вы так, как вам удобно.
Можете через системный вызов запустить вашу програму, которая генерирует файлы воздействия, и потом эти файлы считать в транзакцию. Можете воспользщоваться межъязыковым интерфейсом и вызвать генератор, как библиотеку.

3 minutes ago, RobFPGA said:

А сверху  всего этого интересного  громоздят  вишенку - систему автоматического анализа контроля покрытия  и управления  такими ограничениями для минимизации времени верификации.  

Это да. Но к UVM это уже мало отношения имеет. Но и тут UVM'у есть что предолжить - уже готовая фабрика с возможностью переопределения классов из командной строки без перекомпиляций и СМС.

[Tpeck 0]

1 minute ago, one_eight_seven said:

Нет. Конечно, оно должно быть переведено в тот язык, для которого у вас UVM (он есть на e, SV, SystemC, может ещё на каких, я лично работаю с SV), чтобы дальше работал тестбенч, но само формирование воздействий делаете вы так, как вам удобно.
Можете через системный вызов запустить вашу програму, которая генерирует файлы воздействия, и потом эти файлы считать в транзакцию. Можете воспользщоваться межъязыковым интерфейсом и вызвать генератор, как библиотеку.

Идея вроде понятно.

А вот как дело происходит с большими проектами?

Которые долго симулируются. Там же особо не на рандомизируешь.

На порядок быстрее подать рандомизированные тестовые воздействие в железо и там оценить работоспособность.

8 minutes ago, RobFPGA said:

Но верификацию так тоже делают,  но часто по бедности  - софт  с полноценной  поддержкой UVM стоит немало.  :(

как один из плюсов uvm, что мне попадался. Это работоспособность в любом симуляторе поддерживающий IEEE-1800.

Насколько я понял - это стандарт для SV. Или всё не так просто?

[RobFPGA 28]

Приветствую!
 

4 minutes ago, Tpeck said:

Насколько я понял - это стандарт для SV. Или всё не так просто?

Плюшки  для верификации -  randomization,  coverage, ....  могут идти отдельными  пунктами лицензии (и прайса).  

Удачи! Rob.

[one_eight_seven 6]

1 minute ago, Tpeck said:

А вот как дело происходит с большими проектами?

Именно для них и используют UVM. Отдельно верифицируют блоки и системы блоков. Дальше соединяют это вместе и выполняют верификацию интеграции, уже на подмножестве тестов.

3 minutes ago, Tpeck said:

На порядок быстрее подать рандомизированные тестовые воздействие в железо и там оценить работоспособность.

Вы представляете сколько стоит набор масок хотя бы на 45 нанометров? Чтобы выпустить чип, в котором неизвестна работоспособность. И, кстати, когда это железо уже вышло - не видно, что внутри, что именно надо починить. Виден уже только сам факт неработоспособности.

Системы прототипирования (haps, boston) крайне дороги, и уместить в них большой проект часто не удаётся - только отдельными частями.

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

9 minutes ago, Tpeck said:

как один из плюсов uvm, что мне попадался. Это работоспособность в любом симуляторе поддерживающий IEEE-1800.

Насколько я понял - это стандарт для SV. Или всё не так просто?

Поддержка SV может быть заявлена, но реально её может не быть. Если правильно помню, такое было в ModelSim 10.1c, но с конкретной версией могу ошибаться. В нём просто не было ни covergroup, ни ограничений рандомизации.

Мне попадались отдельные UVM опции - это больше относилось к отладке - запуск отдельных стадий UVM, трассирование транзакций, отдельные менюшки для работы с Register Access Layer, и автоматические генераторы тестов для Register Access Layer. Но сама функциональность SystemVerilog, необходимая для UVM за отдельную цену мне не попадалась.

[Tpeck 0]

24 minutes ago, one_eight_seven said:

Вы представляете сколько стоит набор масок хотя бы на 45 нанометров? Чтобы выпустить чип, в котором неизвестна работоспособность. И, кстати, когда это железо уже вышло - не видно, что внутри, что именно надо починить. Виден уже только сам факт неработоспособности.

Хех, я и имел ввиду на ПЛИС погонять тесты )

Если, под ASIC, то там цена ошибки, весьма и весьма высока.

Спасибо, за развёрнутые ответы )

PS а чего ваши проекты даже в жирные ПЛИС не влезают, чтобы там функционал проверять?

 

 

32 minutes ago, RobFPGA said:

Плюшки  для верификации -  randomization,  coverage, ....  могут идти отдельными  пунктами лицензии (и прайса).  

Дьявол кроется в деталях (с)

[one_eight_seven 6]

5 hours ago, AntonB said:

Ну как по мне, то cocotb в этом плане неплох

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

Однако, нет нормального описания как этим пользоваться. Тот самый плюс питона, что документация на него меньше, чем на SV имеет и обратную сторону - весь новый функционал надо документировать, что не делается, и как пользщоваться рандомизацией - разбирайся сам. Приведены только самые тривиальные примеры.
А уж понимание авторами таких вещей как "распределение" и "soft/hard constraint" и вовсе заставляет чесаться в самых неприличных местах. Например, форма функции считается авторами функцией распределения. А hard и soft constraint - видом возвращаемого значения, если bool, то это hard, а если численное значение - это soft. и всё бы ничего, но они сами пишут, что это соответствует SV hard/soft constraint'ам. Для справки - soft constraint в system verilog означает, что эти ограничения будут действовать, только если не конфликтуют с указанными позже soft constraint'ами или с любыми hard constraint'ами. hard же, в случае конфликтов просто не разрешится и вернёт ошибку.

[1891ВМ12Я 0]

Я пытался UVM освоить, читал книгу The UVM Primer (для новичков самое то), сделал демонстрационный проект для коллег, даже пытался тестовое задание от потенциального работодателя выполнять на тему UVM, но увы, столкнулся с плохим качеством документации и небольшим числом примеров, раскрывающим все возможности. Я понимаю все преимущества, всё очень хорошо по идее там. Мне не удалось заставить работать проект регистровой карты, сделать программные резеты и много других вещей, делается это всё очень туго. Порой непонятные правила и ограничения, невнятные названия портов, которые не говорят сами за себя. Там возможностей очень много, как и в например системе контроля версий git, но порой попытка задействовать это всё в UVM приводит в ступор.

 

Возможно мне стоит перечитать более серьезную книгу.

[one_eight_seven 6]

4 hours ago, AVR said:

Мне не удалось заставить работать проект регистровой карты, сделать программные резеты и много других вещей, делается это всё очень туго.

Вот это как раз очень просто. Особенно, если карта регистров описана в ipxact - тогда симуляторы и вовсе сами создадут структуры данных и заявленные вами тесты.

4 hours ago, AVR said:

Порой непонятные правила и ограничения, невнятные названия портов, которые не говорят сами за себя.

Можно пример? Да, дурацкие названия классов я встречал, например - Virtual Sequence и  Virtual Sequencer, при том, что ни один из этих классов не virtual, а второй - ещё и не секвенсер, но с портами - не встречал.

Непонятные правила и ограничения - тоже не встречал.

Изменено 22 июля, 2021 пользователем one_eight_seven