Как контролировать порядок абонентов порта анализа UVM?

У меня есть порт анализа, подключенный к 3 табло. Когда запись выполняется в порт анализа, подписчики (табло) вызываются в определенном порядке. Но я хочу, чтобы они вызывались в другом порядке.

Пример практического использования явного упорядочивания следующий. Одно табло ведет только журнал, поэтому оно должно вызываться первым. Другое табло выполняет очень простые проверки более низкого уровня, поэтому его следует называть вторым. Третье табло выполняет очень сложные проверки более высокого уровня, поэтому его следует называть последним.

Фрагмент SV:

sb1 = scoreboard_1::type_id::create("sb1", null);
sb2 = scoreboard_2::type_id::create("sb2", null);
sb3 = scoreboard_3::type_id::create("sb3", null);

// Connect analysis port to scoreboard
m_ap = new("ap", null);
m_ap.connect(sb2.m_imp);
m_ap.connect(sb3.m_imp);
m_ap.connect(sb1.m_imp);
m_ap.resolve_bindings();

// Write
m_ap.write(10);

Токовый выход:

# UVM_INFO design.sv(15) @ 0: sb1 [write] scoreboard_1
# UVM_INFO design.sv(32) @ 0: sb2 [write] scoreboard_2
# UVM_INFO design.sv(49) @ 0: sb3 [write] scoreboard_3

Как контролировать порядок вызова абонентов? Я хочу, чтобы они были в таком порядке:

  • табло_3
  • табло_2
  • табло_1

Пример кода на EDA Playground: http://www.edaplayground.com/x/2zQ


system-verilog uvm
person Victor Lyuboslavsky    schedule 09.04.2014    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Провайдеры для порта анализа оказываются внутри ассоциативного массива строк, когда вы вызываете connect(). Выполнив foreach на нем (см. resolve_bindings()), вы получите элементы в лексикографическом порядке. Это работает только из-за текущей реализации UVM; будущая реализация может решить использовать ассоциативные массивы объектов, для которых не определен порядок.

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

Если вы хотите убедиться, что ваши записи выполняются в определенном порядке, вы должны обеспечить это с помощью структуры тестовой среды: либо иметь табло верхнего уровня, подключенное к вашей AP, которое делегирует вызовы в определенном порядке, либо объединить ваши табло в цепочку, чтобы табло1 делает это, а затем записывает на табло2, которое делает это, а затем записывает на табло3.

person Tudor Timi    schedule 09.04.2014
comment
Наличие делегата на табло высшего уровня кажется беспорядком. В этом случае было бы проще создать свой собственный uvm_analysis_port, который поддерживает подписчиков в зарегистрированном порядке. - person Victor Lyuboslavsky; 09.04.2014

arrow_upward
1
arrow_downward

В основных симуляторах (ModelSim / Questa, INCISIV и VCS) порядок ассоциативных массивов строк в uvm_port_base.svh является алфавитным. Это означает, что порядок записи в порт анализа соответствует алфавитному порядку имен абонентов.

Чтобы подписчик писал в запрошенном порядке, измените имена примерно на:

sb1 = scoreboard_1::type_id::create("-sb1", null);
sb2 = scoreboard_2::type_id::create("--sb2", null);
sb3 = scoreboard_3::type_id::create("---sb3", null);

И вы увидите, что результат изменится на:

# UVM_INFO design.sv(49) @ 0: ---sb3 [write] scoreboard_3
# UVM_INFO design.sv(32) @ 0: --sb2 [write] scoreboard_2
# UVM_INFO design.sv(15) @ 0: -sb1 [write] scoreboard_1

Исправление на площадке EDA: http://www.edaplayground.com/x/3bf

person Victor Lyuboslavsky    schedule 10.04.2014
comment
Вы полагаетесь на то, что соединения хранятся в ассоциативном массиве строкового индекса. Для этого в стандарте указывается, что порядок, в котором элементы индексируются, является лексикографическим. Если реализация UVM изменится в будущем выпуске и они решат использовать ассоциативные массивы классов, вы больше не сможете полагаться на этот порядок. - person Tudor Timi; 16.04.2014

arrow_upward
0
arrow_downward

Порядок, в котором вызываются абоненты, «не определен»; то есть при переходе между симуляторами порядок может измениться. Следовательно, вы должны разработать свой код так, чтобы он работал, не полагаясь на порядок.

Если порядок важен, сделайте его явным в коде (то есть объедините свое поведение в одно более крупное табло, которое затем делегирует по порядку). Не полагайтесь на недокументированное поведение.

person Paul S    schedule 15.04.2014
comment
Порядок в настоящее время не «неопределенный», это лексикографический порядок полных имен (возвращенных get_full_name()) подписчиков. - person Tudor Timi; 16.04.2014
comment
Это действительно где-то в документации, потому что я не могу ее найти? - person Paul S; 16.04.2014
comment
Этого нет в документации, но я просмотрел код, и реализации интерфейса анализа хранятся в ассоциативном массиве и индексируются get_full_name(). LRM утверждает, что ассоциативные массивы, индексируемые строкой, повторяются в лексикографическом порядке. Все это в любом случае является деталью реализации UVM, которая может измениться, поэтому для всех намерений и целей я бы предположил, что порядок не определен. - person Tudor Timi; 16.04.2014
comment
Да, отсутствие в документации означает, что это деталь реализации, и на нее не следует полагаться. Для меня это «не определено». - person Paul S; 16.04.2014