Возникли такие же трудности - времянка вообсче плохая - и как раз ошибок много в этом самом эндпойнте. ИСЕ вообсче отказывается собирать дизайн на этапе мапа - не подскажете как вы выходили из положения ?? При чём на этапе синтеза мин период 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

 pcie_ep_original_adopter_arch01.rar ( 585.57 килобайт ) Кол-во скачиваний: 178

 pcie_ep_original_adopter_arch02.rar ( 582.53 килобайт ) Кол-во скачиваний: 173

Насколько я понял спецификацию, при обращении к любому адресату, находящемуся в младших 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 бит адресного пространства.

Сообщение отредактировал serebr - Dec 3 2009, 13:38

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

 prj_v03_NoZ.rar ( 582.42 килобайт ) Кол-во скачиваний: 145

 prj_v04_Z.rar ( 582.72 килобайт ) Кол-во скачиваний: 157