Clock Recovery из 8B10B Опции

[Vitaly_N]

Передо мной стоит задача связать два девайса по одному каналу. Из чипа выходит LVDS и в другой чип входит LVDS. Предполагаю использовать Xilinx Spartan 6 и не использовать GTP (уже занято). Кодирование в канале планирую использовать 8B10B. Передатчик до 950 Мбит/с я уже сделал (это потому что speed grade -2), тут всё просто. А вот с приёмом проблема. XAPP1064 я, разумеется, читал, но вот в чём проблема - я не хочу тащить второй канал для передачи клока. Вот прям очень сильно не хочу - это настолько усложняет реализацию, что лишает всю затею смысла. Короче, считайте, что канал даден свыше только один, и это не обсуждается. (Было бы два - сделал бы, как в XAPP1064, и вопроса бы не было.) Так что очень хочется обойтись одним каналом. Соответственно вопрос - подскажите, пожалуйста, что тут можно придумать, ну или аргументированно объясните, что задача нерешаемая, чтоб я зря время не тратил! Пожалуйста!

(Вариант снизить скорость, скажем, до 125 Мбит/с - это решаемо, но это неинтересно. Надо больше. Чем больше - тем лучше.)

[Vitaly_N]

Была ещё одна идея - не восстанавливать клок, а сдвигать данные. Скажем, и на приёмнике и на передатчике генерятся примерно одинаковые частоты. Очевидно, они слегка различаются. Так вот, с точки зрения приёмника мы видим сигнал с медленно плывущей (относительно клока в приёмнике) фазой. Почему бы нам не попытаться эту фазу постоянно компенсировать за счёт регулирования задержки на IODELAY2? Ну да, с какой-то периодичностью мы будем выпадать из синхронизации, тут тогда вопрос возникает - как часто это будет происходить? Скажем, если я возьму кварцы с малым начальным разбросом частоты, то я могу надеяться, что различие частот будет не более 10 в минус 5, а значит, приёмник будет сбиваться не чаще чем примерно 1 раз на 100 килобит.

[des00]

Была ещё одна идея - не восстанавливать клок, а сдвигать данные. Скажем, и на приёмнике и на передатчике генерятся примерно одинаковые частоты. Очевидно, они слегка различаются. Так вот, с точки зрения приёмника мы видим сигнал с медленно плывущей (относительно клока в приёмнике) фазой. Почему бы нам не попытаться эту фазу постоянно компенсировать за счёт регулирования задержки на IODELAY2? Ну да, с какой-то периодичностью мы будем выпадать из синхронизации, тут тогда вопрос возникает - как часто это будет происходить? Скажем, если я возьму кварцы с малым начальным разбросом частоты, то я могу надеяться, что различие частот будет не более 10 в минус 5, а значит, приёмник будет сбиваться не чаще чем примерно 1 раз на 100 килобит.

сигнал управления у вас будет пила с восходящим или нисходящим наклоном, т.к. линия задержки у вас ограниченна, то на краях возникает перескок +- символ. Что вызовет проскальзывание бита -> выход из синхронизации. В итоге вам придется делать что-то вроде TDMA модема - на передатчике сделать короткие пакеты и вставить между ними паузы. на приемнике входить в синхронизм в начальный момент времени и ловить пакет. Но это будет не 950 мегабит, как вы просили в первом посте.

[Vitaly_N]

сигнал управления у вас будет пила с восходящим или нисходящим наклоном, т.к. линия задержки у вас ограниченна, то на краях возникает перескок +- символ. Что вызовет проскальзывание бита -> выход из синхронизации. В итоге вам придется делать что-то вроде TDMA модема - на передатчике сделать короткие пакеты и вставить между ними паузы. на приемнике входить в синхронизм в начальный момент времени и ловить пакет. Но это будет не 950 мегабит, как вы просили в первом посте.

Ну ведь получится же? Ну пусть не 950 мегабит, но хотя бы 800 - всё лучше, чем 125...

Только потребуется ревизия чипов, где исправлены грубые ошибки в IODELAY2.

А поподробнее можно? Были какие-то errata?

И есть ещё одна идея - при помощи IODELAY2 сдвигать себе референсный клок. При этом потеряем не бит входного потока, а такт клока, который, по большому счёту не жалко., потому что он информации не несёт в отличие от входного потока данных. Уповаем на то, что при делении на D и на М потеря одного клока окажется не смертельной, а частота PLL резко не уползёт и не выпадет из захвата с потоком данных. Или уползёт?