Приветствую уважаемые посетители форума !
Возникло некоторое непонимание как на Altera реализовать приём данных по LVDS с динамической подстройкой фазы, т.е чтобы данные считывались по центру битового периода(sample window), а не в зоне джиттера.
Думаю тут будет уместна эта картинка для наглядности:

К сожалению, Cyclone V, который на моей макетной плате, не содержит блоков DPA (dynamic phase alignment), а в альтеровских application notes я не увидел алгоритмов реализации(может плохо смотрел или не туда), поэтому смотрел как это реализовано у Xilinx(XAPP460, XAPP861, XAPP224), но неужели у альтеры нет ничего похожего ?
Данные принимаю при помощи мега функции ALTLVDS_RX с калибровкой по тестовым паттернам.

Есть мысли применить динамический сдвиг фазы (DPS), вот только неясно как определить границы бита.

Посмотрите реализацию Дмитрия Смехова aka dsmv
https://electronix.ru/forum/index.php?showt...=119622&hl=
https://github.com/dsmv/fpga_components/tre...cm_phase_v8/rtl

Комменты гитхаб зажевал, выкладываю расшифровку.


Есть подозрение, что подойдет на Альтеру без переделок вообще, порт DPS у нее вроде бы один в один.

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

Посмотрите еще вот здесь, совсем недавно было и как раз в тему:
https://marsohod.org/projects/proekty-dlya-...d3/347-fpga-tdc
https://marsohod.org/11-blog/348-fpga-tdc2

Спасибо, я вот натолкнувшись на эту статью и подумал что DPS мог бы помочь в моей задаче. Надо продумать алгоритм. Крутиться мысль одна, но пока она ещё мало покрутилась. Как докрутиться озвучу её

Динамический сдвиг фазы клока PLL конечно поможет, но при условии что все линии выровнены. Алгоритм калибровки описан в доках Xilinx, но для Cyclone V он неприменим. Там идет калибровка каждой линии, для установки клока в центр бита используются блоки IDELAY.

В этом то и проблема, что алгоритмы Xilinx не применить к Altera. А в Altera application notes я не нашёл как реализовать постройку фазы. С выравниванием линий проблема. Они кривые все изначально, стандарт на DVI это допускает.

Что-то подобное должно быть, но для Arria либо Stratix.

Да что-то подобное есть, реализуемое на блоках DPA(Dynamic Phase Alignment), которые есть только в Arria либо Stratix.

Итак, мысль в голове докрутилась до следующего алгоритма:
Для динамической подстройки фазы думаю применять DPS(dynamic phase shift).
В соответствии с протоколом DVI после каждой отрисованной линии(строки на экране) следует тестовая последовательность длинной 128 символов.

Изначально сдвиг фазы равен 0.
В течении всей длительности строки анализируем данные с выхода ALTLVDS_RX (по сути обычного дессерилайзера).
Если по истечению периода строки тестовая последовательность не обнаружена, значит возможно 2 варианта почему так произошло:
1. Захватываем данные в неправильной части окна (читай в зоне джиттера).
2. Неправильно принимаем последовательность, т.е необходимо выравнивание принимаемого слова.
Поэтому после того, как тестовая последовательность не обнаружена,производим сдвиг фазы.
И снова анализируем принимаемые данные, и двигаем фазу...

Если после того, как сдвигами фаз был достигнут сдвиг на целый период, но тестовая последовательность так и не найдена, значит проблема не в фазе, а в неправильном приёме тестовой последовательности. Поэтому портом RX_DATA_ALIGN модуля ALTLVDS_RX сдвигаем приём данных на 1 бит, т.е. делаем BIT_SLIP.
И снова начинаем анализировать принимаемые данные и двигать фазу, и сдвигать прием данных, если тестовая последовательность не найдена.

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

Итак, в процессе разработки DPA возник очень важный для меня вопрос.
Можно ли применять в качестве тактового сигнала, сигнал, не имеющий форму меандра, но полученный на PLL.
Eго вид примерно такой:

