Встреча ПЛИСоводов в Мск и СПб
Начните статью со страницы мотивации

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

cdc, alint

Автор: Akulin

Дата: 14.10.2021 12:00

Категория:Верификация

192

2

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

Всего комментариев : 2
avatar
1 aavdeev • 19:23, 18.10.2021
Вопрос весьма актуален.  Стоит внимания! Хочу въехать в  ALINT-PRO
avatar
2 andreypun • 12:54, Сегодня
Мне кажется на рис. 8 на регистр valid_sync должен подаваться clkb.
avatar
Чуть больше преимуществ для наших патронов на Patreon

Последние статьи нашего сообщества

Познавательное

Поточное вычисление двоичного логарифма

Подробнее

Верификация

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

Подробнее

SystemVerilog

Статическое в SystemVerilog

Подробнее

Xilinx Vivado

Стратегии оптимизации HDL-кода и синтезатора нетлиста для FPGA

Подробнее

Инструкции к сайту

Оформление статей для сборника

Подробнее

Общее

Основы статического временного анализа. Часть 1: Period Constraint.

Подробнее

Познавательное

Вычисление двоичного логарифма итерационным методом на ПЛИС

Подробнее

Познавательное

Искусство отладки FPGA: как сократить срок тестирования за счет грамотной разработки

Подробнее

Прочее

Быстрый старт: поднимаем PCIe (xdma)

Подробнее
Все статьи

Календарь актуальных событий и мероприятий

Вебинар (состоится 14-окт-2021)

Вебинар от ALDEC: Краевые случаи как источник ошибок при проектировании ПЛИС

Подробнее

Вебинар (состоится 21-окт-2021)

История FPGA с Kapil Shankar

Подробнее

Вебинар (состоится )

UVM для FPGA (часть 4): стандарт IEEE 1800.2 - изменения UVM

Подробнее

Вебинар (состоится )

Портирование свёрточных нейронных сетей на платформу Xilinx Zynq Ultrascale Plus и ускорение их работы

Подробнее

Вебинар (состоится )

Двухдневный семинар по Xilinx Versal от Doulos 15-16.09 или 29-30.09 без оплаты.

Подробнее

Мероприятия (состоится )

Конкурс от Xlinix "Adaptive Computing Challenge 2021"

Подробнее

Мероприятия (состоится 14-16 сен 2021)

Сколковская школа синтеза цифровых схем снова открывает свои двери!

Подробнее

Вебинар (состоится 2 сен 2021)

Что нового в OSVVM?

Подробнее

Вебинар (состоится 7-сен-2021)

SoM-модули Kria – ускорение и удешевление разработки устройств с машинным зрением и ИИ. Теория и практика.

Подробнее

Мероприятия (состоится )

Российский Форум Микроэлектроника-2021, 3–9 октября 2021 года, Алушта

Подробнее
Все предстоящие события

FPGA-Systems – это живое, постоянно обновляемое и растущее сообщество.
Хочешь быть в курсе всех новостей и актуальных событий в области?
Подпишись на рассылку