Ещё во время обучения в ВУЗе, проектируя различные тестовые безделушки и выполняя лабораторные работы по цифровой схемотехнике, я попадал в ситуации, когда вроде бы корректный несколько раз перепроверенный проект отказывается работать «в железе». В то время, на заре изучения программируемой логики, мне как-то очень редко доводилось добираться до последних пунктов Design Flow, в чем, вероятно, и крылась беда. Если я нечаянным щелчком мыши открывал Timing Analyzer, то после нескольких секунд беглого просмотра становилось скучно, и я возвращался к издевательствам над отладочной платой и сочинял новые безумства на VHDL.

Когда подошло время более-менее адекватных и серьёзных проектов, проблем стало больше, соответственно, я начал интенсивнее использовать гугл и искать ответы на свои вопросы. Тут мне всё чаще стали попадаться такие страшные словосочетания, как “timing analysis” и “design constraints”, когда я почитал и немного вникнул, пришло осознание того, что я упустил что-то очень важное. Сначала я панически боялся этих неведомых констрейнов, и ведь без них успешно работали первые проекты, благо частота там была не больше пары десятков МГц. Но когда речь зашла о более высоких частотах и более сложных проектах, здесь уже не обойтись без тщательного временного анализа и оптимизации.