Передача данных - что выбрать?, ASI? Опции

[RHnd]

Спешно и неожиданно поставили задачу: есть два циклона, между ними два провода - общий и для передачи информации. Необходимо обеспечить передачу информации от одного к другому. Скорость - около 15 МБит. Средний объем информации для одного сеанса - около 2 Гб (т.е. сеанс длится минут 20). Нужно обеспечить всякие там помехозащищенности, подтверждение приема, перезапрос блока при необходимости и т.п. - т.е. канал будет полудуплексный. "Руководитель" проекта выдает набор слов "ASI, кодирование 8 в 10, манчестер, нужно было еще вчера".
Я глянул описание мегафункции ASI от альтеры - что-то там очень много чего, высокие частоты и т.п. - не уверен, что подходит для данной задачи.
Ах, еще момент. Потенциально, эти два провода между циклонами будут заменены радиоканалом.

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

Заранее спасибо!

[slog]

Делал связь между 2-мя FPGA на 12 мегабит в полудуплексе. Физически через RS-485 метров на 10. Протокол самопальный. На основе RS-232 приёмников-передатчиков. Посылающий данные отправляет пакет стандартной структуры - заголовок, данные, CRC. Принимающий контролирует CRC и отправляет в ответ подтверждение. Никаких процессоров, готовых мегафункций и дополнительных кодировок не использовал, просто RS-232 приёмник-передатчик и автомат состояний.
Работает.

[ASN]

RHnd
Использовал передачу между двумя FPGA одному проводу на основе UART.Скорость - 10 Мбит через оптическую развязку. Можно было и больше, но не потребовалось. Работало надёжно. IMHO, кодировка 8/10 нужна при максимальном использовании полосы пропускания.

[RHnd]

Всем большое спасибо!

Вообщем, решил делать на основе юарт. Планирую 15MHz в лини, в камне 75MHz - мажоритирование 3 из 5.

А пока я развлекаюсь, поясните мне, пожалуйста, а что такое 8-10 и для чего оно толком нужно? Как я понял из описание на альтеровскую мегафункцию, это кодирование просто позволяет в целом выровнять количество нулей и единиц. А зачем?

[Postoroniy_V]

.....
А пока я развлекаюсь, поясните мне, пожалуйста, а что такое 8-10 и для чего оно толком нужно? Как я понял из описание на альтеровскую мегафункцию, это кодирование просто позволяет в целом выровнять количество нулей и единиц. А зачем?

тут коротенько http://en.wikipedia.org/wiki/8B10B

[Syberian]

тут коротенько http://en.wikipedia.org/wiki/8B10B

мегафункция 8-10 есть в Квартусе. Избыточное кодирование с коррекцией ошибок.
Ее надо сериализировать и тупо туды-сюды по каналу гонять.
Проблемы в передаче данных, как тут уже упоминали, вылезут, и делать это непросто.
Если отойти от концепции Ви-Фи, имеем типичную задачу полудуплекса с коллизиями, задержками, арбитражом и проч. "прелестями". В случае радиоканала будем иметь еще и чудовищный джиттер + дефрейминг + помехи.

Предлагаю пакетную реализацию с подтверждениями. Естественно, покадрово. Разруливание коллизий - как в Ethernet, задержками на случайный квант.
Опыта, как сотворить все это чисто на ПЛИС, не имею. Я бы присоветовал использовать ПЛИС как PHY-адаптер со всякими коррекциями, манчестером и проч., а пакетирование проводить на DSP...

[RHnd]

мегафункция 8-10 есть в Квартусе. Избыточное кодирование с коррекцией ошибок.

Она разве с коррекцией?

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

Я весьма слаб в терминологии. Мне казалось, что задача арбитража возникает когда к одному ресурсу одновременно пытаются обратиться несколько потребителей. Где может возникнуть арбитраж при передаче point-to-point?
И что такое дефрейминг?

Предлагаю пакетную реализацию с подтверждениями. Естественно, покадрово. Разруливание коллизий - как в Ethernet, задержками на случайный квант.

Плохо как без терминологии-то. Я собираюсь передавать весь объем данных порезав на куски по 128 (примерно) байт. К каждому куску добавляется CRC, на каждый кусок получается подтверждение. Кроме того, в начале каждого куска есть заголовок, покозывающий, что а) это кусок данных и б) номер этого куска в общем объеме (желательно по условиям задачи иметь возможность передавать только интересующую часть данных). Так же есть посылки без данных, только команды - сообщить статус и т.п.. Естественно, со своим CRC и с подтверждением. Так вот, мне казалось, что такие посылки и есть пакеты. С подтверждениями. Что тогда значит 'покадровость'?

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

Опыта, как сотворить все это чисто на ПЛИС, не имею. Я бы присоветовал использовать ПЛИС как PHY-адаптер со всякими коррекциями, манчестером и проч., а пакетирование проводить на DSP...

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

[Syberian]

......
Плохо как без терминологии-то. Я собираюсь передавать весь объем данных порезав на куски по 128 (примерно) байт. К каждому куску добавляется CRC, на каждый кусок получается подтверждение. Кроме того, в начале каждого куска есть заголовок, покозывающий, что а) это кусок данных и б) номер этого куска в общем объеме (желательно по условиям задачи иметь возможность передавать только интересующую часть данных). Так же есть посылки без данных, только команды - сообщить статус и т.п.. Естественно, со своим CRC и с подтверждением. Так вот, мне казалось, что такие посылки и есть пакеты. С подтверждениями. Что тогда значит 'покадровость'?
....
Как я понимаю, коллизии это когда, скажем, оба поинта пытаются одновременно начать передачу? В моем случае это исключено - в конкретный момент только одно устройство из двух может инициировать сессию.
....
Не, мне это все надо засунуть в оставшиеся 3000 ячеек циклона, никакими дсп там и не пахнет.
Кстати, на сколько реальна задача по объему?

эээммм.. мде.. у меня терминология кажись, тоже хромает
Ваша идея вполне правильная! Единственно, что 128 байт "полезки" в одном пакете - это слишком мало. Особенно для 2Г массивов.... Потому что "оверхед" (всякие синхрогруппы ,CRC, номер пакета - а их будет дофига) будет добавлять еще процентов 50 длины! Что снизит общую скорость передачи.
Рекомендую использовать пакеты переменной длины, с указанием длины в хедере. Пакеты данных пихать 32 килобайта. Служебные - 16 байт. Вместо номера пакета указывать офсет и ренж (offset & range) - т.е. диапазон передаваемых данных, чтобы система на том конце могла перезапросить пакет с произвольного диапазона.

Что касается "коллизии исключены" - они возникнут обязательно на такой скорости, если длина канала будет больше половины "длины волны". В вашем случае это 10 метров. Чисто физического характера, когда система контроля уровня "не успеет" засечь начало чужой передачи и начнет свою.


Если хорошо и с пивом подумать, все-таки, думаю, можно сделать чисто на циклоне если нет многоканальных ФАПЧ и писать "в тексте", а не только рисовать ( как я гыгы) , система займет элементов 2000-2500...

[slog]

эээммм.. мде.. у меня терминология кажись, тоже хромает
Ваша идея вполне правильная! Единственно, что 128 байт "полезки" в одном пакете - это слишком мало. Особенно для 2Г массивов.... Потому что "оверхед" (всякие синхрогруппы ,CRC, номер пакета - а их будет дофига) будет добавлять еще процентов 50 длины! Что снизит общую скорость передачи.
Рекомендую использовать пакеты переменной длины, с указанием длины в хедере. Пакеты данных пихать 32 килобайта. Служебные - 16 байт. Вместо номера пакета указывать офсет и ренж (offset & range) - т.е. диапазон передаваемых данных, чтобы система на том конце могла перезапросить пакет с произвольного диапазона.

Что касается "коллизии исключены" - они возникнут обязательно на такой скорости, если длина канала будет больше половины "длины волны". В вашем случае это 10 метров. Чисто физического характера, когда система контроля уровня "не успеет" засечь начало чужой передачи и начнет свою.
Если хорошо и с пивом подумать, все-таки, думаю, можно сделать чисто на циклоне если нет многоканальных ФАПЧ и писать "в тексте", а не только рисовать ( как я гыгы) , система займет элементов 2000-2500...

Совсем не согласен.

128байт это нормально, оверхеад добавит ~10%. Вообще длина пакета выбирается исходя из кол-ва ошибок в канале.
Коллизии могут быть если есть несколько передатчиков. В данном случае вроде не актуально. тем более приёмное устройство можно сделать мастером, а слэйв передает нужные данные по запросу от мастера.
И займет это все со всей логикой протокола максимум 500 ЛЕ.

[des00]

Совсем не согласен.

128байт это нормально, оверхеад добавит ~10%. Вообще длина пакета выбирается исходя из кол-ва ошибок в канале.
Коллизии могут быть если есть несколько передатчиков. В данном случае вроде не актуально. тем более приёмное устройство можно сделать мастером, а слэйв передает нужные данные по запросу от мастера.
И займет это все со всей логикой протокола максимум 500 ЛЕ.

господа, я может быть что то не понимаю, а чем вам ethernet не угодил?
Ставим PHY, берем MAC от игоря мохора, вырезаем вишбон и все что с ним связано, отключаем всякие таймауты, PauseFrame, динамическое конфигурирование. имеем ~1k ячеек. (кста если с реверс инжинирингом плохо, могу дать обрезанную версию).

Пихать в ethernet кадр можно все что угодно. Ну и простой КА, который набивает эти кадры. Или чуть сложнее PicoBlaze который формирует заголовки и рулит протоклом + КА который набивает кадры.

между платами стандартная витуха.

[RHnd]

Хм. Надо будет таки разобраться и сделать для себя тестовый езернет, а то никогда с ним не работал, нифига о нем не знаю. Смущаю сложности со стороны PC - я в виндовском программировании не очень.

Как я понимаю, PHY - дополнительная микросхема на плате? Если да, то это отпадает - плата не в моей юрисдикции. Фактически, это выглядит примерно так: "Вот на эту ножку циклона данные приходят, а отсюда уходят, одновременно нельзя. А чего мы к этим ножкам приделаем - сами еще не решили: провод, радио, оптика. Вообщем, канальный вопрос остается открытым."