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

Как достоверно проверить тайминги?

Наверняка такие вопросы возникали у многих, но сходу ничего найти не удалось. Так что звиняйте, если боян.

Есть кристалл (Spartan 3), на котором работает тактируемый модуль с математикой. Необходимо подобрать максимальную стабильную тактовую частоту и тайминги для этого модуля. С учётом возможных температурных отклонений, отклонений в серии и.т.д. Знает ли кто-нибудь, как это правильно делать? Может быть, где-то статьи толковые на эту тему есть?

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


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

Наверняка такие вопросы возникали у многих, но сходу ничего найти не удалось. Так что звиняйте, если боян.

Есть кристалл (Spartan 3), на котором работает тактируемый модуль с математикой. Необходимо подобрать максимальную стабильную тактовую частоту и тайминги для этого модуля. С учётом возможных температурных отклонений, отклонений в серии и.т.д. Знает ли кто-нибудь, как это правильно делать? Может быть, где-то статьи толковые на эту тему есть?

А чем post place & route simulation не устраивает?

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


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

В принципе, устраивает, если полученные там результаты - гарантированные. Чтобы не получилось, что я поставлю максимальную частоту, проверю на нескольких устройствах, а где-то на серии потом будут обнаружены проблемы.

Скажем так. Предельную частоту модуля выдаёт ещё синтезатор (93 Мгц). Но реально на такой частоте модуль почему-то работать не хочет.

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


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

Предельную частоту модуля выдаёт ещё синтезатор (93 Мгц). Но реально на такой частоте модуль почему-то работать не хочет.

Синтезатору как раз верить нельзя. Это число "для справки", поскольку не учитывает задержек на распространение сигнала при его размещении в кристалле.

Более правильный подход: описать констрейны и смотреть в Place & Route report выполнились они или не выполнились.

А после этого провести post place & route simulation.

 

IMHO ничего более гарантированного, чем post place & route simulation (до проверки в железе) придумать нельзя. А насколько качественный testbench написал разработчик - это уже другой вопрос :)

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


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

Вообще-то говоря, синтезаторы и place-and-route tool действуют наоборот - они смотрят, какую частоту задал разработчик, и пытаются ее обеспечить. Если задать очень низкую частоту - автоматом может получится рабочая существенно выше, но она не будет максимальной. Вот когда вы попросите скажем 100 Мгц, а вам после размещения отрапортуют о 90 - тогда можно считать, что это максимальная частота, и надо переписывать дизайн для достижения 100 Мгц - смотреть critical path и т.д.

А для гарантии, если надо в железе 100 Мгц, задайте с запасом, например 105 или 110.

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


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

Вот когда вы попросите скажем 100 Мгц, а вам после размещения отрапортуют о 90 - тогда можно считать, что это максимальная частота, и надо переписывать дизайн для достижения 100 Мгц - смотреть critical path и т.д.

 

Не всегда задав заведомо большую частоту можно получить в отчете максимальную частоту для проекта.

 

У xilinx есть скрипт XPLORER, который позволяет в авто-режиме разложить проект несколько раз с различными параметрами и в результате получить наиболее оптимальное их сочетание для проекта.

 

Ну и конечно, запас по частоте нужно иметь, например задав для проекта с микроблазом некоторую чатоту (практически максмальную для проекта) я не получил ошибок таймингов, запас времени для данной частоты по отчету составлял не более 10 пик (для одного из путей в ядре проца), но ядро микроблаза не завелось (остальная логика функционировала нормально), чуть снизив частоту проект запустился (частоту для проверки менял DCMом). Теперь я всегда задаю ограничения с не менее 5% запасом.

Изменено пользователем denisys

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


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

Теперь я всегда задаю ограничения с не менее 5% запасом.

Вообще-то времянка считается по-максимуму обычно, и в запасе необходимости нет, если учтено все. А неучтенными обычно остается дрожание тактовой частоты, которое для Xilinx DCM CLKFX может достигать наносекунды, что есть 10% от 100 МГц, а также скважность (что важно для DDR проектов). Поэтому, если в UCF это учтено - анализ будет проведен с учетом, и запаса от результатов анализа можно уже и не иметь.

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


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

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

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

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

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

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

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

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

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

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