[1891ВМ12Я 0]

В книге "Getting Started with UVM. A Beginner's Guide" есть такой фрагмент:

Мне непонятно - это ошибка? По моему представлению, в терминологии UVM port это вход, а export - выход. Тогда непонятно, почему в данном примере мы соединяем export у scoreboard-а и port у монитора. Как так получилось, что scoreboard, которое лишь собирает статистику (принимает некий поток пакетов/сообщений/транзакций), тут подключается export-ом. А монитор, который сидит на шине и собирает данные, наоборот, подключается port-ом?

 

Ошибка ли это? Ведь это именно монитор порождает данные для анализа, а scoreboard их лишь получает и анализирует.

 

Дальше в книге действительно пишут что port монитора коннектим к export у scoreboard-а или coverage. В то же время ранее в книге seq_item_export sequencer-а подключен к seq_item_port драйвера, т.е. export->port.

[one_eight_seven 6]

https://verificationacademy.com/verificatio...s_port-svh.html

[favalligi 0]

В книге "Getting Started with UVM. A Beginner's Guide" есть такой фрагмент:

Мне непонятно - это ошибка? По моему представлению, в терминологии UVM port это вход, а export - выход. Тогда непонятно, почему в данном примере мы соединяем export у scoreboard-а и port у монитора. Как так получилось, что scoreboard, которое лишь собирает статистику (принимает некий поток пакетов/сообщений/транзакций), тут подключается export-ом. А монитор, который сидит на шине и собирает данные, наоборот, подключается port-ом?

 

Ошибка ли это? Ведь это именно монитор порождает данные для анализа, а scoreboard их лишь получает и анализирует.

 

Дальше в книге действительно пишут что port монитора коннектим к export у scoreboard-а или coverage. В то же время ранее в книге seq_item_export sequencer-а подключен к seq_item_port драйвера, т.е. export->port.

 

Извините конечно, но у вас каша в голове. Лучше почитайте user guide на TLM.

По факту не знаю что это за книжка, и что за порты они соединяют, но предположу, что в мониторе как и везде стоит обычный uvm_analysis_port а в scoreboard у них uvm_subscriber'ы, которые содержат "analysis_export" который по факту является imp портом с единственным write методом. А т.к. scoreboard используется не для сбора статистики как вы пишите, а для проверки отправленных и принятых данных, то обычно делают в самом scoreboard именные imp порты и соединяют их с портом монитора. Но в данной книжке видимо решили усложнить себе жизнь и обернули еще и в subscriber :)

[1891ВМ12Я 0]

Извините конечно, но у вас каша в голове. Лучше почитайте user guide на TLM

Это чистая правда, предпринимаю усилия для исправления. Читаю еще несколько книг :)

Спасибо за ответы.

[1891ВМ12Я 0]

Делаю тестовый пример для демонстрации внедрения UVM.

Есть класс на базе uvm_scoreboard. В нем есть два порта:

uvm_analysis_imp #(uart_item, uart_sb) transmitted;
uvm_analysis_imp #(uart_phy, uart_sb) received;

Специально сделал двух разных типов, чтобы можно было сделать две функции write - одна с типом uart_item, вторая с типом uart_phy. Но UVM жалуется, что нельзя дважды одну и ту же функцию определять.

Как же тогда принимать item-ы из разных источников, чтобы их сравнивать???

 

Пробовал с одной функцией write, с одним типом данных, т.е. всего-лишь один объект типа uvm_analysis_imp.

В итоге часть сообщений теряется, затем дублируются лишние старые. Явно работает не так как надо.

 

Я пытаюсь подключить два uvm_monitor к одному scoreboard (а почему бы и нет?). Если подключать только один монитор к scoreboard - то в обоих вариантах всё работает как надо.

 

UPDATE: В этом документе https://www.testandverification.com/DVClub/...es-Francois.pdf нашел вроде как решение. Позволяет иметь два и более write при помощи uvm_analysis_imp_decl. Но оно почему-то все равно пропускает первый и дублирует последний item в моем тесте. Видимо проблема в логике, а не самом UVM.

[lembrix 0]

Для этого используются суффиксы:

`uvm_analysis_imp_decl(_TX)
`uvm_analysis_imp_decl(_RX)
...
uvm_analysis_imp_TX #(uart_item, uart_sb) transmitted;
uvm_analysis_imp_RX #(uart_phy, uart_sb) received;
...
function void write_TX(...);
...
function void write_RX(...);
...

 

 

[1891ВМ12Я 0]

Для этого используются суффиксы: uvm_analysis_imp_decl()

Да, спасибо! Выше я нашел именно этот способ.

А то что я получал некорректные данные - нашел у себя фатальную ошибку. На этапе освоение UVM хочется грешить на библиотеку, а не на свои ошибки :) Теперь в общем-то всё отлично при помощи uvm_analysis_imp_decl.

 

[Koluchiy 0]

Офф.

 

Подскажите, где можно накопать нормальных примеров на UVM.

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

 

Прилагающиеся к библиотеке примеры, на мой дилетантский взгляд, УГ.

 

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