Делаю связку двух плат (max10-lite).
Есть кодированная последовательность 8b10b передаваемая по lvds_tx. На приемной стороне связка из lvds_rx и декодера 8b10b.
Передаю в начале К28.5 и пытаюсь подстроиться по ней.
Если работа происходит в пределах одной плис, или между двумя, но при наличии тактового сигнала с выхода lvds_tx - то все работает корректно.
Когда разрываю тактовый сигнал с выходящей плис - синхронизация имеет неустойчивый характер.
И есть внутренняя уверенность в том, что lvds без передачи и приема сигнала тактирования - пустая трата сил.

не тратьте времени.
нормально (робастно) принять TMDS (что из HDMI, что из DVI-D) на cyclone (не важно какой серии) не получится. ну либо получится, но с эффектом "мигалки" типа работает 1 раз из 9.

для приема нужны трансиверы. без вариантов.

Сигнал тактирования есть. В DVI есть 4 диф. линии, одна из которых синхросигнал. Я его принимаю, от него запускаю PLL и получаю восстановленный синхросигнал и 10x, для дессерилизации 8b10b.


Есть мысль отказаться от всей затеи принимать TMDS напрямую в cyclone, и применить внешние приёмники. Это было бы самым простым вариантом, я бы сказал даже самым правильным.
Есть мысль просто задать необходимые сдвиги фаз, так сказать угадать их, и получить тестовый рабочий проект. Не думаю что от температурного дрейфа sample window (глаз) уплывет сильно. Тем более частоты приёма не очень и большие. Но это действительно будет мигалка. С одним кабелем работает, с другим кабелем работать не будет.
У Xilinx (xapp460) фактически так-же как у меня происходит подстройка. Единственное принципиальное отличие, что они каналы могут одновременно подстраивать, а в altera придется поочередно подстраивать каналы, т.к PLL не умеет одновременно двигать несколько фаз.

Отпишусь о результатах.
Вроде получилось реализовать DPA на сдвигах фазы клока . Как минимум подстройка происходит, и на экране появляется изображение. Правда я пока вывожу только данные с одной линии. по этому на экране по большей части полная чушь, но очертания букв видны. Как доделаю проект, могу предоставить исходники.
UPD. Немного наврал. Пока не динамическая подстройка, а автоматическая подстройка при включении на центр Sample window. Динамическую пока не сделал.

Расскажите принцип работы системы, для каждой линии отдельный выход PLL используется?

Частоты какие?

Да. Для каждой линии отдельный вывод PLL, отдельный модуль ALTLVDS_RX, отдельный автомат калибровки. Хотя вывод rx_data_align (для организации bitslip) я не применяю. Сдвигаюсь на нужный бит я при помощи сдвигов фаз частоты.
На данный момент думаю над организации калибровки всех трех линий: основная проблема в том, что PLL может в один момент времени сдвигать только 1 частоту, поэтому необходимо придумать механизм калибровки всех линий.


Пока частота данных 40 МГц. В посылке 10 бит, поэтому частота десериализации 400 МГц.
Частота VCO PLL так-же получилась 400 МГц, поэтому двигать могу 1\8 этой частоты , т.е порядка 315 пс.
Была бы больше частота VCO была бы лучше калибровка, но я почему-то не могу найти в GUI настройку "enable phase shift step resolution"

А какую-нибудь Альтеровскую доку по этой теме нашли?

К сожалению нет.
За основу брал доку от xilinx (xapp460), сам принцип определения границ бита, хотя и его несколько по-другому реализовал. Но пока у меня проект совсем-совсем сырой. Не удивлюсь, что переделок будет ещё очень много.
Альтеровскую доку an433, я не очень понял. Думаю потом поглубже изучить её. Как я понял, там не рассматривается вариант, когда соотношения фазы частоты и данных не совпадает и может быть практически любым, и заранее неизвестным, как в случае приема DVI.

