Я при обращении по AXI делал счётчик, который инкрементировал или декрементировал по grant и bresp. Нельзя точно сказать когда данные будут в DDR пока значения счётчика не будут равны нулю. Либо считать максимально допустимое значение счётчика, при заранее известном объёме передаваемых данных.
Если используется port_id, то bresp также обладает id и порядок записи с разными id в этом случае не гарантирован.
После возврата bresp мастеру данные обязаны быть в DDR или контроллер сам решает это на своём уровне, но если результат отличается, то имплементация отличается от стандарта.
Как вариант, переходите на OCP, там таких проблем нет.
Я не сильно силён в PCI, но разве доступ к памяти не подразумевает, что данные могут быть приняты и переданы с прерываниями. Потом у DDR есть refresh, в течении которого он как бы не доступен.
Да. Если у вас есть нагрузка на выход, то путь сигнала на setup рассчитывается в 2 тактовых сигнала. Т.е. по сути тактовым у вас будет делитель частоты на 2, причем зависимый от основного. Но hold так и останется 1.
Не проще ли в середине вставить регистр для временного хранения, с multycycle (если это не входной сигнал с длинной выдержкой) внутри проекта возможны проблемы.
Каждому свое, в свое время привлек тем, что первым из временных диаграмм может сам показывать (по клику на событие на временной диаграмме) причину изменения сигнала в коде, перепрыгивая по иерархии проекта, при этом в коде также отображается текущее значение сигнала (но это я и у каденса вроде видел). Много разных фич, как для дебага в целом, так и на уровне гейтов. С ним нужно поработать какое-то время и потом уже с него не слезешь.
Ну вот у нас как-то так. Симулятор от Cadence, дебаггер от Synopsys, причем эта пара была еще тогда когда он им не принадлежал.
P.s. меня терзают смутные сомнения, а тот ли verdi ?
Не путаю, причем тут vcs, подключаете pli и делаете dump напрямую в fsdb. И причем тут spyglass? Найдите мне хотя бы одно упоминание про spyglass в брошуре о verdi https://www.synopsys.com/verification/debug/verdi.html. Уберите из него все лишнее и оставьте только IDE
По сравнению с simvision это как Автоваз и Мерседес, он очень удобен, вы наверное просто с ним плотно не работали.
В дополнение:
Мне кажется импорт структур лучше производить в заголовке модуля, что-то вроде:
module arp_vlg_tx
import arp_vlg_pkg::*;
#(parameter ...)
(input logic ...
);
Причина: после импорта package будет проинициализирован во всех файлах после первого. В таком случае возможен вариант перезаписи уже существующих структур данных. Проще это делать внутри модуля, но тогда порты не смогут использовать готовые структуры. Решением как раз будет являться закидываением его в заголовок модуля, такти образом он будет существовать только внутри данного конкретного модуля.
P.S. Добавьте assertion и формальной верификации. Это покажет работу с гораздо лучшей стороны и поможет самим верифицировать проект, без привлечения тестовых последовательностей.
Прям завидно так, человек растёт и расширяет области. А в моей реальности (ASIC), более половины времени уходит на верификацию, интеграцию текущих и саппорт уже сделанных проектов.
Недавно у каденса было, если порт является константой, то рекомендуют его как раз через параметр задавать. Хотя подтяжку к земле трудно назвать константой.
Маловероятно. Параметры обычно подставляются во время компиляции проекта, по крайней мере, так об этом пишут мануалы на синтезаторы.
Но если скан цепочка уже проведена, то удалить конечно её уже проблематично.
