Предстоит осваивать данную тему. Вопрос в том, что будут 2 платы с FPGA в стойке µTCA или VPX. Одна плата будет отвечать за сбор данных с АЦП(8-каналов 14-бит 1Msps) в реальном времени и передачу их на вторую плату с ПЛИС, где будет крутиться управляющий алгоритм с DSP и т.д.
Раньше у нас АЦП были завязаны на прямую с ПЛИСом и проблем с получением данных не было. Теперь читаю все эти описания PCIe, 1-10G Ethernet, Serial RapidIO, Aurora - у всех есть проблеммы с задержкой данных. А мне надо, чтобы данные с АЦП были доступны в управляющей ПЛИС как можно скорее(в идеале не позже чем через 1мкс)
Прикол в том, что в современных стйках типа VPX, или µTCA доступны практически все совремненные последовательные каналы - и 1-10GbEthernet, PCIe x1 x4, Serial RapidIO. Плюс еще обмен предстоит делать между ПЛИС, где все эти стандарты можно запустить на одних и тех-же ногах.
Вопрос в том, что выбрать.
PCIe - говорят, что задержка будет недопустимая,
Serial RapidIO - вроде неплохо подходит. Есдинственное, что корки стоят дофига - 25000$.
Ethernet - из-за длины пактов и неприоретизируемости - однозначно отпадает.
Можете подказать, правильный ли мой выбор?

Еще про инфинибанд забыли. И почему езернет так однозначно отпадает? И кто говорит, что задержка у PCIe будет недопустимая?

Измеренная задержка RapidIO составляет 6.7 мкс от запроса до получения на него ответа. Т.е. задержка в одном направлении 3.35 мкс. К тому же для чипа XC5VSX95T 1-lane RapidIO съест 23% ресурсов логики.

Здесь речь идет о задержках serial RapidIO или все же о PCIE?
Интересует задержка от запроса до ответа по линии PCIE Gen 2.0, кто знает подскажите.

минимальный фрейм в 84 байта (с преамбулой, межкадровым зазором и 46 вроде байтами полезной нагрузки) на гигабите передаётся за 0.672 мкс.
так почему бы не упаковывать каждую микросекунду по 16 байт в пакет и отправлять через езернет.

Насколько мне известно, абсолютно все "забугорные" системы, тем или иным образом слушающие эфир, и при этом выполненные в xTCA или VPX, выполняются на SRIO.


для вас проблема размазать эту сумму по всему ОКРу? Закрадываются сомнения, что "вы их просто готовить не умеете". Извиняюсь, если обидел.

По использованию PCIe основная проблема в том, что задержка - недетерминированная! Т.е. всё зависит от того, насколько быстро происходит обработка каждого из прерываний в системе, с учетом средней загрузки процессора.
Тут просится аналогия с московскими пробками. Чаще вечером стоишь примерно по три часа, но иногда так "повезёт", что приходится простоять шесть, и потом ещё идти домой вообще пешком.
А ещё у нас корка PCIe 2.0 x8 занимала 25% от XC5VLX330T.

У Ethernet слишком большие накладные расходы, из-за IP, который как правило используется поверх голого Ethernet. Если в двух словах, то структура плохо оптимизирована под поточную обработку, из-за необходимости проверки контрольных сумм, впёртых посередине, причем итак уже проверенных при помощи Ethernet FCS, (sic!)


100kpps? если такой поток случайно (или не случайно) попадёт на маршрутизатор на базе ПК, то ему однозначно поплохеет, и, вероятно, фатально.

Ценник на корку Infiniband мы запрашивали. Вот это реально глупая затея. ;-)

1Mpps, я так понимаю никуда кроме как между этими двумя платами этот поток попасть не должен.
да и голые езернет фрэймы, без IP, чем плохи для данной задачи.

Посмотрите в сторону Interlaken.
Кстати, Freescale его уже поддерживает в T-серии.

http://www.interlakenalliance.com/
http://www.xilinx.com/products/intellectua...-INTERLAKEN.htm



Это проблема при использовании ЛЮБЫХ способов. Не только PCIe.

Вот IDT честно написала - типа "Вы тут на латентность свичей смотрите... а посмотрите на отклик системы...
и латентность PCIe покажется Вам ничтожной"
Это естественно справедливо для "рутовой" архитектуры (99.9 % случаев применения).
Для P2P латентность уже имеет значение.

