На плате установлена микросхема OED622. TelecomBus заведен на ПЛИС(V4) она же (ПЛИС) и конфигурит OED622. Подаю STM1. ВопросЫ:
- Передается ли RSOH в телебус? (Не вижу А1, А2)..
- Как связаны входная и выходная ветви телебуса ?

Добрый день, с прошедшими праздниками.
Вы написали, что OED программируется через FPGA. Там внутри процессор?
По сути:
А1 и А2 будут на ТВ если:

- правильно сформированы входные для OED сигналы TB, а именно ICFP(начало фрейма),
IJ0J1A((маркеры байтов J0 и J1), IPLA((полезная нагрузка) (см. времянку стр. 44 Datasheet). Формировал в своем FPGA.
Относительно них OED формирует соответствующие выходные сигналы (OCFP, OJ0J1A(, OPLA(),
сопровождающие данные выдаваемые из OED на ТВ. Опираясь на эти сигналы принимаю в буферную память FPGA кадры STM.

- корректно запрограммирована сама OED, в частности в регистрах Master Control Register for SPP #S, STUPPMCR (стр.162 Datasheet)
в бите BYPASS должен стоять "0". В этом случае кадр на ТВ будет четко выравнен по фрейму и байты А1 и А2 будет легко найти.

Однако, как показал опыт, большая часть служебных байтов RSOH на ТВ не передается, что косвенно потвердилось и в ответе от Transwitch
(хотя на указанной времянке они вроде есть). Ответ прозвучал примерно так - а зачем они вам надо?
Часть из них можно выловить при установке в "1" битов BYPASS, однако при этом кадр на ТВ "съезжает" относительно фрейма.
Часть байтов доступна через сам OED, но не всегда это удобно, доступ по процессорной шине довольно медленный.
Вот в основном и все. Если будут вопросы, обращайтесь.
Удачи.




Сорри, вместо смайликов буква В

Сорри, вместо смайликов буква В
[/quote]
Благодарю Вас , что ответили на мою запись. У меня вопрос по поводу формирования сигналов. ICFP я генерю (на выделенной частоте с периодом 125мкс) с ним более-менее понятно. А вот с остальными не совсем ясна логика. И возникают вопросы:
1 - IPLA( (Payload) правильно ли я понимаю Что данный сигнал должен я генерить как бы имитируя реальную загрузку, те вне SOH.
2 - ICTMF и IJ0J1 - их момент не совсем ясен.
3 - каналы А и B. Они взаимосвязаны (кроме FramePulse)
Заранее благодарю.

Добрый день.
1-е
IPLA и IPLВ действительно 1-й маркируют наличие полезной нагрузки на шине, а 0-м
маркируют байты SOH. За фрейм IPLA и IPLВ представляют собой 9-ть 0-вых импульсов,
каждый длительностью 9 тактов частоты 19,44МГц, как на временной диаграмме рис14. стр.44 описания OED.
На рисунке показан только 1-й импульс.
За фрейм по шине передается 2430 байт, по 270 в условной строке. Первые 9-ть байт каждой строки принадлежат SOH.
После приема IPLA и IPLВ OED выдает ответные ОPLA и ОPLВ, маркирующие полезную нагрузку, выдаваемую из OED.
2-е
ICTMF - сигнал мультифрейма, повторяется 1 раз в 4-ре фрейма.
IJ0J1 - сигнал, который маркирует байты J0 и J1, передаваемые в OED по ТВ. J0 - один из байтов SOH заголовка,
J1 - байт РОН. 9-ть байтов РОН передается по одному байту в каждой строке сразу за 9-тью байтами SOH.
После приема IJ0J1, OED выдает ОJ0J1, которые маркируют выдаваемые на шину из OED байты J0 и J1.
По этим маркерам можно определять место байтов РОН на шине. IJ0J1 представляют собой два импульса за фрейм и расположены так,
как показано на времянке рис.14.
Если сформированы IPLA, IPLВ, IJ0J1А, IJ0J1В, ICFP как на рис 14, то из OED получите рис.15.
3-е
Шины А и В по электрическим сигналам одинаковы. Различия в шинах заключается в том, что на них можно коммутировать внутри OED
разные потоки STM1, в режиме STM4(см. описание матрицы HLX).
Попробую сбросить в личный ящик рекомендацию G.707, где описаны назначения SOH, POH.
Удачи

Здравствуйте!



Все логично, он указывает на байт H4 заголовка VC-4(3) (POH), по которому мы понимаем какой именно из байтов V1, V2, V3 и V4 заголовка VC-12 находиться в данном кадре STM (Figure 8-9/G.707). Но не понятно, какое положение этого байта (положение сигнала ICTMF) нужно указывать, а как же цифровое выравнивание? Если оно произойдет во входном потоке, получается нам тоже его «двигать» придется?

Раз ICTMF появляется раз в 4 фрейма, тогда на какое значение байта H4 (на какой из V1, V2, V3 или V4 указывает)? Просто если следовать рекомендации он должен появляться каждый фрейм и изменять 2 бита, образуя там самым мультифрейм.




Получается начало контейнера VC-4(3) находится на 522м байте… а оно всегда там будет (опять к вопросу о выравнивании)?

Насколько я понимаю, есть обратная связь. Мы смотрим заголовки, которые приходят из входного потока, и формируем в соответствии с ними сигналы на входе или мы подаем какую-то идеальную «картину» а TRANSWITCH уже сам преобразует в соответствии с тем что идет во входной линии… что-то я совсем запутался…

Добрый вечер(день).
В описании OED стр.43
ICTMF is used to identify the tributary multi-frame boundary common frame for the incoming
STM-1 data stream on the EXT_IDA. ICTMF is only sampled during the H4 byte position on
the rising edge of the SCLK19, as appropriate. ICTMF is ignored at other byte positions. It is
also considered as the reference multi-frame alignment signal to align the outgoing SDH data
stream of the PP and the data stream on the add bus of the E1MAPPER which makes all
incoming data streams of the HLX have same multi-frame boundary. The OCTMF is
generated and indicates the multi-frame boundary of the first STM-1 data stream on the
EXT_ODA. Because the data delay is fixed through the HLX module, the OCTMF always is
ICTMF delayed by a 69 SCLK19 clock periods.
И еще на стр.44:
ICTMF is set high at the H4 byte position. In fact ICTMF can be set high for the entire
fourth frame of the tributary multi-frame, since ICTMF is only sampled at the H4 byte
position. Если я правильно понимаю, то "for the entire fourth frame" - для целого четвертого фрейма.
По поводу выравнивания.
Если в регистре Master Control Register for SPP (стр.162) в бите BYPASS стоит 0, то выравнивание всегда делает
сам OED. Если установить в этом бите 1, то начало кадра "съезжает" относительно фрейма. Реально проверял.
Из опыта: пока я корректно не сформировал на входы OED ICFP, IPLA/B, IJ0J1A/B получить что-то вразумительное на
выходных шинах ТВА и ТВВ не получалось.
Конечно, я допускаю, что может в чем-то ошибаюсь, но принимая STM-1, из буферной памяти в FPGA я считываю
осмысленную информацию(байты А1,А2 четко в начале фрейма). Кроме того, в режиме теста, я выдавал из FPGA на ТВ кадр 2340 байт,
заполненный тестовым набором, заворачивал его внутри OED (в матрице HLX) и получал обратно.

Темка вроде подходящая, спрошу здесь

Только начал разбираться с OED-155 (демокита нету, есть только описание) появилось пару вопросов:
1) Вопрос по питанию, чем питать сие чудо???? ПОнятно, что аналоговые цепи от линейного стабилизатора, а вот все остальное от DC-DC Step Down Convertor запитать можно??? уж больно токи там большие, жалко в воздух Ваты рассеивать.
2) Вопрос по доступу к внутренним регистрам, на сколько там интерфейс медленный, можно ли не прибегая к обработке TelecomBus работать с отдельными байтами DCC заголовков RS и MS секций, для организации каналов мониторинга и байтов F1 в RSOH секционного заголовка для создания служебной ТЧ связи?

У него вообще то есть специальный интерфейс для SOH. Лучше по нему. По поводу прцессорной шины.. в DataSheete на 622 прописано 200 ns без использования сигнала RDY. Реально (я использую этот сигнал) доступ составляет до 350 ns(то что сам видел.)
Для питания использовал PTH0505W. Проблем с ним не было. Обратить советую на схему синхронизации.. надо использовать внешнюю ФАПЧ.


Огромное спасибо за помощь.. Все вроде с Вашей помощью и с помощью Transwich пошло.. Хотя некоторые вещи остались непонятными... Ну потом осмыслю. Ещё раз благодарю.

Мануал курю, пока еще не все скурил ))), спасибо за подсказки.
1) нашел, есть такое буду разбираться
2) у них указано в датите как минимум 220нс если не использовать RDY, будем посмотреть на живом
3) по питанию понял, у меня входное для блока 5 вольт, для цифры(3.3 и 1.8) использую LM2717 от National, остальное линейники от TI и Micrel.
4) Тут попрошу помощи и уточнений, на схеме боарда вообще ФАПЧ нет, что имеете в виду для чего ФАПЧ схема синхронизации для потоков Е1? По 77.76 на сколько понял достаточно иметь стабильный генератор +-5pmm, если ошибся, поправьте.
5) где и по чем евал. боард брали? вот сомнения терзают, осилим ли без него проект....

