Fibre Channel, скоростная технология передачи данных Опции

[Hadgehog]

Недавно проявилась тема: прием и передача видеоданных через канал Fibre Channel, для упрощения предложено пользоваться протоколом по сервису 3, это означает что данные передаются без установления логического соеденения и подтверждения приема. предожено использовать скорость 250 Мб/с с перспективой наращивания до 1 ГБ/с. среда распостранения витая пара, не более 15 м. предлагается использовать микруху CYP15G0101DXB-BBI или CYV15G0101DXB-BBI в качестве линка, контроллер верхнего уровня на ПЛИС. Кто нибудь использовал то нибудь подобное? если не трудно раскажите про грабли , пожалуста.

[Esquire]

Вот и до Новгорода дошло (ЗАО "Элси", как я понимаю )

Ну что могу сказать: наступание на грабли в самом разгаре...

Конкретные вопросы/предложения - в ПМ.

[one_man_show]

Уважаемый Esquire, Вы хоть про один зубчик от тех граблей поведайте , интересно же всем

[Esquire]

В стандарте на FC предусмотрены две физические среды передачи данных: медный кабель и оптоволокно. В отечественных условиях разработки ведутся с использованием коаксиального/твинаксиального кабеля на частотах от 266 до 1062 МГц, что соответствует диапазону скоростей от 1/4х до 1х. Возрастание затухания и КСВ при увеличении длины медной линии связи (реально до 30-35 м) является самым острым зубчиком в граблях для разработчика. Переход на бОльшие скорости (4, 10 Гбит/с), если он состоится, сулит замену меди на волокно.

интересно же всем

Вот это навряд ли. FC - специализированный интерфейс для авионики, гражданское же его применение (сети хранения данных, SAN) встречается редко, а в России, кажется, и вовсе не встречается. Для всего остального существует Gigabit Ethernet
Всем интересующимся советую изучать теорию = стандарты, драфты которых выложены у разработчиков протокола.

[Hadgehog]

Уважаемый Esquire

про перспективы всё понятно . драфты разработчиков - Т11, проглядывались очень внимательно, все лаконично и по делу, хотя трудно разобраться когда смотришь разные редакции, наверное потому что всё по английски.
Есть ли у кого подробности применения CYP15G0101DXB-BBI.
Вот ещё вопросик по импульсному трансформатору: если длина линии связи не более 15 м, то возможно использовать ТМ266HSCT от PulsSpeciality для скорости 250, как такое решение?
не очень ясен вопрос по соеденителям: хотелось использовать соеденитель на плату АMPHINOL 21-33837-2, для оценки прикладываю доку.
если не трудно поясните правила разделки кабеля Tensolite 28473/02006-4.
Суть вопроса в следующем: у начальства есть желание поставить блочный разъем серии D38999 размера 9 и уже от него кабелем сделать прокладку на печатную плату под запайку, отросток будет короткий, не более 30 мм. Меня беспокоит целесообразность подобного решения, мои ссылки на стандарты приводят только к ответам типа "а в чем разница? провода точно такие же", "установка соеденителя на печатную плату приведет к отрыву соеденителя и растрескиванию печатной платы в процессе эксплуатации"

Сообщение отредактировал Hadgehog - Sep 27 2004, 16:20

Прикрепленные файлы

 21_33837_21_C.pdf ( 113.95 килобайт ) Кол-во скачиваний: 288

 

[Esquire]

Все зависит от конструктива устройства. Если это специзделие, то они правы в большей степени, если макет/отладочная плата - ты прав.
Хотя целесообразность отростка в 3 см у меня тоже вызывает сомнения .

[maksya]

Уважвемый Hadgehog, есть ли результаты в вашей разработке устройства на Fibre Channel. В ближайшем будущем у меня, возможно, появится необходимость делать нечто подобное. Хотелось бы пообщаться со знающим человеком.

[Hadgehog]

