Задача в институте: сохранить поток данных, учеба Опции

[a123-flex]

задали в институте задачку: сохранить (и считать) поток данных на жестком диске.
поток 3-5 гигабит в секунду
писать будем на sata ssd
есть опыт реализации самодельной гарантированной доставки 300 Мбит(LVDS)/ 1 Гбит Ethernet
ясно, что реализация tcp/ip (1/5/10 Гбит) на ПЛИС - занятие малоприятное и маловероятное.
хотелось бы, чтобы передача шла по каналам: 1/10 Гбит Ethernet, а также через GTP/GTX/GTH
главная проблема состоит в том, что самодельные гарантированные доставки хоть и простые, но в нашем случае поддержать их процессором невозможно (требуется мгновенная реакция на сбой), то есть нельзя сделать обмен напрямую - ПЛИС- проц, а нужно тогда интегрировать ПЛИС в систему. Кроме того, код управления phy получается в каждом случае разный.

Есть очевидное решение о передаче MAC пакетов. Не нравится тем что с вероятностью 10-6 будут биться данные.

Может кто знает о стандартных более интересных решениях для таких случаев (SRIO и PCIe для частных случаев не нравится) ?

[SM]

ну присобачьте USB 3.0 - представьте систему с ПЛИС и HDD как некий масс сторейдж, на котором лежит один файл, который физически есть HDD

[a123-flex]

ну присобачьте USB 3.0 - представьте систему с ПЛИС и HDD как некий масс сторейдж, на котором лежит один файл, который физически есть HDD

нет, так неинтересно. Задача доступа к хранилищу решается, но я не могу, например, выбросить хранитель, и воткнуть ПЛИС генератор потока напрямую в комп. Кроме того, вопрос с унифицированным кодом на множестве phy также при таком подходе не решен.

[SM]

но я не могу, например, выбросить хранитель, и воткнуть ПЛИС генератор потока напрямую в комп.

это почему - делаете не только масс сторейдж, а еще второй интерфейс (в смысле interface descriptor USB), который по той же USB3.0 гонит поток напрямую в комп.

ну а унифицированный код на множестве phy выглядит каким-то полубредом... у УСБ 3.0, PCIe, SGMII, XAUI и RapidIO, например, phy имеет единый интерфейс PIPE, он, конечно один, но вот дальнейшие слои все совершенно разные, и объединить их во что-то универсально-единое совершенно не реально (или мегамонстра родите, если вообще родите). Это надо тогда уж не на ПЛИС делать, а на каком-то шустром монстропроце, в котором на борту все интерфейсы сразу есть.

[a123-flex]

это почему - делаете не только масс сторейдж, а еще второй интерфейс (в смысле interface descriptor USB), который по той же USB3.0 гонит поток напрямую в комп.

ну а унифицированный код на множестве phy выглядит каким-то полубредом... у УСБ 3.0, PCIe, SGMII, XAUI и RapidIO, например, phy имеет единый интерфейс PIPE, он, конечно один, но вот дальнейшие слои все совершенно разные, и объединить их во что-то универсально-единое совершенно не реально (или мегамонстра родите, если вообще родите)

блин, я не хочу объединять УСБ 3.0, PCIe, SGMII, XAUI и RapidIO. Я их вообще не хочу- они слишком сложные. Я думаю как предельно просто сделать реализацию гарантированной доставки связи точка-точка (надстройку над phy), с использованием PIPE разной ширины. И чтобы ето можно было реализовать как в PC (x86,Arm), так и в ПЛИС.

[SM]

надстройку над phy

так вот "надстройкой над phy" (в ПЛИС) и станет весь список протоколов более высокого уровня. Ведь во всех PC и ARM нет доступа к PHY, а если готовые USB/PCIe/Ethernet/RapidIO/e.t.c.

[a123-flex]

так вот "надстройкой над phy" и станет весь список протоколов более высокого уровня. Ведь во всех PC и ARM нет доступа к PHY, а если готовые USB/PCIe/Ethernet/RapidIO/e.t.c.

мда. очевидно, тогда ответ - гарантированная доставка с использованием MAC пакетов не TCP/ip. Сетевуха ведь поддерживает raw mode. Интересно, такая есть ?

[SM]

Интересно, такая есть ?

Придумайте сами. Это просто, если это простая точка-точка... Туда шлете пакеты, оттуда подтверждения. Если нет подтверждения на какой то пакет, шлете его заново, пока не получите либо подтверждение, либо что "пакет уже принят ранее" (подтверждение потерялось), вот грубо как-то так.