Привет всем.
Интересно здесь кто-нибудь заморачивался с GPON сетями? Ну или кто хорошо разобрался с xilinxовскими GTX трансиеверами может подскажет.
В общем я сейчас исследую возможность реализации такого ресивера только средствами ПЛИС.
Смысл вот в чем.
GPON - это такая оптическая "1-ко-многим" сеть обычно используемая для интернета.
http://ru.wikipedia.org/wiki/PON
Даунстрим потоки там 2,488Гбит и апстрим 1.244Гбит. Смысл там в том, есть один основной оптический приемопередатчик (OLT) и 32-64 абонента. Сигнал от передатчика разветвляется пассивными сплиттерами. Оптоволокно двунаправленное с волновыим разделением 1490/1330нм. Прикол в том, что даунстрим там вещается непрерывно ко всем абонентам, а апстрим - разделен TDM, то есть каждый абонент вещает только в своей определенный слот времени. Таким образом на основной приемопередатчик обратно свет приходит пакетами. Это и навзывается burst transfer.

Мы используем только физический уровень PON для своих применений - никакого интернета. Но принцип TDM для апстрима остается. Скорость апстрима и даунстрима у нас 640мБит.

Собственно вопросы по приему апстрим burst пакетов.
Перед каждым следующим пакетом ПЛИС сбрасывает оптоприемник, для того, чтобы он нормально адаптировался к уровню сигнала следующего пакета (а он может быть другим из-за разных длин линий)
Для распознавания и выравнивания пакетов мы используем 120-битную преамбулу из чередующихся 1 и 0 и затем стартовый идентификатор из 0x335. В качестве железа используется внешний SERDES TLK1211, из которого альтеровская ПЛИС считывает побайтно невыравненные биты. Длинная преамбула позволяет TLK1211 нормально засинхронизироваться на поток.
Далее идет поиск стартового идентификатора, выравнивание и декодирование 8B10B. Все в альтере сделано в VHDL. Еще прикол в том, что поиск стартового идентификатора разрешается только в том случае если оптический приемопередатчик установил сигнал наличия burst пакета. Это, вроде сделано для того, чтобы при отсутвии света ошибочно не распознать стартовый идентификатор из шума.

Собственно я сейчас разбираюсь, можно ли все это сделать используя GTX в Virtex-6 без внешнего SERDES.
Проблема в том, что я хочу использовать оптические приемо-передатчики без сигнала определения burst пакета. Типа такого: http://www.optoway.com.tw/html/products/pd...L-94B73B-WG.pdf
Но тогда у меня непонятка, как тогда отличить правильный стартовый идентификатор от шума? Путем проверки, что перед ним идет минимум 12 чередующихся 0 и 1? Это вообще возможно? Какова тогда вероятность ложного обнаружения?
Спасибо за прояснения, если будут.

1)тут большой вопрос какое время понадобится rxpll приёмника чтобы залочится ко входному сигналу. думаю что последовательность в виде 120 0 и 1 будет коротковата. нужно почитать ug366.pdf и нужен эксперимент.
2) чтобы не было ложных срабатываний я бы использовал 8b10b encoding, в начале пакета синхро слово(несколько) k28.1, перед данными и в конце пакета к28.5 и т.д.
вообщем мне кажется возможно это реализовать, проблема будет с п.1.

Я так и понял, что вопрос выливается в то, что сможет ли Xilinxовский CDR засинхронизироваться в приемлемое время на входной сигнал. К сожалению все UG366 прошерстил - не нашел характеристик CDR. Может они в другом документе даны?
С ложными срабатываниями я разобрался - SFP приемник все-таки выдает нормальный строб наличия сигнала и по нему можно начинать принимать данные.
Может кто ткнуть ссылкой на зарактеристики CDR в GTX?

Греет то, что в Virtex®-6 LXT Family Serial I/O Protocol Support конкретно сказано, что GPON поддерживается - а там используется точно такой принцип приема.


Просмотрел также Virtex-6 FPGA Data Sheet: DC and Switching Characteristics - там есть про GTX, но тоже нет ничего про CDR.
GTX в Xilinx использует "phase rotator CDR architecture". Теоретически это должно ж быть достаточно быстро, хотя теорию я до конца не понял.

в той таблице line rate для поддерживаемого GPON 1.244. так и надо?
нашёл вот что(virtex6-cxt??? почему то нет дашита для lxt ) тоесть если предположить что GTX в семействах LXT и CXT одинаковые то:
TPHASE - Clock recovery phase acquisition time Lock to data after PLL has locked to the reference clock – – 200 μs
пдф
http://www.xilinx.com/support/documentatio...heets/ds153.pdf
там же
RXPPMTOL - Data/REFCLK PPM offset tolerance
CDR 2nd-order loop disabled –200 – 200 ppm
CDR 2nd-order loop enabled –2000 – 2000 ppm

По всем остальным Виртексам-6 http://www.xilinx.com/support/documentatio...heets/ds152.pdf
Чего-то 200µs - это слишком много. А это точно та характеристика? У меня смутные подозрения, что она что-то другое подразумевает.

поддерживаю. используйте стандарнтую comma 8b10b и сделайте обязательно эксперемент. Если неошибаюсь, cdr корректно захватит комму уже на 10 слове.

Можете подсказать - откуда у Вас такая информация - вы пробовали или это все-таки где-то написано. Эксперимент- експериментом, но хочется, чтобы было гарантированно, а написанные 200µs гарантированно в рамки не влазят.

х.з. та или нета. думаю лучше у хилых спрашивать напрямую.

Смею предположить, что Вы собрались OLT делать.
Если ONT/ONU/RG - то вылетите в трубу в моменте, используя FPGA.
А раз OLT - то денег у Вашей фирмы должно быть не меряно...
Если меряно - то тем более делать в этой облати нечего.
Поэтому, самый простой совет - если хотите делать именно на FPGA и позволяют средства
обращайтесь напрямую в Xilinx за поддержкой.
А тут никто Вам _реально_ не поможет. Это достаточно денежная тема.

Да OLT, но как я писал выше - от PON мы используем только среду передачи, но не протокол.

Почему? ONT у нас уже реализован на внешнем SERDES + ПЛИС. Все отлично работает.

Ну деньги есть. Но я пока не вижу дороговизны OLT. PON уже нам сэкономила кучу денег по сравнению с сотнями peer-to-peer оптических соединений.

Жалко.

syoma, удалось ли вам решить свою задачу?

Встроенный CDR не сработал - слишком медленный. Но задачу решили в лоб - простым оверсамплингом. Запустили приемник на 5,12Гбит - 8-кратное превышение рабочей скорости - и уже в параллельном коде вылавливаем переходы и переводим в биты. Все работает, и скорость захвата практически мгновенная!

Если у Вас есть ссылки на аппноты или другие источники поделитесь если не сложно...

Кроме ксайлинского описания GTX ничего не было...