Уважвемый Hadgehog, есть ли результаты в вашей разработке устройства на Fibre Channel. В ближайшем будущем у меня, возможно, появится необходимость делать нечто подобное. Хотелось бы пообщаться со знающим человеком.

В ближайшее время отправляем в производство макетную печатную плату, если производство не подведёт месяца через 2 можно говорить о результатах.

[deast]

А может у кого есть программная модель CYP15G0101DXB (Verilog/VHDL)...
Тоже ведем разработки с использованием данного компонента. deast@yandex.ru Отлаживаем в среде AHDL 6.3. Спасибо...

[Esquire]

На сайте Cypress такие модели доступны на условиях подписания соглашения о неразглашении (non-disclosure agreement, NDA), но, по-моему, сейчас у них эта опция просто не работает .

P.S. Если это не военная тайна, что за устройства делает "Элвис" на базе FC (можно отвечать в ПМ )?

[deast]

Своим разработкам:

http://www.elvees.ru/multicore/project.shtml

пытаемся найти дополнительные применения. У меня не получилось достать модель на сайте. Может я что-нибудь не правильно делал. Если у Вас есть такая возможность, сделайте пожалуйста. Буду очень признателен...

[Porychik Kize]

http://www.elvees.ru/multicore/project.shtml

пытаемся найти дополнительные применения. У меня не получилось достать модель на сайте. Может я что-нибудь не правильно делал. Если у Вас есть такая возможность, сделайте пожалуйста. Буду очень признателен...

[/quote]

"Мультикор" - платформа интересная. Была бы. Если бы не слухи о бешеных ценах за 1шт. кристалла (мне на глаза попадалась цифра в 1к$/шт) и если бы отсутствовали проблемы с их розничной покупкой. :-))) Или я неправ??? (несколько провокационный вопрос, верно?). Кстати, а вы используете только Altera? (судя по шине AMBA) или Xilinx тоже (ведь в ближайшую среду в зелеке в здании около вас будет xilinx-тусовка)?


to Hadgehog: каковы результаты-то??? народу интересно...

[deast]

Возможно и были когда-то такие цены. Но сейчас это далеко от истины:

http://www.elvees.ru/price/multicore.shtml#snoska1

В основном используем Xilinx.
По поводу покупки, есть на сайте все контакты. Звоните и договаривайтесь. Проблемы я в этом не вижу...

[Esquire]

deast
Cypress рекомендует за файлами моделей обращаться к своим региональным представителям, наверное, с целью подписания вышеупомянутого NDA <_< .

Так значит, "Элвис" все-таки будет проектировать СБИС с FC-интерфейсом (о подобных намерениях было слышно уже года два назад) или нет ?

[deast]

Такие разработки давно уже ведутся. Проблемы только некоторые есть. В основном связанные с нехваткой информации...

[Hadgehog]

to Hadgehog: каковы результаты-то??? народу интересно...

Макетная плата настраевается, запуск канала FC на скорость 250 и 500 Мб/с прошёл нормально, программные модульки приёмника и передатчика успешно формируют и принимают пакеты по ANSI Х3.230.1994, СRС вычисляется. Пока ещё не готовы модульки визуализации принятых данных на мониторе, до конца месяца хочется завершить. Есть определённые вопросы по CRC - не о механизме расчёта, он работает нормально, а о порядке подачи байтов на автомат расчёта, думаю до конца месяца определиться с этим вопросом. Сейчас уже не помю, уточню позже в каком режиме (состояние упр. ножек) произвели запуск. Общее впечатление от микросхемы: чип вменяемый - реакция на управляющее воздействие прогнозируемое, по описанию. потребление достаточно высокое, что интересно от скорости передачи не зависит- или мы не заметили - на скорости 250 и 500 были равные результаты. что интересно, значительное потребление даёт приёмник. награев в режиме когда включен приёмник и передатчик у радиатора 30х30 мм с высотой ребра 7 мм 42 гр.С
Был у нас глюк: подключали трансформатор-эквалайзер к чипу с подтягивающими резисторами на 220 Ом (согласование pecl) поимели очень нестабильные результаты по захвату частоты синхронизации, заменили на резисторы на 330 Ом (что рекомендовано в большинстве описаний) всё работает на ура.
в планах: когда завершим работу с платой (получим устойчевый канал + визуализация) засуним в камеру тепла и холода,
руководство желает использовать неправильные соеденители - типа СНЦ23,
проведём опыт по устойчивости канала с несогласованой нагрузкой .

