Перейти к содержанию
    

Восстановление частоты из потока цифр

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

 

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

 

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

 

Есть микросхема 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.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

Есть микросхема 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 буферах не было-бы проще это сделать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне не очень понятно, почему приняли решение использовать именно GTP...

На LVDS буферах не было-бы проще это сделать?

 

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

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

 

Разницы-то большой нет, всё равно надо как-то получать частоту из того, что есть.

Хоть через GTP, хоть через LVDS...

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

Но хотелось бы обойтись без этого.

Лучше всего как-то найти решение внутри ПЛИС.

Как вариант - поставить какую-то внешнюю микросхему, которая из моей псевдочастоты восстановит исходную частоту потока...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Разницы-то большой нет, всё равно надо как-то получать частоту из того, что есть.

Хоть через GTP, хоть через LVDS...

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

Но хотелось бы обойтись без этого.

Лучше всего как-то найти решение внутри ПЛИС.

Как вариант - поставить какую-то внешнюю микросхему, которая из моей псевдочастоты восстановит исходную частоту потока...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

Проблем с data recovery нет... Всё нормально восстанавливается.

Проблемы есть только с приведением восстановленной частоты к пристойному виду.

Думаю, такая проблема есть для любого алгоритма цифрового CDR, не только моего...

 

Вот думаю, будет ли плодотворна следующая идея.

На вход DCM подается собственная опорная частота.

И через интерфейс внешнего управления DCM изменять ее, частоты, фазу согласно сигналам из алгоритма CDR.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

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

 

Проблем с data recovery нет... Всё нормально восстанавливается.

Проблемы есть только с приведением восстановленной частоты к пристойному виду.

Думаю, такая проблема есть для любого алгоритма цифрового CDR, не только моего...

 

Вот думаю, будет ли плодотворна следующая идея.

На вход DCM подается собственная опорная частота.

И через интерфейс внешнего управления DCM изменять ее, частоты, фазу согласно сигналам из алгоритма CDR.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Так я так сейчас и делаю.

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

Не для работы собственно CDR, а для других нужд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так я так сейчас и делаю.

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

Не для работы собственно CDR, а для других нужд.

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

В системе нет других стабильных источников? Если есть то в чём проблема перейти

через фифошку (на входе - recovered clock, на выходе - стабильный клок) в другой

домен с заведомо более шустрыми клоками. Поток данных регулировать с помощью дополнительного

сигнала валидности. При желании - сгородить автомат на выходе фифошки, который будет "нарезать"

поток на блоки определённой длины?

 

 

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

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

несоответствие частот разруливать средствами протокола.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

несоответствие частот разруливать средствами протокола.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Могу сказать про область, с которой сам довольно плотно общался, а именно SDI video. Так вот, в приложениях, где надо принять видео, обработать и потом отдать на выход в случаях HD (1.5GHz) и 3G(3GHz)

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

В общем, подводя резюме, всё зависит от протокола и задачи - допустимо ли свдвигать данные по времени и рулить потоком в данном приложении.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

 

2 Koluchiy

поставили бы и не парились :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если не забуду завтра спрошу у коллеги, у него что-то похожее было, правда на альтере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Нужна частота, кратная частоте приходящего потока.

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

 

2 Koluchiy

поставили бы и не парились :biggrin:

 

Да я найду, чего поставить из CDR.

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

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

 

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

Если не забуду завтра спрошу у коллеги, у него что-то похожее было, правда на альтере.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...