Верификация проблем с пересечением тактовых сигналов в ПЛИС с помощью ALINT-PRO

Предположим, у вас есть одна или несколько ПЛИС, на которые подаются разные тактовые сигналы для отправляемых и принимаемых данных (назовем их «клоки», пусть будет snd_clk для отправки данных и rcv_clk для приема этих данных). Что будет, если эти сигналы не синхронизованы, то есть «плавают» друг относительно друга? Непредсказуемый сдвиг их фронтов во времени может вызывать функциональную нестабильность вашего проекта. Как бы оно работает почти всегда, причем при моделировании оно работает вообще всегда, но в реальном железе иногда «сбоит».  Это известная проблема Clock Domain Crossing (Пересечение Тактовых Сигналов). Давайте посмотрим, что происходит.

Если в проекте есть ситуация «тактирования» сигнала одним клоком при передаче данных (snd_clk) и «защелкивания» этого сигнала другим клоком при приеме (rcv_clk), то фронт принимающего клока может случиться в любой момент времени относительно фронта передающего клока. Кроме того, задержка переключения передаваемого сигнала, как и сама задержка передачи, может быть непредсказуема, поэтому нет никакой гарантии, какое значение сигнала было сейчас защелкнуто приемником – «предыдущее» или «следующее».

Рис. 1: Функциональные проблемы, вызванные Clock Domain Crossings

Как пример - выходные логические элементы, «суммирующие» (или как-то еще обрабатывающие) два сигнала при передаче, могут создать ложное срабатывание в приемнике, пик («glitch»), который может быть непреднамеренно передан в приемную логику и некорректно отработан. Хотя оба выходных триггера (sigA и sigB на картинке 2) могут тактироваться от одного и того же передающего клока, в приемник может прийти некорректно сформированный сигнал, потому что задержка передачи от каждого из триггеров при прохождении через комбинаторную логику (CL на картинке 2) может быть разной.

Рис. 2: Комбинаторная логика перед синхронизатором может вызывать сбои

Это важный момент – нужно исключить вероятность генерации «пиков» на входах синхронизатора – приемника. Наиболее разумное решение для этого – поставить дополнительный синхронизатор «по передающему клоку» прямо перед входом синхронизатора «по приемному клоку».

Программный пакет верификации кода ALINT-PRO и его составная часть, модуль проверки Clock Domain Crossing, проверяет весь ваш проект на отсутствие таких «критических» мест и гарантирует отсутствие «пиков» и ложных срабатываний на входах синхронизирующих схем.

Копнём немного глубже. Непредсказуемость задержки – вот еще одна проблема в таких системах, и она может вызвать сильную головную боль при отладке и поиске причин таких нерегулярных сбоев в передаче данных. Предположим, два или больше взаимосвязанных сигнала передаются и затем «суммируются» уже в принимающей части, после синхронизации на входе. Интересно то, что эти сигналы «случайным образом» могут оказаться сдвинуты один относительно другого на один период принимающего клока. Суммирование (или «рекомбинация») этих сигналов в дальнейшем может вызвать нежелательные сбои в данных (см. пример на картинке 3).  

Рис. 3: Проблема суммирования сигналов с нежелательным сбоем данных

Посмотрим на вот такой пример проекта с суммированием двух сигналов (рис.4).

Рис. 4: Пример проекта с суммированием двух сигналов

При моделировании, скорее всего, ошибка обнаружена не будет. А вы видите ошибку в коде? А вот анализ CDC в программном пакете ALINT-PRO обнаруживает проблему с суммированием сигналов на глубине 2 на входе регистра "valid_sync" (рис.5).

Рис. 5: Анализ проблем суммирования сигналов в программе ALINT-PRO

Что означает термин «глубина 2» в данном случае? Речь про то, что оба сигнала «сходятся» сразу после синхронизатора, который решает проблему плавающих клоков. Сами эти синхронизаторы мы считаем первым каскадом регистров, а регистр "valid_sync" на картинке 5 мы считаем вторым каскадом регистров.

Для примера давайте посмотрим схождение сигналов на втором каскаде регистров после синхронизатора, то есть на глубине схождения 3 (рис.6).

Рис. 6: Анализ схождения двух сигналов при глубине схождения 3

Кстати говоря, в пакете ALINT-PRO есть настройка максимальной глубины, на которой надо искать такие проблемы схождения сигналов - "Convergence analysis depth" в меню "Design Entry -> Constraints -> CDC window of Project Properties". Чем больше вы зададите эту величину, тем, разумеется, дольше будет производиться анализ на ошибки, особенно для больших проектов со сложными путями прохождения сигналов и с несколькими такими клоками, которые могут «плавать» по фазе друг относительно друга. Не рекомендую ставить это значение больше, чем 4, а для больших проектов вообще уменьшить до 2 (рис.7).

Рис. 7: Настройка глубины поиска проблем CDС в пакете ALINT-PRO

Что же делать, если мы обнаружили такую проблему (не важно, с помощью ALINT-PRO при разработке, или уже при работе проекта в реальном железе)? Нам надо исправить те места, в которых обнаружены потенциально опасные передачи сигнала из одного клока в другой клок. Одно из возможных решений – это перенос всей комбинаторной логики в область передающего клока, и уже результирующий, хороший и чистый сигнал, должен передаваться в область принимающего клока и там синхронизироваться без проблем (рис.8).

Рис. 8: Исправление проблемы схождения сигналов в проектах CDC

Выводы:

Будьте внимательны, если у вас в проекте есть два или больше синхронизирующих сигнала, которые могут «плавать» друг относительно друга, и используйте программы верификации, типа ALINT-PRO, для автоматического обнаружения проблемных мест, связанных с пересечением тактовых сигналов и вызывающих функциональные сбои.