Требуется передавать данные от одного устройства на несколько других. В оба направления. Передатчик и приемник - ПЛИС. Для последовательной передачи достаточно скорости 50-100 Мб/с. Устройства связаны кабелем или шлейфом и расстояние между ними до 0,5 м.
В качестве физического протокола я выбрал LVDS. У меня возникли такие вопросы:
1. Можно ли передавать данные по обычному SPI. Т.е. использовать 3 линии SCK, MOSI, MISO(через LVDS)? Или это слишком высокая скорость?
2. Можно ли использовать синхронный или асинхронный UART на 50-100 Мб/с?
3. Какие еще варианты посоветуете?

Я работал с SPI только на скоростях до 25 Мб/с и только через КМОП. Разумеется, есть быстрые последовательные протоколы(RapidIO, PCI-E, Aurora и др). Но в спецификациях на них указано что они разработаны для скоростей в 10 раз выше нужной мне, и для их использования нужна будет более дорогая ПЛИС на стороне приемника. И отлаживать их дольше.

Еще хочу задать вопрос по протоколам. Мне известны протоколы для низких скоростей: RS-4.., CAN, SPI, I2C и др. И известны высокоскоростные: PCI-E, Ethernet. Существуют ли решения для скоростей именно 25-~ 200 Мб/с?
МБ/с - это мегабит в секунду.

100 МБ/с - это 100 мегабит в секунду или мегабайт?
Даже если это всего лишь 100 мбит/с то это точно не уарт . Может быть SPI . Для работы Aurora на стороне приёмника нужна такая же плис как и на стороне передатчика, правда там не lvds .
А ещё есть SerDes .

да можно.


uart до 50 не разогнать. без извращений


по простому - double или quad spi.


Ethernet 100 - как раз оно. Возможно идеальный путь, если места на плате не жалко под phy и пинов на плисе. Или SpaceWire. Или перепиливать UART. Или в личку.

Манчестер можно попробовать

Можно понизить частоту SPI, используя больше линий данных. Есть же Quad SPI, но линий данных можно и больше сделать.

SPI стандартный работать не будет на 100 МГц. На 50 может быть. Проблема в обратной по отношению к клоку передаче данных. Можно сделать модифицированный SPI с двумя линиями клоков - в одну и другую строну, тогда проблем не будет. Синхронный UART тоже можно использовать (это, правда, уже не UART, но в смысле клок и данные со старт-стопом). Только с той же оговоркой - в каждую строну свой клок.

SPI-flash вполне себе работают на 100+ МГц. Да, для больших частот предлагается калибровать фазу приемного клока. Но на 100 МГц у меня сейчас просто FPGA грузится без всяких ухищрений.

Завялено требование в 0.5 м, а SPI-flash обычно существенно ближе.

делали на 128 МБит/с, отлично работает без каких-либо извращений. Но при условии, что это действительно UART, а не какой-то синхронный мутант. Единственное ограничение -- на приёмной стороне должна быть возможность работать на тактах 2x.

Да, согласен. 0.5 м это уже 7 нс задержки туда-обратно...

если клок только у мастера, тогда да, проблема. если данные в обе стороны со своими клоками, управляющими сигналами и т.д. идут, то +/- одинаковые задержки будут, но в таком случае даже lvds наловит столько помех, что ему хватит (тем более, что проводами качественный lvds не сделать).
а UART -- линия туда, линия обратно. обе "молчаливые". для отсеивания "вдруг чего словится" -- можно добавить контрольную сумму.

..мой опыт говорит - не хочешь проблем , веди синхронные интерфейсы.

не вижу никаких проблем кроме той, что нужен клок в 2 раза выше того, на котором сформирована последовательность бит. если сделать всё грамотно, то как раз наоборот: меньше сигналов -- меньше проблем.

Напомню про Ultra-640_SCSI:

Так говорят, что физический уровень lvds а это согласование и никакой отражухи.
А SPI обычно CMOS3.3 или меньшего напряжения.

вы считаете что spi жёска связан с CMOS ?

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

SPI для флэшки, думаю что да.

