Добрый день!

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

Идеи возникали разные:

1. Поставить на каждой плате ARM и использовать I2C - не прошла идея из-за низкой скорости.

2. Поставить на каждой плате ARM и на одной организовать HOST - детально еще не думал.

3. Поставить на каждой плате ARM и использовать TCP/IP - тестировал скорость соединения на основе чипа LPC 2378, получил скорость от 1-10Mbps в зависимости от размера пакета. Думаем как ускорится, пока единственный вариант.

Может кто чего еще посоветует. Главное это низкая латентность и желательно скорость повыше.

К рассмотрению принимаются всевозможные идеи

Выкинуть нахрен и TCP и IP. Для нескольких плат прекрасно будет работать физический уровень Ethernet - MAC адресация есть, контрольные суммы есть, аппаратная фиксация ошибок в канале передачи есть. Легкую надстройку по вкусу над фреймом IEEE 802.3 и все.

Можно даже вместо трансформаторов поставить конденсаторы.
Просто контроллер Ethernet с PHY на борту. А может для этого брать процессор с ядром МАС.
И в продолжение темы, в КиТе была статья о том, как ДСП-процессоры общались между собой через свич.

Давайте все же на инженерном форуме пытаться формулировать свои вопросы понятно.
Ну что значит скорость повыше? Приведите хотя бы в байт/с, что ли.
Я бы предложил CAN на 1.6 МБит, но непонятно много это ли мало.

Извиняюсь за недоговаривание, исправляюсь.
Скорость требуется не меньше 32Mbps и при этом необходима низкая латентность.
1.6Мbps однозначно недостаточно.

А как можно прикинуть необходимую скорость процессора, что б он успевал обеспечивать скорость порядка 50Mbps ?

Никак.
Поскольку не понятно, чем он еще заниматься должен и насколько продвинут MAC контроллер, дуплекс или нет, точка точка или нет ...... Но в любом случае 50Mbit это очень даже не мало - просто так за счет "волшебного слова" Ethernet не решится.

Ок. А может можно еще можно что то придумать помимо Ethernet? Может кто нибуть использует что нибуть другое? Или такой скоростью некто дел не имел.
Просто я сам первый раз столкнулся с таким заданием. Вот теперь сижу думаю

Последовательные порты в DSP-процессорах или SerDes в FPGA.

В случае применения FPGA можно попробовать LVDS - до XXX Гбит
Можно разделить на отдельные потоки (физически) - этакое подобие наращивания как у PCI-X.
Память FPGA использовать под FIFO.
И выход на АРМ 32 разрядной шиной.
Может получиться очень быстро.

А данные случайно не легко упаковываемые?

Вчера начали тестировать скорость TCP/IP в связке DSP + WizNet chip ( W3150A ) Буду надеятся что скорость будет достаточная, но вот вопрос латентности.... Ведь в DSP и сам чип вносят некого рода задержку, хотелось бы что нибуть в одном корпусе, да еще и достаточно резвое.
2lolikandr Уточните вопрос с данными.

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

Т.е. если Вам надо передавать, например, какие-то команды, состояния и т.д. (неделимые куски информации объёмом X..Y байт) то имеет смысл пакетная передача.
Если у Вас идёт поток однородных данных, например с АЦП, и его надо как можно быстрей передать, то тут уже следует подумать о всяких битовых потоках (SPORT-ы в DSP-ях, LVDS и т.д.), тут латентность может быть в пару отсчётов, в то время как при пакетной передаче с N отсчётов в пакете латентность будет около 2*N отсчётов.

В связке DSP + WizNet удалось достигнуть скорости 24Mbit (близко к пределу, 16Mbit - легко) с использованием UDP.

Передавать надо пакеты, примерно 32 байта. Может больше.
А про числовое значение латентности много сказать немогу что команда должна выполнится за 5 мксек. Так что из такого расчета надо подобрать транспорт.

2Dopler
А какую DSP и какой WizNet использовали? А в этой связке нельзя поднять скорость хотябы до 32Mbps?

В этой связке WizNet с его даже теоретическими 25Mbit причем далеко не на 32байтовых пакетах лишний. СОВСЕМ лишний. DSP соединяются, как предписано Создателем встроенными синхронными интерфейсами. 32Mbit - легко.

Да, zltigo прав. В нашем случае данные передавались в компьютер пакетами 1024 байта (плюс несколько служебных байт). Использовалось ADSP2185 и WIZNET W310A, больше 25 поднять производительность нельзя. Простой тест - без заполнения буферов просто давать команду отправить пакет (например, те же 1024 байта), а на компьютере оценить пропускную способность (количество принятых пакетов за, например, 10 сек.). Это решение годится для внешней связи устройства, для внутренней SPORT ADSP на мой взгляд намного предпочтительней.

Как вариант - а нельзя команду передать чуть заранее, а строб времени дать по отдельной ноге? Ну это конечно если нужна именно синхронизация, а не время реагирования.

А так вообще-то жесткие требования - 32 байта и 5 мкс это чуть больше 50 мбит даже если просто это время затратить на передачу пакета... И может 32 байта можно уменьшить? Кроме прочего, эзернет тут вам добавит кучку лишних байт. Посмотрите правда в сторону последовательных синхронных каналов.

У меня стек TCP дает 67 Мбит/c без напряга.

Но на UDP с размером пакета 8192 байта и без собственно использования принятого пакета.
А на 64 байта тот же стек всего 5 Мбит/c , так что на Ethernet вам своей задачи не достичь.

Включите 2-а SPI параллельно, и на любом ARM-е с DMA получите заветные 50 Мбит/c