Всем здравствуйте.
Столкнулся с задачей верификации проекта. Схема работы примерно следующая: прогрузка по "медленным" интерфейсам (I2C, SPI) настроек, сбор данных по быстрым интерфейсам (нечто вроде SPI на 40 МГц), форматирование этих данных и передача "наверх" так же по "быстрому" интерфейсу.
Для первоначальной прогрузки настроек по "медленным" интерфейсам необходимо порядка нескольких секунд, затем начинается "быстрая" работа, которая занимает ~2-8 ms. Мой компьютер не особо производительный, поэтому полноценно (с отрисовкой waveform) моделировать несколько секунд - это очень долго и печально. Так же первоначальная конфигурация не представляет большого интереса для валидации (прогрузил - увидел, что все правильно загрузилось - забыл про этот интерфейс). Все самое интересное для отладки скрывается за 1-2 секундами модельного времени.
Вопросы:
1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки)
2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)?
Использую Questa + SystemVerilog.
Если подкинете ссылки на какие-то буквари по данной области на русском - буду так же благодарен.
Спасибо.
Полная версия этой страницы: Симуляция длительных процессов
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Среды разработки - обсуждаем САПРы
Цитата(nice_vladi @ May 3 2018, 15:08) 
Использую 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.
Цитата(nice_vladi @ May 3 2018, 11:08)
1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки)
Статейка (англ.)
Нажмите для просмотра прикрепленного файла
Цитата(nice_vladi @ May 3 2018, 11:08)
Вопросы:
1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки)
2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)?
1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки)
2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)?
Сделать параметр "дебаг-релиз" и к нему соответственно два набора параметров. В режиме "релиз" тактовые по интерфейсам оставить "как должно быть в железе". А в "дебаг" - сделать тактовые по интерфейсам например в 4 клока... При этом время симулирования значительно сократится...
Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга.
Цитата(des00 @ May 4 2018, 00:54)
вроде работало
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.
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.
Спасибо, точно буду пользовать.
Цитата(iosifk @ May 4 2018, 07:29)
Сделать параметр "дебаг-релиз" и к нему соответственно два набора параметров. В режиме "релиз" тактовые по интерфейсам оставить "как должно быть в железе". А в "дебаг" - сделать тактовые по интерфейсам например в 4 клока... При этом время симулирования значительно сократится...
Думал об этом. НО. В прошивке есть привязка к тактовым частотам (разрядности счетчиков и т.д.). Т.о., если я задеру частоты, скорее всего, что-то сломается. Причем, возможно, я этого даже не увижу (не пойму). Т.к. DUT написан не мной.
Цитата(lembrix @ May 4 2018, 07:37)
Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга.
Думал об этом. Что-то вроде:
1. Проверить "медленную" часть;
2. Сделать слепок конфигурации и, при отладке "быстрой" части, загружать его за 1 такт в симуляторе;
Но это значит - лезть в тестируемую прошивку. Чего очень не хочется.
Цитата(lembrix @ May 4 2018, 10:37)
Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга.
Добавлю...
И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части...
Цитата(nice_vladi @ May 4 2018, 11:01)
Думал об этом. НО. В прошивке есть привязка к тактовым частотам (разрядности счетчиков и т.д.). Т.о., если я задеру частоты, скорее всего, что-то сломается. Причем, возможно, я этого даже не увижу (не пойму). Т.к. DUT написан не мной.
Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д....
Цитата(iosifk @ May 4 2018, 09:04)
Добавлю...
И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части...
Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д....
И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части...
Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д....
Понятно, как НАДО. Но сделано так. И лезть в немаленький и абсолютно чужой проект не хочется от слова совсем - черт его знает, что там умрет, если я разрядности подкручу.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.