[Hadgehog]

добрый день.
вчера закончили модуль выдачи и приёма тестового сигнала. Прокачали через канал картинку 640х480 30 к/с, правда картинка цветные полосы, без хитрых элементов, думем как прикрепить на этот фон подвижный объект, хотим посмотреть динамику. Телевизионная камера с выходом FC пока не готова.
Очень впечаляет работа трансформатора на витую пару от PulsSpeciality, за не имением под рукой правильного провода на 150 Ом в экране, взяли обычную витую пару 5 категории - сколько было-38 м. смотрим как ведёт себя CRC, пока особых проблем нет. В понедельник будем замешивать в канал помеху.

[deast]

Еще одна проблема связанная с FC. Не куда выводить информацию. Нужен монитор, а где искать не знаем. Может кто подскажет?

[Esquire]

Все зависит от того, в соответствии с каким протоколом будет работать передатчик.

Если планируется применить стандартный FC-AV (Fibre Channel - Audio-Visual), то наиболее удобным представляется вариант приемник-адаптер FC с возможностью вывода на обычный монитор (соответствующие примеры приведены здесь ), а если ваши работы координируются с пионером FibreChannel-строения в России, раменским РПКБ, применяющим обмен, несколько отличный от стандартного, то можешь посмотреть на их индикаторы с входом FC.

P.S. Достаточно давно говорят о российском стандарте в области FC, но пока дело движется очень медленно, хотя наверное, неизбежно, учитывая постоянно расширяющееся применение интерфейса в спецтехнике.

[Sasha P.]

Здравствуйте!
Hadgehog, скажите пожалуйста, а что Вы использовали в качестве генератора тактовой частоты для трансмиттера? Что-нибудь Epson'овское? И где такие осцилляторы можно найти?

[Hadgehog]

Здравствуйте! 
Hadgehog, скажите пожалуйста, а что Вы использовали в качестве генератора тактовой частоты для трансмиттера? Что-нибудь Epson'овское? И где такие осцилляторы можно найти?

использовали генераторы типа HG-2150CA-BXC 25МГц от EPSON
заказывали в С.Петербурге ф. "Специал Электроник"

[Sasha P.]

использовали генераторы типа HG-2150CA-BXC 25МГц от  EPSON
заказывали в С.Петербурге ф. "Специал Электроник"

Спасибо!
Но я думал, что для входов опорной частоты трансмиттера REFCLK+/- лучше использовать LVPECL-осцилляторы.
Вот, у EPSON есть
EG-2101CA
EG-2102CA-P
EG-2121CA-P
Но они не подходят по температурному диапазону...

EV-2101CA-P - подходящий, но у нас его не найти - по efind.ru, во всяком случае.

Есть ещё осцилляторы от ICS...

А HG-2150CA-BXC - CMOS'овский! Конечно, в PDF'е на трансмиттер указано, что можно использовать только вход REFCLK+ с подключенным к нему источником LVCMOS или LVTTL сигнала. Но я думал, что LVPECL - правильнее.

Как же, всё-таки, лучше? Вы, наверное, выбирали наиболее доступный компонент?

[Hadgehog]

использовали генераторы типа HG-2150CA-BXC 25МГц от  EPSON
заказывали в С.Петербурге ф. "Специал Электроник"

Спасибо!
Но я думал, что для входов опорной частоты трансмиттера REFCLK+/- лучше использовать LVPECL-осцилляторы.
Вот, у EPSON есть
EG-2101CA
EG-2102CA-P
EG-2121CA-P
Но они не подходят по температурному диапазону...

