Comments 26
Это вполне может быть потому что Вы используете кодировку, предназначенную для быстрых интерфейсов, на таких низких битрейтах.
Скорость 5 Гбит/с это максимальная скорость для ПЛИС Virtex-6 с быстродействием 1. И на сегодняшний день ещё нельзя говорить что это низкая скорость. Кодировка от скорости вообще не зависит. Кодировка нужна для балансировки среднего уровня сигнала. Выбор не очень большой. В ПЛИС Virtex-6 аппаратно поддержаны только 8/10, 64/66 и 64/67; Я и выбрал 64/67 — она лучше отслеживает балансировку среднего уровня.
Кодировка от скорости вообще не зависит. Кодировка нужна для балансировки среднего уровня сигнала.
Ну вот это два взаимоисключающих параграфа. Я же не просто так это написал. 64 нуля/единицы подряд на битрейтах 5Gbps и 8Gbps — дадут Вам два разных спектра. И в первом случае оно может не очень хорошо пролазить через AC-конденсаторы, так как будет лежать в области более низких частот. Даже на PCIe Gen3 вместе с 64/66 применяют скрэмблирование, как раз чтоб такая ситуация не случалась. А на вашей скорости это и подавно стоит делать.
Лучше всего балансировку отслеживает именно 8/10. Потому что более 5 одинаковых битов подряд там в принципе быть не может. Что достаточно сильно ограничивает спектр снизу.
Сравнивался ли этот показатель с результатами, показанные на платами других производителей?
Есть еще Ethernet, но между чипами на плате по-моему лучше всего подходит Aurora.
И вообще ИМХО лучше всего использовать стандартные протоколы — потом легче будет переносить проект на следующую плис.
Даже из-за ограничения пропускной способности PCIe не вижу смысла. Сейчас уже вовсю продаются Ultrascale, которые и дешевле и быстрее Virtex-6. На них можно спокойно запустить PCIe gen. 3.
Стандартные протоколы это конечно хорошо. Но с одной стороны Ethernet, RapidIO, Aurora, PCIe, Interlaken в данной работе хуже чем PROTEQ. С другой — перенос на другую ПЛИС всегда непредсказуем.
Например перевод PCIe c Virtex6 на Kintex7 прошёл достаточно просто. Но и PROTEQ перешёл просто. А вот PCIe для Ultrascale совершенно другой. Но и в реализации кодировки 64/67 для Ultrascale они тоже намудрили, пришлось долго разбираться.
Хочу ещё раз обратить внимание — главной задачей PROTEQ является передача данных от АЦП, которое не может приостановить свою работу. Это разумеется требует наличия FIFO перед каналом передачи. Но вот размер FIFO определяется возможными задержками, в том числе на восстановление данных. PROTEQ как раз и отличается от стандартных протоколов быстрым восстановлением данных.
Что ж у вас там за данные от АЦП, которые нельзя потерять? Какая проблема сегодня с гигантскими размерами ПЛИС увеличить буффер до нужных размеров, чтобы забыть об этом?
А вообще мое ИМХО вам также стоит задуматься о том, чтобы привести свой обмен к модели OSI. В модели OSI канальный уровень отвечает за целостность и обнаружение ошибока, но не отвечает за восстановление данных после сбоя — это работа следующего, транспортного уровня. Aurora реализует только канальный уровень — поэтому она и не может восстанавливать данные.
Вы же в своем PROTEQ смешиваете и канальный и транспортный уровни — это может привести к проблемам с пониманием принципов работы и в будущем.
PROTEQ соответствует модели OSI. А точнее физический, канальный и частично сетевой уровень.
Физический уровень это конечно GTX. А основная реализация это канальный уровень.
Более подробно можно прочитать в «dcr1206 — Протокол обмена данными PROTEQ.pdf» — документ здесь
То что Aurora на канальном уровне не обеспечивает надёжную передачу — это её особенности.
Не могли бы Вы поправить ссылки.
Однако при ближайшем рассмотрении применять стандартные протоколы в ПЛИС не всегда удобно.
…
Протоколы действительно разные, но сравнивать их можно и нужно.
Вот тут бы подробнее написать, какую именно задачу Вы решаете. Судя по тексту Вам надо организовать соединение точка-точка между двумя ПЛИС Xilinx. Тогда для решения такой задачи, используя наработки RapidIO, из всего стека протоколов RapidIO надо выбрать только подходящий протокол физического уровня (physical layer).
PROTEQ это не соперник полному стеку RapidIO или PCI Express! Их бесмысленно сравнивать. Но можно сравнить PROTEQ и, скажем, RapidIO LP-Serial Physical Layer v3.1.
PCI Express и RapidIO работают с кодировкой 8/10 что сразу ограничивает пропускную способность.
Тут мне знающие люди подсказали, что не одним 8/10 жив RapidIO LP-Serial. В версии 3 спецификации RapidIO LP-Serial для baud rates более 3.125 Гбод используется кодирование 64b/67b (см. http://www.rapidio.org/wp-content/uploads/2014/10/RapidIO-3.1-Specification.pdf, стр. 479 и далее). А есть и совсем новая спецификация RapidIO версии 4 (см. http://www.rapidio.org/rapidio-specifications/).
Никак не критикую проделанную автором работу, просто прошу быть более последовательным в изложении и точным в деталях.
P.S. Не в коей мере не пытаюсь восхвалить RapidIO, просто знаком с RapidIO чуть лучше, чем с PCI Express или Aurora.
Если сравнить PROTEQ и RapidIO LP-Serial Physical Layer v3.1, то скорее всего PROTEQ будет гораздо компактнее и обеспечит более быстрое восстановление при сбое. Что мне и нужно.
Вот здесь возникает вопрос что значит «взять». Взять и прочитать спецификацию — но её в ПЛИС на засунешь. Нужно IP ядро. Для Rapid IO есть OpenSource ядро которое сделали в Индии, но они сами пишут что в железе не проверяли. У них это академическая разработка. Xilinx имеет IP Core для спецификации 2.0 — это кодировка 8/10. Стоит он дорого, ~2M рублей. Есть американская фирма, которая предлагает IP Core спецификации 3.0, так они мне даже цену не сообщили.
Если сравнить PROTEQ и RapidIO LP-Serial Physical Layer v3.1, то скорее всего PROTEQ будет гораздо компактнее и обеспечит более быстрое восстановление при сбое. Что мне и нужно.
Вот такое объяснение звучит гораздо убедительнее, чем
PCI Express и RapidIO работают с кодировкой 8/10 что сразу ограничивает пропускную способность.
Спасибо!
PROTEQ — протокол обмена по мультигигабитным линиям для ПЛИС Xilinx