МАРСОХОД

Open Source Hardware Project

Передача группы сигналов в другой клоковый домен

Мы знаем, что такое метастабильность D-триггера, и знаем, как с этим явлением бороться. Цифровая схема может иметь несколько блоков, тактируемых от разных генераторов. Это, так называемые клоковые домены. Для передачи сигнала из одного клокового домена в другой должны использоваться синхронизаторы – как минимум два последовательных D-триггера.

А что, если нам нужно передать не одиночный сигнал, а группу сигналов, сигналы шины?

Синхронизатор для группы сигналов, Clock Domain Cross

Я сделал вот такой простейший проект в Altera Quartus II.
Четырехбитные данные со входа data[3:0] фиксируются тактовой частотой clk в четырехбитном триггере A. Зафиксированные в триггере A данные затем пересекают клоковый домен и далее фиксируются тактовой частотой clk2 в следующем четырехбитном триггере B, далее в четырехбитном триггере C и, в конечном итоге, поступают на выход out[3:0].

Похоже, что все правильно, правда? Мы ведь установили в принимающем клоковом домене синхронизаторы для каждого из четырех сигналов данных. Но все ли здесь хорошо?

Запускаю компилятор Quartus II.

При компиляции такого проекта модуль квартуса Design Assistant (о том как его включить читайте здесь) выдает вот такое сообщение:

Warning: (Medium) Rule D102: Multiple data bits that are transferred across asynchronous clock domains are synchronized, but not all bits may be aligned in the receiving clock domain. (Value defined:2). Found 1 asynchronous clock domain interface structure(s) related to this rule.
Warning: Node  "A (Bus)"


Смысл этого сообщения такой: данные передаются в другой клоковый домен, они правильно синхронизированны, но могут быть зафиксированны не одновременно.

И действительно, такая проблема может быть. У нас есть 4 триггера источника (A) и 4 четыре триггера приемника (B). Физическое размещение триггеров в кристалле микросхемы определяет длину пути сигналов между триггерами. Какой-то путь длиннее, какой-то короче. Какой-то сигнал придет к триггеру назначения раньше, а какой-то позже.

размещение триггеров в кристалле

Вот на картинке изображено возможно расположение триггеров в кристалле. Красные прямоугольнички – это триггера источники, а синие – это триггера приемники. Длина трассы между ними естественно оказываются разные.

Честно говоря, эта картинка несколько утрированная. Конечно, Quartus II сделает все возможное, чтобы расположить триггера приемники как можно ближе к источникам. И скорее всего, время распространения будет одинаковое для всех передаваемых бит. Однако, тут важно понимать принципиальную возможность этой проблемы. Когда проект будет занимать 90% кристалла, то у компилятора (фиттера) будет не так много возможностей по оптимальному размещению триггеров и логики.
Временные диаграммы сигналов передачи данных через клоковый домен
Вот так может выглядеть временная диаграмма сигналов. В данном конкретном случае видно, что после фиксации данных DATA[3:0] в регистре A сигналы будут распространяться ко входам регистра B, но сигналы на входах regB[0] и regB[3] чуть запаздывают. Однажды фронт асинхронной частоты clk2 может зафиксировать в некоторых битах регистра B «новые» значение, а в «оставшихся» битах регистра B - старые значения. Принятое значение в регистре B в этом такте будет искаженное.

Конечно, нужно понимать, что такое поведение схемы нельзя однозначно считать ошибкой проектирования. Все зависит от конкретной прикладной задачи. Для некоторых задач иногда не верное фиксирование вообще не является проблемой. Для других задач такое поведение может быть абсолютно не приемлимым.

Один из способов «правильной» передачи группы сигналов (шины) в другой клоковый домен состоит в следующем:

  1. Данные на передающей стороне фиксируются первой тактовой частотой clk1 в регистре источнике A. 
  2. С выхода регистра A данные поступают в другой клоковый домен без синхронизаторов на входы регистра приемника B, где фиксируются тактовой частотой clk2.
  3. После фиксации данных в регистре источнике A, передатчик формирует сигнал запроса на передачу REQ, который через синхронизатор поступает во второй клоковый домен.
  4. Приемник принимает запрос REQ после синхронизатора и использует принятые данные из регистра B по назначению.
  5. После приема данных приемник выставляет сигнал подтверждения приема ACK, который через синхронизатор отправляется на сторону передатчика.
  6. Передатчик ожидает сигнал ACK от приемника. После того, как синхронизированный ACK получен, передатчик может приступать к передаче по шине следующих данных.

Таким образом, синхронизируются только сигналы запроса REQ и подтверждения приема ACK. На самих передаваемых данных синхронизаторы в этом случае не ставятся.

Этот метод передачи данных в иной клоковый домен хорош, но, к сожалению, является черезвычайно медленным, так как теряется много времени на пересинхронизацию этих запросов и ответов.

Существуют и иные методы передачи данных в другие клоковые домены, каждый метод имеет свою область применения.

 

 

Комментарии  

0 #3 uglyduck 01.03.2012 08:30
По моему подобная проблема может возникнуть еще в триггерах А - ведь пути сигналов к тем самым "красным" прямоугольникам тоже разной длины... Тоесть data[3:0] должна иметь определенную продолжительнос ть что бы быть зафиксированна правильно. Правильно ли я думаю?

Спасибо tda2030 за супер ресурс, ну и марсоходам конечно за хорошие статьи.
+1 #2 tda2030 25.02.2012 09:14
Видел похожую, но чуть более подробную и чуть более сложную для меня статью
http://www.kit-e.ru/articles/circuit/2009_02_102.php

если вдруг кому нужно, можете ознакомиться.

зы. ребят, напишите, пожалуйста, о проблемах, которые еще могут встретиться при использовании такого типа синхронизаторов .
0 #1 Dog 24.02.2012 09:04
Николай, можете поделится то литераторуй, в которой поднимаются подобные проблемы при проектировании проектов в Квартусе?

Добавить комментарий



facebook  GitHub  YouTube  Twitter
Вы здесь: Начало Статьи о разном Передача группы сигналов в другой клоковый домен