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

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

В принципе, устраивает, если полученные там результаты - гарантированные. Чтобы не получилось, что я поставлю максимальную частоту, проверю на нескольких устройствах, а где-то на серии потом будут обнаружены проблемы.
Скажем так. Предельную частоту модуля выдаёт ещё синтезатор (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.

Ок, спасибо. Буду пробовать так.

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

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

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

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