По п.4
http://electronix.ru/forum/index.php?showtopic=51222
По п.5 В России продает это все Росспецпоставка. Без кита тяжко. Я сдуру не взял.. собрал все шишки..

Спасибо за ответ. С синхронизацией пока еще не все понятно, ведь в OED (в моем случае OED155) используется 77.76 МГц частота как опора для восстановления CLK из линии и как частота передачи, у меня были проблемы с различными микросхемами от Infineon(и не только), когда опора подавалась с внешнего аналогового ФАПЧ который в свою очередь синхронизировался от восстановленного микросхемой сигнала RCLK, в этих случаях возникала положительная обратная связь двух последовательно включенных ФАПЧ, которая приводила к неустойчивой работе всей системы синхронизации в целом, уже не говоря о таких тонких параметрах как TIE и MDEV, поэтому меня гложут сомнения, не смотря на прилагаемый по ссылке файл для OED622, в живучести такой системы. Вы конкретно иссследовали полученную систему синхронизации на устойчивость, вносили джиттер, вандер, проверяли при этом параметры синхронизации????

К сожалению про OED155 сказать не могу. Но с фапчами от ZARLINK(MITEL) работал много ещё на потоках Е1. Фирма специализируется на коммуникациях и всем, что с этим связано. Картинку ту(которая в том посте пристегнута) прислал мне TRANSWITCH. ОНИ РЕКОМЕНДУЮТ такое включение. Хотя одни мои знакомые тупо умножили частоту 19,44 на 4 на DCM в SPARTANе. Джиттер - дрянь, но работает.