EV-2101CA-P - подходящий, но у нас его не найти - по efind.ru, во всяком случае.

Есть ещё осцилляторы от ICS...

А HG-2150CA-BXC - CMOS'овский! Конечно, в PDF'е на трансмиттер указано, что можно использовать только вход REFCLK+ с подключенным к нему источником LVCMOS или LVTTL сигнала. Но я думал, что LVPECL - правильнее.

Как же, всё-таки, лучше? Вы, наверное, выбирали наиболее доступный компонент?

Добрый вечер. Честно говоря при выборе опорного генератора было прядка 10 позиций, начальный выбор происходил исходя из требований стабильности и температурного диапазона, на последнем этапе доступность играла основную роль.
использование LVPECL конечно более правильное, но как показывает практика использование генератора с уровнем CMOS при подключении к ПЛИС и разгон (умножение), равно как и деление частоты на PLL и последующая выдача на трансмиттер вполне допустима. Хитрость состоит в том, что для надёжного съёма информации при приёме необходимо пользоваться востановленой частотой от трансмиттера.

[Sasha P.]

Добрый вечер. Честно говоря при выборе опорного генератора было прядка 10 позиций, начальный выбор происходил исходя из требований стабильности и температурного диапазона, на последнем этапе доступность играла основную роль.
использование LVPECL конечно более правильное, но как показывает практика использование генератора с уровнем CMOS при подключении к ПЛИС и разгон (умножение), равно как и деление частоты на PLL и последующая выдача на трансмиттер вполне допустима. Хитрость состоит в том, что для надёжного съёма информации при приёме необходимо пользоваться востановленой частотой от трансмиттера.

Спасибо! Посмотрим, как получится.

[deast]

Может у кого есть стандарт ANSI X3.230-1994. В соответствии с ним собираемся проектировать свой модуль FC...

[Hadgehog]

Может у кого есть стандарт ANSI X3.230-1994. В соответствии с ним собираемся проектировать свой модуль FC...

Выложил в upload/doc/ANSI X3.230-1994 документик, может быть поможет.

[deast]

Спасибо за документ. Очень пригодился...
Ну вот и мы добрались до конкретики. Появилось множество вопросов.
1) Что можно подавать в качестве IDLE слов? В ТЗ указано, что в качестве примера IDLE может быть N-K28.5 D21.4 D21.5 D21.5. Что это значит, понять пока не можем. Как я понял -- это константа или последовательность констант. Может кто владеет?
2) SOF и EOF --- начало и конец кадра. Тоже самое не понятно.
Остальная информация в fc-кадре зависит от самой информации и аппаратуры. Мы предполагаем передавать видеоданные. А именно картинку 1280*1024. Это значит, что надо передать 1310720 слов. Разрядность цвета 32 bit. В одном fc-кадре может содержаться до 2112 байт данных. В нашем случае это 528 слов. Это значит, что надо передать последовательность из 2482 fc-кадра по 528 слов и 1 fc-кадр из 224 слов. Правильно ли я понимаю опсанную процедуру? Может какие-то замечания есть? Спасибо...

[Hadgehog]

добрый вечер deast
по пункту-1. заполнителль IDLE передаётся всегда когда линия не активна, т.е. по неё не передаётя полезная информация в виде пакетов данных. Отсюда вытекает очень важное правило: все передаваемые данные в канале ориентированы на 32-х разрядную архитектуру. Если надо передать хоть байт, хоть слово необходимо занять минимум 32 бита - слово в терминологии FC.
что касается К28.5 и D21.4.. и.т.д все вопросы по правилам формирования к IBM, такая кодировка это их изобретение. символ "К" признак служебного символа, "D" -признак символа данных, отличия в правилах форирования битовой последовательности-разрешённого количества "1" и "0" подряд.
Одним словом IDLE - 40 бит в линии связи. Самое простое решение: пользоваться готовыми кодеками с встроеным кодировщиком 8/10, и умножителем с ФАПЧ для востановления несущеёй частоты.

