Есть кто уже работал с ядром Xilinx "PCI Express Block Plus" в Virtex 5 ?

Работали с софтовой версией. Интерфейс такой же (local link), но в V-5 не надо следить за буфером принимаемых completion на материнке

А интерфейс local link писали с нуля или дополняли интерфейс из example design?

+ Я Вам отправил личное сообщение

Писали с нуля, пример там только для target. Не советую писать с нуля, много время потратите. Лучше взять готовый backend от nwlogic (ссылки есть на сайте xilinx)

Искал на тему backend на сайте, но эта информация не попадалась. Внутренний интерфейс их ядра так и называеnся в оригинале Local Link? И скорей всего это ядро платное?!

Искать надо через pci-express block plus. Там на вкладке есть ref design. Если туда пойти, попросит зарегистрироваться, а потом даст ссылку на файлы от nwlogic (ядро платное, но сколько стоит не знаю).

Вы сами создавали интерфейс к Local link + User Interface?
C вами можно напрямую пообщаться (ICQ,Skype,..)?

Разбирался в Example design и заметил, что если они принимают пакет с TD=1, то и выходной пакет они передают тот же самый бит TD (что и в принятом). Но, если в принятом ЕДЗ ECRC можно игнорировать, то в Complition его надо генерить. А в коде TX нет генерации ECRC(TLP digest) - в этом случает TLP будет Malformed ?!

Я делал свой мультипортовый scatter/gather DMA контроллер. TLP digest я вообще не использовал (ставил галку trim). В пакете и так есть контрольная сумма, достатчно для большинства приложений. ICQ не пользую

Уточняли?! При этом ядро исправляет этот бит, если он присутсвует в исходящем пакете. К вопросу о качестве екзампл дизайна.
Пока мне нужен простейший target с двумя небольшими однонаправленными FIFO. Может у Вас есть что-то, что поможет их связать с ядром от ксайлинкса(через Local Link). Или подскажите подводные камни Local Link интерфейса от Xilinx/ У меня пока единственный вариант доделовать example design под мои задачи. А шишек при первом знакомстве с PCI express от Xilinx на их плате ML555 думаю будет и так не мало...

В nwlogic отправил запрос (с их сайта лишь). Посмотрим что пришлют. Хотя на их сайте нет явных упоминаний про интерфейс к ядру от Xilinx (у них оно свое есть). Но для моей текущей задаче их платное ядро будет излишеством

У Вас есть что-то на работе, чтобы можно было пообщаться в реалтайме?

Для target всё довольно просто, example design подойдёт. Работает всё нормально (правда медленно, большая задержка в pcie, хотя если увеличить число линий должно быть быстрее). К фифо подключить тоже легко, надо выкинуть ramb и поставить селектор адреса для фифо и регистра флагов.

Сколько Mb/s по Вашему можно получить на х8, если оставить из примера обработку по 1 DW payload в обе стороны?

Вам удобней здесь общаться или можно также через e-mail? Просто, думаю, всплывут некоторые тонкости ядра от Xilinx. Вдруг Вы их уже проходили.

Кто работал и добился, чтобы сходились тайминги для хард-ядра x8 - подскажите "настройки" ISE (для Multi PAR).

В FAQ Xilinx советует только использовать мульти PAR - но это только уменьшает число ошибок. Но не убирает их полностью.

большой скорости с нагрузкой TLP в 1 DW не добиться нужно переписывать под 1024 DW ... чем сейчас и занимаюсь.... буду рад пообщаться с теми кто занимается данным вопросом

Как вы моделировали ядро PCI Express Endpoint Block Plus?

У меня первый же простейший тест типа: записать-прочитать по последовательным
адресам не проходит. Completion пакет чтения на 7-ой итерации почему-то теряется.
Чем он отличается от 6-ти предыдущих ума не приложу.
Кто-нибудь с подобным сталкивался?

если вы выбрали sample_smoke_test0 то в первых 9 транзакциях будет производиться симуляция чтения пространства конфигурации.. затем запись в память с 32 и 64 битной адресацией 1DW. и запрос на чтение с ожиданием соответствующего Completion.

Нет, я использую свой тест.
Текст теста в аттаче. (user_test0.txt)
Результат моделирования тоже. (sim_log.txt)

Дошел уже до разбора символов на Link Layer.
Пытаюсь понять, пакет завершения не выдается тестируемым Endpoint-ом
или drop-ается принимающим его Downstreам_Port-ом?

