собственно не могу сообразить - есть ли какой то скрытый смысл в этом сигнале, кроме как разделение старшей-младшей части принятого слова. Может есть какие хитрости связанные с ним - для калибровки, или еще для чего. А может я и с "разделением" ошибся...

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

т.е. при калибровке при применении на ИСЕРДЕСЕ функции БИТСЛИП, получив на выходе заданную константу мы должны будем сдвигать (через ИОДЕЛЕЙ) ФРЭЙМ до тех пор, пока не получим ту же самую константу... в чем смысл ? а если учесть что диапазон сдвига на ИОДЕЛЕЕ около 2 нан (31 тап по 70 пик), то мы вообще можем не получить желаемого... как быть в этом случае?

Есть документ на этот АЦП там все довольно подробно разжевано и догадки строить не требуется.
Если кратко, то нужно читать данные и фрейм по тактовому сигналу dclk. Как это реализовать - вам решать.

Для Altera всё понятно, там есть готовое ядро ALTLVDS_RX для приёма таких данных. Есть ли что-то похожее у Xilinx? Или придётся делать свой приёмник?

так в том то и дело что в юзер гайде на АЦП с последней ревизией в сентябре 2013 я ничего дельного на эту тему не нашел. кроме этой диаграммы и описания пина:
DAFRAMEP, DAFRAMEM — Differential frame clock output for channel A

а, ну еще вот это изображение
http://pix.my/n1O9NE5P

и, сосбтвенно, все...

зы
если у вас есть какой то другой юзер гайд - пульните его мне, мыло в личку скину



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

для ддр режима я год назад делал блок автоматической подстройки - по включению питания ацп настраивался на тестовый режим, с пинов все заводилось на нужные буферы, ИОДЕЛЕИ и на ИСЕРДЕСы. И путем подстройки задержек на линиях данных и синхры я добивался появления стабильной константы на выходах ИСЕРДЕСов.

но входные условия поменялись - теперь нужен QDR режим. и тут я поплыл. появился мутный фрейм, плюс частоты выросли в 2 раза... начал смотреть на механизм БИТСЛИПа для подстройки (непонятно - почему до этого я его не использовал ), но возникли вопросы что тогда делать с фреймом

У Xilinx по этой теме есть много xapp'ов с примерами-проектами для китов.
Например, xapp585, xapp524, xapp774, xapp860, xapp866 и др с учетом особенностей FPGA.

Спасибо, посмотрю.
Нашёл само ядро, в Vivado - SelectIO Interface Wizard.

а вот за эту наводку отдельное спасибо - будем искать/читать

Для семейства S6- xapp1064. Здесь реализована динамическая автоподстройка.
Самому надо будет писать или заимствовать автомат калибровки задержки клока
и калибровки битслип (выравнивание кадра)

а совершенно случайно - по 7 семейству там ничего нет ?

Для 7 семейства -xapp585, нужно определиться с вариантом надежного приема данных от АЦП
в зависимости от ваших условий и задачи. Их описано несколько вариантов. (xapp855,856 и тд)
И реализовать который больше подходит.

Xapp524 также подходит для 7 серии. Нужно будет выбрать вариант. Мне лучше подходил как у xapp585.

500-е уже скачал, но еще не посмотрел - залип на 1064. Похоже что я ваш должник

Все мы чуточку должны друг другу.

Надо проштудировать эти документы. И определить для себя, что лучше. Может и практически попробовать.
Я сначала пробовал вариант xapp524. Но потом вариант- xapp585.
В любом случае автомат калибровка клока и битслипа. Это самое трудоемкое.

Как понимаю, всё, что Вы посоветовали - вручную собранный приёмник, почему не воспользоваться готовым ядром?

Собрать это ядро не проблема, прочитав xapp'ы. Можно пользоваться этим ядром, но он без автоматов.
Автоматы все равно надо создавать. Это так в ISE.



ИДЕЛАЙ и ИСЕРДЕС включить не особая проблема.

Важно к xapp' ам есть примеры проекта .zip файлы.

user guide я даже не смотрел. В документе http://www.ti.com/lit/ds/symlink/ads42lb49.pdf на страницах 31-33, 41-43 приведено достаточное количество картинок для понимания работы интерфейса. Если этого не хватает, то можно например посмотреть аналогичные АЦП с подобным интерфейсом, работаю они также.

Что понимается под автоматом? Работал с ALTLVDS_RX от Altera, там АЦП необходимо загнать в режим синхронизации, кога на выход идёт тестовая последовательность. Автомат тактирует align порт ядра и задаёт правильное выравнивание (приём) данных, после чего АЦП переключается в рабочий режим. Тут также?

