Почему WinXP не видет BAR Memory без перезагрузки ?
Как можно обойти это перезагрузку ?

1. Глагол "видеть" - неправильный, поэтому не "видЕт" а "видИт". См. учебник русского языка.
2. Насколько мне позволяют предположить мои способности к телепатии, вы пытаетесь на ходу перезагрузить PCIeшную корку и
сильно удивляетесь тому обстоятельству, что БАРы перестают быть видимыми из софта. Ничего удивительного тут нет. В процессе
конфигурации в БАРы записывается базовый адрес ваших окон памяти и/или портов. При перезагрузке FPGA эти значения, само собой
сбрасываются в дефолтные. Необходимо по новой провести конфигурацию девайса. Под виндой есть как минмум два способа решения
этой задачи. :
1. Простой способ. Перед тем как перешить FPGA в девайс менеджере говорите вашему девайсу "disable". Прешиваете FPGA.
Там же, в девайс менеджере говорите своему девайсу "enable". Недостаток способа - слишком много кнопок надо нажать чтобы
произвести перезагрузку.
2. Более сложный способ. Пишите свою маааленькую апликушку под винду, которая перед перегрузкой FPGA читает и запоминает у себя
значения всех важных регистров, а после перегрузки - восстанавливает их обратно. Таким образом, винда "ничего не заметит".

Старый стал, забывать начал



Спасибо, идеи понятны.

Хочу дополнить, что первый способ не работает, а второй работает не на всех компьютерах.
Для примера:
Компьютер на chipset P45 полностью восстанавливал работоспособность.
Компьютер на chipset P55 - не полностью. Он не выполняет запросы на чтение 512 байт от устройства. В связи с этим - не работает DMA. Запросы на 128 байт выполняются нормально.
Программу я уже где-то в форуме выкладывал. Если нужно, могу ещё раз выложить.

2 dsmv
а какова причину, почему так?

Точная причина неизвестна. Есть предположение. Параметр MAX_REQ_SIZE (максимальное число байтов для запроса чтения) должен быть установлен по всей иерархии - от ROOT до ENDPOINT. При перезагрузке ENDPOINT он устанавливается в значение по умолчанию где-то в середине иерархии. Для P45 остаётся значение 512 байт, для P55 - только 128 байт. И я вижу, что запрос на 512 байт не выполняется. Приходит несколько ответов, но не все.

Не имел подобных проблем потому, что пользовал только самые короткие пакеты. Причина этого - прирост производительности мизерный, а вот проблем с переносимостью возникает сразу куча.

Я использовал ядро PLDA, и поэтому размер пакета от меня скрыт. Они используют максимальный размер 512 байт.
В новом контролере ядро PLDA не использую. Формирую запрос минимальный. И в итоге получил падение скорости на 11 %.

512 байт - скорость ПК->устройство 1080 Мбайт/с
128 байт - 957 Мбайт/с

Так что буду увеличивать количество байт в запросе до 512.

В этом вопросе необходимо внести ясность.
Под длиной пакета я имел ввиду пакеты в обратную сторону, то есть с устройства в хост.
В этом направлении от размера пакета практически ничего не зависит, так как паузу между пакетами можно сократить до минмума.
В направлении из ПК в хост всё немного сложнее.
Тут можно поступать двумя способами. Первый (простой) : посылаем запрос, ждём пока прилетят все данные по этому запросу, только после этого посылаем следующий запрос.
Естественно, на скорость тут влияет та самая пауза между посылкой запроса и появлением первых данных с хоста. По моим наблюдениям, она может составлять порядка 200 тактов шины.
Понятно, что в этом случае чем больше размер запроса, тем меньше относительное влияние этой неизбежной (на каждый запрос) паузы. Отсюда такая разница в скоростях.
Размер пакета с запросом на данные может быть любым, лучше конечно максимальным, хост сам разберётся и если надо, разобьёт большой пакет на мелкие куски.
Второй способ (более производительный и более сложный в реализации) : Посылаем один запрос, сразу же посылаем ещё один. Принимаем данные и следим (контролируя количество прилетающих с хоста данных) за тем, чтобы в очереди всегда было как минмум 2 запроса. В этом случае пауза между первым запросом и данными возникает всего один раз на всю операцию ДМА, соответственно влияние этой паузы "размазывается" на размер всей операции ДМА, и практически нулевое. Однако в этом способе тоже есть свои подводные камни. Дело в том, что хост контроллер не гарантирует того, что данные будут передаваться в девайс именно в том порядке, в котором их запрашивали, поэтому на границах пакетов довольно часто мелкие блоки данных от разных соседних запросов переставляются местами.
В принципе эта проблема тоже победима, так как у каждого запроса может быть свой уникальный ID, значит данные можно сначала собирать в промежуточную память размером в 2 пакета, и по получению всех данных от текущего пакета отдавать далее в конвеер обработки. Но это довольно серьёзное усложнение схемы, хотя в случаях когда нужно выжать максимальную производительность может быть оправдано.

У меня решён самый сложный способ. Я посылаю 8 запросов на чтение, принятые данные записываю в промежуточную память в соответствии с адресом. Так что ответы могут приходить в любом порядке.
Разница между скоростью 1080 и 957 Мбайт/с набегает из-за размера запрашиваемых данных. Если я запрашиваю в одном запросе 512 байт, то получаю 1080 Мбайт/с. Если 128 байт - то 957 Мбайт/с.
Кроме контроля адреса, необходимо контролировать ошибку Completion Timeout. Данные могут совсем не прийти. В этом случае я повторяю запрос на чтение.