Встреча ПЛИСоводов в Мск, СПб, Минске и Томске
  1. Home
Не пропусти встречу FPGA разработчиков в Москве, Томске, Минске и Санкт-Петербурге в апреле 2022!

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

cdc, alint

Автор: Akulin

Дата: 14.10.2021 12:00

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

658

5

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

Всего комментариев : 5
avatar
1 aavdeev • 19:23, 18.10.2021
Вопрос весьма актуален.  Стоит внимания! Хочу въехать в  ALINT-PRO
avatar
2 andreypun • 12:54, 20.10.2021
Мне кажется на рис. 8 на регистр valid_sync должен подаваться clkb.
avatar
3 aafonin1981 • 14:37, 22.11.2021
1. да, исправьте рис. 8, на регистр valid_sync должен приходить clkb.
2. в конфигурации на рис. 8 перед синхронизатором появилась комбинаторная логика - а это вызывает глитчи. В соответсвии с первой частью статьи пакет ALINT-PRO должен был это отловить. 
Почему ошибка при анализе CDC не обнаружилась?  Из-за ошибочного подключения clka на вход valid_sync анализ некорректно отработал?
avatar
4 Akulin • 19:19, 28.11.2021
Пока что не получается исправить картинку в статье, интерфейс не позволяет.
Однако я решил сначала обратиться к первоисточнику, уточню у компании ALDEC, и вернуть сюда с ответом.
Спасибо вам за внимательное прочтение статьи!
avatar
0
5 Akulin • 10:57, 01.12.2021
Исправили картинку! Спасибо!
avatar
Чуть больше преимуществ для наших патронов на Patreon

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

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

Технология встроенных FPGA (eFPGA): прошлое настоящее и будущее

Подробнее

VHDL

Реализация базовых компонентов ЦОС: КИХ фильтр

Подробнее

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

Игра: Напиши статью на FPGASYSTEMS

Подробнее

Общее

Основы статического временного анализа. Часть 2.1: System Synchronous Input Delay Constraint.

Подробнее

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

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

Подробнее

Верификация

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

Подробнее

SystemVerilog

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

Подробнее

Xilinx Vivado

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

Подробнее

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

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

Подробнее

Общее

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

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

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

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

Xilinx Technologies for New Space / Space 2.0

Подробнее

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

Повышаем качество RTL кода

Подробнее

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

Онлайн викторина по электронике

Подробнее

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

Мероприятия для студентов профильных вузов.

Подробнее

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

Цифровые фильтры на ПЛИС. С чего начать

Подробнее

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

Платформа прототипирования СБИС и СФ-блоков от Siemens EDA

Подробнее

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

Сто вопросов к основателю FPGA комьюнити

Подробнее

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

Вебинар «Разработка на ПЛИС с применением IP-ядер российского производства»

Подробнее

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

День технологий Intel FPGA

Подробнее

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

Вебинар о инструментах разработки на языках C и C++ для ПЛИС Microchip — 16 и 17 ноября в 15.00(мск)

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

Объявления

Ищу сотрудников

FPGA Designer в компанию MicroAvia

Подробнее

Продам

Продам плату QMTECH ZYNQ 7020

Подробнее

Куплю

Куплю Microzed

Подробнее

Ищу сотрудников

Инженер-верификатор

Подробнее

Ищу сотрудников

Инженер-программист FPGA (FPGA Designer)

Подробнее

Ищу сотрудников

Инженер-разработчик ASIC

Подробнее

Ищу сотрудников

Инженер-программист ПЛИС

Подробнее

Ищу сотрудников

Инженер-верификатор (UVM)

Подробнее

Продам

Курс по VHDL

Подробнее

Ищу сотрудников

FPGA разработчик. Полная занятость (Москва)

Подробнее
Все объявления

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