Соединение LVDS на 10 метров по витой паре Опции

[SergeyPro]

Всем доброго дня.

Есть потребность соединить два устройства по LVDS, передача однонаправленная. Думаю использовать обычную витую CAT5e витую пару с бестрансформаторными разъемами. Требуемое расстояние передачи до 10-20м, битрейт относительно низкий - до 30 МБит/с по каждой паре. TI в даташитах обещает до 150-190 Мбит на 10м. Соединяемы по LVDS устройства будут иметь обычные (не импульсные) блоки питания. У меня есть опасения в работоспособности такого решения из-за возможных проблем связанных со сдвигом потенциала земель двух соединяемых устройств.

Вопросы у меня следующие:
1. Достаточно ли будет выравнивания потенциалов между устройствами по экрану витой пары? На мой взгляд, это не эстетичное решение.
2. Оправдано ли использование в моем случае RJ-45 разъемов с трансформаторной развязкой? Ясно, что DC не передать и придется кодировать в манчестере, например. Будет ли такой вариант работать от микрух типа SN65LVDS391 / SN65LVDS348? Для 4-х пар придется использовать 1Gbit - разъемы с трансформаторами, а они денег заметно стоят.
3. Или не париться и делать с гальванической связью, так как примник SN65LVDS348 допускает сдвиг земель -4 +5 вольт (-4 V to 5 V Common-Mode Input Voltage Range)?

Если есть у Вас опыт работы с LVDS, то прошу поделится
Ethernet не предлагать!

Сообщение отредактировал SergeyPro - May 2 2018, 06:12

[a123-flex]

Есть потребность соединить два устройства по LVDS, передача однонаправленная. Думаю использовать обычную витую CAT5e витую пару с бестрансформаторными разъемами. Требуемое расстояние передачи до 10-20м, битрейт относительно низкий - до 30 МБит/с по каждой паре. TI в даташитах обещает до 150-190 Мбит на 10м. Соединяемы по LVDS устройства будут иметь обычные (не импульсные) блоки питания. У меня есть опасения в работоспособности такого решения из-за возможных проблем связанных со сдвигом потенциала земель двух соединяемых устройств.

Вопросы у меня следующие:
1. Достаточно ли будет выравнивания потенциалов между устройствами по экрану витой пары? На мой взгляд, это не эстетичное решение.
2. Оправдано ли использование в моем случае RJ-45 разъемов с трансформаторной развязкой? Ясно, что DC не передать и придется кодировать в манчестере, например. Будет ли такой вариант работать от микрух типа SN65LVDS391 / SN65LVDS348? Для 4-х пар придется использовать 1Gbit - разъемы с трансформаторами, а они денег заметно стоят.
3. Или не париться и делать с гальванической связью, так как примник SN65LVDS348 допускает сдвиг земель -4 +5 вольт (-4 V to 5 V Common-Mode Input Voltage Range)?

Если есть у Вас опыт работы с LVDS, то прошу поделится
Ethernet не предлагать!

Такие системы работают в реале, но при условии нормальной земли - и - да - при ее наличии париться не нужно и Вы можете не волноваться про выравнивание по DC в коде. На Вашем расстоянии, ИМХО, при условии приличного кабеля и отстутствии мощной внешней наводки - проблем быть не должно.
ИМХО, на ваших скоростях (и для 100-мбит eth), и на ваших расстояниях, совершенно все равно, какие разъемы - главное чтобы была витая пара.
Использование же трансформатора автоматически приводит к disparity == 8b10 == ethernet, либо манчестер, что гораздо отстойнее, тк скорость никакая, а геморрой тот же.

100 Мбит phy стоит чуть ли не дешевле, чем SN65LVDS391 (на самом деле LVDS драйверы адски дорогие, особенно в пересчете на пропускную способность), имхо выигрыш от использования eth огромный.
И даже Gbit phy сейчас есть недорогие. В долгосрочном виде решение с ethernet выгоднее тысячекратно.