Изменения теста такие как:
- обращения по одному и тому же адресу,
- чтение без записи
- добавление пауз
и т.п.
ситуацию не меняют.

всавил ваш тест в tests.vhd но ни каких транзакций кроме чтения пространства конфигурации не наблюдал... может вы еще внесли какие то изменения в проект симуляции. потому как стандартные тесты у меня работают нормально.

помимо этого, только выбор теста в 'pci_exp_usrapp_tx.vhd'
строка 115: test_selector => String'("pio_writeReadBack_test0")
заменить соответственно на: test_selector => String'("user_test0")

все, больше ничего...

Проблема решилась!

Я случайно использовал модель Endpoint Block версии 1.9
совместно с тестовым окружением от версии 1.11
Xilinx Core Generator не смотря на предупреждение о возможной перезаписи
сгенерированных ранее файлов создал вдобавок к 'pcie_endpoint_plus.vhd'
новый файл 'pcie_endpoint_v1_11.vhd'. А я упустил это из виду.
Новая версия отличается несколькими портами. Возможно, это как-то повлияло,
или причина кроется где-то в недрах Endpoint Block.

Теперь все работает!

Здравствуйте.

Чтоб не открывать новую тему решил запостить сдесь (и так уже много чего полезного написано).
Вопрос есть один, касательно симуляции.
Доработал я pio_tests.v, а в частности pio_writeReadBack_test0. Файлик прицепил
Нажмите для просмотра прикрепленного файла
В 2-х словах: сделал 2 записи по 10 и 6 dword-ов , и после этого сделал 2 чтения по 12 (с середины записанного региона) и 16 (весь записанный регион) dword-ов. Запись прошла на ура, и 1-е чтение тоже, а вот 2-е загнулось , хотя я в модельсиме видел как моя логика честно отгрузила положенное . Решил упростить задачу сделал чтение 4 (с середины записанного региона) dword-ов и 16 (весь записанные регион) dword-ов - первое чтение проходит, а на 2-е имеем ту же ситуацию - моя логика честно отгрузила положенное, а dsport загнулся на ожидании данных. Вот и интересует - чем 4 dword-а от 16 отличаются (оба больше 1 конечно; кстати и с 8-ю dword-ами тоже проходит чтение) ? Отчего такая разница ??
И есть есчё интересное поведение trn_tdst_rdy_n - при комбиинации для 2-х заходов чтения 12/16 корка выставляет этот сигнал для 1-го чтения, а для второго не ставит, и что самое интересное первое чтение проходит, а второе нет ? С чего бы это - там же буфер на 2 килобайта, я больше чем 16*2 dword-ов в своих комбинациях не вычитываю ??

Я не спец по верилогу, но так понимаю Вы читаете и пишете память slave устройства пакетами по несколько DW? А как собираетесь сделать это на плате? В PCIE нет системного ПДП контроллера, надо делать мастер. И вообще, как показывает практика, моделирование PCIE - пустая затея, потом придётся половину контроллера переделывать из-за неверных предположений. Гораздо проще и надёжнее чипскопом на плате смотреть.

2 dmitry-tomsk - а про какой контроллер идёт речь ? И в смысле - как собираюсь делать это на плате - самый примитив - получаю несколько qword-ов по адресу такому то, и записываю их себе в память. Потом когда приходит реквест на чтениес этой памяти - генерию комплетишн с данными, вроде просто всё.. Моя мать позволяет в ответе до 128 байт иметь, пока мне хватит... Так а чём вопрос то ?

То, что MAX_PAYLOAD_SIZE и MAX_READ_SIZE материнки 128 байт (это минимум из возможного), не говорит о том, что Вы можете читать и писать по 128 байт. Только до 4 байта для 32-х битных процессоров и 8 - для 64-х разрядных. Читайте xapp859 как надо делать

2 dmitry-tomsk - прочитал.. интересно.. Только не пойму где там написано про то что дял 32-х битных процессоров будем читать/писать по 4 байта , а для 64-х битных по 8 байт? В главе "Transaction Layer Packet Maximum Payload and Maximum Read Request Size" расказывается про 128 байт, и в сносках к ней на асусовскую мать тоже говорится про 128.
Вот разве что удручает так это разбиение пакетов:
То есть на сколько я понял юзеровские пакеты по 4кб ко мне дойдут только в виде 128 байтных реквестов на write (то есть это железяка их сама побъёт без ючастия юзера) а чтение 4kb с моей стороны будет выглядеть как кучка комплетишнов по 128 байт каждый, которые эта же железяка соберёт и отправит юзеру наверх.

