[Алга 0]

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

[doom13 0]

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

 

Поскольку frameclk и линии данных выравнены то задержки для всех IDELAY также равны.

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

[Алга 0]

Подстройка задержки для каждой линии данных, конечно, более надежное решение.

Очень важно установить клок в центр данных для каждой линии.

Если задержка одна и таже для всех (упрощенный вариант), То мало ли что может произойти, например, при производстве.

И тогда поиск неработоспособности.

[doom13 0]

... Если эти данные не совпали (это означает что попали на фронт,спад данных) ...

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

 

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

[Алга 0]

В Xilinx документации говорится, что переход (фронт/спад) проявляется в течении 3 тапов (единиц) задержки, те 3 тапа х 78 ps.

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

Те посмотреть что реально происходит И несколько раз повторить.

 

[Алга 0]

Дополню: берете самый худший АЦП и снимаете характеристику задержка (0-31) и принимаемые данные.

У вас должен быть стабильный участок длиной 16 ед задержки 400Mhz= 2.5 ns, DDR, полпериода 1.25 ns/78 ps= 16 eд.

Лучше считается участок более ближний к нулю, меньше джиттер.

И в результате этой калибровки нужно получить средину этого участка. Те задержка равна средине этого участка.

[doom13 0]

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

 

Дополню: берете самый худший АЦП и снимаете характеристику задержка (0-31) и принимаемые данные.

У вас должен быть стабильный участок длиной 16 ед задержки 400Mhz= 2.5 ns, DDR, полпериода 1.25 ns/78 ps= 16 eд.

Лучше считается участок более ближний к нулю, меньше джиттер.

И в результате этой калибровки нужно получить средину этого участка. Те задержка равна средине этого участка.

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

[Алга 0]

Да, похоже на эти 3 ед нестабильного перехода.

Важно отработать алгоритм работы автомата для надежного и стабильного поиска середины(центра) данных.

Потом еще важна процедура битслип чтобы получить правильные данные.

 

[doom13 0]

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

[Алга 0]

Пока алгоритм у меня работает без всяких усреднений.

Те каждому тапу задержки (после смены величины задержки-

моя временная задержка на установление процесса) получаю одно значение данных фреймклока

(без накопления и усреднения) и которое затем использую для сравнения с предыдущей запомненной.

(Ошибка подстройки задержки на единицу (две) к ухудшению качества приема данных не приводит в наших условиях).

Параметры АЦП похожи 375 Мгц DDR, 12bit (В проекте 4 АЦП 12bit, 8 lvds пар линий данных плюс фреймклок каждый)

Пока алгоритм такой.

 

[Kronac 0]

Добрый день. Нужна помощь. Работаю с данным АЦП (ADS42LB69) в QDR режиме. XILINX Vivado 18.3, использую сигналы FRAME для декодирования отчётов. Установил и настроил все необходимые IDELEY и ISERDES. Приём данных осуществляется верно, вся структура вроде работает. Но очень не стабильно. От компиляции к компиляции разные результаты. Иногда проскакивают ошибки потери некоторых бит данных. Создал регистры для управления задержками на линиях данных и Фреймов. Подставляя туда каждый раз разные значения удаётся подобрать те, с которыми прошивка будет работать корректно, но в следующей прошивке данные значения уже не актуальны.  Смотрел примеры и по ним входные сигналы Frame были заданы как клоки на определённой частоте (например так: create_clock -period 4.464 -name FRAME0 -waveform {0.000 2.232} [get_pins U_79/O]) Я так понимаю, это не совсем правильный подход. Возможно мне нужно жёстко объявить input/output delay для моих пинов? Работал раньше только в Quartus, он это дело делает и подбирает автоматически, Вивадо этого вроде не умеет и приходится делать ручками. Сталкивался кто нибудь с похожей проблемой?