Бывает, что есть проект, который вроде бы работает. Как только начинаешь добавлять в него новые модули или какие-то казалось бы небольшие изменения — перестает работать. В чем тут может быть дело? Каким правилам нужно следовать, чтобы получить стабильный проект? На мой взгляд правило есть только одно — проект не должен содержать асинхронной логики, все процессы должны быть только строго синхронными.
Что такое синхронный дизайн? В синхронном проекте для ПЛИС есть один дирижер для всех музыкантов, для всей логики - это сигнал тактовой частоты. По каждому активному фронту тактовой частоты все регистры проекта одновременно фиксируют сигналы на своих входах и передают их на свои выходы. Подключенные к выходам регистров логические функции начинают свое вычисление и у них, как правило, есть только один период тактовой частоты для этих вычислений. Новые вычисленные значения из логических функций подаются на входы регистров и должны быть готовы к очередному активному фронту тактовой частоты.
Логические функции — это сумматоры, вычитатели, умножители, мультиплексоры, дешифраторы и всякое другое. Выход логической функции зависит только от сигналов на входах. Внутри логической функции нет запоминающих элементов. Вычисление логической функции занимает время — чем сложнее логическая функция, тем дольше может считаться отклик. Например, сумматор 32х битных чисел является более сложной функцией, чем сумматор 4х битных чисел. Значит он будет вычислять дольше.
Посмотрите на рисунок выше. Здесь изображены несколько регистров и в овалах — логика. Например, есть блок логики который выполняется дольше всего, целых 18 наносекунд. Именно этот критический путь будет определять максимально возможную частоту на которой сможет работать проект. В данном случае: Fmax = 1/ max(t1,t2,t3...tn) = 1/18нс ~ 55МГц.
Данные на входах регистров должны быть стабильны в момент фронта тактовой частоты. Еще правильней сказать, что данные должны быть стабильны как минимум «setup time» (tsu) до фронта и «hold time» (th) после фронта тактового сигнала. tsu и th – это параметры конкретной ПЛИС. В принципе, компоновщик (fitter) компилятора старается расположить элементы и логику в ПЛИС так, чтобы пути сигналов были короткими, чтобы задержка распространения сигнала была минимальной. Однако, к сожалению, это не всегда удается. Если проект сложный, если рабочая частота проекта оказывается равной или большей, чем рассчитанная во время компиляции Fmax, то проект работает на грани возможного. В состав пакета Quartus II входит временной анализатор TimeQuest. Эта программа рассчитывает и показывает критические пути и Fmax проекта после компиляции. Однажды компилятор смог удачно расположить логику и рассчитанная Fmax оказывается равной или выше реальной частоты проекта. В этом случае проект еще работает. Даже небольшое изменение в проекте заставляет компилятор располагать логику и регистры в ПЛИС несколько иначе, чем в прошлый раз. Критические пути меняются и расчетная Fmax может оказаться ниже реальной. Проект перестает работать. В этом случает требуется пересмотреть логические функции, насколько их можно упростить. Если упростить логические функции в критических путях не получается, то их можно пытаться разбивать на стадии вычисления, делать pipeline.
Рассмотрим еще более тяжелый случай.
Рассмотрим неудачный дизайн, с несколькими тактовыми частотами, где данные пересекают клоковый домен без должной синхронизации.
Посмотрите. Здесь данные фиксируются в четырехбитном регистре с частотой CLK1, а затем данные передаются другой группе регистров работающих на частоте CLK2.
В общем случае, когда CLK1 и CLK2 – это несвязанные частоты, время между фронтами двух частот может быть каким угодно (t1, t2, t3, t4 ...) — может быть достаточным для распространения сигналов от первой группы регистров, а может быть и весьма малым, таким, что сигналы просто не успевают распространяться одновременно от первых регистров ко вторым. В этом случае появляется некоторая вероятностная составляющая. Пока проект маленький, регистры расположены близко друг к другу и с большой вероятностью данные из одного клокового домена будут успешно (почти всегда) переданы во второй клоковый домен. Когда же проект растет, компилятор уже не может расположить регистры достаточно близко друг к другу.
Вот как на этом рисунке: в результате перекомпиляции fitter разместил регистры на удалении друг от друга, пути прохождения сигналов к отдельным регистрам стали разной длины. Время распространения сигнала до каждого конкретного регистра становится неодинаковым. Вероятность правильной передачи данных падает. Проект, кажется, перестает работать правильно. На самом деле он и раньше не очень хорошо работал, просто вероятность ошибки передачи между разными clock domain была довольно низкой и мы ее толком не замечали.
Как же быть в этом случае? Неужели нельзя в проекте использовать несколько разных частот одновременно? На самом деле использовать несколько частот можно, но нужно понимать, как ими пользоваться. Будет правильно использовать для передачи данных из одного клокового домена в другой мегафункцию FIFO или двухпортовое ОЗУ. Например, альтеровский Megafunction Wizard позволяет создавать FIFO с двумя разными тактовыми входами для передающей и принимающей стороны. Альтеровское FIFO уже содержит в себе схему синхронизации, движение указателей на данные в ФИФО передается с помощью специальных кодов Грея.
Что еще можно сказать по поводу стабильности проектов.
Есть документ Альтеры https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/quartus2/qts_qii51006.pdf
Recommended Design Practices. В этом документе написано, какие методы проектирования приветствуются, а каких лучше избегать.
Вот краткий перечень, чего лучше не делать:
1) не используйте асинхронный сброс или установку регистров для логической обратной связи, вообще старайтесь избегать использование асинхронных сбросов и установки. Асинхронные сброс и установка нужны только для начальной инициализации проектов и для симуляции.
2) не используйте защелки данных по управляющему уровню (latch), для запоминания и хранения данных есть регистры, используйте регистры
3) не используйте задержки сигнала на логических элементах
4) не создавайте импульсов или мультивибраторов принцип действия которых основан на задержках в элементах
5) не используйте выход логической функции как сигнал тактовой частоты, вместо этого, используйте выход регистра как сигнал тактовой частоты
6) не используйте последовательных счетчиков
7) не используйте переключение тактовой частоты во время работы проекта
8) не используйте подавление тактовой частоты с помощью логики, вместо этого используйте синхронные схемы разрешения записи.
Возможно я что-то упустил из вида, но кажется, что про основные возможные проблемы с проектами ПЛИС я рассказал. Тем не менее, на нашем сайте мы уже кое-что писали по поводу стабильности:
1) Передача группы сигналов в другой клоковый домен
2) Синхронизатор сигнала для CDC на Verilog
4) Пример цифровой системы с несколькими тактовыми частотами.
6) Базовые принципы построения FIFO.
Подробнее...