Хороший способ доступа к пути интерфейса

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

Поэтому в моем коде мне приходится делать несколько форсировок, так как один и тот же провод управляется tb и другой частью дизайна. В результате у меня есть много принудительных утверждений, подобных этому:

force TOP.u_proto_mc_top.gtx_rx_reset = TOP.u_proto_mc_top.u_GTX_RXB.gtxMaster_itf_inst.rstn;

force TOP.u_proto_mc_top.gtx_tx_reset = TOP.u_proto_mc_top.u_GTX_RXB.gtxMaster_itf_inst.txstn;

Поэтому я просто копирую и вставляю один и тот же путь к интерфейсу снова и снова, я имею в виду этот путь: TOP.u_proto_mc_top.u_GTX_RXB.gtxMaster_itf_inst

Каждый раз, когда мне нужно форсировать сигнал интерфейса, я должен копировать и вставлять этот путь. Это некрасиво для меня. Может кто-нибудь предложить другое решение этой проблемы, потому что я не копирую/вставляю путь к интерфейсу снова и снова.

Спасибо


system-verilog uvm
person haykp    schedule 03.04.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Быстрые решения используют текстовый макрос.

`define uTOP TOP.u_proto_mc_top 
`define GTXMaster `uTOP.u_GTX_RXB.gtxMaster_itf_inst
force `uTOP.gtx_tx_reset = `GTXMaster.txstn;
person dave_59    schedule 03.04.2017
comment
У меня есть модуль GTX в середине моей иерархии, мой тестовый стенд сначала тестирует канал GTX, отправляя некоторые данные через этот модуль GTX, после того, как убедился, что канал GTX включен, он запускает тест верхнего уровня. назначить mc_rx_update = rx_reg_we | rx_обновление; GTX u_GTX_RXB ( .update (mc_rx_update), .. ) Итак, у меня есть интерфейс, который содержит все порты GTX. Затем я привязываю этот интерфейс к модулю GTX. Здесь, если мы возьмем сигнал обновления, с одной стороны он управляется моим модулем драйвера, с другой стороны, «mc_rx_update» также пытается управлять им. В основном «mc_rx_update» — это X. - person haykp; 04.04.2017
comment
В результате я получаю 2 разных драйвера в одной сети, отсюда и Xs. Чтобы решить эту проблему, я создаю задачи force_signal и release_signal, которые заставят «mc_rx_update» подключаться к портам интерфейса. - person haykp; 04.04.2017

arrow_upward
1
arrow_downward

Вместо этого вы можете использовать uvm_hdl_read() и uvm_hdl_force()? Эти встроенные функции UVM принимают строку в качестве входного аргумента для пути hdl.

string if_path = "TOP.u_proto_mc_top.u_GTX_RXB.gtxMaster_itf_inst";
string top_path = "TOP.u_proto_mc_top";
uvm_hdl_data_t val;

uvm_hdl_read({if_path,".rstn"}, val);
uvm_hdl_force({top_path, ".gtx_rx_reset", val);

uvm_hdl_read({path,".txstn"}, val);
uvm_hdl_force({top_path, ".gtx_tx_reset", val);
person hevangel    schedule 23.07.2017
comment
хм, а какая польза от этого синтаксиса? дает ли uvm_hdl_force какие-либо полезные опции пользователю - person haykp; 24.07.2017
comment
Преимущество заключается в том, что hdl_path внутри кавычек — это просто текстовая строка. Вы можете построить другую строку или привязать к другой иерархии DUT во время выполнения. Определение пути hdl с помощью текстового макроса жестко запрограммировано во время компиляции и затрудняет повторное использование кода. - person hevangel; 05.08.2017