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

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


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

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

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

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

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

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

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

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

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

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