[_Ivan_ 0]

http://www.sunburst-design.com/papers/Hunt...esets_paper.pdf

 

в Advanced UVM эта статья скопирована

 

Перечитал дискуссию, понял что я немного не понял Kopart

Я сейчас речь веду про 100% transition coverage и phase jump поможет.

 

А вот загнать это в default state увы.

Видится только force release state_reg DUT

[_Ivan_ 0]

Вопрос появился:

 

Допустим у нас есть сложный sequence_item.

А для reusable у нас сделан драйвер, который воспринимает только простые операции.

Например есть burst на axi шине. А драйвер может только чтение или запись 1 слова.

Преобразование сложного пакета в набор простых операций делаем в sequencer, так?

Или есть какие то еще методы?

[yuravg 0]

Например есть burst на axi шине. А драйвер может только чтение или запись 1 слова.

Преобразование сложного пакета в набор простых операций делаем в sequencer, так?

Или есть какие то еще методы?

Поищите по словам: Parameterized Interfaces and Reusable VIP

(part1

part2

part3)

Вам надо будет переписать driver и sequencer, а формирование сигналов помещается в интерфейс.

В приведенных примерах реализация без burst, но добавить его не сложно.

В результате получите универсальный компонент для разной ширины адреса, данных, burst (я делал такой для avalon)

Изменено 26 октября, 2016 пользователем yuravg

[_Ivan_ 0]

Спасибо!

[radigast 0]

Questasim

 

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

 

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

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

 

Я бы даже больше сказал. На моей практике у правила «то что не проверено - не работает» исключений практически не было. Поэтому если блок является критическим узлом будущей системы лучше к нему отнестись с должным уважением. Последнее время мы стараемся доводить такие блоки до 100% покрытия (да, осознанные исключения отдельных состояний могут иметь место, особенно если речь идёт про стиль RTL, учитывающий X пессимизм, см. «The Dangers of Living with an X»)

Более того, надо понимать, что покрытие кода это не панацея. Если есть непокрытый участок кода — у вас точно дыра в тестах. Если у вас 100% покрытие кода, это ещё не гарантия того, что все ошибки фиксируются.

Примеры:

1. Тест на фичу при исполнении фоном дёргаёт сигналы устройства, которые явно не завязаны на результат работы данного теста, но являются важными для другой фичи, на которую теста ещё нет. Анализ покрытия в этом случае может оказаться слишком оптимистичным. (Лечится совмещением CDC подхода, классического тестового плана и функционального покрытия).
2. Тест может быть написан, но при прохождении неполноценно контролировать результат. (методы борьбы — дополнительные assertions, методы анализа качества тестов на базе проверки фиксации ошибок в коде см. средства типа Synopsys certitude)
3. Сложные автоматы типа блоков управления конвейером процессоров без функционального покрытия вообще небезопасно проверять (тут также 100% покрытие кода лишь первый шаг).

 

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

 

[_Ivan_ 0]

radigast, спасибо, очень ценный совет!