Восстановление частоты из потока цифр, Как получить качественную частоту? Опции

[Koluchiy]

Здравствуйте, уважаемые гуру.

Подскажите пожалуйста, как подступиться к следующей проблеме.

Для начала краткая предыстория.

Есть микросхема Spartan-6LXT.
К ней на вход GTP приходит поток STM-1 (155.52Mhz).
Надо восстановить из потока опорную частоту в более-менее приличном виде.

Трабла в следующем. GTP Спартана-6 поддерживает частоты от 614МГц.
Соответственно, работать напрямую с потоком 155.52 МГц оно не может.
Можно использовать передискретизацию - GTP настраивается на частоту в (допустим) 4 раза больше, принимать и передавать каждый бит 4 раза.

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

Пришлось пойти по другому пути - GTP настроил на режим lock-to-reference, т.е. входной поток принимался на собственной частоте микросхемы (которая может быть отличной от частоты входного сигнала).
Входной поток получался вида:
0000111100001111000001111000011110000111100001111100001111
То есть в случае несоответствия частот принимаемого потока и опорной микросхемы в потоке периодически появляются биты "длиной" пять (или три, смотря в какую сторону расхождение) отсчетов, что довольно легко устраняется, в результате чего извлекаем нужные данные.

Такая реализация позволила поднять устойчивость к джиттеру, но появилась другая проблема.
Надо не только извлекать без потерь данные из входного потока, но и восстанавливать частоту, которая в дальнейшем должна идти на вход различных PLLек системы.
Описанный выше метод позволяет выдать лишь, по сути, собственную опорную частоту микросхемы, с изменяющейся довольно редко (частота изменения порядка 0...1000Гц в зависимости от разницы частот) фазой, но сразу на 90 градусов.
То есть, имеем выходную частоту вида:
001100110011...00110001100110011001100...110011100

В принципе, можно сделать так, чтобы скачки были не на 90, а на 45 градусов (поднять частоту дискретизации в 2 раза).

Собственно, вопрос.
Можно ли из этого как-то восстановить "нормальную" частоту входного сигнала?.
Так, чтобы с ней можно было работать как с нормальной частотой, подавать на входы PLLек и т.д..
Желательно, конечно, средствами ПЛИС - т.е. DCM&PLL.

Заранее спасибо за любые идеи.

[Victor®]

Здравствуйте, уважаемые гуру.

Подскажите пожалуйста, как подступиться к следующей проблеме.

Для начала краткая предыстория.

Есть микросхема Spartan-6LXT.
К ней на вход GTP приходит поток STM-1 (155.52Mhz).
Надо восстановить из потока опорную частоту в более-менее приличном виде.

Трабла в следующем. GTP Спартана-6 поддерживает частоты от 614МГц.
Соответственно, работать напрямую с потоком 155.52 МГц оно не может.
Можно использовать передискретизацию - GTP настраивается на частоту в (допустим) 4 раза больше, принимать и передавать каждый бит 4 раза.

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

Пришлось пойти по другому пути - GTP настроил на режим lock-to-reference, т.е. входной поток принимался на собственной частоте микросхемы (которая может быть отличной от частоты входного сигнала).
Входной поток получался вида:
0000111100001111000001111000011110000111100001111100001111
То есть в случае несоответствия частот принимаемого потока и опорной микросхемы в потоке периодически появляются биты "длиной" пять (или три, смотря в какую сторону расхождение) отсчетов, что довольно легко устраняется, в результате чего извлекаем нужные данные.

Такая реализация позволила поднять устойчивость к джиттеру, но появилась другая проблема.
Надо не только извлекать без потерь данные из входного потока, но и восстанавливать частоту, которая в дальнейшем должна идти на вход различных PLLек системы.
Описанный выше метод позволяет выдать лишь, по сути, опорную частоту, с изменяющейся довольно редко (частота изменения порядка 0...1000Гц в зависимости от разницы частот) фазой, но сразу на 90 градусов.
То есть, имеем выходную частоту вида:
001100110011...00110001100110011001100...110011100

В принципе, можно сделать так, чтобы скачки были не на 90, а на 45 градусов (поднять частоту дискретизации в 2 раза).

Собственно, вопрос.
Можно ли из этого как-то восстановить "нормальную" частоту входного сигнала?.
Так, чтобы с ней можно было работать как с нормальной частотой, подавать на входы PLLек и т.д..
Желательно, конечно, средствами ПЛИС - т.е. DCM&PLL.

Заранее спасибо за любые идеи.

Мне не очень понятно, почему приняли решение использовать именно GTP...
На LVDS буферах не было-бы проще это сделать?

[Koluchiy]

Мне не очень понятно, почему приняли решение использовать именно GTP...
На LVDS буферах не было-бы проще это сделать?