1) В общем я спросил через тогоже Павла Котлярова у разработчиков про ПОС двух ФАПЧ, ждем ответа.
2) Работает это мало, должно работать и соответствовать рекомендациям уважаемого ITU-T, а вот последнее ИМХО сомнительно для такой струткуры, о чем я и сообщал в предыдущем посте. К микросхеме зарлинка не имею никаких претензий даже думаю zl30123 использовать она по-новее и по-дешевле, но вот построение системы синхронизации вызывает вопросы, к сожалению у меня нет возможности все проверить, ехать за этими приборами далеко и дорого , а все потому, что разработчики трансвитча не удосужились разделить клоковые домены ClkRef и ClkTx , отсюда и проблемы, лень им видимо было или создавали микросхему только для фронт енд применений, о чем не удосужились сообщить.

Я использовал ZL30117. Откровенно говоря интерфейс управления (SPI) не заработал вообще. И тем не менее ФАПЧ работал и лочился(проверял частотомером и генераторм)

Про SPI очень интересно, по второму вопросу в том что захват будет происходить сомневаться не приходится, а вот сомнения в стабильности есть, Вы то этого не проверяли как я понял, для этого надо по крайней мере ANT-20 иметь под рукой с соответствующими опциями и/или нечто вроде Oscilloquartz(вместо опций синхронизации в ANT-20) и того на сумму 80 килозеленых.

