|
|
|
UVM port export, направление |
|
|
|
Jun 22 2018, 12:10
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
В книге "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.
--------------------
|
|
|
|
|
Jun 27 2018, 11:05
|
Участник
Группа: Участник
Сообщений: 25
Регистрация: 16-04-12
Пользователь №: 71 387
|
Цитата(AVR @ Jun 22 2018, 15:10) В книге "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
|
|
|
|
|
Aug 7 2018, 11:51
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Делаю тестовый пример для демонстрации внедрения 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.
--------------------
|
|
|
|
|
Aug 7 2018, 14:16
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 13-04-17
Из: Зеленоград
Пользователь №: 96 508
|
Для этого используются суффиксы: Код `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(...); ...
|
|
|
|
|
Aug 8 2018, 10:51
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Цитата(lembrix @ Aug 7 2018, 17:16) Еще вот вопрос такой: я сделал замечательный тест, по всему UVMовскому феншую, задействовав все мыслимые модули и классы, корректно завершаю по drop_objection. Но не могу понять одной вещи. Как и куда сообщать что данный тест failed или passed?1) Вызывается check_phase и где мне смотреть, были ли вызовы uvm_error? Я должен сам подсчитывать события, где возникала ошибка? 2) Допустим, был хотя бы один uvm_error, что мне вызывать? uvm_failed/uvm_passed? Гуглю-яндексю, рою примеры - в них этот вопрос умалчивается. Я конечно могу формировать файл, как я делал это всегда, и добавить в нем строку "тест такой-то PASSED" или FAILED. Но быть может в UVM есть стандартный механизм репорта результата тестирования? Цитата(Koluchiy @ Aug 8 2018, 12:28) Подскажите, где можно накопать нормальных примеров на UVM. Ну в смысле в виде набора файлов, а не из книг выцеплять. Прилагающиеся к библиотеке примеры, на мой дилетантский взгляд, УГ. Что я понимаю под нормальными примерами: где есть нормальный синтезируемый модуль (со входами, выходами, регистрами, интерфейсами и т.п.), который подлежит верификации.
Все примеры, которые я вижу в книгах - убогие. И поставляемые в комплекте еще хуже. Я такой пример делаю сам. Могу поделиться потом. Только доделать бы.
--------------------
|
|
|
|
|
Aug 9 2018, 07:03
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 13-04-17
Из: Зеленоград
Пользователь №: 96 508
|
Цитата(AVR @ Aug 8 2018, 13:51) Еще вот вопрос такой: я сделал замечательный тест, по всему 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 класса конкретного теста.
|
|
|
|
|
Aug 9 2018, 07:47
|
fpga designer
Группа: Свой
Сообщений: 613
Регистрация: 20-04-08
Из: Зеленоград
Пользователь №: 36 928
|
Цитата(Koluchiy @ Aug 8 2018, 12:28) Офф.
Подскажите, где можно накопать нормальных примеров на UVM. Ну в смысле в виде набора файлов, а не из книг выцеплять.
Прилагающиеся к библиотеке примеры, на мой дилетантский взгляд, УГ.
Что я понимаю под нормальными примерами: где есть нормальный синтезируемый модуль (со входами, выходами, регистрами, интерфейсами и т.п.), который подлежит верификации. есть книга uvm primer у нее есть гитхаб https://github.com/rdsalemi/uvmprimer
--------------------
|
|
|
|
|
Aug 9 2018, 08:38
|
Участник
Группа: Участник
Сообщений: 25
Регистрация: 16-04-12
Пользователь №: 71 387
|
По ошибкам. Для подсчёта тех или иных ошибок в библиотеке 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 - Aug 9 2018, 08:39
|
|
|
|
|
Aug 9 2018, 09:36
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Цитата(favalli @ Aug 9 2018, 11:38) По ошибкам. Для подсчёта тех или иных ошибок в библиотеке UVM есть встроенный механизм uvm_report_server. Вот, это уже гораздо ближе. Это удобно - не надо делать свою глобальную переменную с errors count. Хорошо. Но вот куда потом этот status идет? Стандартного механизма не проглядывается? Не могу его найти. Я видел в других более простых фреймворках тестирования, там обязательно есть такая тема, что вот тест завершился, и очень важно сообщить если он failed или наоборот, passed. Там это не обошли вниманием. Вот и UVM, симулятор можно завершать с отрицательным кодом ошибки. Или иной механизм сбора результатов теста. UPD: Еще вижу в последних строка reporter [TEST_DONE], ощущается наличие некоей пост-тестовой подсистемы, в которую быть может как-то надо сообщить passed/failed.
--------------------
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|