[Magnum 0]

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

[Flip-fl0p 4]

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

Изменено 6 июля, 2017 пользователем Flip-fl0p

[Magnum 0]

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

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

[Magnum 0]

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

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

 

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

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

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

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

[Flip-fl0p 4]

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

Изменено 7 июля, 2017 пользователем Flip-fl0p

[Magnum 0]

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

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

 

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

 

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

 

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

 

[Flip-fl0p 4]

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

 

 

 

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

Хм... А может действительно получиться. Попробую в кишках покопаться. Спасибо !

Восстановитель тактовой - это хорошо. Но тогда правильнее всего изначально внешний DVI приёмник поставить.

Но на данный момент на моей макетной плате (de1-soc mtl 2) ничего этого нет и приходится выкручиваться. Даже внешний согласователь CML --> LVDS пришлось на коленке собирать.

Как ни странно jitter получился совсем небольшой, в районе 500 ps с каждой стороны sample window. Сам глаз навскидку получился 1,5 нс.

Изменено 7 июля, 2017 пользователем Flip-fl0p

[Flip-fl0p 4]

Сейчас в процессе написания собственного приёмника LVDS на DDR регистрах. В процессе написания приёмника столкнулся с непонятной работой PLL.

При динамическом сдвиге фазы необходимо указывать адрес частоты , которую надо двигать.

Т.е:

CLK0 - Адрес B"00000"

CLK1 - Адрес B"00001"

CLK2 - Адрес B"00010"

И.Т.Д.

Но столкнулся с тем, что при указании адреса CLK0 у меня ещё одновременно с этой частотой двигается частота CLK2....

А при указании адреса CLK2 частота не двигается вообще.

Кто сталкивался с подобным поведением ?

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

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

Изменено 27 июля, 2017 пользователем Flip-fl0p

[bogaev_roman 0]

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

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

Ищите документ по ключевым словам Switching Characteristics для своего семейства.

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

[Flip-fl0p 4]

Ищите документ по ключевым словам 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

И всё заработало как должно быть.

Изменено 27 июля, 2017 пользователем Flip-fl0p

[warrior-2001 0]

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

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

[Flip-fl0p 4]

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

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

 

[Flip-fl0p 4]

А как правильно законстрейнить вариант в случае динамической подстройки фазы ?

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

Изменено 28 июля, 2017 пользователем Flip-fl0p

[Flip-fl0p 4]

Всё мучаюсь с констрейнами :crying:

В реальности железка стабильно работает на скорости 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]