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

по первому вопросу, открытых рабочих корок лично я не знаю. По второму вопросу - разработка корки, полностью выполняющей все, что есть в стандарте, с полным тестированием, да, сложна и долгосрочна. А вот разработка корки с минимально необходимой функциональностью для задачи - ну не перенапрягаясь можно за месяц сварганить, если твой уровень таков, что не вызывает никакого страха написание корок PCI (с бусмастером), DDR2/DDR3, PCIe

Если Ваш уровень таков, что не напрягает, то как я потом смогу етим воспользоваться (меня PCIe, честно, напрягает), и как исправить ошибку после неполного тестирования ? Насколько я знаю исходники на opencores именно такие - почти работают)
Есть такой Дмитрий Смехов (Инсис)- большой специалист по поводу етого самого pcie - в интернете где-то его исходники валялись - ну ето просто тихий ужас.... мегабайты.
И потом, ну правда, смешное сравнение - USB 2.0, PCIe, DDR2/DDR3 и USART...

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

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


По поводу всего этого, есть абсолютно верная поговорка - "глаза боятся, руки делают"

когда я писал свое tcp, встроил ЛА с полным дампированием всех переменных проекта, я написал анализаторы (для модели и внешнего ЛА), по битовому потоку восстанавливающие требуемое состояние всех переменных потока, и тем не менее иногда происходили ситуации, на разбор которых уходило по нескольку дней - я видел что есть ошибка, но найти модуль в котором она случилась, не мог. Одновременно нужно было контролировать 400 переменных, но моделирование ето еще были цветочки. Потом началась отладка в железе - вот ето стало совсем весело - при отладке тут же отпала возможность восстановления произвольной секции потока - у ЛА не хватало памяти, а латентность алгоритма управления оказалось очень большой - огромной проблемой стал просто поиск точки сбоя. Гребаная обратная связь творила ну просто чудеса - сбои были как в приемнике, так и в передатчике, как основном русле алгоритма, так и в алгоритмах обратной связи, а самые интересные глюки находились в тракте управления.... Далее текущие задачи потребовали своего решения, в результате ядро было предельно упрощено. Но тем не менее все же занимало 1500 ЛЭ Virtex2. К сожалению, при разработке я не пользовался coverage и всякими uml. C другой стороны, в дальнейшем coverage какого-то из модулей проекта был сделан и показал такое количество ошибок (а реально опасными из них были в действительности 1%, и они очень быстро вылезли при отладке в железе), что на ето просто забили.
Поетому, если Вы с такой легкостью говорите о PCIe - то Вы либо реальный гений, либо ето такой, легкий, пиар
Но тогда не понимаю, как ето можно было потратить долгое время на UART)

Ну как-то так оно и есть... неделю пишешь, потом месяц отлаживаешь. IMHO TCP сложнее на порядок, чем необходимая функциональность PCIe для большинства проектов. Да и PCIe имеет четкую иерархию не слишком сложных слоев, что упрощает отладку.

И, разумеется, правильные осциллографы, анализаторы, и т.п. оборудование...

мне очень стыдно, но я потратил год...

ну... как бы "на порядок" - это в 10 раз... как раз - месяц-два -> 10-20 месяцев.



Да работал он себе полгода, и никто не знал, что в нем есть глюк и все на него забили. Переписать его заново - реально два дня с отладкой.

ХА, етот proteq - продукт Смехова! VHDL
форматы служебных и рабочих пакетов у меня в ядре полностью идентичны тем что получил он)
только у него кодирование 64b67 и фиксированный пакет 256 байт * 4 - не очень удобно для работы.
мы подобрали код 8b9 и пакеты произвольной длины
управление потоком не реализовано, из-за етого будет нельзя/неудобно делать маршрутизацию. При правильном управлении потоком мультикаст легко реализуется как надстройка.
У меня в ядре транзакции разных линий абсолютно независимы. Более того, мое ядро может работать, при произвольном сочетании приемников/передатчиков. У Смехова - пакет принят, если по всем линиям корректный прием.
процессорная реализация невозможна, как и у меня.
Впрочем ето больше, чем ничего, спасибо Дмитрию Смехову, и des00
о ужас. моя концепция местами сложнее pcie

ето Вы верно заметили. В свое время глянул исходники декриптованного контроллера pcie, ужаснулся, и не стал с ним разбираться, начал писать с 0. Глядишь, не испугался бы, щаз мое ядро было бы покрасивее(