Да ну в общем удобно... По крайней мере так казалось, пока не обнаружилась проблема с неустойчивостью к входному джиттеру.
Собственно, та же плата с другими настройками должна работать как STM-4, а там описанных выше проблем вроде нет...

Разницы-то большой нет, всё равно надо как-то получать частоту из того, что есть.
Хоть через GTP, хоть через LVDS...
Можно, конечно, поставить внешний CDR, который смог бы работать нормально на частоте 155.52...
Но хотелось бы обойтись без этого.
Лучше всего как-то найти решение внутри ПЛИС.
Как вариант - поставить какую-то внешнюю микросхему, которая из моей псевдочастоты восстановит исходную частоту потока...

[des00]

Можно, конечно, поставить внешний CDR, который смог бы работать нормально на частоте 155.52...

я бы сделал так %)

[dmitry-tomsk]

Да ну в общем удобно... По крайней мере так казалось, пока не обнаружилась проблема с неустойчивостью к входному джиттеру.
Собственно, та же плата с другими настройками должна работать как STM-4, а там описанных выше проблем вроде нет...

Разницы-то большой нет, всё равно надо как-то получать частоту из того, что есть.
Хоть через GTP, хоть через LVDS...
Можно, конечно, поставить внешний CDR, который смог бы работать нормально на частоте 155.52...
Но хотелось бы обойтись без этого.
Лучше всего как-то найти решение внутри ПЛИС.
Как вариант - поставить какую-то внешнюю микросхему, которая из моей псевдочастоты восстановит исходную частоту потока...

Я бы для плис использовал внешний тактовый генератор на 155,52. Тогда приём обычным ddr триггерами или iresdesами в ячейках ввода-вывода с передескритизацией в 4 раза. Данные потом корректруются алгоритмом (data recovery, описан в xapp) чтобы разность частот учесть. Вроде даже в logicore как то видел готовый модуль для data recovery.

[Koluchiy]

я бы сделал так %)

Плату переделывать...

Я бы для плис использовал внешний тактовый генератор на 155,52. Тогда приём обычным ddr триггерами или iresdesами в ячейках ввода-вывода с передескритизацией в 4 раза. Данные потом корректруются алгоритмом (data recovery, описан в xapp) чтобы разность частот учесть. Вроде даже в logicore как то видел готовый модуль для data recovery.

О каком xapp речь, если не секрет?

Проблем с data recovery нет... Всё нормально восстанавливается.
Проблемы есть только с приведением восстановленной частоты к пристойному виду.
Думаю, такая проблема есть для любого алгоритма цифрового CDR, не только моего...

Вот думаю, будет ли плодотворна следующая идея.
На вход DCM подается собственная опорная частота.
И через интерфейс внешнего управления DCM изменять ее, частоты, фазу согласно сигналам из алгоритма CDR.
При этом, из алгоритма CDR поступают команды на сдвиг фазы на 90 градусов, а фазу DCM двигать не рывком на 90, а плавно, шажочками, насколько это возможно... А потом переключаться на выход, сдвинутый по фазе на 90.

[dmitry-tomsk]

Плату переделывать...


О каком xapp речь, если не секрет?

Проблем с data recovery нет... Всё нормально восстанавливается.
Проблемы есть только с приведением восстановленной частоты к пристойному виду.
Думаю, такая проблема есть для любого алгоритма цифрового CDR, не только моего...

Вот думаю, будет ли плодотворна следующая идея.
На вход DCM подается собственная опорная частота.
И через интерфейс внешнего управления DCM изменять ее, частоты, фазу согласно сигналам из алгоритма CDR.
При этом, из алгоритма CDR поступают команды на сдвиг фазы на 90 градусов, а фазу DCM двигать не рывком на 90, а плавно, шажочками, насколько это возможно... А потом переключаться на выход, сдвинутый по фазе на 90.

Data recovery разный есть, xapp древний не помню. Смысл вообще не восстанавливать тактовую, не двигать фазой dcm и частотой pll. Есть стабильная тактовая с pll, по ней снимаются данные со входа. А конечный автомат выдаёт каждый такт либо один бит данных (почти всегда), либо 2 бита данных иногда, если тактовая меньше частоты данных, либо 0 бит данных - если больше. Преимущества - не надо обучать, нет потерь, работает на больших разницах частот и при большом джиттере входных данных. Минус - ограничение по частоте данных, слишком большую нельзя выбирать в нескольких точках.

[Koluchiy]

Смысл вообще не восстанавливать тактовую, не двигать фазой dcm и частотой pll. Есть стабильная тактовая с pll, по ней снимаются данные со входа. А конечный автомат выдаёт каждый такт либо один бит данных (почти всегда), либо 2 бита данных иногда, если тактовая меньше частоты данных, либо 0 бит данных - если больше.

Так я так сейчас и делаю.
И трабла именно в том, что тактовая всё равно нужна.
Не для работы собственно CDR, а для других нужд.

