[kirill70674 4]

Здравствуйте, коллеги 
Попал ко мне на стол VIP от Cadence под названием CDN_AXI.
Подключил его классически: интерфейс+конфиг+агент+sequence.
Но сигнал WVALID ведёт себя неадекватно, т.е. переводится в единицу и так в ней и висит до конца симуляции...
VIP настроен на полный AXI4. У всех транзакций burst  законстрейнен до длины 1.
Бывало ли такое у кого и как лечится?

[one_eight_seven 0]

С чего вы взяли, что это неадекватно? Да и вообще, кто же поведение AXI оценивает по одному сигналу? Вы же сами пишете: "У всех транзакций". Чтобы передать хотя бы одну транзакцию нужно перевести WVALID в 1 и, если вы до конца симуляции не поднимете WREADY, она и должна оставаться в единице.

У вас как? сколько транзакций? Где вейвформы, в конце-концов?

Edited November 14 by one_eight_seven

[kirill70674 4]

WREADY как и положено взводится на 1 такт DUTом и опускается в 0.

Во всей очереди только 1 транзакция. После `uvm_do_with() идёт get_response(rsp). На get_response(rsp) очередь и зависает, т.е. если бы и были другие транзакции - они бы не прошли.

[kirill70674 4]

Проблема определена. И относится она к тайм-слотам.
Сигналы *VALID и *READY наблюдаются VIP'ом в том же тайм-слоте, где они меняются. Изменение *READY соответственно происходит раньше, чем VIP успевает считать его предыдущее значение. Далее VIP, судя по всему, ломается. Помогла задержка *READY на долю нс. Соответственно проблемный тайм-слот пройден и VIP считывает ожидаемое значение сигнала *READY.

Есть ли более элегантное решение?

[andrew_b 12]

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

 

[kirill70674 4]

4 часа назад, andrew_b сказал:

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

 

Сигналы (грубо говоря) формирует Агент (не Mr.Smith, а UVM-агент).

С синхронными сигналами такое вполне случается. Собственно данный топик это иллюстрирует.

Яркий пример это какая-нибудь BFM для чтения какой-нибудь шины: Если по одному фронту и читать с помощью BFM и писать из DUT, то возникнет race-condition. И одним из решений является чтение по заднему фронту. Но это в моём случае не применимо, т.к. вся имплементация BFM и всего что к ней прилагается скрыта в VIP.

[one_eight_seven 0]

Это называется логические гонки. Неконсистентность в бокирующих/неблокирующих присваиваниях.

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

Edited November 15 by one_eight_seven

[kirill70674 4]

1 час назад, one_eight_seven сказал:

переписывал интерфейсы сам, включая в них clocking.

Этим же и я озадачился.

Добавил clocking block в интерфейс для установки input and output skew. По какой то причине добавление такового блока не оказывает решительно никакого эффекта ни на входы ни на выходы.
В чём может быть проблема?

[one_eight_seven 0]

Например в том, что вы их не используете.

[kirill70674 4]

4 часа назад, one_eight_seven сказал:

Например в том, что вы их не используете.

Смешно. Их VIP не использует, а не я, как выяснилось...

[one_eight_seven 0]

Почему смешно? в VIP я clocking вообще у cadence не видел, по крайней мере когда с ними работал. Поэтому, clocking писал сам, соотвественно и использование - тоже было на мне.

[kirill70674 4]

12 часов назад, one_eight_seven сказал:

Почему смешно? в VIP я clocking вообще у cadence не видел, по крайней мере когда с ними работал. Поэтому, clocking писал сам, соотвественно и использование - тоже было на мне.

Вы имеете в виду использование clocking ЗА пределами интерфейса?

Ведь в чём соль: т.к. сам VIP clocking не использует, соответственно от создания такового блока самому VIPу ни холодно ни жарко. Т.о., единственная выгода, которую можно извлечь из создания clocking внутри интерфейса - это тактировать сигналы с помощью него из вне интерфейса. Или проще говоря, создание wrapper над интерфейсом, в котором все сигналы будут тактироваться от clocking.

Пример:

interface axi4_wrap(
  input aclk,
  ...,
  input awready,
  ...
  );
logic awready_dly;

clocking cb @(posedge aclk);
	default input #1step;

	input awready;
	...
endclocking: cb

initial forever begin
    @(cb);
	...
    awready_dly = awready;
	...
end
  
axi4_vip_intf axi4_if(
	.aclk(aclk),
  	...,
    .awready(awready_dly),
    ...
);
  
endinterface: axi4_wrap

 

[one_eight_seven 0]

Вы упускаете момент присваивания сигналов, которые идут из DPI. Если выбудете делать присваивания из/в этих DPI сигналов с использованием clocking, то он будет работать.

[kirill70674 4]

1 минуту назад, one_eight_seven сказал:

Вы упускаете момент присваивания сигналов, которые идут из DPI. Если выбудете делать присваивания из/в этих DPI сигналов с использованием clocking, то он будет работать.

Да, этот момент в примере опущен. Кстати про него: остальная часть блока initial выглядит так:

initial forever begin
    @(cb);
	...
    awready_dly = awready;
	...
    cb.awvalid <= awvalid_dly; // awvalid_dly подключён к VIP интерфейсу
	...
end

Т.е. выходы интерфейса VIPа присваиваются выходам обёртки с помощью неблокирующего присваивания. Использование этого типа присваивания - необходимое условие для успешной компиляции.

Понять не могу: почему запись cb.awvalid = awvalid_dly выдаёт compile-time ошибку типа: "Cannot write to clocking block signal"?

 

[one_eight_seven 0]

Так список переменных в clocking block обязан использовать неблокирующее присваивание. Это же синхронная конструкция. Кроме того, у симулятора же есть его система помощи, расшифровки сообщений, и т.п.
Но вообще, пункт стандарта Syncronous Drives именно это и описывает.