в классических реализациях uart-а внутренняя частота - x16
x2 - это как раз и есть извращения.

если извращаться, то и x1 работает.


Вам просто показали, что помехозащищенности lvds достаточно для устойчивой работы на скорости в 3 раза выше, чем у ТС и на дальности в 20 раз больше, чем у ТС. Калибраторы и синхронизаторы там совершенно из другой оперы.

Можно Вас попросить подробнее описать, как Вы это делали?

Что ваяяете если не секрет?
Хотите сделать свой велосипед - аналог эзеркат?

Мы уже работаем над этим.
Поэтому, ребят, можете "расслабиться".
Как сделаем Вам написать за сколько у нас Вы его сможете купить?

То что ТС хочет, называется SpaceWire. Оно уже сделано, и оно бесплатное)
А EtherCat, насколько я понимаю, процессорная фишка, а не ПЛИС-овая.

И потом, вроде Real Time Ethernet уже сделан и опубликован, нет ? White Rabbit разве не оно ?

У этих двух проектов правда есть одно общее свойство - там черт ногу сломит)

Ни разу не видел аббревиатуру "White Rabbit".
А вот SERCOS III, PowerLink и EtherCAT уже более 10 лет назад как придумали.

Поэтому советую топиг стартеру не "изобретать велосипед"

Это скорее всего из Вашего Асутп.

А white rabbit - это проект из ITER, европейского токамака.
https://www.ohwr.org/
Они там миллиарды пилят, и чтоб хоть какая-нибудь польза была, свою гору железа и софта самодельного, частично в opensource выложили.

Интересные кстати очень проекты там есть.


ему это все советуют

И каков был oversampling интересно знать? Обычно он == 16, ну или в худшем случае == 8.
Даже для oversampling == 8 получаем тактовую частоту UART = 1024 МГц.
Так сколько у вас было?

с x1 -- согласен. x2 -- уже вполне адекватными решениями можно добиться цели.


так речь же не идёт о том, что можно сделать. понятное дело, многое. только какой ценой? исходя из контекста я понимаю, что речи о золотых во всех смыслах проводах не идёт. ну как минимум таких, чтобы удовлетворить ключевые требования к высокочастотным lvds линиям. всего-то надо передать 100 Мбит/с.

Народ. А если 32 уровня сигнала использовать можно же тогда 5 бит за такт передавать

xapp224 - это дорого ?

поток 128 МБит/с, тактовая на приёме 2x = 256 МГц, но! некоторые триггеры, которые ловят старт-бит, работают по другому фронту. в результате имеется один (если правильно помню) переход между некоторыми триггерами, где получается t=(1/256MHz) / 2, эквивалент ~ 512 МГц. Грубо говоря, oversampling получается 4. Но с учётом того, что на этом переходе только клоковый домен меняется, нету ни логики или еще чего-то, разводится норм. ну на свежих поколениях, как минимум.

это Вы про PAM5 ?
http://www.ecolan.ru/imp_info/introduction/magest/

да там ничего особо хитрого, клок 2x, работа по обоим фронтам клока. вот и вся хитрость. получаем 4 семпла на бит. нарисовать это на бумаге и всё очевидно станет. можно и проще сделать, как посоветовал



там тоже 4x, для относительно небольших скоростей вполне подходит вариант. но увеличение скорости требует увеличения точности смежных фаз клоков. плюс еще вместо одного домена используется 2. мелочь, но жаба душит. поэтому мой вариант с одним доменом 2x, но с DDR мне больше понравился. Тем более, что 2x уже и в других модулях используется. Ну и если требуется повышенная надёжность -- не забывайте про защиту от метастабильности.

)


В оригинальном xapp rloc.
Поэтому метастабильности там нет - проверено десятками тысяч часов и сотнями девайсов. Доменов действительно 2. Частота там 1x.
Очень полезно такое бывает, когда линию подразогнать нужно.

Это если тактовая - строго меандр.
Но даже если меандр, всё равно - точность определения точки стробирования в 4 раза ниже стандарта UART. Ну и соответственно - помехоустойчивость.
Можно ли это назвать полноценным UART? Вопрос....

Я бы делал по-другому:
Разбил поток на блоки некоей длины, с маркерами начала и конца блока, добавил в блок информацию для контроля целостности.
В передатчике выдвигал биты как в UART, только без стартового и стоповых битов - синхронизируемся в начале блока, макс.длина блока выбирается такой, чтобы точка стробирования не ушла за пределы бита при максимальных отношениях частот приёмника/передатчика.
В приёмнике сделать oversampling любой насколько позволяет макс.тактовая, но не менее 3. Завести N приёмников (где: N - величина oversampling-а) с точками стробирования в каждом такте.
Все приёмники работают независимо принимая параллельно один и тот же блок. В конце блока проверяем его валидность (по контрольной информации). Если блок валиден - передаём его на выход.
Ну и сделать между приёмниками необходимую синхронизацию для удаления лишних копий блоков.
Делал когда-то давно подобное только на DSP - работало стабильно. Да и сейчас ещё работает - устройство уже десяток лет в коммерческой эксплуатации.

домена 2 -- это минус.
частота 1x -- это плюс.
ну и наглядность, простота реализации в xapp мне тоже понравилась.
тут, видимо, исходя из реальных обстоятельств лучше принимать решение. Просто, повторюсь, у меня к тому моменту уже были задействованы dcm и с 2x, и с 3x. Лишнего уже не терял по потреблению и ресурсам. Вот и реализовал именно так не задумываясь.
обеспечение точности разницы фаз, конечно, на совести трассировщика...
Я никого не стремлюсь убедить/переубедить, но лично мне спокойнее, когда работаю на 1 домене.


не будет она строго меандром, конечно, но ~40% внутри кристалла вполне достижимо ведь?
помехоустойчивость... а что мы сможем тут сделать в разумных пределах кроме попыток защиты от метастабильности? не фильтровать же в самом деле на 16x сигнал? да и от помехи зависит. даже если фильтровать -- далеко не всегда спасёт. если нужна надёжность -- только дублирование. всего. засылок, устройств и т.д. и то не факт, что метеорит не упадёт.

В каналах на базе xapp контролировалась целостность потока. Частота была 96 Мгц, кристаллы - spartan3, virtex2. Генераторы с обоих сторон 50 ppm. Разъемы мр, провода и разводка в модулях жуть. Длина 2-6 метров. Температура была -20 +85. За несколько лет на многих устройствах сбоя не было ни разу.


расходненько будет.

у меня тоже контролируется. года за 3-4 тоже сбоя не было ни разу.

Сам oversampling как раз и нужен для повышения помехоустойчивости. Чем он выше, тем точнее определение точки стробирования.
Т.е. - самая минимальная помеха, которая чуть-чуть сдвинет фронт стартового бита, при оверсэмплинге==16 внесёт ошибку равную всего лишь 1/16 baudrate в определение точки стробирования.
А вот при 4x, промахнёмся аж на четверть бита и точка стробирования на стартовом бите уже может находится на расстоянии 0.25 битового периода от края бита (это без учёта отличия скважности от меандра).


Зато макс.битовая скорость может быть всего лишь в 3 раза ниже макс.тактовой частоты.

диалог наверно позабавит разработчиков модемов

(+/-) 1/16 = |1/8|, если быть точнее.

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

Чем именно? У меня указанный алгоритм как раз в модеме и работал.

Битовой плотностью. В моем представлении модем - то что из лапши на километр мегабиты жмёт.

В том модеме на каждый строб у меня не один бит приходился.
Очень узкие у вас представления о модемах. Модемы не только на мегабиты бывают, и работают не только по лапше, но и по радиоканалу например. Либо вообще внутри сложного комплексного канала.

Ну простите

Беспроводным каналом я раз в жизни занимался - мне не понравилось.
Может быть это потому было, что мы систему за 2 месяца под ключ сдали.
Это было ужасно.

Поэтому беспроводные я подсознательно исключил)

Рекомендую почитать тему: Обмен инфой между микроконтроллерами со скоростью 1Гбит/с

посмотрите еще это - использование внешнего серилизатора