по вопросу кодирования 8/10 можно поковырять мегафункцию Альтеры- доступна ограниченая WEB версия, ранние варианты ядра подвергались лечению, настоящие не пробывал.

по пункту-2
SOF- четырёх байтный символ начала кадра данных (в линии 40 бит данных )
EOF- четырёх байтный символ конца кадра данных (в линии 40 бит данных)
не стоит забывать о обязательных полях: номер кадра в последовательности, номере последовательности, CRC32итд.

Предложеная нарезка FC-кадров вполне справедлива, ввиду того что разрядность цвета на точку 32 разряда. В случае если кодировка точки -8, 16, 24 разряда, то FC-кадр необходимо выравнивать до кратного 32, заполняя хвосты 00.

То что предполагается для передачи видео вообще не FC в стандартном виде, это HotLink в терминологии Cypress - выхолощеный до нельзя канал уровня FC-PH ориентированый на одностороннюю передачу данных(видео данных). работать будет, но в целом могут быть проблемы позже, если потребуется сменить формат или переключать форматы изображения во время передачи.

можно посмотреть драфты стандарта ANSI X3.... для аудио видео приложений FC-AV, там много стандартных реализаций передачи видеоданных.

[Onneg]

Уважаемый Hadqehoq

Расскажите пожалйста, каким образом Вам удалось достать pdf-ку
на раз'ём Amphenol 21-33837-21.
В настоящее время я тоже занимаюсь разработкой модуля
ввода-вывода видео, используя Fibre Channel.
Для себя я присмотрел раз'ёмы Amphenol 21-33833-101,
21-33832-91, 21-33833-111. У меня получилось скачать
только каталог, где указано, что такие раз'ёмы в принципе существуют,
и приведены их фотографии. Но чертежей с указанием размеров
я просто нигде найти не могу.
Помогите пожалуйста.
Заранее благодарен.

[Hadgehog]

Уважаемый Hadqehoq

Расскажите пожалйста, каким образом Вам удалось достать pdf-ку
на раз'ём Amphenol 21-33837-21.
В настоящее время я тоже занимаюсь разработкой модуля
ввода-вывода видео, используя Fibre Channel.
Для себя я присмотрел раз'ёмы Amphenol 21-33833-101,
21-33832-91, 21-33833-111. У меня получилось скачать
только каталог, где указано, что такие раз'ёмы в принципе существуют,
и приведены их фотографии. Но чертежей с указанием размеров
я просто нигде найти не могу.
Помогите пожалуйста.
Заранее благодарен.

добрый вечер
поставками соединителей AMPHINOL в Россию осуществляет фирма bee-pitron (Би питрон) С.Петербург
bee-pitron.ru. Вопросами поставки и техническими консультациями занимается Стуколкин Николай.

[deast]

Хорошо, а каким образом микросхема CYP15G010DXB определяет, служебная информация подается или данные? И еще не совсем понятно. Основной неделимой единицей передачи информации является кадр. Он имеет определенную структуру, состоящую из поля данных и нескольких полей служебной информации. При чем сказано, что размер поля данных может быть до 2112 байт (528 слов по 32bit). Не нашел, где задается размер этого поля. Есть только в поле заголовка порядковый номер кадра в данной последовательности и бит последнего кадра. Как система понимает, где заканчиваются данные?

[Onneg]

Уважаемый Hadqehoq,
большое спасибо за помощь, контакт с bee-pitron
установлен, запрос отправлен, ожидается ответ…

[Hadgehog]

Хорошо, а каким образом микросхема CYP15G010DXB определяет, служебная информация подается или данные? И еще не совсем понятно. Основной неделимой единицей передачи информации является кадр. Он имеет определенную структуру, состоящую из поля данных и нескольких полей служебной информации. При чем сказано, что размер поля данных может быть до 2112 байт (528 слов по 32bit). Не нашел, где задается размер этого поля. Есть только в поле заголовка порядковый номер кадра в данной последовательности и бит последнего кадра. Как система понимает, где заканчиваются данные?

