Вопрос про входные сигналы поднимался тут. Теперь про ответную часть.

Вот валится поток - данные (по параллельной шине, хотя это и не важно) и клок. Клок, понятное дело, задержан на какую-то величину. Величина не очень большая, не больше половины периода. Если поток принимает "железяное" устройство, где четко указаны setup/hold времена, то вопросов нет. Но если поток идет в FPGA, то тут возникают вопросы.

Т.к. скорость потока (тактовая частота синхросигнала - клока) достаточно велика - соизмерима с клоком в принимающей FPGA, то просто пропустить через синхронизаторы не годится. Напрашивается использование двухклокового FIFO, в которое поток будет наливаться со своей скоростью, а выгребается из другого порта на частоте собственного клока ПЛИС. Это, в общем, известное и понятное решение. Но вот есть нюанс. Дело в том, что это FIFO двухклоковое строится на основе двухпортовой памяти, а блоки этой памяти лежат где-то в недрах ядра ПЛИС. И от входных пинов до выходных портов памяти задержки вполне соизмеримы с задержкой входного клока относительно входных данных. Иными словами, когда эти входные сигналы дойдут до портов памяти, временнЫе соотношения между ними будут уже совсем не такими, какими они были на входе.

Вот если бы можно было бы защелкнуть входные данные по входному клоку прямо во входных триггерах IO элементов, то проблемы бы не было. Но сделать это, насколько понимаю, вряд ли возможно - нельзя подать этот клок на тактовые входы триггеров, сохраняя при этом временнЫе соотношения с данными.

Второй вариант - обконстрейнить. Т.е. и на сигналы входных данных, и их клока наложены констрейны, задающие максимальную и минимальную задержки от входных пинов до входных портов памяти. Этот вариант работает. Вроде. Но почему-то нет уверенности, что это 100%-ный вариант, что это будет всегда и везде работать.

Кто как делается в таких случаях? Какие мнения, опыт?

Спасибо.

В квартусе же есть "Fast input registers", вроде как раз под этот случай. не подходит?

многое зависит от того как этот клок заходит и его частота. Вот те варианты которые я делал.

1. Подать клок на dedicated clock pin который предназначен для того IO банка где идет шина данных и использовать триггеры в IOB
2. Подать клок на PLL в режиме компенсации входной задержки и на этом клоке резать данные используя триггеры в IOB
3. Нарезать цифровой поток более ВЧ клоком используя триггеры в IOB и детектор фронта тактовой частоты
4. Если другие варианты не работают, то остается садить клок на глобальную линию и резать на этом клоке триггерами в IOB.

Констрейны нужно прописывать во всех случаях

Это почему нельзя. Заводите ваш клок на глобальный, и принимаете ваши данные на входные триггера по этому клоку. А затем подаете их на FIFO. Именно так и нужно делать.

Частота порядка 100 МГц.


К сожалению, устройство - плата - уже изготовлено. И даже работает с вышеописанными констрейнами. Но червь сомнения гложет.


Это что, клок, пропущенный через PLL, окажется на тактовых портах триггеров IO точно в момент, соответствующий исходной задержке между данными и клоком? Так ведь эта задержка порядка 2.5 нс. Неужели прохождение через PLL + трассировка до IOB составят меньшую величину?


Тут не сильно разгонишься.


Так тут все равно пока клок дойдет до глобальной линии, пока по ней добежит до IOB, эти несчастные 2.5 нс уже истекут. Даже если учесть, что от пина до входа данных IO триггера тоже есть задержка - порядка 1.3 нс, все равно мало времени, не успеет он.


А какие констрейны нужны в чисто синхронном дизайне, кроме указания клока и его характеристик?

Наверное, надо слепить тестовый проектик простой и посмотреть эти времянки на симуляторе после синтеза.


И сколько времени нужно клоку, чтобы от пина глобального клока пройти до IOB? И как эта задержка соотносится с задержкой данных от пинов до входов триггеров в IOB? Исходная задержка клока составляет 2.5 нс. Эта величина сохранится?

Да, еще забыл сразу сказать. Поток данных нерегулярный, в нем есть паузы. Как короткие - один-два такта, так и длинные - десятки микросекунд.

Эта информация есть в даташите на плисину. Точнее там приводятся времена ts и th. И приводятся они для случая, когда клок заведен на глобальную клоковый вход. Только опираясь на эти цифры, вы можете гарантировать нормальную работу девайса. И эти времена вы должны выдержать.



Догадываюсь что вы хотели сказать. У вас видать и клок на это время пропадает? Так делать не надо. Желательно, чтобы клок работал всегда. А данные, раз уж они не регулярные, сопровождать сигналом значимости, который с точки зрения передачи ничем от самих данных не отличается.

В доке на ПЛИС (EP2C8) в Table 5–17. IOE Internal Timing Microparameters есть параметр TSU, который указан для используемого спидгрейда (8) - 101 ps. Означает ли это, что если подать сигналы данных на пины IO, а клок на DEDICATED CLK, то достаточно выдержать задержку клока 101 пс относительно данных, чтобы защелкивание работало корректно?


Понимаю, что используемый вариант не самый лучший, но выбирать не приходится. Во-первых, это уже сделано и работает, во-вторых, приемником этого потока может быть не только ПЛИС, но и другое устройство, которое является аппаратным и для него никаких разрешений не надо, только данные и клок.