Ваше user application должна состоят из двух частей - мастера и слэйва. Слэйв принимает memory read/write request длина которых в принципе не может быть больше 1 или 2 DW, так как в процессорах нет команд чтения/записи больше 1 слова из памяти, а системный ДМА контроллер (ISA, EISA) не доступен для PCIE. Мастер может в писать в память хоста пакеты memory write request с MAX_PAYLOAD_SIZE байтами в нагрузку (ограничение со стороны материнок 128 байт, со стороны ядра 512 байт). Мастер может читать из памяти хоста пакеты через memory read request с размером запроса не более MAX_READ_SIZE байт. Хост вправе вернуть не один пакет MAX_READ_SIZE, а несколько, например, 1 и 127 байт, зависит от root complex. Посмотрите ещё xapp1052

2 dmitry-tomsk - спасибо за просвещение
В принципе нашёл почти всё прочто вы писали, только не ясно откуда вы взяли что

В том же xapp1052 нашёл такое:

Это предложение вроде бы как раз указывает на то, что в write request-е для данного чипсета может быть 128 байт а не 4 или 8...
Или я что то не так понял ?

Нашёл я в реководстве по написанию драйверов (драйверы самому приходится писать и это иногда полезно
Вот Ваш мастер как раз и может генерить write request c 128 байтами в нагрузке, read request c 64 байтами. А вот на материнке такого мастера нет.

2 dmitry-tomsk - благодарствую.
Тут кстати подключил вчера чипскоп - и что меня удивило - непрерывные посылки broadcast from RootComplex vendor defined message - данные каждый раз разные, а ID-шки и адреса одниковые. Что на openSUSE 32бит что на WinXPSP2 32бит...
Не подскажете что оси постоянно пытаются в мой дизайн записать?
И есчё что интересно - дизайн с xapp1022 - нормально мапился в openSUSE как временный файл (или файл подкачки, не вспомню я счас эти тонкости), и можно было писать читать по 4 байта в реквесте, а мой дизайн мапится - мапится, только read реквестов я не вижу, а с write - только те что broadcast from RootComplex vendor defined message . Тут вот странно, ведь реквесты заходить должны всегда ? То есть понятно что свой драйвер будет, этот финт ушами был для проверки что мне заходит с компа, но почему такая существенна разница на такой простой реализации??
И потому тут есть вопрос такой, скорее уточнение, потому как вроде ясно, но хотелось утчонить (из-за вышеупомянутого, что вводит в некоторое недоумение) у работавшего с этим чЮдом - на сколько я понял мне приходят запросы с юзер уровня - и на них я отвечаю, а всякие специфические запросы можно игнорить - в смысле не отвечать на них (в спецификации по крайней мере написано что можно) - то есть не чревато ли это чем то?

Ну про openSUSE это к специалистам по ней, а про специфичные запросы - на них точно можно не отвечать Насчёт проверки на проектах xapp тоже ничего сказать не могу, когда я делал свой контроллер их ещё не было.

2 dmitry-tomsk - в обсчем есчё раз большое благодарствую... На днях посмотрим что там драйвер нам скажет... За одно и узнаем про DMA котроллер и PCIe в линухе

Возникли такие же трудности - времянка вообсче плохая - и как раз ошибок много в этом самом эндпойнте. ИСЕ вообсче отказывается собирать дизайн на этапе мапа - не подскажете как вы выходили из положения ?? При чём на этапе синтеза мин период 5.9 нс , а на этапе мапа - слак у клока в ендпойнте 10 НС(8нс период) !!

Да такая же проблема... не могу уложиться в тайменги. Причем на х1 и частоте 65 МГц все работает отлично. при переходе на х4 и частоту 125МГц тайменги укладываются, ядро временно работает (гонит счетчик), но через некоторое время "отваливается" по тому что на такой частоте нужно отслеживать Transaction Receiver Credits Available (как это делать я еще не разобрался). А на х4 и частоте 250МГц начинают появляться тайминг error.

2 demon_rt - а не подскажете что есть Transaction Receiver Credits Available ?
На счёт времянок - когда просматривал xapp859 дизайн - там всё законвееризировано оказалось - где то даже встречал в каментах, что это сделано как раз для того чтобы времянки сошлись...

Transaction Receiver Credits Available это проверка на наличие свободного места в буферах приемника ядра. Является одним из методов борьбы с переполнением в режимах х4 и х8. Смотрите ug167. На счет тайменгов, удалось оптимизировать проект путем замены фи-фо на двухпортовую память и некоторой коррекции кода. Но столкнулся с такой проблемой. В режиме х4 передачи данных на хост (пишу в оперативную память в режиме DMA), Endpoint прогоняет порядка 70Гб со скоростью 800 Мб/с и предача останавливается...

2 demon_rt - благодарствую

2 demon_rt - кстати, на счёт остановки - а как это выглядит ? Вы это уже побороли ??

Нет еще не поборол. Обрыв транзакций происходит в различные моменты времени, что не похоже на переполнение буферов. После обрыва в конфигурационном пространстве порта PCI Express на хосте в Secondary Status Register появляется Signaled Target Abort и Fatal Error. Причем линк ап не падает в момент обрыва транзакции, но дальнейшая передача невозможна. Причину возникновения данных ошибок я еще не понял.

Вопросик есчё один есть , не знаю как бы получше его решить.
СОсбно вся проблема заключается в том , что нужно считать адрес для 64-битного адресного пространства (задал через BAR0/BAR1). Считываем через Configuration (CFG) interface - это понятно.. Но как считать, когда уже конфиг произошёл (собсно вопрос именно в определении времени когда комп уже сконфигурил мне бары) и в барах уже корректный адрес ?

Здравствуйте.

А никто не пробовал работать с 64-битными барами ?
Вопрос собственно почему возник - имеем 64-битный бар, он выбран естественно для того чтобы иметь 64-битный адрес на входе, а не делать всякие ре-органайзеры когда нужно много куда то писать. Смотрим в спецификацию для PCI Express версии 1.1 на страницу 62, видим Figure 2-13: Request Header Format for 64-bit Addressing of Memory , и радуемся.
Вот пока требуемый объём был не больше 4 ГБ - мать стартовала, но при адресации к этому 64-битному бару хедер был странный - не по спецификации - Fmt == 01/11 (тут вроде норма) а вот адрес - на 32 бита, а потом сразу данные (это при записи, при чтении - там указание от rrem - что валидные только верхние 32 - как раз где 32-бита адреса)..
Захотелось поставить больше 4ГБ - одни матери тупо повисают при старте (c 945/965 чипсет), та что поновей - постоянно перезагружается (мать GA-P55). На последней матери стоит 860 Core i7 с него напрямую выходит PCI-Express на разъём - на него и поцепили нашу ПП с Virtex5, чтоб избавить себя от всяких чипсетов/мостов по пути к процессору. ОС - Linux (Suse 11.1) PCI Express Endpoint корка - 1.11 (ISE 11.2).

Это я где то проглядел/недочитал или как это понимать вообсче вот такое поведение ??

И есчё - не подскажете кто пробовал - на виндовсе при запросе памяти меньше 4ГБ - входной хедер соответствует тому, что в спецификации для 64-битной адресации ?

Обновлю информацию, может кому будет полезно в будущем:
1) при запросе памяти меньше 4ГБ - входной хедер по размеру соответствует 32-х битному(там 32б верхние адреса отпадают, написано в спецификации).
2) Тестирование на запрос памяти > 4ГБ проводилось так же на других десктоповых машинах - всё то же. В конце концов добрался до HP ML370 - на нём не висло и не ресетилось, биос просто забил при конфигурации на эту область и пошёл себе дальше... Вот такая поддержка спецификации в обсчем и целом