согласен, но в случае с SRIO или Intarlaken можно оценить резервы - хотя бы по буферам принятых пакетов в самих IP-корках, и точно сказать что для того, чтобы "не пролилось" нужно обрабатывать не реже чем раз в N мкс.
В случае с PCIE никаких буферов нет, всё пишется с помощью DMA, но вот сказать через сколько мкс root отпустит первый completion и даст ready для пресылки второго - невозможно.
У нас были опыты с компами (Core2duo-e8200, 2xXeon-5520, и через свичи PLX8648 на обоих) - задержка везде разная, соответственно и максимальная установившаяся скорость везде разная, отклонения конечно небольшие, в пределах 2-5%. И теперь самое интересное, когда эти машины пинговали (я уж не говорю про SSH) скорость просаживалась в этот момент на треть.
В какое место ядра Linux надо лезть чтобы объяснить что прерывания сетевой подсистемы и вообще весь Netlink API менее важны чем прерывания от нашего изделия и вообще наш драйвер?
А без операционки PCIe поднять, мягко говоря, затруднительно. ;-)
Можно конечно QNX, но во-первых спецов днём с огнём не найти, во-вторых там тоже не всё идеально, и общая тенденция такова, что куски кода хотя и выполняется не более известного кванта времени, но арбитраж и планировщик зарезают производительность. Меня например отпугнула производительность дисковой подсистемы. Хватило настолько чтобы больше к вопросу о QNX вообще не возвращаться.

свичей под Interlaken по архитектуре вроде как не бывает, это же точка-точка. Соответственно как городить систему в xTCA или в VPX если нужна точка-многоточка не очень понятно.
соответствующих спецификаций VITA 46.x и PICMG тоже нет.

syoma, нашёл ваше предыдущее сообщение
http://electronix.ru/forum/index.php?showtopic=102008

root у вас в Virtex, потому и в 1,5 раза дольше.

вообще в вашем случае я бы не ставил спартан со сбором на одной плате VPX а обработку на другой, а сделал бы две одинаковые платы, раскидав каналы АЦП на обе, и оставил бы virtex. Ну и обработку делал бы на них, никуда данные не гоняя.
или у вас каналы АЦП тесно связаны и разбить их на две разные группы нельзя?
Если так, то есть VPX 6U. Всё на одной плате, данные придется гонять не через трансиверы а напрямую между ПЛИС. На Virtex-6 в режиме SDR 650-700 МГц на пин можно принять/отдать. Один банк - на вход, второй - на выход. Можно посмотреть на OIF SFI-4.1 например, получите под 10 гигабит для связи между ПЛИС. мало?
http://www.xilinx.com/support/documentatio...tes/xapp856.pdf

Написано конечно много, но мне интересно какое максимальное время отклика по шине PCIE без учета задержек операционной системы. Если скажем два чипа Xilinx соединены по PCIE, на обоих одна и та же корка.
Какое время отклика будет в такой связке. В микросхемах только IPCOre PCIE и код интерфейса верхнего уровня. В одной микросхеме просто шлет запросы время от времени, во второй просто loop пуляет данные обратно.
Кто нить может сказать какое время отклика будет в микросекундах, желательно конкретные цифры задержек и для какого поколения PCIE.
Спасибо.

А hyperlink, который встроен в тексасы 66х не подойдет. Он точка-точка, до 25 гбит/с.
Для FPGA в конце года могут появится эвалюхи и кора (цена не ясна).
http://www.integretek.com/products2.html

Моя тема, а не заглядывал я сюда давно. Сорри. В итоге выбрали PCIe, так как на RapidIO слишком мало готовых плат есть. И все под военку за огромные бабки. Мы организовали обмен между ПЛИСами по PCIe минуя Root. В итоге латентность в основном определяется задержкой самих корок и чуть-чуть собственно свича. Про задержки PCIe писал я уже в этой теме: http://electronix.ru/forum/index.php?showtopic=89948. В Virtex6 LX240 корка х4 занимает 7%. Главное, что все стабильно - root вообще только для конфигурации и в обмене не учавстсвует.
Главный успех - помимо АЦП на Спартане используем стандартные платы АЦП в виде PMC модулей - в итоге ПЛИС опрашивает эти платы через DMA и мы получили 200kSps(ограничено самой АЦП) с латентностью в 5µs+АЦП.

Как я понял, Вы реализовали то, что в терминах PCIe стандарта называется
P2P (peer-to-peer).
С какими трудностями столкнулись и как решили? (если не секрет )
И какую скорость выжали с каким пайлодом?
Как я примерно подозреваю у Вас есть PCIe switch (PLX скорее всего) апстримом к хосту.
2 даунстрима общаются как П2П.