Имхо. Выбросить ALTLVDS_RX, и самому все написать.
Клок приемника немного сдвинуть по частоте относительно клока передатчика, настолько, чтобы гарантированно сохранялся знак разностной частоты.
Принимать по 2 каналам с постоянным сдвигом по фазе, можно выделить и усреднить биения, по ним и синхронизироваться с передатчиком, выбирая нужный канал.

Да действительно ALTLVDS_RX проще выбросить нафиг, с ним одна морока. Поскольку этот гад требует для сигналов тактирования и разрешения вставлять специальный буфер между собой и PLL. Единственный плюс это то, что по даташиту ALTLVDS_RX умеет работать со скоростью 800Mpbs. На простых регистрах не думаю, что смогу достичь такой скорости. Тут думаю можно ускорить приём применяя DDR регистры....
Что-бы не думать над фазировкой клоков, я применяю FIFO для передачи между доменами, поскольку в моём случае фаза постоянно меняется....

Вот тут можно чуть поподробнее объяснить принцип ? Если честно я не очень понял Вас.
UPD
Пока работает без ALTLVDS_RX. Приёмник свой написал.

A,B - сдвинутые по времени выборки, XOR дает биения, которые надо усреднить и использовать для коммутации A,B на выход.
"Скольжение" всегда в одну сторону, если разностная частота не меняет знак.
Использовал этот принцип в приемнике 100base-TX.

Когда делал 100base-TX, динамически двигать фазу PLL не умел.
Со сдвигом фазы можно добавить синхронный канал с динамическим сдвигом фазы.

Спасибо ! Интересная задумка. Подумаю на досуге.
А можете порекомендовать какую-нибудь литературу где про такие вот интересности рассказывается ?

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

Итак господа. Отпишусь о результатах. DVI приёмник работает, калибруется. Приём сигнала стабильный, и по прошествии несколько часов не сбивается. Но принимает данные некорректно . Т.е. изображение принимается, буквы, цифры отчетливо видны, но в цветах полная неразбериха. Либо я TMDS decoder неправильно написал, либо данные в DVI передаются не в формате RGB. Либо ещё что-то. Что странно, картина очень похожа на то, что разряды перепутаны, старший с младшим... буду проверять. В процессе проверки нашел ошибку в datasheet на плату, там перепутали разряды ЦАП для вывода VGA.
Подкиньте идею как проверить корректность приема ?
Есть у меня смутные подозрения что данные передаются не в RGB а в YCbCr. Завтра с утра постараюсь выложить картинку того, как принимаются данные. А может на свежую голову ещё какое решение придет.
А если подскажите каким битом вперед передаются данные(младшим или старшим), то было бы вообще отлично. DVI spec 1.0 уже давно глаза мозолит, может и не заметил очевидной информации.

Выставьте вручную множитель и делитель PLL. Таким образом сможете повысить частоту VCO и разрешение сдвига фаз.

Итак. Мучения с DVI походят к концу. Сегодня получил стабильное изображение с корректными цветами.
Очень долго времени не мог разобраться с некорректным отображением цветов по ряду причин:
1. Я принимал данные неправильно начиная со старшего. А данные передаются начиная с младшего бита.
2. В спецификации DVI 1.0 контрольные слова не соответствуют тому, что передается на самом деле. Контрольные слова соответствуют спецификации на HDMI.
3. Так совпало, что с неправильным приёмом данных, и с неправильными контрольными словами я получил стабильное изображение с некорректными цветами... Как по мне, так ошибка очень неочевидная. Поскольку с неправильным приёмом я получил правильные тайминги кадровой и строчной синхронизации для вывода на VGA...
Думаю, как до "ума" доведу проект выложу его на Guthub.

Было бы интересно взглянуть

