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

[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.

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

[Koluchiy]

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

Так я так сейчас и делаю.
И трабла именно в том, что тактовая всё равно нужна.
Не для работы собственно 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.) не приводят к остановке выхода, более того вся логика, тактируемая от кварцованного клока в такой схеме, неубиваема. В случае внешней плл-ки пропажа входного сигнала может привести к печальным последствиям.
В общем, подводя резюме, всё зависит от протокола и задачи - допустимо ли свдвигать данные по времени и рулить потоком в данном приложении.