Обмен данными с компьютером, Принимаю советы и замечания по модернизации старого проекта Опции

[Boris_TS]

Тему создал в этой ветке конференции, ибо надо заменить старое ПЛИС решение на новое или на что-то вообще другое.

Как лучше модифицировать имеющееся решение:

Имеется система сбора данных - ящик 19 дюймовый 4U. Внутри ящика самопальный cross на 10 плат расширения и 1 плата управления. От платы управления шел самопальный канал связи (6 диф. пар по 50МГц) к PCI плате (32бита 5V), втыкаемой в обычный компьютер.

Назрела необходимость изменить ввод данных в компьютер (отказаться от самопальной PCI платы, да и аналогичного канала передачи данных).

Cross и пачки различных плат расширения переделывать ой как неохота, а поэтому имеем такое схемно-убогое решение: от каждой платы расширения (ввода и обработки данных) к
блоку управления тянется по 6 LVPECL пар (если быть более точным, то Xilinx LVPECL аля Virtex-E/Spartan-2E) - по 4 к плате расширения и по 2 к блоку управления, итого 60 пар.

Груды LVPECL пар, заходящих на блок управления, подаются на 2 XCV50E-7PQ240, каждый Virtex-E занимался работой со своей половиной шины. Первый мультиплексировал поточные данные от плат расширения и заливал эти данные в PC (по однонаправленной шине). Второй обрабатывал запросы от PC (записать конфигурационную информацию/считать оную из плат расширения). При таком построении системы получалось 2 независимых шины, простое решение в ПЛИС (почти что одни мультиплексоры и коммутаторы). Особенностью аппарата является то, сбор данных необходимо производить с привязкой к пространственной координате, т.е. весьма шустро реагировать на изменения скорости подвижного объекта, в котором собран измерительный комплекс - в том числе и из-за этой особенности стандартные платы ввода данных в PC не использовались (может быть зря ?).

Конструктивно блок управления может быть полноразмерной ISA (PCI) платой – с местом проблем нет – задняя планка ISA (KHPC) Bracket.

Поток (по, как я это безобразие назвал, «Control Bus») данных управления в обе стороны не превышает 1 Мбит/с.
Поток данных (по, как я это безобразие назвал, «Data Bus») от плат расширения к PC пока не превышает 16 Мбит/с, но хочется развивать (потихонечку) одну из модификаций плат расширения... и раздуть поток до 105 Мбит/с, а затем и до 210 Мбит/с (из-за возрастающих пожеланий заказчика).

Думаю надо бы переделать передачу данных на Ethernet (а лучше бы с полной поддержкой TCP/IP). А вот тут и возникают вопросы как бы это получше сделать... Т.к. изделия не серийные, то можно использовать компоненты (в т.ч. ПЛИС) ценой в несколько тысяч рублей.
1. Может собрать почти как и было: поставить 2 Startan-3AN TQ144 (теоретически запаять BGA корпуса можно у соседей, но разводкой печатной платы под BGA пока не занимался, а чувствую, что это не делается с наскоку)... и приторочить к каждому Spartan’у по некоей фиговине (у которой с одной стороны какая-то шина, а с другой Ethernet (а лучше сразу TCP/IP) - знать бы еще как оные зовутся ?) ?
2. А может быть поставить одну ПЛИС и собрать там могучий мультиплексор, разгребающий данные к/от Ethernet ?
3. Может есть другие варианты - получше гигабитного Ethernet ???

P.S. работаю только с ПЛИС Xilinx. С EDK пока еще не работал...

[SM]

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

[Boris_TS]

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

Точно.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п. Но архитектура уже более или менее определилась: две груды LVPECL линий заходят на Spartan-3AN (благо, хоть это и не документированно для этой ПЛИС, но при желании, можно собрать LVPECL выходы аналогичные "Virtex-E LVPECL"), благополучно преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).
Также не может не радовать и то, что выступившим удалось передать более 100МБайт/с по Gigabit Ethernet, мне же всего-то требуется только 15МБайт/с (или, если очень захочется заказчику увеличить количество датчиков - ну никак не более 30МБайт/с - только для меня остается загадной: нафига ставить еще больше датчиков - их и так в полноценной системе их дофига, а обычно заказывают с 50%-60% каналов сбора данных).

[Builder]

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).

Один из плюсов UDP - стандартные возможности програмирования, например в винде стандартно можно работать только с TCP и UDP, если ниже, придётся использовать WinPCap: http://netgroup-serv.polito.it/winpcap/
Если WinPCap допустим, можно и без UDP попробовать.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п.

И к чему склоняетесь?

преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

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