Вот интересно, а зачем понадобилось делать такой объём памяти в BAR? Это регистровый файл в Вашем устройстве такой большой?
Даже для ДМА контроллера пакеты с поддержкой 64 битного адреса нужны ли вообще для ПЛИС? Длина пакета на слово больше, хотя бы теоретически это уменшить пропускную способность. Выделить кусок непрерывной памяти больше нескольких мегабайт под windows уже будет проблемой, а для SGDMA нужен такой огромный объём памяти под дескрипторы, что ПЛИС придётся хранить их во внешней памяти. Для x1 два буфера по 1 МБайт ping-pong давали практически теоретический максимум, не пробовал на x4 или x8, может там и мало будет, но никак не ГБ.

2 dmitry-tomsk - нам там очень понравились форматы для TLP пакетов, очень они подходили под нашу задумку - ничего дополнительного городить не нужно было в плиске - всё б уже готовое с матери приходило б ( в смысле длинна пакета есть, адрес в 64битном формате, сами данные ну и всё такое - красота, бери только и пиши ). Пакеты то по 4КБ прихордят по стандарту (реально даже меньше).

И снова здравствуйте.

В принципе, думал что знаю PCI Express Block Plus, но тут получилась интересная ситуация. Хотелось бы получить консультацию профи, потому как мне не ясно на данный момент отчего там чЮдеса творятся.

