Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Порядок транзакций PCIe
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
sp1
Всем, здравствуйте. Делаю систему на FPGA на основе xapp1052 для двусторонней передачи данных FPGA Spartan-6 (кит sp605) - оперативка. Передача данных из оперативки в FPGA осуществляется следующим образом: FPGA отправляет транзакцию MRd с соответствующими адресом, тегом и размером запрашиваемых данных, в ответ приходит транзакция CPLD с данными.

Столкнулся со следующей проблемой, нарушается порядок следования транзакций CPLD. Т.е. я отправляю транзакции MRd с адресами данных последовательно, и теги в транзакциях MRd идут последовательно 1, 2, 3, ... 1F, 0, 1 ... а в ответ периодически приходят CPLD с нарушенным порядком. Например, сначала CPLD с тегом 2, потом CPLD с тегом 4, потом CPLD с тегом 5, потом CPLD с тегом 3, потом CPLD с тегом 6. И данные, соответственно, лежащая по адресам, соответствующим тегам. В результате в принимаемом на стороне FPGA файле данные перемешиваются.

Пробовал выставлять всем транзакциям MRd одинаковый тег, данные все равно перемешиваются, хоть и CPLD идут с одинаковым тегом.

Читал спецификацию PCI-Express, но так и не понял, это такая особенность PCI-Express, что ему разрешено менять порядок транзакций CPLD во избежании Deadlock'ов или дело в чем-то другом? Причем такая фишка у меня только в компах под управлением 64-разрядной операционки (Linux). В 32-разрядных Linux всё ОК.

Кто-нибудь сталкивался с подобной проблемой? Что можете посоветовать?
Timmy
Перемешивать как запросы так и ответы на чтение спецификация разрешает, см. раздел Transaction Ordering. А вот выставлять нескольким исходящим и незавершенным запросам один тэг - запрещаетsm.gif.
Так что надо учитывать в алгоритме, что CPLD придут не по порядку.
sp1
Цитата(Timmy @ May 16 2016, 16:18) *
Перемешивать как запросы так и ответы на чтение спецификация разрешает, см. раздел Transaction Ordering. А вот выставлять нескольким исходящим и незавершенным запросам один тэг - запрещаетsm.gif.
Так что надо учитывать в алгоритме, что CPLD придут не по порядку.


а запретить системе перемешивать CPLD как-нибудь можно?
Bad0512
Цитата(sp1 @ May 16 2016, 19:27) *
а запретить системе перемешивать CPLD как-нибудь можно?

Нет, нельзя. Выхода тут два : либо ждать пока придут все данные от текущего запроса и только потом выставлять следующий. Недостаток данного подхода очевиден - сильно падает производительность, так как после каждого запроса до прихода первых данных всегда приличная пауза, соответственно эта пауза автоматически добавляется к любой транзакции размером не более 4к. Достоинства этого подхода также очевидны - простота реализации.
Второй вариант - данные перекладывать в промежуточные буфера, и отдавать их далее только по наполнению этих промежуточных буферов полностью. Тут тоже всё очевидно - механизм сложнее, зато есть вариант выжать максимальную скорость.
sp1
Всем спасибо за полезную информацию!
Tue
Цитата(Bad0512 @ May 17 2016, 07:57) *
Второй вариант - данные перекладывать в промежуточные буфера, и отдавать их далее только по наполнению этих промежуточных буферов полностью.

Промежуточные буфера не нужны, если ваш локальный в ПЛИС буфер, в который вы принимаете данные работает в режиме памяти (то есть по адресам). В этом случае в каком бы порядке ни приходили данные - они положатся в буфер по своим адресам и перемешивания не будет.
Bad0512
Цитата(Tue @ May 19 2016, 20:18) *
Промежуточные буфера не нужны, если ваш локальный в ПЛИС буфер, в который вы принимаете данные работает в режиме памяти (то есть по адресам). В этом случае в каком бы порядке ни приходили данные - они положатся в буфер по своим адресам и перемешивания не будет.

В случае памяти - да, ничего страшного не произойдёт, нужно лишь дождаться пока все данные прилетят, поэтому порядок их не очень важен. Однако существуют и другие приложения (например, вам надо сформировать некий поток, данные в котором передаются последовательно), тут порядок прихода данных уже становится важен, без промежуточного буфера не обойтись.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.