Нет,
Altera похоже автоматизировала этот процесс, ее ядро. Значит ALTERA здесь лучше подумала.
У Xilinx этот процесс калибровки не автоматизирован- делай сам вручную! О чем я и пишу.
Твой самопальный автомат (или заимствованный из какого-нибудь проекта) будет делать эти калибровки.

Подозреваю, что у Altera может быть эти калибровки идут постоянно,
динамически подстраиваясь под изменения температуры, питания и тд. Tе динамическая подстройка

У Xilinx также имеется форум и поиск по ключевым словам iserdese, bitslip xapp585, и тд работает

то же самое я и делал, только для ддр режима у ацп-ки. при этом xapp-ы не читал . первоначальная подстройка по включению питания, плюс возможность подстройки в любой момент - только дернуть соответствующую ногу у моего контроллера. а ее можно было дернуть при определенном значении температуры (контроллер под внешний температурный датчик тоже я делал ), либо же блок управления мог по таймеру или по еще какому прерыванию это сделать. а вот с qdr-ом что то затупил - и кристалл поменялся и требования повыше...

Подстройка выравнивания клока и данных может выполняться непрерывно, для этого клоковый вход подключается к SERDES, как обычная линия данных, и тактируется собой же через IDELAY, в аппнотах это описано подробно.

только я не соображу как потом распределяются эти частоты. задача - собрать данное на ИСЕРДЕСЕ в режиме MEMORY Interface Type. На ИСЕРДЕСЕ клоки ЦЛК, ОЦЛК, ЦЛКДИВ. Соответственно как я понимаю:
ДЦЛК = ЦЛК
BitClk_MonClkOut = ОЦЛК
BitClk_RefClkOut = ЦЛКДИВ

в этом случае выполняются все требования - фронты ЦЛК и ОЦЛК разнесены и не получится попадания на момент переключения, и ОЦЛК с ЦЛКДИВом выровнены по фазе.

вот только не знаю - можно ли с выхода ЛВДС буфера так растянуть нетку на ИОДЕЛЕЙ, ИСЕРДЕС (Д вход в этом же пине) и как синхру на ИСЕРДЕС в другом пине

А зачем тянуть выход LVDS буфера прямо на синхру? Все линии данных синхронизируются по BitClk_MonClkOut и BitClk_RefClkOut, в XAPP-ах же исходники есть.

уже разобрались. хилинх предполагает что ДЦЛК и данные уже выровнены (фронт синхры посередине данных) и подстраивает внутрянку с буферов под входную, предполагая что тогда и она будет посередине данного. этот вариант не подходит - синхру с данными надо ровнять вручную

Так и не понял, что Вы тут хотели сказать?
Ядро SelectIO Interface Wizard работает по тому же принципу, что и ALTLVDS_RX у Altera. Порт bitslip используется для битового сдвига данных, чтобы получить правильное выравнивание. Если битовым сдвигом не удаётся получить правильные данные, то можно ставить задержки на линии "клока" и данных. Автомат будет определять выравнены ли данные и управлять сдвигом данных (о чём я и спрашивал).

Ядро SelectIO Interface Wizard состоит только из примитивов ISERDESE IDELAY,
которыми надо управлять внешними сигналами BITSLIP и задержками. Те строится внешний автомат калибровок.
Он не входит в состав ядра.

С Aлтерой я не работал. Если здесь ядро похоже сделано то грустно.

Если синхра с данными не выровнена из-за несогласованной длины дорожек, надо в каждый вход вставить IDELAY, откалибровать их всех на старте, а потом динамически выравнивать только клок и данные, таким же образом, как предлагает Xilinx.

Уточните, пожалуйста, у Алтеры полностью готовое ядро или "болванка", к которой необходим дополнительный
внешний автомат калибровок (state mashine).

Необходим внешний автомат, только там нельзя ставить задержки на линии клока/данных, вместо этого есть возможность настраивать PLL, если битового сдвига недостаточно для правильного приёма данных

Если можно, расскажите алгоритм работы автомата калибровки (предполагаем, что линии данных и клока могут иметь разную длину).