[des00]

И трабла именно в том, что тактовая всё равно нужна.

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

[Bad0512]

Так я так сейчас и делаю.
И трабла именно в том, что тактовая всё равно нужна.
Не для работы собственно CDR, а для других нужд.

Тактовая нужна именно 155МГц или поровну какая, лишь бы что-то было?
В системе нет других стабильных источников? Если есть то в чём проблема перейти
через фифошку (на входе - recovered clock, на выходе - стабильный клок) в другой
домен с заведомо более шустрыми клоками. Поток данных регулировать с помощью дополнительного
сигнала валидности. При желании - сгородить автомат на выходе фифошки, который будет "нарезать"
поток на блоки определённой длины?

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

ИМХО клок с выхода CDR по определению "чистым" быть не может, ибо он recovered, у него приличный джиттер. Правильнее работать от кварцованного источника,
несоответствие частот разруливать средствами протокола.

[des00]

ИМХО клок с выхода CDR по определению "чистым" быть не может, ибо он recovered, у него приличный джиттер. Правильнее работать от кварцованного источника,
несоответствие частот разруливать средствами протокола.

ну прям, посмотрите на все CDR для OC потоков. везде стоят гуны + петли + задаются определенные маски на джиттер. средствами протокола разруливать SDH достаточно геморойное занятие. Кроме того гасители джиттера не зря для таких вещей придумали

[Bad0512]

ну прям, посмотрите на все CDR для OC потоков. везде стоят гуны + петли + задаются определенные маски на джиттер. средствами протокола разруливать SDH достаточно геморойное занятие. Кроме того гасители джиттера не зря для таких вещей придумали

Могу сказать про область, с которой сам довольно плотно общался, а именно SDI video. Так вот, в приложениях, где надо принять видео, обработать и потом отдать на выход в случаях HD (1.5GHz) и 3G(3GHz)
никогда никто recovered clock для тактирования выхода не пользует. Именно из-за высоких требований на джиттер.Да, можно сделать внешнюю ПЛЛ-ку, управляемую из FPGA, такие даже существуют (см. например GS4911), но есть и другой способ. Выход работает на своей кварцованной частоте. Данные со входа валятся во фреймбуфер во внешней памяти, выход кормится тоже из этого фреймбуфера. Для устранения коллизий буферов обычно бывает несколько (минмум - два). Понятно, что примерно раз 10^4 кадров приходится либо дропать кадр либо повторять его, но в этом нет ничего страшного - никто не увидит.Способ этот хорош тем, что никакие казусы на входе (нестабильный клок, пропадение сигнала, etc.) не приводят к остановке выхода, более того вся логика, тактируемая от кварцованного клока в такой схеме, неубиваема. В случае внешней плл-ки пропажа входного сигнала может привести к печальным последствиям.
В общем, подводя резюме, всё зависит от протокола и задачи - допустимо ли свдвигать данные по времени и рулить потоком в данном приложении.

[des00]

Могу сказать про область, с которой сам довольно плотно общался, а именно SDI video.

здесь как я понял речь идет именно об SDH иерархии, в частности STM-1, а там за такое

Понятно, что примерно раз 10^4 кадров приходится либо дропать кадр либо повторять его, но в этом нет ничего страшного - никто не увидит.

руки обрывают по самую голову

там требования на остаточный коэффициент ошибок 2^-13 (одна битовая ошибка в два дня), а вы кадр дропать/повторять....

2 Koluchiy
поставили бы и не парились

[wolfman]

to Koluchiy Я вроде бы Вам, в свое время, указывал на необходимость CDR, но тогда у Вас была задача STM-4 поднять.
Если не забуду завтра спрошу у коллеги, у него что-то похожее было, правда на альтере.

[Koluchiy]

Тактовая нужна именно 155МГц или поровну какая, лишь бы что-то было?

Нужна частота, кратная частоте приходящего потока.
Один из основных принципов SDH - синхронность, т.е. аппаратура работает на одной частоте, задаваемой высокостабильным источником. Эта частота передается через потоки данных, ее надо уметь восстановить, тактироваться от нее и передавать дальше.

2 Koluchiy
поставили бы и не парились

Да я найду, чего поставить из CDR.
Но хотца ставить не CDR, а какую-нибудь мегаPLL, которая сможет справиться с моей "крякозяброй" типа 0011001110011 или подобной и сделать из нее нормальную частоту.
Выигрыш будет в том, что такую микросхему можно поставить одну, а CDR надо ставить по одной на канал...

to Koluchiy Я вроде бы Вам, в свое время, указывал на необходимость CDR, но тогда у Вас была задача STM-4 поднять.
Если не забуду завтра спрошу у коллеги, у него что-то похожее было, правда на альтере.

Было, да. Но тогда я еще не знал о том, что по приему STM1 будет трабла с устойчивостью к джиттеру...