И, кстати, бубен все равно будет нужен - канонический uart на 30 Мбит = 30 * 16 = 480 МГц, а это значит интересные упражнения.
Возможно eth на стандартном маке тупо проще

Ведь вы же не собирались SPI использовать ?)

[MegaVolt]

1. Достаточно ли будет выравнивания потенциалов между устройствами по экрану витой пары? На мой взгляд, это не эстетичное решение.

Не знаю... мы используем развязку или трансформаторную или просто конденсаторами.

2. Оправдано ли использование в моем случае RJ-45 разъемов с трансформаторной развязкой? Ясно, что DC не передать и придется кодировать в манчестере, например. Будет ли такой вариант работать от микрух типа SN65LVDS391 / SN65LVDS348? Для 4-х пар придется использовать 1Gbit - разъемы с трансформаторами, а они денег заметно стоят.

Мы применяем импульсные трансы. Всё отлично ездит. Один нюанс когда восстанавливаем DC нужно задать изначальное смещения для приёмника или 0 или 1. Чтобы при отключенном передатчике не было неопределённости.

Правда столько большие длинны не применяли.

[SergeyPro]

Такие системы работают в реале, но при условии нормальной земли - и - да - при ее наличии париться не нужно и Вы можете не волноваться про выравнивание по DC в коде. На Вашем расстоянии, ИМХО, при условии приличного кабеля и отстутствии мощной внешней наводки - проблем быть не должно.
ИМХО, на ваших скоростях (и для 100-мбит eth), и на ваших расстояниях, совершенно все равно, какие разъемы - главное чтобы была витая пара.
Использование же трансформатора автоматически приводит к disparity == 8b10 == ethernet, либо манчестер, что гораздо отстойнее, тк скорость никакая, а геморрой тот же.

100 Мбит phy стоит чуть ли не дешевле, чем SN65LVDS391 (на самом деле LVDS драйверы адски дорогие, особенно в пересчете на пропускную способность), имхо выигрыш от использования eth огромный.
И даже Gbit phy сейчас есть недорогие. В долгосрочном виде решение с ethernet выгоднее тысячекратно.

И, кстати, бубен все равно будет нужен - канонический uart на 30 Мбит = 30 * 16 = 480 МГц, а это значит интересные упражнения.
Возможно eth на стандартном маке тупо проще

Ведь вы же не собирались SPI использовать ?)

Спасибо. Я про eth phy тоже размышлял, но к нему проц нужен. А у меня на "приемном конце" пока только аудио ЦАП предполагается со своими mckl/bck/lrck/data.

[a123-flex]

Спасибо. Я про eth phy тоже размышлял, но к нему проц нужен. А у меня на "приемном конце" пока только аудио ЦАП предполагается со своими mckl/bck/lrck/data.

А что у вас мозги собсно ? Я полагал, ПЛИС ?

[SergeyPro]

А что у вас мозги собсно ? Я полагал, ПЛИС ?

Верно, ПЛИС. Только на стороне передатчика. А приемник -LVDS+ЦАП. На стороне приемника будет стоять или маленький MAX V или PIC16 для конфигурирования ЦАП по SPI.

[a123-flex]

Верно, ПЛИС. Только на стороне передатчика. А приемник -LVDS+ЦАП. На стороне приемника будет стоять или маленький MAX V или PIC16 для конфигурирования ЦАП по SPI.

а разнодлинность пар вас не смущает ?

Имхо решение сильно оптимистичное. Вы какбы считаете, что канал ничего не будет вам стоить. А это не так.

Я бы в такой ситуации делал Arm - Eth - Arm - получилось бы по деньгам дешевле, результат проще, надежнее, разработка быстрее, и без странных велосипедов.
30 Мбит Arm должен прососать, при аккуратном программировании.

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

[bogaev_roman]

И, кстати, бубен все равно будет нужен - канонический uart на 30 Мбит = 30 * 16 = 480 МГц, а это значит интересные упражнения.

