[_Ivan_ 0]

Всем привет!

 

Интересует такой вопрос:

 

Вот у нас есть code coverage. Там анализируется такой показатель как transitions в fsm. Допустим в DUT у нас есть автомат, который при резете из любого состояния переходит в состояние IDLE.

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

 

Вопросы:

1) Как по фен-шую сделать такую штуку? Видится драйвер резета и sequence резета запущенная параллельно с нормальным тестбенчем и нужно еще получается отключать покрытие и scoreboard когда модуль в резете.

2) А такое вообще делают в верификационной индустрии? Показатель Code coverage всегда должен быть равен 100% или же можно идти на сделку с совестью и ...? У меня получилось 80 процентов всего по одному из модулей.

 

 

[Poluektovich 0]

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

[_Ivan_ 0]

Хорошо, а еще такой вопрос:

есть же default состояние в FSM

И в рамках симулятора загнать DUT в это состояние можно только при помощи force release

Иначе 100% line coverage не видать.

Как с этим поступить?

[lexus.mephi 0]

Хорошо, а еще такой вопрос:

есть же default состояние в FSM

И в рамках симулятора загнать DUT в это состояние можно только при помощи force release

Иначе 100% line coverage не видать.

Как с этим поступить?

В этом посте (ссылка) расписал процедуру для исключения ветки из отчета Branch Coverage. Аналогичным образом можно скорректировать и покрытие строк.

[_Ivan_ 0]

Спасибо, но это читерство.

 

Я тут недавно книгу Advanced UVM купил и сейчас пролистав ее решение нашел.

Сначала сам попробую, потом с народом поделюсь. Это мой первый uvm тестбенч, хочу статью накатать.

[favalligi 0]

Спасибо, но это читерство.

 

Я тут недавно книгу Advanced UVM купил и сейчас пролистав ее решение нашел.

Сначала сам попробую, потом с народом поделюсь. Это мой первый uvm тестбенч, хочу статью накатать.

 

Если есть возможность был бы благодарен за скан данной книжки, в интернете не нашел, а покупать жаба душит ((

[_Ivan_ 0]

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

 

Да и 40 баксов это отличная возможность стать лучше, мотивировать себя лучше знать uvm, а также сэкономить себе кучу рабочих часов за счет грамотной работы, а затем попросить прибавку к зарплате.

[favalligi 0]

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

Ну тогда буду еще более признателен если поделитесь :rolleyes:

 

Да и 40 баксов это отличная возможность стать лучше, мотивировать себя лучше знать uvm, а также сэкономить себе кучу рабочих часов за счет грамотной работы, а затем попросить прибавку к зарплате.

Бедным сотрудникам РАН на жизнь еле хватает, не то что на книжки по 40 баксов

[1891ВМ12Я 0]

Бедным сотрудникам РАН на жизнь еле хватает, не то что на книжки по 40 баксов

Просто любопытно, чем же они занимаются, будучи сотрудниками РАН? Я не верю что если человек делает нужную работу от которой есть заметный экономический эффект, то он не получает того чтоб хватало на жизнь.

 

Вопрос автору темы: в каком софте делает coverage? Я вот тестированием Verilog-проектов занимаюсь, до уровня code coverage еще не доросли, но мне заранее интересно.

[favalligi 0]

Просто любопытно, чем же они занимаются, будучи сотрудниками РАН?

 

Верификакией СБИС проектов с применением UVM методологии , иначе зачем мне эта книжка

 

[Loki5000 0]

Вопросы:

1) Как по фен-шую сделать такую штуку? Видится драйвер резета и sequence резета запущенная параллельно с нормальным тестбенчем и нужно еще получается отключать покрытие и scoreboard когда модуль в резете.

http://verificationhorizons.verificationac...et_vh-v8-i2.pdf

К слову, ресурс http://verificationacademy.com очень рекомендую. Там можно найти ответы на почти все вопросы.

А остальные просто задать.

Для полного доступа там нужна регистрация, но ее не так сложно пройти.

Обладать лицензиями Mentor Graphiсs при этом не обязательно.

Вопросы:

2) А такое вообще делают в верификационной индустрии? Показатель Code coverage всегда должен быть равен 100% или же можно идти на сделку с совестью и ...? У меня получилось 80 процентов всего по одному из модулей.

100% Code coverage нужен только тогда, когда вы занимаетесь проектированием ради самого процесса проектирования.

При решение реальных задач перфекционизм не уместен. Даже если речь об авионике и прочих ответственных задачах 100% Code coverage никогда не бывает.

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

Улучшить, но не идеализировать. Вообще 100% проверку теоретически может дать только формальная верификация. Но это больше красивая теория.

 

А теперь нужно вспомнить о функциональной верификации (functional verification). И это куда более важный аспект верификации, чем просто code coverage.

Потому как код вы может и проверифицируете, а вот делает ли ваш код то, что задумано - большой вопрос! И куда более важный.

И вот здесь уже % coverage субъективный параметр. Т.к. все зависит от того, насколько детально и правильно вы описали требуемую функциональность устройства.

Грубо говоря, процесс может превратится в бесконечный. Здесь решающим фактором будет являться опыт людей, ставящих задачу верификаторам.

Просто любопытно, чем же они занимаются, будучи сотрудниками РАН? Я не верю что если человек делает нужную работу от которой есть заметный экономический эффект, то он не получает того чтоб хватало на жизнь.

Но это вы прям как не в России живете. ;)

Отрадно слышать, что кто-то здесь еще верит в справедливость мира...

[_Ivan_ 0]

Вопрос автору темы: в каком софте делает coverage? Я вот тестированием Verilog-проектов занимаюсь, до уровня code coverage еще не доросли, но мне заранее интересно.

 

Questasim

 

 

100% Code coverage нужен только тогда, когда вы занимаетесь проектированием ради самого процесса проектирования.

При решение реальных задач перфекционизм не уместен. Даже если речь об авионике и прочих ответственных задачах 100% Code coverage никогда не бывает.

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

Улучшить, но не идеализировать. Вообще 100% проверку теоретически может дать только формальная верификация. Но это больше красивая теория.

 

Спасибо за мнение, но.

 

Как раз у меня случай с авионикой. DO-254, 10^-9 вероятность отказа и прочее. И если ошибка - погибнут люди. А я потом спать не буду и все такое.

Сейчас примерно смотрю - у меня по code coverage - переходы автомата из состояния в IDLE состояние по резету нету покрытия и default в автомате. Но так как там еще будет вотчдог, то наверное придется рушить автомат для покрытия этого и смотреть. В любом случае uvm это дело очень сильно упрощает и если я раньше думал что это гвозди микроскопом, то сейчас мне кажется при reusability модулей тестбенча это все весьма прекрасно.

 

 

 

[Kopart 0]

Я тут недавно книгу Advanced UVM купил и сейчас пролистав ее решение нашел.

Сначала сам попробую, потом с народом поделюсь. Это мой первый uvm тестбенч, хочу статью накатать.

Заинтриговали.

Напишите, этой свой вариант. Может я такой не проверял...

[_Ivan_ 0]

Заинтриговали.

Напишите, этой свой вариант. Может я такой не проверял...

 

 

Phase jump. Не думаю, что не проверяли.

[Kopart 0]

Phase jump. Не думаю, что не проверяли.

Это значит заход и выход в пределах дельта-цикла симуляции? (Например через х для полного case)

Я предположил вариант, который укажет, что этот default невозможен.