Есть 2 прожекта - оба минимальные доработки примера от Xilinx.
В первом архиве используется прямая адресация + обращение к барам - изменения по сравнению с примером существенные.
Во втором архиве - заменён только контроллер памяти из примера - тестовая прога(всмысле драйвер) пишет всегда 1DW, так что rd/wr_byte_enable не нужны, совсем примтивный арбитраж.
Вроде бы на мой взгляд оба проекта практически идентичны, однако при работе с драйвером под SUSE 11.1 в первой реализации по 0x80 адресу в BAR0 появляются нули (они там островками - видна даже периодичность), а вот во второй реализации никаких нулей где бы то ни было в BAR0/1 не наблюдается. На симуляции - оба примера присылают одинаковые данные для адреса 0x80 и выше в BAR0

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Насколько я понял спецификацию, при обращении к любому адресату, находящемуся в младших 4 Гбайт адресного пространства, инициатор обязан всегда использовать 32-битную адресацию, т.е. 3 DW header. Т.е. независимо от того, как на End Point был объявлен BAR0/1 (2 по 32 или 1 по 64 бит), если система посадила End Point в младшие 4 Гбайт, то от PCIe свитча будут всегда приходить запросы, имеющие 3 DW header (32 бит адресация).

P.S. Тоже самое относится и к встроенному мастеру на End Point: если адрес получателя "сидит" в младших 4 Гбайт, то инициатор мастера обязан использовать 3 DW header, если выше 4 Гбайт - 4 DW. Оно и понятно примерно, зачем так сделано: откуда мастеру End Point'а знать, как был заявлен другой End Point, к которому ему надо обратиться. А так всё просто - шлём короткий или длинный header и плюём на то, что другому End Point'у хотелось - 32 или 64 бит адресного пространства.

Последние новости с полей
в архивах прожекты отличающиеся только адресацией на чтение. Как можно понять один даёт на тестовой железяке "нули", а другой нет. Вся разница заключается в том что в дизайне без "нулей" (изначальный который) адрес для чтения был на 12 бит (байтовая адресация), при чём при подаче на "контроллер" памяти адрес сводился к двордовому (2 нижние бита адреса отрезались). Изменение заключается в том, что я убрал это "обрезание" и формирую read адрес изначально в двордовом представлении.
Понять пока глубокую суть этого не могу
Помогите постигнуть дзен

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Пока нет времени детально разобраться с приведенными логами.
Первое что приходит в голову - несоблюдение правила 4KB границ адресных диапазонов при формировании запроса (пункт 2.2.7 спецификации). Вторая возможная причина - нарушение границы адресного диапазона для правила Read Completion Boundary (RCB, пункт 2.3.1.1).

2 serebr - а не могли бы вы учтонить(пример всмысле)? Потому как в принципе понимаю о чём речь, только не могу понять как это может быть привязано к изменению.
(прицепил выше не логи а полностью прожекты)

тоже как-то не хватает времени посмотреть проекты, но упоминание об усечении адреса и 1 dw посылках наводит на следующую мысль: даже если посылается 1 dw, но по байтовому адресу, то придёт 2 dw в payload data, и в first last dw byte enables будут не 1, а 0 и 1 со сдвигом в зависимости от исходного адреса. Адрес в пакете будет усечённый. Пустые байты скорее всего будут заполнены нулями, хотя это зависит от мастера, я в своём их не обнулял.
Может поможет!

Новости с полей:
после того как в отправке Completition Header-е поле Lower Address стал наполнять байтовым адресом вырезанным из получаемого (нижние 2 бита меняю согласно спецификации как и раньше) и изменил процедуру отправки прерывания (стало MSI, как по UG) - всё заработало без сбоев.
В обсчем как обычно - нужно внимательно читать ДШ и не пропускать мелочи

Поздравляю! Мне всё это ещё предстоит пройти, но своим путём, т.к. делать надо не на Xilinx'е, а на Lattic'e.