Зачем передискретизация на 16, на 4 не хватит на такой низкой скорости? Там запас получается минимум в четверть чипа (8,33нс) на переходные процесссы и разбег частоты.
to SergeyPro - Вам время распространения пакета критично?

[_pv]

Спасибо. Я про eth phy тоже размышлял, но к нему проц нужен. А у меня на "приемном конце" пока только аудио ЦАП предполагается со своими mckl/bck/lrck/data.

да собственно и без процессора, если на phy с одной стороны tx_en зажать навсегда, и подать ваши сигналы на шину TXD, то с другой стороны они вполне "прозрачно" из RXD вылезут.
KSZ9031 не дороже стоит чем SN65LVDS391.
плюс его потом можно и в человеческий езернет переделать при желании.

[bogaev_roman]

да собственно и без процессора, если на phy с одной стороны tx_en зажать навсегда, и подать ваши сигналы на шину TXD, то с другой стороны они вполне "прозрачно" из RXD вылезут.
KSZ9031 не дороже стоит чем SN65LVDS391.
плюс его потом можно и в человеческий езернет переделать при желании.

Т.е. не потребуется дополнительной реализации MDC/MDIO интерфейса и установки качественного внешнего генератора (просто интересно - сам использовал марвеловский phy в режиме RGMII на гигабит и много времени потратил на режим инициализации, плюс генератор внешний пришлось менять)?

[_pv]

Т.е. не потребуется дополнительной реализации MDC/MDIO интерфейса и установки качественного внешнего генератора (просто интересно - сам использовал марвеловский phy в режиме RGMII на гигабит и много времени потратил на режим инициализации, плюс генератор внешний пришлось менять)?

а он не должен по умолчанию сам в autonegotiation максимальную скорость выбирать?
ну и какая-то минимальная конфигурация bootstrap ногами тоже выбирается.

[bogaev_roman]

а он не должен по умолчанию сам в autonegotiation максимальную скорость выбирать?
ну и какая-то минимальная конфигурация bootstrap ногами тоже выбирается.

Должен, но для правильной работы, помимо зажать tx_en в 1 и гнать данные, придется еще документацию почитать, посмотреть куда чего подключить, выбрать правильно источник внешнего тактового генератора и прописать временные ограничения на входы-выходы, потом пакет еще собирать. А для uart на lvds - пропустил через цепочку триггеров на повышенной частоте и все.

[_pv]

потом пакет еще собирать. А для uart на lvds - пропустил через цепочку триггеров на повышенной частоте и все.

не, не надо ничего собирать, просто подать этот последовательный i2s интерфейс с его клоками и чипселектами прямо на TXD.
не трогая клоки и тактирование PHY вообще.
phy эти 4 бита (RGMII) захватит по своему TXC, передаст и на другой стороне выплюнет в RXD,
ну и пусть он внутри, подряд передаёт по много раз одно и то же состояние всех четырёх битов TXD на частоте 250МГц, которые на самом деле меняются только с частотой 30МГц.
30 мбит-то по каждой линии ведь пролезут, хоть и с джиттером в 4нс.

[@Ark]

Всем доброго дня.
Есть потребность соединить два устройства по LVDS, передача однонаправленная. Думаю использовать обычную витую CAT5e витую пару с бестрансформаторными разъемами. Требуемое расстояние передачи до 10-20м, битрейт относительно низкий - до 30 МБит/с по каждой паре...

Ethernet не предлагать!

Можно предложить RS-422.
Чем не вариант?

[a123-flex]

Зачем передискретизация на 16, на 4 не хватит на такой низкой скорости? Там запас получается минимум в четверть чипа (8,33нс) на переходные процесссы и разбег частоты.

передискретизация на 4 - это уже не канонический uart, и бубен для него тоже нужен)

[SergeyPro]

а разнодлинность пар вас не смущает ?

Имхо решение сильно оптимистичное. Вы какбы считаете, что канал ничего не будет вам стоить. А это не так.

Я бы в такой ситуации делал Arm - Eth - Arm - получилось бы по деньгам дешевле, результат проще, надежнее, разработка быстрее, и без странных велосипедов.
30 Мбит Arm должен прососать, при аккуратном программировании.

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