Пользовал и корку lvds_rx и просто на регистре десериализатор, до 480Мб/с работало более менее, без динамической подстройки, но не hdmi, а 1 сигнал. Для повышения стабильности нужно конечно правильно разводить плату, ибо далеко не все пины могут работать в режиме lvds_rx (там используется специальный хардварный высокоскоростной fifo-регистр), прописывать констрейны и правильно располагать на кристалле. Также может быть полезна идея использования lvds_rx в режиме ddr, для него не требуется pll и он позволяет понизить частоту в 2 раза.

К сожалению отказаться от PLL нет возможности поскольку частота в DVI не строго соответствует стандартам VESA , а может плавать в больших пределах. И эту частоту необходимо применять как опорную для PLL. Другого выхода я не вижу пока.
А вот от корки LVDS_RX я временно отказался по ряду причин:
1. Применение внешнего PLL (extrenal PLL) требует установки между собой и коркой LVDS_RX специального клокового буфера.
2. Применение LVDS_RX требует формирование сигнала ENA на PLL. Т.е для 3 LVDS линий мне придется потратить 6 выходов PLL (по 2 на каждую LVDS_RX). Применение одной LVDS_RX для 3 линий невозможно, поскольку все линии рассинхронзированны друг относительно друга, и каждую линию надо подстраивать отдельно.
3. Для динамической подстройки необходимо ещё 3 модуля LVDS_RX которые работают в "фоновом режиме".
Т.е 3 основных приемника LVDS_RX включаются при старте, калибруются и выдают данные.
А 3 приёмника в фоновом проверяют текущее значение положения фронтов относительно потока данных. И через определенное время, подправляют прием основных приемников. По стандарту DVI это необходимо делать каждые 50 ms.
3. Судя по USER GUIDE у LVDS_RX режим DDR включается только на определенных коэффициентах дессерилизации.
На данный момент я добился стабильного приема видео потока (разрешение 800х600 это 400 Мб/с по каждой линии) на протяжении почти 8 часов. Синхронизация и подстройка была один раз при включении. Приёмников, работающих в фоновом режиме для подстройки я ещё не делал. Принимаю в обычные регистры но похоже, что я приблизился к потолку. Более 450 МГц обычные регистры не вытягивают у меня. Сейчас думаю попробовать принимать в DDR регистры. Есть ещё одна мысль как обойти обязательное применение клоковых буферов между PLL и LVDS_RX, но озвучивать не буду. Не получится и фиг с ним.

Так идея в том и состоит, что можно на быстрых DDR-регистрах понизить частоту в 2 раза до ~200МГц, а дальше десериализировать на обычных внутренних.

Можно же использовать например internal PLL, чем не устраивает?

Ну и наверное было бы лучше поставить внешние CDR на каждую линию, если в DVI всё так плохо с тактовыми.

Наверное тем, что на каждый блок lvds_rx будет заграбастан отдельный PLL. У ТС целых три приемных линии - минус три PLLa. Если еще тактовую взять, то все четыре.

Изначально задача упирается в то, что прежде чем принимать биты данных и обрабатывать их необходимо подстроиться на sample window каждой линии. В случае каких-то вншешних LVDS источников данных, например таких как АЦП - задача сильно упрощается тем, что там частоты, как правило привязаны к кадровой частоте и разбежки между данными и этой частоты почти нет ( во всяком случае в нескольких АЦП, datasheet на которые я читал было именно так), и задача приёма сводиться к тому, что необходимо подстроиться на правильный порядок приёма битов, подсчитать значения TCCS, RKSM, и выставить установить клок в центр данных. И эти задержки будут всегда одинаковые, при включении устройства. Поскольку физически АЦП и ПЛИС размещены на одной плате. Тут я могу ошибаться, поскольку я не очень подробно изучал доку AN433, может быть я и не правильно её понял.
В случае приёма DVI сигнала у нас допустимая разбежка между синхросигналом и каждой линии данных допускается в 0,6Tpixel, т.е. в одной линии фаза данных могут убежать вперед на 6 бит. А в другой линии назад на 6 бит. Фактически в DVI сигналы никак не привязаны друг к другу (если верить спецификации ver 1.0). Я конечно могу подсчитать TCCS, RKSM. Но эти данные будут работать только с тем кабелем который подключен на данный момент. Сменить кабель - и задержки будут другие.
Поэтому при решении задачи я исходил из-того, что перед приёмом данных, мы должны автоматически подстроиться на sample window каждой линии и только потом уже обрабатывать эти данные
Применяя ALTLVDS_RX с internal PLL я должен указать сдвиг фазы клока для каждой из линий данных, а по условию задачи сдвиг фазы неизвестен изначально, и его требуется найти.
Применив extrenal PLL я могу вручную управлять сдвигом фазы каждого клока, и таким образом я могу сам настроиться на центр каждой линии данных, и калиброваться уже могу при включении, и таким образом я не буду зависеть от задержек, вносимых физической средой передачи. Ну и тратить 3 PLL как -то жалко на это.
Под внешними CDR Вы имеете ввиду внешние микросхемы дессерилайзеров ?

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