добрый вечер,
разделение служебной информации от данных производится на основе анализа сформированого кода 8/10, коды данных - кодируются строго по правилам, служебные команды нарушают правила кодирования.

Для определения длинны кадра специально предусмотрены служебные символы SOF и POF которые однозначно определяют границы кадра, поэтому объём данных вычисляется по мере приёма кадра, просто должен стоять программый ограничитель на длинну кадра. Если длинна кадра вышла за допустимые граници -сигнализировать о ошибке кадра.

[deast]

С форматом пакета немного разобрался, теперь с данными и кодированием. Мы тоже используем микросхему CYP15G0101DXB. Есть входная шина TXD[7:0] на нее подается код символа. Также имеем TXCT[1:0] двухразрядную шину для кодирования. SCSEL как-то тоже участвует в кодировании. И TXMODE[1:0] -- это совсем не понятно. Задает какие-то режимы работы. В первую очередь хочу понять, какие режимы нужны в моем случае, или туда можно канстанту какую-нибудь подать?
Если будем передавать только слова IDLE. По Т.З. формат слова имеет структуру: N-K28.5 D21.4 D21.5 D21.5. В Т.З. также сказано, что каждый передаваемый символ состоит из восьми бит: a,b,c,d,e,f,g,h. Имет обозначение Zxx.y Где Z -- контрольная переменная (может принимать значение D или K). xx -- десятичное значение двоичного числа, составленного из битов e,d,c,b,a, y--десятичное значение двоичного числа, составленного из битов h,g,f.
По этим правилам получается
D21.4 = 100_10101,
D21.5= 101_10101,
K28.5= 101_11100.
С символами D-типа проблем нет. А вот значения символа K-типа противоречит описанию микросхемы. Какое значение поставить пока не знаю. Также пока разбираюсь, какие режимы передачи задавать TXMODE[1:0] во время передчи слов IDLE и как кодировать слова...

[Zugus]

Добрый вечер.
Вопрос по формированию десятибитовой последовательности в микрухе CYP15G010DXB, она может быть разной.
Вот цитата с http://text.marsu.ru/osp/lan/2000/01/019.htm

/*
Каждый байт данных или специальный символ имеет два (возможно, одинаковых) передаваемых кода, т. е. каждый передаваемый символ имеет два представления, в частности K28.5 может быть представлен и как десятибитовая последовательность 0011111010, и как 1100000101. Какое из двух возможных представлений будет выбрано для передачи, зависит от значения «текущего дисбаланса» (Running Disparity, RD). Двоичный параметр RD вычисляется на основании баланса 0 и 1 в подблоках передаваемого символа. 1 соответствует сигналу с большей оптической мощностью (для оптических каналов) или сигналу с большим напряжением на контакте +, чем на контакте – (в случае медных линий). Текущий дисбаланс вычисляется после первых шести битов каждого передаваемого символа и затем после последних четырех его битов.
*/

Собственно хотел спросить, кто-нибудь может подробнее обьяснить, как вычисляется этот RD.

Спасибо.

[Onneg]

Добрый день, Esquire.

У нас возникла необходимость в адаптере GRAV32_PCI_FCAV фирмы Great River Inc.
Вы ранее упоминали о таких. Подскажите, пожалуйста, каким образом и где возможно
осуществить заказ этого адаптера в России.
Заранее благодарен.
------------
Onneg

[Onneg]

Добрый день.

Вычисление параметра Running Disparity (Текущего дисбаланса или нечётности)
в соответствии с FC-PH по ANSI X3.230-1994 происходит следующим образом:


- 10 бит a, b, c, d, e, i, f, g, h, j представляется двумя субблоками
a, b, c, d, e, i и f, g, h, j;

- Текущая нечётность в начале 6-ти битового субблока является текущей
нечётностью в конце последнего переданного символа;