Для XIlinx FPGA (Virtex-e/Spartan-2E и Spartan-3A) мухлевал так:
1. До некоторых под возможно скомпенсировать задержку clock IBUFG путём использования в IBUF данных элементов Delay.
2. Если есть возможно использовать ПЛИС'овый DLL/PLL (обратная связь внутрикристальная), то до некоторых под хватает его компенсации задержки + использования в IBUF данных элементов Delay.
3. Если всего вышеперечисленного не хватает, то тогда тоже использует ПЛИС'овый DLL/PLL, но обратную связь делаем с проходом через дополнительную пару ног (выход - вход).

Мне обычно хватало и первого варианта,.. но т.к. случаи могут быть разные прорабатывал все 3. Во всех случаях данные фиксировались в InputFlipFlop.

В случае необходимости перехода на внутреннею частоту, данные после InputFlipFlop подавались на двухпортовую память (часто на Distributed DpRAM, а не на блочную, т.к. объема Distributed DpRAM вполне хватает и размазана она по всему кристаллу - задержки от IOB получаются меньше).

ну нормальная частота, с бООльшим запасом %)



Читайте описание режимов Source-Synchronous Mode и как в этом режиме работает PLL. Вот немного из даташита





Ну во первых вы забываете что клок у вас тоже заходит через IO PAD, что в некоторой мере компенсирует задержку на ввод в фпга, а во вторых если у вас клок отцентрирован, то у вас 5нс в каждую сторону от центра данных, для игры задержками времени вагон.



даже как то совестно вас направлять Quartus Handbook-> Section II. Timing Analysis -> The Quartus II TimeQuest Timing Analyzer -> I/O Specifications и для систем всех видов.



PLL сразу отпадает, нужно делать другими способами %)

Имею счастье использовать в Xilinx'e вариант 4, предложенный des00 в сообщении #3.
Подробнее:
1. Тактовая отправляется на глобальный буфер, на задержку наплевать.
2. В FPGAEditor'e фиксируется разводка этой цепи от пина до глобальника - от влияния переразводок избавились.
3. Задержка от глобальника до всех триггеров одинакова (в масштабе 100МГц расбросом можно пренебречь)
4. Таким образом задержка от входа тактовой до триггеров данных в блоках ввода/вывода зафиксирована.
5. Осталось на модели посмотреть величину задержки и определить каким фронтом запоминать данные, либо насколько двигать тактовую
с помощью IODELAY (если схемотехника ПЛИС это позволяет).

Сообщение отредактировал kaktus - Jun 29 2009, 05:45

Всем здравствовать.

DXP, выглядит все так, что лучший способ по цене/качеству тактировать регистры во входных буфферах стробом, получаемым снаружи. Разводить его не по глобальным клоковым сетям, а локально, стараясь минимизировать количество регистров напрямую от него тактируемых.

По поводу FIFO. Они вовсе не обязаны быть на dual port sram, помучайте wizard и получите на ячейках общего назначения. Фишка в dual clock не память, а схема управления и передачи информации об указателях через границу клоковых доменов.

В HyperTransport 400MHz я подавал опорный клок на DCM(PLL), его выход через глобальную сеть передавал к регистрам в IOB, там сэмплировал им и клок и данные. Для синхронизации после reset пробегал по шагам полный оборот фазы, находил фронты клока, затем ставил фазу на найденный фронт клока и снимал reset с остальной схемы.

Есть ещё вариант. У Вас подстройка фазы производится однократно, но никто не запрещает подстройку фазы производить постоянно.

Я сделал автомат подстройки фазы, который за 1024 такта определяет принимает решение куда сдвинутся и производит сдвиг DCM. Это работает постоянно во время работы основной схемы.
В результате удалось принимать поток данных на частотатх от 50 MHz до 500 MHz

С этого места можно поподробнее?
Какой кристалл, каков алгоритм, если не секрет.

Проверено на ПЛИС Virtex 4:
1. SX35-11
2. LX60-10
3. FX20-10

Мне кажется я уже писал об этом в этом форуме, но точно не помню.
Основные положения алгоритма:
1. Входной сигнал тактовой частоты защёлкиваем в IOB на триггере. (это внешний сигнал)
2. На тактовый вход тригера подаём сигнал тактовой частоты с выхода DCM (это внутренний сигнал)
3. Если фронт внутреннего сигнала не совпадает с фронтом внешнего сигнала, то на триггере будет либо стабильны 0, либо стабильный 1
4. Если фронт внутреннего сигнала приблизительно совпадает с фронтом внешнего сигнала, то за счёт джиттера на выходе тригера будет либо 0, либо 1
5. Производим подсчёт нулей и единиц на некотором интервале времени, у меня это 1024 такта
6. Если нулей и единиц примерно одинаково, то фронты совпадают - автомат DCM никуда не сдвигает
7. Если нулей мало - то DCM сдвигаем на одну позицию в одну сторону
8. Если нулей много - то DCM сдвигаев в другую сторону

Как показывает практика, в установившемся режиме DCM постоянно колебается на одну позицию.
У Xilinx примерно такой алгоритм описан.

Вот собственно идея.