задали в институте задачку: сохранить (и считать) поток данных на жестком диске.
поток 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 для частных случаев не нравится) ?

а почему бы сразу не сделать SATA в ПЛИС, пусть сохраняет мимо всех процов и шин сразу на диск (без файлов и файловых систем, прямо поток прямо на диск). Такой опыт есть, вполне положительный.

знаем-знаем) Но мне же надо к устройству записи обращаться каким-то каналом. В смысле у меня устройство записи отделено от генератора потока и читателя

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

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

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

это почему - делаете не только масс сторейдж, а еще второй интерфейс (в смысле 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), так и в ПЛИС.

что за институт? можно в личку, если с этим строго.

дело в том что задача до боли знакомая, и, возможно, принимал участие на предыдущих этапах.

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

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

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

tcp/ip ето отлично. но я уже писал его и написал. получилось хреново. больше не хочу его писать

а почему нельзя взять готовую разработку ЕМНИП dmsv для соединения устроств через PCIE точка точка с гарантированной доставкой ? сорцы открытые, только физику поменять вот линк на тему не помню, искать надо


нашел http://ds-dev.ru/projects/proteq/wiki только там не по PCIE, а по гигабитным линкам

Ну опыт показывает, что быстрее самому все сделать, чем чужую корку разобрать, раскопать и довести до ума, чтобы с ней было удобно и эффективно работать в окружении конкретного устройства.... Чужие корки, разве что, годятся для подглядывания, в помощь чтению документации - "а как они это сделали" (только за последний год я пытался использовать корку USB2 (коммерческую!!!) и обычный тупой и простой уарт 16550, в результате после долгого тестирования и там и там нашлись глюки, пришлось плюнуть, и сделать свое, сейчас вот PCIe на очереди, даже не буду пытаться готовую корку брать)

Можно подброшу свой вопрос, тут про SATA говорилось мельком, а есть в природе бесплатные работоспособные корки или открытые проекты?. На opencores видел пару дизайнов, точнее всего два, рабочие они или нет, вопрос. А то тут так запросто предлагается "подключить SATA", но насколько я понимаю, написать корку SATA это от года плотной работы. Или я чего то не понимаю...
Собственно вопросов два. Первый "есть ли корки рабочие SATA"? и второй "действительно их разработка сложна и долгосрочна или это преувеличено и можно запросто накатать за пару месяцев?"