Epikur 0 13 июня, 2008 Опубликовано 13 июня, 2008 · Жалоба Наверняка такие вопросы возникали у многих, но сходу ничего найти не удалось. Так что звиняйте, если боян. Есть кристалл (Spartan 3), на котором работает тактируемый модуль с математикой. Необходимо подобрать максимальную стабильную тактовую частоту и тайминги для этого модуля. С учётом возможных температурных отклонений, отклонений в серии и.т.д. Знает ли кто-нибудь, как это правильно делать? Может быть, где-то статьи толковые на эту тему есть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o-henry 0 13 июня, 2008 Опубликовано 13 июня, 2008 · Жалоба Наверняка такие вопросы возникали у многих, но сходу ничего найти не удалось. Так что звиняйте, если боян. Есть кристалл (Spartan 3), на котором работает тактируемый модуль с математикой. Необходимо подобрать максимальную стабильную тактовую частоту и тайминги для этого модуля. С учётом возможных температурных отклонений, отклонений в серии и.т.д. Знает ли кто-нибудь, как это правильно делать? Может быть, где-то статьи толковые на эту тему есть? А чем post place & route simulation не устраивает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Epikur 0 13 июня, 2008 Опубликовано 13 июня, 2008 · Жалоба В принципе, устраивает, если полученные там результаты - гарантированные. Чтобы не получилось, что я поставлю максимальную частоту, проверю на нескольких устройствах, а где-то на серии потом будут обнаружены проблемы. Скажем так. Предельную частоту модуля выдаёт ещё синтезатор (93 Мгц). Но реально на такой частоте модуль почему-то работать не хочет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o-henry 0 13 июня, 2008 Опубликовано 13 июня, 2008 · Жалоба Предельную частоту модуля выдаёт ещё синтезатор (93 Мгц). Но реально на такой частоте модуль почему-то работать не хочет. Синтезатору как раз верить нельзя. Это число "для справки", поскольку не учитывает задержек на распространение сигнала при его размещении в кристалле. Более правильный подход: описать констрейны и смотреть в Place & Route report выполнились они или не выполнились. А после этого провести post place & route simulation. IMHO ничего более гарантированного, чем post place & route simulation (до проверки в железе) придумать нельзя. А насколько качественный testbench написал разработчик - это уже другой вопрос :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gate 0 13 июня, 2008 Опубликовано 13 июня, 2008 · Жалоба Вообще-то говоря, синтезаторы и place-and-route tool действуют наоборот - они смотрят, какую частоту задал разработчик, и пытаются ее обеспечить. Если задать очень низкую частоту - автоматом может получится рабочая существенно выше, но она не будет максимальной. Вот когда вы попросите скажем 100 Мгц, а вам после размещения отрапортуют о 90 - тогда можно считать, что это максимальная частота, и надо переписывать дизайн для достижения 100 Мгц - смотреть critical path и т.д. А для гарантии, если надо в железе 100 Мгц, задайте с запасом, например 105 или 110. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Epikur 0 16 июня, 2008 Опубликовано 16 июня, 2008 · Жалоба Ок, спасибо. Буду пробовать так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
denisys 0 16 июня, 2008 Опубликовано 16 июня, 2008 (изменено) · Жалоба Вот когда вы попросите скажем 100 Мгц, а вам после размещения отрапортуют о 90 - тогда можно считать, что это максимальная частота, и надо переписывать дизайн для достижения 100 Мгц - смотреть critical path и т.д. Не всегда задав заведомо большую частоту можно получить в отчете максимальную частоту для проекта. У xilinx есть скрипт XPLORER, который позволяет в авто-режиме разложить проект несколько раз с различными параметрами и в результате получить наиболее оптимальное их сочетание для проекта. Ну и конечно, запас по частоте нужно иметь, например задав для проекта с микроблазом некоторую чатоту (практически максмальную для проекта) я не получил ошибок таймингов, запас времени для данной частоты по отчету составлял не более 10 пик (для одного из путей в ядре проца), но ядро микроблаза не завелось (остальная логика функционировала нормально), чуть снизив частоту проект запустился (частоту для проверки менял DCMом). Теперь я всегда задаю ограничения с не менее 5% запасом. Изменено 16 июня, 2008 пользователем denisys Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 16 июня, 2008 Опубликовано 16 июня, 2008 · Жалоба Теперь я всегда задаю ограничения с не менее 5% запасом. Вообще-то времянка считается по-максимуму обычно, и в запасе необходимости нет, если учтено все. А неучтенными обычно остается дрожание тактовой частоты, которое для Xilinx DCM CLKFX может достигать наносекунды, что есть 10% от 100 МГц, а также скважность (что важно для DDR проектов). Поэтому, если в UCF это учтено - анализ будет проведен с учетом, и запаса от результатов анализа можно уже и не иметь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться