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

[RHnd]

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

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

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

[DmitryR]

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

[RHnd]

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

Хороший вопрос. Будем считать, что пока нет. однако, канал на плате - не безпомеховый. Точнее, это провод некоторой длины между двумя платами.Соответственно, помехозащищенность и полудуплекс нужны. Можно изобретать свое, но хотелось бы не тратить время и по максимуму использовать готовые решения. Или, хотя бы, известные подходы.
По радио - к тому моменту, когда точно решат его ставить, можно будет постепенно понижать скорость передачи покуда не заработает. Да и потом, я на данный момент понятия не имею, что там за радио аппаратура будет. Если будет.

[RHnd]

Неужели никто не решал похожих задач передачи информации? Поделитесь опытом, какие решения использовали?

[maxfox2k]

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

ethernet

[slog]

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

[alexander55]

Делал связь между 2-мя FPGA на 12 мегабит в полудуплексе. Физически через RS-485 метров на 10.

Это надежное решение. С помехозащищенностью все хорошо.

[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 ячеек циклона, никакими дсп там и не пахнет.
Кстати, на сколько реальна задача по объему?

[DmitryR]

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

Если у вас осталось ВСЕГО 3000 ячеек, то есть использовать все вы не сможете, так как довольно трудно забить ПЛИС на 100%, то у вас могут возникнуть проблемы даже с проводной реализацией, а о радио и речи быть не может.

[RHnd]

Да не, не все так страшно. Там камень на 6k, из них около 1.5 тысяч займет другая часть проекта, а в оставшееся и надо засунуть приемо-передатчик. Вот я и прикинул - при наполнении камня процентов на 80 можно рассчитывать на 3k элементов. Плюс, свободно несколько килобайт памяти и pll.

[Михаил_K]

Хороший вопрос. Будем считать, что пока нет. однако, канал на плате - не безпомеховый. Точнее, это провод некоторой длины между двумя платами.Соответственно, помехозащищенность и полудуплекс нужны. Можно изобретать свое, но хотелось бы не тратить время и по максимуму использовать готовые решения. Или, хотя бы, известные подходы.

Какой длинны будет провод? Как сделано питание двух плат? От разных источников или от одного? Какой тип провода вы собираетесь использовать?

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

[slog]

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

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

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

Мне - всем бы угодил, отличный вариант, но у меня опыта с эзернетом нет, а разбираться некогда. Поэтому делал как быстрее и чтоб работало.
С реверс инжинирингом у меня хорошо, но нет времени заниматься всем сразу. От обрезанной версии не отказался бы. Пока посмотреть, а на потом - есть куда пристроить такое решение.

[des00]

От обрезанной версии не отказался бы. Пока посмотреть, а на потом - есть куда пристроить такое решение.

постараюсь на неделе выдернуть последний рабочий вариант из свна и выслать вам. Кстати куда вам выслать ?