ну вот написал ,про петли, фапчи.... получил ответ (Задорнов рулит )))) "From a jitter standpoint I am quite sure that this will be OK. I am talking with Zarlink about the MTIE  to double check that it will be OK." Очень грамотный технически обоснованный ответ ))) я плачу.... Нарисовал им картинку, может так дойдет ??????? Время покажет.

В pdf-е картинку кто нарисовал?

Дык говорю же - мое произведение, нарисовал как смог ,потому как структуру системы синхронизации кристала в даташите не показали, отослал в трансвитч в техподдержку, в надежде, что может до них так дойдет, что ситема с ПОС не может работать устойчиво.... Чего им стоило разделить клоковые домены на передачу и опоры приемного ФАПЧ????

В техподдержке картину мою поглядели, поняли(или сделали вид, что поняли) в чем суть вопроса, обещали подумать.... ждем..

А Трансвич не присылал Вам структурную схему синхронизации, которую они рекомендуют? Я взял её( выше ссылка) сделал всё по ней и все поехало... Я не заморачивался даже такими как у Вас структурами следящих систем.. Насчет Вашего рисунка... У Вас общая структура... А внутри Фапчей(DPLLs) всегда существуют корректирующие контуры(реализованые в различном виде) для обеспечения устойчивости...

1) эту структурную схему я взял там-же .
2) сделал всё по ней и все поехало....
Вот тут нужно уточнить, что и куда поехало????? То что у Вас произошел захват частоты я не сомневаюсь, меня берут сомения совершенно в другом, что происходит с фазой сигнала после второй ФАПЧ, а именно зарлинга ZL30XXX ????? Вы хотя бы осциллографом смотрели глазковую диаграмму - соотношения фаз входного сигнала после оптики и частоты на выходе ZL30XXX???? Вы можете утверждать, что в диапазоне отстройки и при заданных параметрах входного джиттера и вандера у вас все будет отлично, и вы уложитесь в требования ITU????? Мне думается, что Вы этого не проверяли, но у Вас есть железка и при желании это можно проверить.
3) теперь немного размышлений
Дело в том, что система первого ФАПЧ в первом приближении устойчива, т.к. как бы ни качалась опора(в разумных пределах) в данном случае Clk78 первая ФАПЧ подсинхронизируется импульсами, которые идут из линии, таким образом по частоте эта система работает и вопросов возможно не возникает, по фазе возможно тоже не возникает т.к. импульсы идут достаточно часто, о чем заботится скремблер, а вот фаза восстановленного сигнала после второй системы ФАПЧ просто обязана плавать, т.к. она подсинхронизирует сама себя , т.е. включена в контур ПОС, который ничем не компенсируется.
Хотите верьте на слово выпускнику кафедры САУ, хотите проверьте - не так просто компенсировать глобальную ПОС локальной ООС даже математически, а физически реализовать еще труднее с учетом того что-бы локальная система (вторая и первая ФАПЧ) оказалась бы сама по себе устойчивой, а не только в контуре. То что производители у микросхем разные и мало между собой связаны вероятность таких усложнений вообще сводит к нулю, а Вы говорите "поехало"....., Куда поехало?

Под "поехали" я подразумевал - заработало.
Мое устройство приемо передающее. Я на вход подаю оптический сигнал, внутри ус-ва заворачиваю данные на частоте СФОРМИРОВАНОЙ ФАПЧ внешней(ZL30117) и передаю в виде оптического сигнала. У меня 2 какнала (восток запад) включаются оба. В качестве тестового оборудования(соответствующего анализатора увы нет) использую пару мультиплексоров STM1 и включаю свое устройство в разрез между ними.(оптический поток выходит из мультиплексора, попадает в мою плату,в ней заворачивается на передачу и передается на вход другого мультиплексора.) В STM запаковываю Е1 с PRBS. Моя плата снимает потки Е1. Анализатор Е1 (такой у меня к счастью есть), мультиплексоры, Выходные данные с платы - все идет без ошибок. Прогон 24ч в термокамере (0.. + 40). К своему стыду я не настолько хорошо искушён в ТАРЕ. Могу конечно на устойчивость рассчитать... Просто я даже не заморачивался этим вопросом.. Фирма производитель рекомендовала мне соответствующее включение. Я его реализовал и... все поехало.

