Привет всем.
кто хорошо знает корки PCIexpressные на Xilinx подскажите?
Хотим использовать PCIe для системы управления. Смысл в том, что в системе будет одна или несколько измерительных плат на Spartan-6 и одна плата на Virtex-6. Spartan-6 будут управлять быстрыми АЦП, считивать с них информацию (возможно фильтровать, выделять фазу и т.д.) и затем передавать все это в Virtex-6 для дальнейшей ЦОС обработки и управления. Проблема в том, что система будет управляющей, а не сбора данных - и поэтому время реакции критично.
Мы решили пока попробовать PCI express - как стандартный интефейс между платами. Приобрели SP605 и ML605, а также PCIe extension box с несколькими слотами и IDT свичами.
Весь смысл обмена в том, что SP605 должен постоянно брать данные с АЦП и пересылать их (или записывать) в память ML605 со скоростью примерно 1Mhz и минимальной задержкой. ,Для этого я скомпилил корки PCIe для обеих плат. Вначале пробовали с Microblazeом - но при этом получались жуткие тормоза. Сейчас все заставил работать без него и сейчас могу посулать одиночные TLP со спартана на виртех с любой скоростью и до 8Mhz все работает без затыков, но есть две проблемы.
1. Задержка между отправкой и приемом. При отправке при запуске передачи я изменяю значение одного бита и соответственно ему пина на SP605. В ML605 я по приему пакета и анализе, тоже устанавливаю пин. В итоге все меряю осциллографом - и получаю 1.7мкс задержку +-100нс. Как по мне - это дофига. Мне рисовали радужные картинки порядка 800нс вот здесь: http://electronix.ru/forum/index.php?showtopic=89948 А у меня намного больше. И это только в одну сторону. Специально проверял запрос - 3.4мкс и не меньше. Но это не так страшно, как второе.
2. PCIe был выбран также из-за возможности приоритезировать трафик, что мне очень нужно, так как по тому же PCIe каналу проц будет общаться с платами время от времени. Я сэмулировал данную ситуацию путем имитации трафика с процом и обнаружил, что измерения мои ессно попадают в очередь и принимаются уже и через 6 и через 10мкс, в зависимости сколько пакетов попало между ними. Ну а потом обломался со всей этой приоретизацией - оказывается Xilinxовые корки поддерживают только один VC и все.

В общем я в ступоре. Запустил симулятор, чтобы посмотреть, когда в реальности появляются данные на шине после старта пакета - на ML605 показывает около 700нс. На SP605 - пока не получаяется - симулятор бред показывает. Т.е чтобы посчитать CRC и создать TLP нужно так много тактов? Частота референсного клока 125МГц. Задержка свича вроде в районе 100-150нс.
Вообщем как реально посмотреть где образуется задержка? И как можно ее минимизировать? И как-то можно легкими путями приоретизировать трафик? Я вроде корки от 3-их фирм нашел, что это поддерживают, но за них платить надо дофига, наверное.
Спасибо.
ПС. С PCIe я к сожалению только начинаю разбираться и вот с наскока сразу пытался решить задачу и пролетел.

Можно попробовать:

1. Для Virtex 6 сформировать ядро с частотой внутренней шины 250 МГц - пакеты будут быстрей обрабатываться.


2. Для Spartan 6 ввести паузу между отправкой пакетов. Это нужно, что пакеты не скапливались внутри PCIe блока в очереди на отправку. Очередь будет в Вашей части проекта. И тогда можно будет распределять время между АЦП и командами управления.

1. Да, над повышением частоты ядра до 250МГц я сам думал. На Virtex-6 это, вроде можно сделать. Но на Спартане, по-моему, 125 - максимум, или не?

2. Немного не понял. Что ядро можно настроить работать без ФИФО? Фигня в том, что команды управления обычно будут поступать в Virtex, как раз между пакетами данных с АЦП. Проц, ессно, не знает, когда конкретно данные посылаются и шлет всю пачку запросов одним махом, забивая канал.
В принципе, наверное, выход в том, чтобы процу ограничить частоту запросов на более низком уровне, потому что счас он шлет запросы, как угорелый - я насчитал около 150нс между приходящими пакетами.

В Spartan 6 поднять частоту нельзя.


В ядре FIFO есть и убрать его нельзя. Но можно его не забивать полностью. Максимальная скорость известна и посылать пакеты быстрее нет смысла. Но лучше ограничить поток команд от процессора.


Для уменьшения задержки на Virtex 6 можно попробовать сигнал s_axis_tx_tuser[2]



Сюдя по описанию это позволяет ядру начинать отправлять пакет до того как он полностью окажется в FIFO. Но я сам его не пробовал.

В PCIe не спец., но при подобной постановке задачи мы думаем попробовать Xilinx Aurora - просто как идея.

Transmit cut through на Спартане и так используется. Прикол в том, что сейчас в Chipscope внимательно разобрался со структурой задержки на Спартане и Виртексе - реально Виртекс разбирает и посылает пакеты примерно в 1.5 раз медленнее, чем Спартан! Я смотрю между десериализиованным выходом GTX и реальным появлением обработанного пакета с корки.
Не пойму в чем причина. В спартане 32-битная корка работает на 125МГц. В Виртексе 64-битная корка тоже на 125Мгц.
Мы тоже думали насчет Aurora - но она быстро отпала, так как будем использовать стандартный рэк, а там количество линий ограничено, и так как будет стоять проц, выбор был либо PCIe либо Serial RapidIO. PCIe показался по проще и дешевле.

Крайне интересное наблюдение.


Насчёт Aurora - надо помнить, что этот протокол не гарантирует сохранности данных.