Нет, просто восстановитель тактовой типа adn2816

Хм... А может действительно получиться. Попробую в кишках покопаться. Спасибо !
Восстановитель тактовой - это хорошо. Но тогда правильнее всего изначально внешний DVI приёмник поставить.
Но на данный момент на моей макетной плате (de1-soc mtl 2) ничего этого нет и приходится выкручиваться. Даже внешний согласователь CML --> LVDS пришлось на коленке собирать.
Как ни странно jitter получился совсем небольшой, в районе 500 ps с каждой стороны sample window. Сам глаз навскидку получился 1,5 нс.

Сейчас в процессе написания собственного приёмника LVDS на DDR регистрах. В процессе написания приёмника столкнулся с непонятной работой PLL.
При динамическом сдвиге фазы необходимо указывать адрес частоты , которую надо двигать.
Т.е:
CLK0 - Адрес B"00000"
CLK1 - Адрес B"00001"
CLK2 - Адрес B"00010"
И.Т.Д.
Но столкнулся с тем, что при указании адреса CLK0 у меня ещё одновременно с этой частотой двигается частота CLK2....
А при указании адреса CLK2 частота не двигается вообще.
Кто сталкивался с подобным поведением ?
И вообще, где указана максимально возможная частота работы регистров. В частности модуль ALT_LVDS_RX может принять максимум 840 Mbps
А если его писать собственный приёмник, чем я сейчас и занимаюсь, то как подсчитать максимально возможную теоретическую скорость на DDR регистрах ?

Ищите документ по ключевым словам Switching Characteristics для своего семейства.
ЗЫ. Если не получится использовать сдвиг по фазе опорной частоты, то возможен еще вариант - задействовать delay chain во входном буфере (для разных семейств корка называется по-разному), там точность подстройки десятки ps.

Спасибо !
Только я не опорную частоту двигаю(от которой запускаю PLL) а частоту дессерилизаци. Для каждого канала по отдельности.
UPD
Действительно, при выставленном адресе B"00000" когда должна двигаться только фаза частоты CLK0 двигается ещё фаза частоты CLK2.
При выставленном адресе B"00010" когда должна двигаться фаза частоты CLK2, её фаза не двигается.
Смотрел по signal tap, как говориться на живую.
Либо где-то datasheet врет, и там адресация другая.
Либо разводчик вместо частоты CLk2 на модуль приёма завел частоту CLK0. Может ли быть такое ? Хотя если смотреть по RTL Viewer то все частоты приходят туда, куда должны.
UPD.
Мистика. Поменял частоты местами и всё заработало.
Раньше было:
CLK0 - адрес B"00000" - частота приема по линии RX0
CLK1 - адрес B"00001" - частота приема по линии RX1
CLK2 - адрес B"00010" - частота приема по линии RX2
CLK3 - адрес B"00011" - восстановленная кадровая частота