- Текущая нечётность в начале 4-х битового субблока является текущей
нечётностью в конце 6-ти битового субблока;

- Текущая нечётность в конце символа является текущей нечётностью в конце 4-х
битового субблока;

- Текущая нечётность устанавливается положительной, если число единиц
в субблоке больше числа нулей. Также текущая нечётность устанавливается
положительной в случае, если субблок содержит комбинацию 000111 (или 0011);

- Текущая нечётность устанавливается отрицательной, если число нулей в субблоке
больше числа единиц. Также текущая нечётность устанавливается отрицательной в
случае, если субблок содержит комбинацию 111000 (или 1100);

- Во всех других случаях текущая нечётность не изменяется.

Изначально (перед передачей первого символа,
после включения и инициализации передатчика)
текущая нечётность автоматически устанавливается отрицательной.

Onneg.

[deast]

Если кто владеет, подскажите, что указывается в поле Parameter заголовка FC кадра? Я предполагаю, что это физический адрес в памяти, куда следует положить первое полезное слово данного пакета. Если это так, то адрес является абсолютным, а во всех описаниях сказано, что данный адрес является относительным. Если так, то относительно чего этот адрес надо вычислять? Спасибо...

[UNIT]

Добрый день.

Уважаемые господа разработчики! Подскажите пожалуйста, кто сталкивался с выбором(покупкой)драйвера-эквалайзера для организации FC канала на 50-омном кабеле.
В частности интересует продукция "Pulse Specialty Components" TM266DCB2 и TM531DCB2.
Если с мелкосерийной закупкой TM266DCB2 вопрос как то решается( срок поставки 10-12 недель), то с TM531DCB2 совсем плохо .
Буду признателен за любую информацию по теме.

[Artemii Panasuk]

Приветствую.

Подскажите пожалуйста, кто сталкивался с выбором(покупкой)драйвера-эквалайзера для организации FC канала на 50-омном кабеле.

Ну не совсем на 50-омном, но сталкивался. Делаю по стандарту на 75 ом. Применяю трансформатор от Mini-Circuits Tx-2-5-1. У них же есть трансформаторы FC до 533 МГц.

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

В частности интересует продукция "Pulse Specialty Components" TM266DCB2 и TM531DCB2.
Если с мелкосерийной закупкой TM266DCB2 вопрос как то решается( срок поставки 10-12 недель), то с TM531DCB2 совсем плохо .
Буду признателен за любую информацию по теме.

Mini-Curcuits покупается в "Альтекс"
С уважением, Артем.

[starley]

Ого, тут оказывается вокруг Fiber жизнь кипит, а я думал мы одни такие умные А у нас есть мезонины и PCI-карты для FC-ASM для меди и отечественной оптики (от ЗАО ВОСПИ). Канал на 1 ГБит/с. Скорость передачи с ПК на ПК до 90 МБайт/с. Пока сердце системы Virtex2Pro, сейчас переводим это дело на ASIC.

Если кто владеет, подскажите, что указывается в поле Parameter заголовка FC кадра? Я предполагаю, что это физический адрес в памяти, куда следует положить первое полезное слово данного пакета. Если это так, то адрес является абсолютным, а во всех описаниях сказано, что данный адрес является относительным. Если так, то относительно чего этот адрес надо вычислять? Спасибо...

Это не так. Данное поле может использоваться как относительное начальное смещение данных в пакете протокола верхнего уровня. Это определяется значением соответствующего бита в F_CTL. В основном данное поле служит для сборки пакета верхнего уровня разбитого на несколько отдельных последовательностей кадров. Куда складывать полученные данные определяет протокол верхнего уровня, например, FC-VI или FC-ASM, cам FC-FS отвечает только за пересылку данных по сети.

[vikk]

2 starley:

А протокол передачи какой используете? видео, сообщения...

[starley]

2 starley:

А протокол передачи какой используете? видео, сообщения...

FC-AE-ASM - сообщения.