Привет всем.
Интересно здесь кто-нибудь заморачивался с 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? Это вообще возможно? Какова тогда вероятность ложного обнаружения?
Спасибо за прояснения, если будут.
Полная версия этой страницы: Burst-mode receiver на GTX Virtex 6 для PON сетей
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(syoma @ Feb 3 2012, 19:29) 
....
Но тогда у меня непонятка, как тогда отличить правильный стартовый идентификатор от шума? Путем проверки, что перед ним идет минимум 12 чередующихся 0 и 1? Это вообще возможно? Какова тогда вероятность ложного обнаружения?
Спасибо за прояснения, если будут.
Но тогда у меня непонятка, как тогда отличить правильный стартовый идентификатор от шума? Путем проверки, что перед ним идет минимум 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". Теоретически это должно ж быть достаточно быстро, хотя теорию я до конца не понял.
С ложными срабатываниями я разобрался - 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". Теоретически это должно ж быть достаточно быстро, хотя теорию я до конца не понял.
Цитата(syoma75 @ Feb 9 2012, 23:56)
Я так и понял, что вопрос выливается в то, что сможет ли 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". Теоретически это должно ж быть достаточно быстро, хотя теорию я до конца не понял.
С ложными срабатываниями я разобрался - 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 - это слишком много. А это точно та характеристика? У меня смутные подозрения, что она что-то другое подразумевает.
Чего-то 200µs - это слишком много. А это точно та характеристика? У меня смутные подозрения, что она что-то другое подразумевает.
QUOTE (Postoroniy_V @ Feb 7 2012, 00:39)
2) чтобы не было ложных срабатываний я бы использовал 8b10b encoding, в начале пакета синхро слово(несколько) k28.1, перед данными и в конце пакета к28.5 и т.д.
вообщем мне кажется возможно это реализовать, проблема будет с п.1.
вообщем мне кажется возможно это реализовать, проблема будет с п.1.
поддерживаю. используйте стандарнтую comma 8b10b и сделайте обязательно эксперемент. Если неошибаюсь, cdr корректно захватит комму уже на 10 слове.
Цитата
Если неошибаюсь, cdr корректно захватит комму уже на 10 слове.
Можете подсказать - откуда у Вас такая информация - вы пробовали или это все-таки где-то написано. Эксперимент- експериментом, но хочется, чтобы было гарантированно, а написанные 200µs гарантированно в рамки не влазят.
Цитата(syoma75 @ Feb 10 2012, 17:26)
По всем остальным Виртексам-6 http://www.xilinx.com/support/documentatio...heets/ds152.pdf
Чего-то 200µs - это слишком много. А это точно та характеристика? У меня смутные подозрения, что она что-то другое подразумевает.
Чего-то 200µs - это слишком много. А это точно та характеристика? У меня смутные подозрения, что она что-то другое подразумевает.
х.з. та или нета. думаю лучше у хилых спрашивать напрямую.
Цитата(syoma @ Feb 3 2012, 13:29)
Привет всем.
Интересно здесь кто-нибудь заморачивался с 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? Это вообще возможно? Какова тогда вероятность ложного обнаружения?
Спасибо за прояснения, если будут.
Интересно здесь кто-нибудь заморачивался с 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? Это вообще возможно? Какова тогда вероятность ложного обнаружения?
Спасибо за прояснения, если будут.
Смею предположить, что Вы собрались OLT делать.
Если ONT/ONU/RG - то вылетите в трубу в моменте, используя FPGA.
А раз OLT - то денег у Вашей фирмы должно быть не меряно...
Если меряно - то тем более делать в этой облати нечего.
Поэтому, самый простой совет - если хотите делать именно на FPGA и позволяют средства
обращайтесь напрямую в Xilinx за поддержкой.
А тут никто Вам _реально_ не поможет. Это достаточно денежная тема.
Цитата(Victor® @ Feb 14 2012, 21:55)
Смею предположить, что Вы собрались OLT делать.
Да OLT, но как я писал выше - от PON мы используем только среду передачи, но не протокол.
Цитата
Если ONT/ONU/RG - то вылетите в трубу в моменте, используя FPGA.
Почему? ONT у нас уже реализован на внешнем SERDES + ПЛИС. Все отлично работает.
Цитата
А раз OLT - то денег у Вашей фирмы должно быть не меряно...Если меряно - то тем более делать в этой облати нечего.
Ну деньги есть. Но я пока не вижу дороговизны OLT. PON уже нам сэкономила кучу денег по сравнению с сотнями peer-to-peer оптических соединений.
Цитата
Поэтому, самый простой совет - если хотите делать именно на FPGA и позволяют средства
обращайтесь напрямую в Xilinx за поддержкой.
А тут никто Вам _реально_ не поможет. Это достаточно денежная тема.
обращайтесь напрямую в Xilinx за поддержкой.
А тут никто Вам _реально_ не поможет. Это достаточно денежная тема.
Жалко.
syoma, удалось ли вам решить свою задачу?
Цитата(spbroma @ Nov 12 2014, 16:12)
syoma, удалось ли вам решить свою задачу?
Встроенный CDR не сработал - слишком медленный. Но задачу решили в лоб - простым оверсамплингом. Запустили приемник на 5,12Гбит - 8-кратное превышение рабочей скорости - и уже в параллельном коде вылавливаем переходы и переводим в биты. Все работает, и скорость захвата практически мгновенная!
Цитата(syoma @ Mar 19 2015, 18:31)
Встроенный CDR не сработал - слишком медленный. Но задачу решили в лоб - простым оверсамплингом. Запустили приемник на 5,12Гбит - 8-кратное превышение рабочей скорости - и уже в параллельном коде вылавливаем переходы и переводим в биты. Все работает, и скорость захвата практически мгновенная!
Если у Вас есть ссылки на аппноты или другие источники поделитесь если не сложно...
Цитата(antsu88 @ Mar 20 2015, 14:44)
Если у Вас есть ссылки на аппноты или другие источники поделитесь если не сложно...
Кроме ксайлинского описания GTX ничего не было...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.