Поменял на так:
CLK0 - адрес B"00000" - восстановленная кадровая частота
CLK1 - адрес B"00001" - частота приема по линии RX0
CLK2 - адрес B"00010" - частота приема по линии RX1
CLK3 - адрес B"00011" - частота приема по линии RX2
И всё заработало как должно быть.

Адресация там какая? Может байтовую со словной путаете?

Да не, не путаю. В апликухе так и написано, как я делаю. (AN661 страница 7)

А как правильно законстрейнить вариант в случае динамической подстройки фазы ?
Такое подозрение данные пути анализировать вообще смысла нет т.к Tsu Th автоматически будут выполняться.
Поэтому по входному клоку и данным надо писать констрейн set_false_path
Во всяком случае специалит от Altera говрит что не надо https://www.alteraforum.com/forum/showthread.php?t=227 :

Всё мучаюсь с констрейнами
В реальности железка стабильно работает на скорости 780Mbs по каждому каналу.
На скорости 1080Mbs появляются проблемы с некорректным отображением цветов, хотя приём данных еще более менее стабильный. Но тут уже скорее у меня LVDS буферы на микросхемах ds90lv001 не успевают работать, поскольку они по даташиту расчитаны на скорость 800Mbs.
Так вот TimeQuest мне говорит, что выше ~400Mbs работать не будет, но констрейны у меня кривые.
Сейчас основная проблема в том, что не знаю:
1. Как указать, что у меня фаза подстраивается на центр данных.

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

На данный момент пока задал такие вот констрейны:

Вы требуете слишком повышенных обязательств от lvds, даже сама альтера обязуется работать не более чем на 800МГц. Если надо больше, то для этого придумали спец. GX-трансиверы и pcml.

Так я и не требую работать со скоростью более 800Mbs. Про скорость выше 800Mbs - это я сказал к слову.
На данный момент я хочу правильно обконстрейнить проект.
Ведь неправильно, что Timequest говорит, что выше 400Mbs работать не будет, а реальная железка работает на 800Mbs +, очевидно что заданы неправильные временные ограничения.
Вот я и хочу разобраться, как задать их правильно. Но, к сожалению, примера констрейнов при динамической подстройки я не нашел.
UPD.
Я не знаю как:
1. Задать констрейны на входные данные, поскольку временные отношения между данными и клоком могут быть абсолютно любые. Более того, они могут быть разные при каждом включении питания.
2. Задать констрейн на клок чтения(приёма данных), поскольку фаза этого клока не фиксированная и подстраивается при включении питания.

Забыл написать. Проблема была не там где я её искал.
Поскольку про сдвиг частоты я определяю по косвенным признакам - изменение приёма данных по линиям, на видео это видно визуально. То оказалось всё гораздо интереснее. Проблема не в том, что частота не двигалась, а в том, что частота не создавалась. Т.е на RTL видно все частоты которые я создаю на PLL, но в technology map этой частоты уже нет. Более того, TimeQuest не видит этих частот. При чем Quartus удаляет частоты с одинаковым сдвигом фаз. Т.е когда у меня были указаны частоты
CLK0 - 200 Mhz - сдвиг фаз 0 градусов
CLK1 - 200 Mhz - сдвиг фаз 0 градусов
CLK2 - 200 Mhz - сдвиг фаз 0 градусов
Quartus удалил частоты CLK1, CLK2. И даже не выдал сообщение об этом, гад такой. А на RTL все красиво. Все частоты есть.
Если же указать каждой из частоты разные сдвиги фаз, то он их не удаляет.

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

А какую именно из большого множества документов ?
Читал AN433, https://www.alteraforum.com/forum/showthread.php?t=4806, и ещё несколько. Но тут скорее связано в неполном понимании самого процесса расчета Timequest временных ограничений. Сейчас как раз читаю и пытаюсь понять как вообще происходит расчет временных ограничений, и пытаюсь разобраться как временные ограничения влияют на этот расчет.

Именно так и делаю. Каждый раз как я принял 10 бит по LVDS я их отправляю в FIFO. А читаю с FIFO уже на нормальной частоте.