Да, пожалуй вы правы. Сейчас изучаю ATSAME70Q21. Он 300 МГц, DMA многоканальное, два I2S. Думаю, что для моих целей должно хватить.

[a123-flex]

Да, пожалуй вы правы. Сейчас изучаю ATSAME70Q21. Он 300 МГц, DMA многоканальное, два I2S. Думаю, что для моих целей должно хватить.

Я бы смотрел STM или Philips бывший. Мне нра STM, у него ИМХО более качественная периферия и лучшая поддержка.
Это мейнстрим, у них есть камни под 200 Мгц - этого точно должно вам хватить.
Atmel аутсайдер.

Проще всего убедиться в успехе, купив пару макеток с Eth, и написав тестовый обмен.
Я бы купил чтото такое:
https://www.terraelectronica.ru/product/1204298

считаю 7 тыр за твердую уверенность в результате вашей разработки совсем недорого.

Дешево и вкусно, + будет возможность отлаживать софтину, пока спокойно выпиливаете железо, по образу и подобию.

Про philips не знаю, у STM есть чудесные STM32 Сube MX, Atollic, STM Studio, System Workbench for STM32 - полное конфигурирование кристалла и интеграция lwip tcp/ip стека в проект несколькими кнопочками, все бесплатно.

Божественная поддержка, прекрасный интерфейс, все красиво и понятно, чего бы не говорили злопыхатели. С ними вы протестируете все быстро и легко.

[Alex11]

Про philips не знаю, у STM есть божественный STM32 Сube MX, Atollic, STM Studio, System Workbench for STM32 - полное конфигурирование кристалла и интеграция lwip tcp/ip стека в проект несколькими кнопочками, все бесплатно.

Бесплатный сыр бывает только в мышеловке. При том, что железу у них изумительное, и я его очень люблю, то, что они наворотили в софте - ужос.

И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои.

[a123-flex]

При том, что железу у них изумительное, и я его очень люблю, то, что они наворотили в софте - ужос.

мы делаем довольно много проектов, на текущий момент идут одновременно 4, все контроллеры разные, и у нас штук пять разных отладок, со всеми работали (0xx,1xx,2xx,4xx серий).

Еще не разу критических проблем с софтом не было. Глюки в cube я видел и сам, и довольно много, но они не смертельны - ну упала система при фильтрации тысячи параметров - ткнуть 2 галки в матрице выбора заново недолго. Я никогда в жизни не видел настолько удобного и с огромным функционалом софта по параметрическому подбору контроллера и поиску совместимых аналогов, а впервые собирал систему на арме лет 12 назад)

Без этой софтины в море продуктов STM можно было бы провести месяцы в поиске оптимального контроллера, а с ней даже 2 поиска займут не больше получаса.

Их периферия, в которой фактически реализована плисовая матрица для вывода чего угодно куда угодно, и средства конфигурации - ИМХО венец творения.
Я не могу представить себе ничего более удобного.
В софте для конфигурации IO я не видел глюков, правда я им пользуюсь мало, в основном мои инженеры. Я никогда не слышал от них жалоб по поводу этого ПО.

Бесплатный сыр бывает только в мышеловке.

Я бы не сказал, что этот сыр такой уж бесплатный.
Есть мнение, что рядом с Alwinner-ом и другими большими армами по цене маленьких от STM цена на продукты STM сильно завышена.
STM пытается остаться в рынке, и делает это качеством сервиса - стандартная стратегия Запада.

