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

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

отсутствие возможности сделать на логике CDR на такие скорости. либо тащите клок, либо ставьте внешнюю CDR, либо освобождайте GTP

Клок тащить - не вариант, я уже сказал, GTP освободить невозможно.

Я думал использовать DCM_CLKGEN. Там есть интересная фича - FREEZEDCM. Если его подать, то DCM продолжает генерить сигнал даже при отсутствии входного клока. Задумка была такая. Ставлю два IODELAY2, один задерживает на T, другой - на 2T (2T = один бит). XOR их между собой и входным сигналом. Получаю некий импульс синхронно с каждым переходом. Этот импульс подаю на CLKIN DCM, а в отсутствие импульса на DCM подаю FREEZEDCM. Точнее, сначала при старте системы DCM кормлю от генератора с нужной частотой, чтобы он завёлся, а потом, когда увижу данные в канале, через BUFGMUX переключаю на работу от детектора переходов. Однако результаты симулирования отрицательные - несмотря на FREEZE DCM продолжает измерять период входного сигнала. Ну и когда потом FREEZE снимаешь, дескать, поехали работать, эта скотина считает, что новый период должен быть таким, чего DCM намерил со времён последнего импульса.

Вообще, именно на такой скорости клок в логике получать и не обязательно. Вполне сгодится клок любой другой частоты, а при помощи PLL потом получу, сколько надо. Скажем, битовая скорость 950 МБит/с, 10 бит на слово, стало быть, вполне устроит восстановленная частота 95 МГц (что вполне посильно для логики общего назначения) или даже 47.5 МГц, которую на PLL разогнать до 950 МГц. Лишь бы синхронно со словом было. В общем, вполне устроит один перепад на слово. Вопрос только, как этот перепад гарантированно выделить...

Ещё в ISERDES2 есть встроенный фазовый детектор, правда, я ещё не разобрался, как им пользоваться, стало быть, и не могу понять, поможет оно мне или нет.

не всегда наши желания, совпадают с нашими возможностями (с)


шаманство оно всегда такое.


нет у вас слов в канале. там летит поток бит 950Мб/с. 8б10б это всего лишь способ борьбы с постоянкой. И что бы с работать с символами 8б10б, нужно сделать эти символы из битового потока в 950МГц. Для этого нужен CDR.

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

С IODELAY2 может быть и получится. Насколько я помню, к одному дифференциальному входу можно подключить два канала IODELAY2+SERDES с независимым управлением. Один канал будет принимать данные, а второй заниматься калибровкой. Когда принимающий канал уплывет по задержке за пределы диапазона подстройки, надо переключить приём на другой канал, предустановленный с запасом по подстройке задержки, а освободившийся использовать для калибровки.
Только потребуется ревизия чипов, где исправлены грубые ошибки в IODELAY2.

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

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



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

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

Подобные решения (приём данных без восстановления тактов) для 8B10B, правда на скорости 270 МБит/с, описаны в XAPP514, XAPP1014 и XAPP1015. В них три разных варианта реализации приёмника DVB-ASI.
Но, ИМХО, для Вашей скорости надёжнее внешний CDR.

У Xilinx'а есть такое ядро как 1000BASE-X SGMII PCS PMA. Начиная с Virtex 6 -2 speed grade и последующие семейства поддерживают организацию 1Gb SGMII с помощью LVDS-каналов. Данное ядро не подойдет для Spartan 6, но посмотреть как оно устроено внутри ТС стоит.

сделайте 400-500. лучше чем 125, надежнее чем недо950

Спасибо, посмотрю!



А например какие? Я предполагаю, что это не канал с клоком от источника, а некий чип, который стоит на приёмной стороне и из потока 8B10B клок восстанавливает и держит его более-менее синхронным с потоком?

http://www.analog.com/en/products/optical/...ryretiming.html

Спасибо!

От $10 до $40... "Однако!" (с) Киса Воробьянинов в ресторане из "12 стульев"

UPD. А ведь не пойдёт! Посмотрел, скажем, ADN2806 и ADN2816 - а ведь они выдают SDR клок. Скажем, если битрейт 622 Мбита в секунду, то и выходной клок будет 622 МГц - Spartan 6 столько просто не примет. Получается ограничение битрейта где-то в районе 311 Мбит/с. Ладно, понял, как называется чип, поищу с выходом DDR или с программируемым коэффициентом деления, если такое в природе бывает.

Сообщение отредактировал Vitaly_N - Oct 26 2015, 16:25

Посмотрел XAPP224. Это, правда, старая аппликуха, "not recommended for new design", но на старом Virtex II обещают аж до 420 Мб/с. Обратил внимание, что Fig.4 ну уж очень напоминает ISERDES2. Переписал код, вместо первых трёх рядов триггеров вставил ISERDES2. Непонятно почему, но получилась фигня. В симуляции работать-то работает, но хуже, чем оригинальный дизайн на триггерах. В "железе" не испытывал.