Cогласно Xapp585 предусмотрена следующая структура :
-Вход frameclk поступает на MMCME для генерации битклока, те здесь производится умножение частоты для приема данных в ISERDES, например в моем случае frameclk равен 62.5 Mhz, битклок необходим 375 Mhz для приема 12 бит данных в режиме DDR. Параллельно Вход frameclk поступает на IDELAY, ISERDES.
-Каждый Вход данных подключены через IDELAY, ISERDES.
-На ППМ длина проводников frameclk (клоковый вход фпга) и данных выравнены.
Работа автомата калибровки следующая: производится поиск центра БИТданных,
для этого установливается начальная задержка IDELAY равная нулю, Производится прием данных frameclk, и фиксируются эти данные. Увеличиваем задержку. Считываем данные frameclk'а и сравниваем с предыдущим значением. Если эти данные не совпали (это означает что попали на фронт,спад данных) то запоминается величина задержки и данные frameclk'а. Далее увеличивая задержку ищем второй переход(изменение данных) и также запоминаем. Затем вычисляется разница кода задержки первого и второго переходов, делится на 2 добавляется к задержке первого перехода (или вычитается из задержки второго перехода) и устанавливается полученное значение задержки в IDELAY. Поскольку frameclk и линии данных выравнены то задержки для всех IDELAY также равны.
Далее калибровка- битслип выравнивание принимаемых 12 бит данных по границе. Производится путем сравнения принимаемых данных с кодом frameclk = 000000111111 и управляя сигналом BITSLIP ISERDES. Делается мах 12 циклов чтобы получить желаемый код frameclk'a. Калибровки закончены. Ждем следующего запуска.

Если frameclk и линии данных имеют разную длину, То АЦП нужно установить в режим калибровки (тестовый режим когда он генерирует код допустим похожий на код frameclk (000000111111). И С КАЖДОЙ линией данных провести операцию по подстройке задержки для поиска центра (середины). И потом битслип операция.

xapp585

Спасибо. Вроде понял, буду пробовать. Пока пытался синхронизироваться с использованием только bitslip-a, как итог - тестовую последовательность ловит, но при переключении АЦП в рабочий режим данные неправильные, плюс может настроиться не на каждую тестовую последовательность. Надеюсь, установка клока в центр данных поможет решить проблему.


Можно ли на это раcсчитывать, наверное лучше сразу делать синхронизацию для каждой линии?

Подстройка задержки для каждой линии данных, конечно, более надежное решение.
Очень важно установить клок в центр данных для каждой линии.
Если задержка одна и таже для всех (упрощенный вариант), То мало ли что может произойти, например, при производстве.
И тогда поиск неработоспособности.

Что можете сказать по поводу длительности фронта? Можно ли по однократному несовпадению утверждать, что попали на фронт?

Есть 12 каналов АЦП (3 АЦП по 4 канала), режим работы: 8-bit serialization, 2-line mode (каждый канал передаётся по двум линиям), DDR LVDS, битовый клок 400 МГц, иногда один/два канала синхронизируются криво (тестовая последовательность 0xF0 на линии принимается нормально, но при переключении в рабочий режим данные принимаются неправильно, на последовательность 0xAA вообще не каждый канал может настроиться).

В Xilinx документации говорится, что переход (фронт/спад) проявляется в течении 3 тапов (единиц) задержки, те 3 тапа х 78 ps.
Можно все это по шагам посмотреть: устанавливаешь задержку- получаешь данные, следующая задержка- следующие данные. Ну и анализ
Те посмотреть что реально происходит И несколько раз повторить.

Дополню: берете самый худший АЦП и снимаете характеристику задержка (0-31) и принимаемые данные.
У вас должен быть стабильный участок длиной 16 ед задержки 400Mhz= 2.5 ns, DDR, полпериода 1.25 ns/78 ps= 16 eд.
Лучше считается участок более ближний к нулю, меньше джиттер.
И в результате этой калибровки нужно получить средину этого участка. Те задержка равна средине этого участка.

Спасибо. Пока нашёл баг в своей стейтмашине, вернее в самом алгоритме - 3 тапа на переходные процессы после нахождения фронта, в найденном примере использовалось окно 4 тапа и я так же сделал (ранее не использовал окно при нахождении первого фронта). Стало работать стабильнее. Сейчас стало синхронизироваться и на 0xAA, но всё равно иногда вылетает один канал (всегда один и тот же).


Длительность бита 1.25 ns/78 ps= 16 eд, т.е. длительность стабильного участка будет меньше?

Да, похоже на эти 3 ед нестабильного перехода.
Важно отработать алгоритм работы автомата для надежного и стабильного поиска середины(центра) данных.
Потом еще важна процедура битслип чтобы получить правильные данные.

Как у Вас происходит оценка текущего положения клока - по одной точке или оцениваете выборку (т.е. для каждого тапа оценка что делать далее осуществляется по одной временной точке или оцениваете выборку)?

Пока алгоритм у меня работает без всяких усреднений.
Те каждому тапу задержки (после смены величины задержки-
моя временная задержка на установление процесса) получаю одно значение данных фреймклока
(без накопления и усреднения) и которое затем использую для сравнения с предыдущей запомненной.
(Ошибка подстройки задержки на единицу (две) к ухудшению качества приема данных не приводит в наших условиях).
Параметры АЦП похожи 375 Мгц DDR, 12bit (В проекте 4 АЦП 12bit, 8 lvds пар линий данных плюс фреймклок каждый)
Пока алгоритм такой.