[1891ВМ12Я 0]

Еще вот вопрос такой: я сделал замечательный тест, по всему UVMовскому феншую, задействовав все мыслимые модули и классы, корректно завершаю по drop_objection. Но не могу понять одной вещи. Как и куда сообщать что данный тест failed или passed?

1) Вызывается check_phase и где мне смотреть, были ли вызовы uvm_error? Я должен сам подсчитывать события, где возникала ошибка?

2) Допустим, был хотя бы один uvm_error, что мне вызывать? uvm_failed/uvm_passed? Гуглю-яндексю, рою примеры - в них этот вопрос умалчивается. Я конечно могу формировать файл, как я делал это всегда, и добавить в нем строку "тест такой-то PASSED" или FAILED. Но быть может в UVM есть стандартный механизм репорта результата тестирования?

 

 

 

Подскажите, где можно накопать нормальных примеров на UVM.

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

Прилагающиеся к библиотеке примеры, на мой дилетантский взгляд, УГ.

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

Все примеры, которые я вижу в книгах - убогие. И поставляемые в комплекте еще хуже.

Я такой пример делаю сам. Могу поделиться потом. Только доделать бы.

[Кнкн 5]

Я понимаю процесс так:

в тестбенче имеется scoreboard, в нем сравнивается

реакция DUT с эталоном, при этом формируются

сообщения об ошибках, осуществляется их подсчет и т.п.

[lembrix 0]

Еще вот вопрос такой: я сделал замечательный тест, по всему UVMовскому феншую, задействовав все мыслимые модули и классы, корректно завершаю по drop_objection. Но не могу понять одной вещи. Как и куда сообщать что данный тест failed или passed?

1) Вызывается check_phase и где мне смотреть, были ли вызовы uvm_error? Я должен сам подсчитывать события, где возникала ошибка?

2) Допустим, был хотя бы один uvm_error, что мне вызывать? uvm_failed/uvm_passed? Гуглю-яндексю, рою примеры - в них этот вопрос умалчивается. Я конечно могу формировать файл, как я делал это всегда, и добавить в нем строку "тест такой-то PASSED" или FAILED. Но быть может в UVM есть стандартный механизм репорта результата тестирования?

Я, если что, тоже только недавно начал осваивать UVM. У меня в конце теста выводится такая сводка каким-то стандартным механизмом:

# --- UVM Report Summary ---
# 
# ** Report counts by severity
# UVM_INFO :   11
# UVM_WARNING :    6
# UVM_ERROR :    0
# UVM_FATAL :    0
# ** Report counts by id
# [DISP]     1
# [Questa UVM]     2
# [RNTST]     1
# [TEST_DONE]     1
# [TPRGED]     6
# [uvm_test_top.env]     4
# [uvm_test_top.env.in_agent.driver]     1
# [uvm_test_top.env.out_agent.driver]     1
# ** Note: $stop    : ../vip/tb_top.sv(97)
#    Time: 260012 ns  Iteration: 62  Instance: /tb_top

У вас такой нет? Кроме того, вывожу по привычке свой отчет вида "TEST PASSED/FAILED" и какие-то подсчитанные вручную параметры в extract_phase класса конкретного теста.

[_Ivan_ 0]

Офф.

 

Подскажите, где можно накопать нормальных примеров на UVM.

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

 

Прилагающиеся к библиотеке примеры, на мой дилетантский взгляд, УГ.

 

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

 

 

есть книга uvm primer

у нее есть гитхаб https://github.com/rdsalemi/uvmprimer

[favalligi 0]

По ошибкам.

 

Для подсчёта тех или иных ошибок в библиотеке UVM есть встроенный механизм uvm_report_server.

 

Обычно используется внутри report_phase:

        uvm_report_server r_srv;
        string status;
        r_srv  = uvm_report_server::get_server();

        if (r_srv.get_severity_count(UVM_FATAL) + r_srv.get_severity_count(UVM_ERROR) == 0)
            status = "TEST_PASSED";
        else
            status = "TEST_FAILED";

PS. Код для UVM-1.2 для 1.1d он будет отличатся т.к. был изменен принцип работы этого класса и uvm_root.

Изменено 9 августа, 2018 пользователем favalli

[1891ВМ12Я 0]

По ошибкам. Для подсчёта тех или иных ошибок в библиотеке UVM есть встроенный механизм uvm_report_server.

Вот, это уже гораздо ближе. Это удобно - не надо делать свою глобальную переменную с errors count. Хорошо.

 

Но вот куда потом этот status идет? Стандартного механизма не проглядывается? Не могу его найти. Я видел в других более простых фреймворках тестирования, там обязательно есть такая тема, что вот тест завершился, и очень важно сообщить если он failed или наоборот, passed. Там это не обошли вниманием.

 

Вот и UVM, симулятор можно завершать с отрицательным кодом ошибки. Или иной механизм сбора результатов теста.

 

UPD: Еще вижу в последних строка reporter [TEST_DONE], ощущается наличие некоей пост-тестовой подсистемы, в которую быть может как-то надо сообщить passed/failed.