Перейти к содержанию

    

UVM port export

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

post-10008-1529669080_thumb.png

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В книге "Getting Started with UVM. A Beginner's Guide" есть такой фрагмент:

post-10008-1529669080_thumb.png

Мне непонятно - это ошибка? По моему представлению, в терминологии 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 :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Извините конечно, но у вас каша в голове. Лучше почитайте user guide на TLM

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Делаю тестовый пример для демонстрации внедрения 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

`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(...);
...

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Для этого используются суффиксы: uvm_analysis_imp_decl()

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Офф.

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

 

 

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Еще вот вопрос такой: я сделал замечательный тест, по всему 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 класса конкретного теста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Офф.

 

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

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

 

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

 

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

 

 

есть книга uvm primer

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По ошибкам.

 

Для подсчёта тех или иных ошибок в библиотеке 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.

Изменено пользователем favalli

Поделиться сообщением


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

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти