Приём LVDS с динамической подстройкой фазы, Как это реализовать на Altera, не имея спец. блоков DPA Опции

[Flip-fl0p]

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

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

[Flip-fl0p]

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

[dm.pogrebnoy]

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

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

------------------------------------------------------------------------------
--
-- Description : Узел автоподстройки фазы тактовой частоты
--
-- Сигнал входной тактовой частоты поступает на триггер во входном буфере.
-- Выходной сигнал DCM сдвигается до тех пор, пока фаза сигнала не попадёт
-- в область нестабильного защёлкивания сигнала входной тактовой частоты.
-- Автомат подсчитывает число 1 и 0 на интервале 1024 такта, и принимает
-- решение о сдвиге фазы. При достижении максимального или минимального
-- значения сдвига производится инверсия сигнала поступающего на DCM,
-- сброс DCM и автомата управления в начальное состояние.
--
-- Узел включает в себя автомат определения изменения тактовой частоты.
-- При изменении входной тактовой частоты происходит сброс DCM и
-- начинается новый цикл подстройки фазы
--
-- Тактовая частота clk используется для определения изменения тактовой
-- частоты. На входе clk частота должна быть всегда
--
-------------------------------------------------------------------------------
--
-- Version 1.0 17.03.2014 Dmitry Smekhov
-- Создан из ctrl_dcm_phase_v6 v1.5
--
--
-------------------------------------------------------------------------------

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

[Flip-fl0p]

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

[spectr]

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

[Flip-fl0p]

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

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

[doom13]

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

[Flip-fl0p]

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

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

[doom13]

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

[Flip-fl0p]

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

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

[Flip-fl0p]

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

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

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

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

[Flip-fl0p]

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

Код

________/TTTT\___________________________________/TTTT\___________________________________/TTTT\___________________________________

Сообщение отредактировал Flip-fl0p - Jun 21 2017, 16:57

[Александр77]

...
Поэтому после того, как тестовая последовательность не обнаружена,производим сдвиг фазы.
И снова анализируем принимаемые данные, и двигаем фазу...
...

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

[krux]

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

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

[Flip-fl0p]

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

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

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

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

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

Сообщение отредактировал Flip-fl0p - Jun 21 2017, 20:21

[Flip-fl0p]

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

Сообщение отредактировал Flip-fl0p - Jun 26 2017, 12:44

[doom13]

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

[Leka]

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

[Flip-fl0p]

Расскажите принцип работы системы, для каждой линии отдельный выход 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"

[doom13]

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

[Flip-fl0p]

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

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

[Leka]

Пока частота данных 40 МГц. В посылке 10 бит, поэтому частота десериализации 400 МГц.

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

[Flip-fl0p]

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

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

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

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

Сообщение отредактировал Flip-fl0p - Jun 27 2017, 11:17

[Leka]

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

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

Сообщение отредактировал Leka - Jun 27 2017, 17:25

Прикрепленные изображения

 

[Flip-fl0p]

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

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

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

[Leka]

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

Сообщение отредактировал Leka - Jun 28 2017, 15:06

[Flip-fl0p]

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

Сообщение отредактировал Flip-fl0p - Jun 29 2017, 20:08

[dvladim]

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

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

[Flip-fl0p]

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

[Kuzmi4]

...как до "ума" доведу проект выложу его на Guthub.

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

[Magnum]

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

[Flip-fl0p]

Пользовал и корку 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, но озвучивать не буду. Не получится и фиг с ним.

Сообщение отредактировал Flip-fl0p - Jul 6 2017, 18:43

[Magnum]

3. Судя по USER GUIDE у LVDS_RX режим DDR включается только на определенных коэффициентах дессерилизации.

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

[Magnum]

1. Применение внешнего PLL (extrenal PLL) требует установки между собой и коркой LVDS_RX специального клокового буфера.

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

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

[Александр77]

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

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

[Flip-fl0p]

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

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

Изначально задача упирается в то, что прежде чем принимать биты данных и обрабатывать их необходимо подстроиться на 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 Вы имеете ввиду внешние микросхемы дессерилайзеров ?

Сообщение отредактировал Flip-fl0p - Jul 7 2017, 05:27

[Magnum]

Применяя ALTLVDS_RX с internal PLL я должен указать сдвиг фазы клока для каждой из линий данных, а по условию задачи сдвиг фазы неизвестен изначально, и его требуется найти.
Применив extrenal PLL я могу вручную управлять сдвигом фазы каждого клока, и таким образом я могу сам настроиться на центр каждой линии данных, и калиброваться уже могу при включении, и таким образом я не буду зависеть от задержек, вносимых физической средой передачи. Ну и тратить 3 PLL как -то жалко на это.

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

Под внешними CDR Вы имеете ввиду внешние микросхемы дессерилайзеров ?

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

[Flip-fl0p]

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



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

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

Сообщение отредактировал Flip-fl0p - Jul 7 2017, 06:52

[Flip-fl0p]

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

Сообщение отредактировал Flip-fl0p - Jul 27 2017, 08:05

[bogaev_roman]

И вообще, где указана максимально возможная частота работы регистров. В частности модуль ALT_LVDS_RX может принять максимум 840 Mbps
А если его писать собственный приёмник, чем я сейчас и занимаюсь, то как подсчитать максимально возможную теоретическую скорость на DDR регистрах ?

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

[Flip-fl0p]

Ищите документ по ключевым словам 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
И всё заработало как должно быть.

Сообщение отредактировал Flip-fl0p - Jul 27 2017, 10:04

[warrior-2001]

при выставленном адресе B"00000"

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

[Flip-fl0p]

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

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

[Flip-fl0p]

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

First of all, I assume you are talking about timing the ALTLVDS when DPA is not enabled. If DPA is enabled, the clock is centered in the data valid window dyanamically, therefor timing analysis doesn't make sense and cannot be performed.

Сообщение отредактировал Flip-fl0p - Jul 28 2017, 08:29

[Flip-fl0p]

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

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

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

Код

set_time_format -unit ns -decimal_places 3
derive_clock_uncertainty
create_clock -name {CLK} -period 108MHz [get_ports {CLK}]

create_clock -period 540MHz -name VIRT_RX0_CLK
create_clock -period 540MHz -name VIRT_RX1_CLK
create_clock -period 540MHz -name VIRT_RX2_CLK


derive_pll_clocks

set RX0_CLK PLL_COMP|my_pll_inst|altera_pll_i|cyclonev_pll|counter[1].output_counter|divclk
set RX1_CLK PLL_COMP|my_pll_inst|altera_pll_i|cyclonev_pll|counter[2].output_counter|divclk
set RX2_CLK PLL_COMP|my_pll_inst|altera_pll_i|cyclonev_pll|counter[3].output_counter|divclk

set_clock_groups -exclusive -group [list $RX0_CLK VIRT_RX0_CLK]
set_clock_groups -exclusive -group [list $RX1_CLK VIRT_RX1_CLK]
set_clock_groups -exclusive -group [list $RX2_CLK VIRT_RX2_CLK]

[Magnum]

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

[Flip-fl0p]

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

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

Сообщение отредактировал Flip-fl0p - Aug 4 2017, 11:22

[Flip-fl0p]

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

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

Сообщение отредактировал Flip-fl0p - Aug 4 2017, 12:51

[bogaev_roman]

Я не знаю как:
1. Задать констрейны на входные данные, поскольку временные отношения между данными и клоком могут быть абсолютно любые. Более того, они могут быть разные при каждом включении питания.
2. Задать констрейн на клок чтения(приёма данных), поскольку фаза этого клока не фиксированная и подстраивается при включении питания.

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

[Flip-fl0p]

почитайте документацию -

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

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

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

Сообщение отредактировал Flip-fl0p - Aug 4 2017, 13:11

[bogaev_roman]

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

Посмотрите, что они советуют прописывать при разных настройках корки lvds serdes https://www.altera.com/content/dam/altera-w.../ug_altlvds.pdf
На какой частоте пишете, на какой считываете - источник один, а фаза произвольная? Каким образом происходит пересинхронизация - банально пишете на одной, а считываете на другой?

[Flip-fl0p]

Посмотрите, что они советуют прописывать при разных настройках корки lvds serdes https://www.altera.com/content/dam/altera-w.../ug_altlvds.pdf
На какой частоте пишете, на какой считываете - источник один, а фаза произвольная? Каким образом происходит пересинхронизация - банально пишете на одной, а считываете на другой?

На опорной частоте TMDS_CLK - 40 МГц я запускаю PLL. PLL в режиме source synchronous, хотя в моем случае это никак не влияет на результат.
Поскольку у меня прием идет на DDR регистрах то на PLL я формирую следующие частоты:
CLK_40MHz - 40 МГц
RX0_CLK -200 МГц
RX1_CLK -200 МГц
RX2_CLK -200 МГц
Частоты RX0_CLK, RX1_CLK, RX2_CLK изначально имеют разные сдвиги фаз. Иначе Quartus удаляет частоты RX1_CLK и RX2_CLK. Но на начальный сдвиг фаз нам наплевать, поскольку всё равно мы их двигаем блоком подстройки фазы.
Запрос на чтение FIFO у меня постоянно разрешен и частота чтения FIFO - это частота CLK_40MHz.
Принимаю данные на частоте дессерилизации.
Т.е для приёма данных по линии RX0 я применяю частоту RX0_CLK, которую блоком подстройки фазы я устанавливаю в центр окна.
Каждые 5 тактов частоты RX0_CLK я формирую запрос на запись данных в FIFO. Частота записи у меня естественно RX0_CLK .
Для каждой линии приёма у меня свой FIFO буфер. Общее для них это частота чтения - CLK_40MHz
Лучше конечно выложить сюда проект, многие вопросы отпадут сами собой и появятся новые. Но у меня проект ещё очень сырой и мне просто стыдно такое выкладывать на всеобщее обозрение.

Сообщение отредактировал Flip-fl0p - Aug 4 2017, 14:19

[Corner]

Частота 800 МГц вытекает из 2 x максимальная частота тактирования регистров. Для этой ПЛИС 400 МГц потолок.

[Flip-fl0p]

Частота 800 МГц вытекает из 2 x максимальная частота тактирования регистров. Для этой ПЛИС 400 МГц потолок.

А где Вы нашли это если не секрет ? Я весь даташит прочитал, и нашёл только:
Global clock and Regional clock 550 MHZ (стр.39)
Максимальная скорость встроенного LVDS приёмника 875Mbs (стр.48)
А вот с какой скоростью могут работать регистры в ячейках я не увидел. Если что у меня speedgrade -C6 (5CSEMA5F31C6).
Да я и не собираюсь выжимать больше, поскольку у меня согласователь уровней CML -> LVDS ограничен скоростью 800 Mbs.
Сейчас основная задача разобраться с временными ограничениями и задать констрейны, чтобы реальная железка соответствовала тому, что говорит Timequest.

[bogaev_roman]

А где Вы нашли это если не секрет ? Я весь даташит прочитал, и нашёл только:
Global clock and Regional clock 550 MHZ (стр.39)
Максимальная скорость встроенного LVDS приёмника 875Mbs (стр.48)
А вот с какой скоростью могут работать регистры в ячейках я не увидел. Если что у меня speedgrade -C6 (5CSEMA5F31C6).

Мне тоже интересно, откуда такие цифры. Согласно документации https://www.altera.com/content/dam/altera-w...-v/av_51002.pdf
Global clock and Regional clock 525MHz (1-43)
SERDES factor J = 1 to 2, Uses DDR Registers (1-51, (79*) - The maximum ideal data rate is the SERDES factor (J) x the PLL maximum output frequency (fOUT), provided you can close the design timing and
the signal integrity simulation is clean) Далее, кстати, на 1-44 fOUT_max=400MHz (This specification is limited by the lower of the two: I/O fMAX or FOUT of the PLL). Но это в случае без DPA, для DPA фактор сериализации начинается от 4.

Каждые 5 тактов частоты RX0_CLK я формирую запрос на запись данных в FIFO. Частота записи у меня естественно RX0_CLK .
Для каждой линии приёма у меня свой FIFO буфер. Общее для них это частота чтения - CLK_40MHz

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

[Flip-fl0p]

Мне тоже интересно, откуда такие цифры. Согласно документации https://www.altera.com/content/dam/altera-w...-v/av_51002.pdf
Global clock and Regional clock 525MHz (1-43)
SERDES factor J = 1 to 2, Uses DDR Registers (1-51, (79*) - The maximum ideal data rate is the SERDES factor (J) x the PLL maximum output frequency (fOUT), provided you can close the design timing and
the signal integrity simulation is clean) Далее, кстати, на 1-44 fOUT_max=400MHz (This specification is limited by the lower of the two: I/O fMAX or FOUT of the PLL). Но это в случае без DPA, для DPA фактор сериализации начинается от 4.

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

Так у меня CYCLONE V а не ARRIA V
А зачем мне делать пересинхронизацию, если я принятые данные отправляю в DC FIFO буфер ? Я принял слово и отдал в FIFO буфер. Сам буфер обеспечит синхронизацию, для этого его и ставил.
Я сейчас привожу проект к тому виду, чтобы можно было показать общественности. Думаю, после того как проект выложу (ну и фиг с ним, что сырой), диалог будет более конструктивный.
Пока выложу структуру приемника по одной линии.
А слаки возникают из-за того, что данные слишком долго идут от выводов DDR регистра до регистра-приёмника.
Ну и заодно вопрос про мультициклы. Является ли путь от SHREG до PARALEL_REG мультицикловым или нет.



Сообщение отредактировал Flip-fl0p - Aug 8 2017, 07:56

[bogaev_roman]

Так у меня CYCLONE V а не ARRIA V

А, перепутал, извиняюсь.

А слаки возникают из-за того, что данные слишком долго идут от выводов DDR регистра до регистра-приёмника.

Крайний метод - прибить гвоздями поближе к пинам -

set_location

Ну и заодно вопрос про мультициклы. Является ли путь от SHREG до PARALEL_REG мультицикловым или нет.

Хотел вначале написать да, но на самом деле нет - входные данные меняются каждый такт и актуальны они только один такт. А вот путь между parallel_reg/load_ena_reg и out_fifo в обещем случае да (если частоты от одного источника).

А зачем мне делать пересинхронизацию, если я принятые данные отправляю в DC FIFO буфер ? Я принял слово и отдал в FIFO буфер. Сам буфер обеспечит синхронизацию, для этого его и ставил.

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

[Димыч]

Вопрос топикастеру: сколько сейчас у Вас ресурсов съел проект в использумой ПЛИСине?
спасибо!

[Flip-fl0p]

Весь проект, а это приём по DVI видеопотока и вывод его на VGA монитор, занял в районе 650 логических ячеек CYCLONE V. После оптимизации всего этого дела, проект занимает в районе 250 логических ячеек.
На данный момент не реализовал блок динамической подстройки, который с определенной периодичностью подстраивает частоты чтения. Сейчас у меня идет калибровка "в ручном режиме" Т.е я вручную устанавливаю номер частоты, которою хочу откалибровать, и вручную запускаю автомат подстройки. Так проще на отладке. Целиком весь проект в Modelsim безумно долго моделируется...
P.S. Про оптимизацию я имею ввиду когда Quartus выполнит полную компиляцию проекта.

Сообщение отредактировал Flip-fl0p - Aug 8 2017, 16:52

[Димыч]

Спасибо! Довольно немного.
Дело в том, что собираюсь сделать что-то подобное на MAX10 и оцениваю необходимую "жирность" чипа. Ставить внешний ресивер (например, TFP401) пока нет желания

[Corner]

Спасибо! Довольно немного.
Дело в том, что собираюсь сделать что-то подобное на MAX10 и оцениваю необходимую "жирность" чипа. Ставить внешний ресивер (например, TFP401) пока нет желания

У МАХ10 есть DDR?

[Flip-fl0p]

У МАХ10 есть DDR?

Если верить "MAX 10 External Memory Interface User Guide" то есть DDR регистры. И судя по "MAX 10 High-Speed LVDS I/O User Guide" их можно применять как приёмники LVDS

Сообщение отредактировал Flip-fl0p - Aug 16 2017, 05:04

[doom13]

Приветствую.
Смотрю доку на Cyclone 10, правильно ли понимаю, что блок DPA работает автоматом без всяких управляющих сигналов? Т.е. подобрать определенное значение задержки не получится, все настроится автоматом оптимально?

[_Anatoliy]

Очень похоже что так.

Dynamic phase alignment (DPA) is independent of the skew between channels or between channels and the clock, and it continuously aligns the data to the clock.

[doom13]

Т.е. оно круче чем у Xilinx (Kintex-7), там автомат калибровки необходим, но тапов там больше.

Всё само сделает, круто

В Arria V использовали эти блоки?

[_Anatoliy]

В Arria V использовали эти блоки?

Пока нет. Если бы использовал ответил бы гораздо уверенней
По структуре шины управления не нашёл.

Эскизы прикрепленных изображений

 

[Flip-fl0p]

Пока нет. Если бы использовал ответил бы гораздо уверенней
По структуре шины управления не нашёл.

А есть где нибудь информация по какому принципу работают блоки DPA, т.е. как определяется центр окошка ?

[_Anatoliy]

А есть где нибудь информация по какому принципу работают блоки DPA, т.е. как определяется центр окошка ?

А откуда информация что DPA подстраивается именно под максимум глазка? Можете указать документ?

[Flip-fl0p]

А откуда информация что DPA подстраивается именно под максимум глазка? Можете указать документ?

Прямо об этом вроде нигде не говорится.
Но вот тут вот:
https://www.altera.com/en_US/pdfs/literature/an/an236.pdf

Код

The dynamic phase aligner block uses the incoming
data and clocks to generate a new clock that is phase-aligned with the data.

[_Anatoliy]

Прямо об этом вроде нигде не говорится.

Да, я тоже уже успел кое что найти. А то сбило что у них режимы либо DPA либо CDR, а это всё таки не одно и то же если DPA работает по глазку.

Эскизы прикрепленных изображений