Перейти к содержанию
    

Симуляция длительных процессов

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

 

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

 

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

 

Вопросы:

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

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

 

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

 

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

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Использую 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Статейка (англ.)

Want_a_Boost_in_your_Regression_Throughput.pdf

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопросы:

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вроде работало

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.

 

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

 

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

 

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

 

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

 

Думал об этом. Что-то вроде:

1. Проверить "медленную" часть;

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Добавлю...

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

 

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добавлю...

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...