У меня есть сомнения и я их выразил, готовое устройство может не пройти сертификации именно по указанным пунктам, у меня тоже нет оборудования для проверки всех этих вещей, ана коленках достаточно трудно выловить эти проблемы, пусть уж производитель почешется и выдаст что либо логичное - кроме все будет ОК, по крайней мере я хочу подстраховаться, все равно буду использовать эту микросхему, т.к. уже закуплено.
Запросил дезайн мануал по зарлинку ZL30123 пока тишина.... вобще поражают полу-даташиты от этой конторы с отсутствием необходимой информации, хоть бы Preliminary написали что ли .

Сомнения - это хорошо! Главное что бы они в тупик не завели...
В свое время я делал по подобной схеме устройство на поток Е1. Анализаторы у меня есть. И я сдавал заказчику на них, с проверкой по синхронизации.
А даташиты они щас все начинают прятать.

Все дошел до точки.... получил ответ на свою картинку:
"However, at 1st glance the path that the SSS indicates as a positive feedback path may not be one because the RCLKA output follows LINE_RPOSA/RNEGA and not SCLK78"
Т.е. с ФАПЧ OED155 все будет ОК, т.к. он следует за линейным сигналом LINE_RPOSA/RNEGA...... слов нет одни буквы.... А от опоры типа вобще ничего не зависит..... Хваленое узкоспециализированное западное образование, дальше своего носа ничего не видят или не хотят....

Получил картинку от трансвича, как решение проблемы петель, коряво но работоспособно. По крайней мере здесь нет ПОС, хотя такое решение мне откровенно не нравится, правда другого выхода пока не видно

Вы их убедили видно. Хотя и требуются дополнительные CDR..


Простите а в чем у Вас вообще стояла задача?(если не секрет)

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


Задача простая STM1 + Ethernet в вариантах точка/точка и кольцо, если в 1-м варианте проблем нет, то во втором на сетях часто используют ретрансляцию клока по кольцу (без замыкания естественно), так вот в таком включении и возникают проблемы с ПОС, таким образом в кольце режим ретрансляции опорной частоты 155МГц просто так не реализуется. Я пока буду делать плату без внешних CDR а там видно будет.... может они выпустят релиз микросхемы с разделенными клоковыми доменами опорной частоты и частоты передачи. Пока еще точка не поставлена, я запросил мат модели DPLL и его параметры OED, обещали выяснить, если у меня будут такие данные я попробую расчитать полосу внешнего PLL, ткаим образом, что-бы не нарушались условия устойчивости ситемы, но это вопрос долгий, поэтому отложу на 2-ой этап проекта.

А Вам не кажется, что с точки зрения синхронизации, включение точка-точка и кольцо - одно и тоже. Есть MASTER задающий тактовую частоту, Есть SLAVE берущий тактовую частоту из входного сигнала и передающий на этой частоте.


Я бы на это не надеялся..

1) Все верно, но возможен еще и другой вариант для транспортной системы при соединении точка точка не обязательно сам транспорт отдавать назад с частотой мастера, т.е. можно работать в системе - мастер/мастер, но при этом потоки Е1 синхронизировать с частотой ведущего узла, такое включение вполне допустимо. В кольце так-же можно работать по частоте мастер/мастер, только глобальной синхронизации от потока высшего уровня - STM1 не получится.
2) Я и не надеюсь

Вопрос: Маппер Ethernet трансвичевский TXC-04246 не использовали случаем???? если использовали, то что к нему со стороны Ethernet подключали????

Нет не использовал у меня на телебусе плиска. Все в ней.

Свершилось! После долгих боданий с техподдержкой трансвич они таки выпустили еррату по синхронизации OED155 http://www.transwitch.com/controller/produ...f?document=1837 Значица труд не пропал даром

Кто разбирался с алгоритмом BIP-8 в кадре внешнего интерфейса SOI у Transwitch из даташита не понятно как его вычислять:
This byte is allocated for error monitoring. This function should be a Bit Interleaved Parity
8 (BIP-8) code using even parity. The BIP-8 is computed over all 31 bytes (from ID to R6)
of the current section overhead frame.
Подскажите кто знает.

