Нет, я использую свой тест.
Текст теста в аттаче. (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. Файлик прицепил
 mem64_tb_part.txt ( 7 килобайт ) Кол-во скачиваний: 251

В 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 в линухе