Всем здравствуйте.

Столкнулся с задачей верификации проекта. Схема работы примерно следующая: прогрузка по "медленным" интерфейсам (I2C, SPI) настроек, сбор данных по быстрым интерфейсам (нечто вроде SPI на 40 МГц), форматирование этих данных и передача "наверх" так же по "быстрому" интерфейсу.

Для первоначальной прогрузки настроек по "медленным" интерфейсам необходимо порядка нескольких секунд, затем начинается "быстрая" работа, которая занимает ~2-8 ms. Мой компьютер не особо производительный, поэтому полноценно (с отрисовкой waveform) моделировать несколько секунд - это очень долго и печально. Так же первоначальная конфигурация не представляет большого интереса для валидации (прогрузил - увидел, что все правильно загрузилось - забыл про этот интерфейс). Все самое интересное для отладки скрывается за 1-2 секундами модельного времени.

Вопросы:
1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки)
2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)?

Использую Questa + SystemVerilog.

Если подкинете ссылки на какие-то буквари по данной области на русском - буду так же благодарен.

Спасибо.

вроде работало
Questa®Questa®SIM User’s Manual -> Chapter 10 Advanced Simulation Techniques -> Checkpointing and Restoring Simulations ->
The checkpointand restorecommands allow you to save and restore the simulation state within the same invocation of vsimor between vsimsessions.

Статейка (англ.)
 Want_a_Boost_in_your_Regression_Throughput.pdf ( 929.2 килобайт ) Кол-во скачиваний: 114

Сделать параметр "дебаг-релиз" и к нему соответственно два набора параметров. В режиме "релиз" тактовые по интерфейсам оставить "как должно быть в железе". А в "дебаг" - сделать тактовые по интерфейсам например в 4 клока... При этом время симулирования значительно сократится...

Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга.

Спасибо, точно буду пользовать.



Думал об этом. НО. В прошивке есть привязка к тактовым частотам (разрядности счетчиков и т.д.). Т.о., если я задеру частоты, скорее всего, что-то сломается. Причем, возможно, я этого даже не увижу (не пойму). Т.к. DUT написан не мной.



Думал об этом. Что-то вроде:
1. Проверить "медленную" часть;
2. Сделать слепок конфигурации и, при отладке "быстрой" части, загружать его за 1 такт в симуляторе;

Но это значит - лезть в тестируемую прошивку. Чего очень не хочется.

Добавлю...
И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части...



Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д....

Понятно, как НАДО. Но сделано так. И лезть в немаленький и абсолютно чужой проект не хочется от слова совсем - черт его знает, что там умрет, если я разрядности подкручу.