Связался с техподдержкой вот ответ, может кому пригодится:

To do a BIP-8 calculation with even parity, you XOR each of the bytes
together like shown below (referring to table 4 on 32):

ID xor E1 xor F1 xor ... R5 xor R6 = BIP-8 with even parity.

Just fyi, for odd parity you would just invert the calulated BIP-8.

So to check if there are data errors in the received section overhead
frame data you would calculate the BIP-8 and compare it with the BIP-8
code in the section overhead frame data from the OED155. Each bit that
does not match is considered a parity error.

BIP-8 means that you are doing 8 parity calculations, e.g. bit 0 of all
the bytes is considered as 1 stream over which parity is calculated. Bit
1 of all bytes is considered as another stream over which parity is
calculated, etc.

Продолжаем разбираться с чудесами от TranSwitch.
EtherMap®-3 Pt Device про подачу питания имеем из даташит:

During power-up, I/O Supply Voltage VDD33 (3.3V) must lead the VDD18 (1.8V), VDDP18 (1.8V) and
VDDPA18 (1.8V) supplies. In addition, the Core Supply Voltage (VDD18) needs to be brought up after I/O
Supply Voltage, and can be brought up together with VDDP18 and VDDPA18 supplies. After power up, the I/O
Supply Voltage must not go below the Core Supply Voltage by more than 0.5V at any time, including power
down. The maximum interval that VDD18, VDDP18 and VDDPA18, must be powered up after VDD33 depends
on the slew rate of power ramp-up in customer’s application.

Так вот на самом деле оказалось, что если подать питание IO и не подать питания ядра, то через 600-800мкс происходит резкое возрастание потребления микросхемы по IO, она начинает сильно нагреваться. Если подавать питание ядра не позднее 200 максимум 300мкс, то все стартует нормально.

Вопрос по OED 622. Подскажите кто знает.
Делаю кроссконнект на уровне VC-12.
Например, прописываю
1-VC-12 Line A (0 порт) на 1-VC-12 Line B (4 порт)
2-VC-12 Line A (0 порт) на E1-1 Mapper A (16 порт)
соединения двухсторонние, после этого не проходит сигнал из 4 порта в 0.
Что я делаю не так?
HLXCR0 бит low order mode
HLXCR4 бит low order mode
HLXCR16 бит low order mode

HLXCM0(addr 00)= VC-4 POH (4 порт)
HLXCM0(addr 01)= 1-VC-12 (4 порт)
HLXCM4(addr 00)= VC-4 POH (0 порт)
HLXCM4(addr 01)= 1-VC-12 (0 порт)

HLXCM0(addr 00)= VC-4 POH (16 порт)
HLXCM0(addr 01)= 1-VC-12 (16 порт)
HLXCM16(addr 00)= VC-4 POH (0 порт)
HLXCM16(addr 01)= 1-VC-12 (0 порт)

По отдельности все работает, а вот вместе работает только последний прописанный.
Может не так нужно прописывать заголовки?

А как Вы предполагаете оно должно проходить? Чередованием данных что ли? Естественно, работает последнее двустороннее соединение, первое становится односторонним.

Получается, что одновременно нельзя сделать транзитное соединение части VC-12 с одного порта оптики на другой и одновременно сделать ввод вывод оставшихся VC-12 на mapper?
Не может быть!
Сокрее всего я что-то не так прописываю.
В первом сообщении была опечатка.

HLXCM0(addr 00)= VC-4 POH (4 порт)
HLXCM0(addr 01)= 1-VC-12 (4 порт)
HLXCM4(addr 00)= VC-4 POH (0 порт)
HLXCM4(addr 01)= 1-VC-12 (0 порт)

HLXCM0(addr 00)= VC-4 POH (16 порт)
HLXCM0(addr 02)= 1-VC-12 (16 порт)
HLXCM16(addr 00)= VC-4 POH (0 порт)
HLXCM16(addr 01)= 2-VC-12 (0 порт)

При таких значениях работает только одно соединение.

[удалено]