Вот не удержался - хвастаюсь

Вышла моя статья на habrahabr:
"PROTEQ — протокол обмена по мультигигабитными линиям для ПЛИС Xilinx"
http://habrahabr.ru/sandbox/90013/
Она пока в песочнице.

P.S. Не стреляйте в пианиста, он играет как умеет.

Поздравляю!

может стоит было реализовать схему исправления ошибок - типа БЧХ, LDPC, коды Хемминга и т.д.?
чем постоянно "слать" пакет....

тем более Вы пишите



PS Как Вы получили инвайт на http://habrahabr.ru?

Нет. Здесь выгодней использовать переповтор. Вероятность ошибки очень маленькая. Реально на аппаратуре ошибка происходит где-то раз в час. Запас по скорости есть.
Схема исправления ошибок типа Хемминга требует дополнительных битов данных, что снижает скорость. Конечно это всё является предметом обсуждений.

Кстати, на первых ещё не отлаженных образцах ошибки шли очень часто - каждую секунду, но PROTEQ отлично справлялся с исправлением ошибок.



Пока не получил, эта статья в песочнице. Туда можно написать сразу после регистрации.

Возникла пара вопросов:

1) (По вашему опыту) Нарезка проекта на такое количество блоков в том числе мелких и их последующая плотная компоновка действительно дает сильный выигрыш ?

2) Как быть с сохранением порядка данных на приемной стороне в случае перезапроса пакета на одном из буферов ?

3) Если ошибки возникают и требуется перезапрос, а ацп остановить нельзя все равно рано или поздно на передающей стороне возникнет переполнение, и данные потеряются, тогда зачем их перезапрашивать в данный момент ?

или скорость обмена плис-плис заведомо гораздо больше скорости получения данных с ацп ? тогда 2,3 отпадают.

Спасибо!

Не сильно вдаваясь в описанный способ, тем не менее, вижу, автор рассчитывает на редкие сбои, и поэтому выбрал способ повторять сбойные пакеты. Мне кажется, способ кодирования однозначно должен определяться уровнем ошибок. Думаю, PCI Express не дураки разрабатывали.

Да. Мой опыт показывает что так разводится лучше.



Порядок обязательно сохранятся. Например если произошла такая ситуация - возникла ошибка в буфере 1, а буферы 2 и 3 приняты правильно. То будет ожидание правильного приёма в буфер 1. А после запись в выходное FIFO буферов 1,2 и 3 в правильном порядке. Для этого кстати работа с линией ведётся на частоте 156.25 МГц, а работа с FIFO на частоте 250 МГц.
Один из тестов в модели формирует как раз такую ситуацию. Возникает ошибка при передаче буфера и видно как сначала выдача данных в выходное FIFO задерживается, зато потом несколько буферов передаются очень быстро.


Конечно между АЦП и линией должно быть FIFO которое компенсирует задержку на переповтор. И конечно должен быть запас по скорости.
PROTEQ разрабатывался с учётом уменьшения времени на переповтор, что позволяет снизить требования к входному FIFO и к запасу скорости.
Мне кажется, что это удалось.

Respect и уважуха. ИМХО статья слишком краткая, функциональная схема, наброски КА обработки буферов + больше подробностей только добавили бы плюсов

Фраза из статьи: "С учётом недостатков стандартных протоколов и особенностей применения я решил реализовать свой протокол обмена".

Давайте будем честны сами с собой и с окружающими: эта фраза должна звучать так "мне было очень лень разбираться с протоколами PCIexpress и RapidIO и их реализацией и поэтому..."

Протоколы сейчас делают большие коллективы разработчиков из нескольких компаний сразу. Используется огромный объём знаний и предыдущего опыта. А вы видимо гений-одиночка?

Придётся ещё похвастаться. Я хорошо знаю и использую протоколы PCI Express и Rapid IO. Немного работал с Aurora. Реализацию DMA контроллера для PCI Express я также выложил как OpenSource проект: http://ds-dev.ru
RapidIO мне совершенно не нравиться, но использовать приходится.

Большие коллективы это конечно хорошо, но наверняка в них тоже очень многое держится на одиночках.
Этот проект реально работает. И он сразу был OpenSource, кстати систему моделирования помогал делать Kuzmi4 - за это ему большое спасибо.

Вот есть ещё описание: dcr1206 - Протокол обмена данными PROTEQ.pdf

2 Kluwert
не вопрос, а как тогда вы обоснуете существование GivEVision стандарта для передачи видео по эзернету, который по сути есть надстройка над UDP, своеобразная аналогия TCP/IP но со своей спецификой ? По вашей логике получается что ребятам было лень разбираться в TCP/IP и они налабали свой аналог....