Добавлю - которая последние 30 лет стандартно проигрывает Востоку, с его демпингом(

[_pv]

И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои.

развалится синхронизация чего с чем?
у езернета на физическом уровне "побитовая" синхронизация, в не зависимости от передаваемых данных, за счёт избыточности 4b5b и 8b10b у гигабита.

[Alex11]

развалится синхронизация чего с чем?

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

[a123-flex]

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

разве нельзя принятые данные тактировать наружу восстановленным клоком ?

[_pv]

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

ну у mii, rgmii клоки на приём передачу отдельные, имхо было бы глупо вместо того чтобы на rxc просто вытащить восстановленный клок, городить ещё фифо.

хотя вот у rmii клок общий, и иногда только на вход, там проблема синхронизации должна быть.

[Kluwert]

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

Нету никаких ограничений: забивали на пакетную передачу и гнали через гигабитные физики непрерывный поток - всё работает отлично.

ну у mii, rgmii клоки на приём передачу отдельные, имхо было бы глупо вместо того чтобы на rxc просто вытащить восстановленный клок, городить ещё фифо.

хотя вот у rmii клок общий, и иногда только на вход, там проблема синхронизации должна быть.

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-
erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

[a123-flex]

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

на самом деле 88e1111 имеет если не ошибаюсь 4 режима тактирования выходных данных: как с derived clock, так и с независимым и elastic буфером. Соответственно в разных режимах работает по разному.

Последнее время на 88e1111 ценник такой, что она стала непопулярна. Мы ее больше не ставим

[Kluwert]

на самом деле 88e1111 имеет если не ошибаюсь 4 режима тактирования выходных данных: как с derived clock, так и с независимым и elastic буфером. Соответственно в разных режимах работает по разному.

Последнее время на 88e1111 ценник такой, что она стала непопулярна. Мы ее больше не ставим

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то

[a123-flex]

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то

м. Нам нужна индустриальная версия, и если первоначальная цена была 30$, то после переворота в Украине и с началом войны когда последний раз я смотрел в efind она была доступна по 200$, и вообще industrial было очень мало. Я испугался, что мы не сможем укомплектоваться и мы сменили ее.

На замену мы взяли именно KSZ9031, но еще ее не пробовали, что с ней не так ?

[dxp]

за счёт избыточности 4b5b и 8b10b у гигабита.

В каком месте у гигабитного изернета кодирование 8b10b? GMII, RGMII или по физической линии? Если только SGMII.

По клокам у гигабитного изернета. Насколько помню, оба чипа физического уровня работают на одной тактовой - они договариваются, кто мастер, и второй чип извлекает тактовую из входного потока. Это очень важное условие - чёткий захват клока входного потока необходим для качественного извлечения данных из суперпозиции сигналов - там ведь сигналы обоих направлений одновременно присутствуют в линии. RxClk соответственно всегда равен тактовой в линии. Elastic buffer тут не нужен, да и протокол не предусматривает посылку IDLE/SKIP символов в линию.

[_Anatoliy]

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то

KSZ - отстой,тоже забыл как страшный сон.
55 рублей за штуку - вот это цена.
AR8035

[_pv]

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

я про 100мбитный RMII, у которого один единственный клок в обе стороны и тот иногда бывает входом, а не выходом.
тогда скорость выдачи данных по rxd задаётся МАСом, а не из восстановленных клоков из приёмника. соответственно данные в приёмник приходят с другой скоростью.

В каком месте у гигабитного изернета кодирование 8b10b? GMII, RGMII или по физической линии?

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

[dxp]

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

Но там ведь нет 8b10b? Там вроде 4D-PAM5. 8b10b в контексте гигабитного изернета только в SGMII. Вроде так.

[_pv]

Но там ведь нет 8b10b? Там вроде 4D-PAM5. 8b10b в контексте гигабитного изернета только в SGMII. Вроде так.

да, действительно нет там 8b10b (он вроде в 1000base-FX), но в 4D-PAM5 тоже избыточность log2(5^4) * 125MHz = больше гигабита. которая разбавляет данные и позволяет синхронизироваться за любую последовательность данных.
ну то есть приёмный клок в любом случае восстанавливается из данных и ограничения на длину пакета из-за несовпадения клоков приёмника/передатчика с разных сторон быть не должно.

[MegaVolt]

Рекомендации от TI по работе LVDS на длинных кабелях.
http://www.ti.com/lit/an/slla053b/slla053b.pdf