Блог

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

Меня смущает то, что кажется, что этот подход может работать только на двух платах одновременно. После того, как запрограммирована третья плата, а затем обновлен диспетчер задач, система запрашивает недостаточно ресурсов: «Это устройство не может найти достаточно свободных ресурсов, которые оно может использовать (код 12)»

Я попытался отключить две другие платы, но устройство по-прежнему вызывало конфликты. Я не знаю, как запрашивать конфликтующие ресурсы.

На моих платах есть 2 панели (BAR0: 2 КБ, BAR1: 16 МБ) и 1 IRQ.

Я провел несколько экспериментов и почувствовал, что это вызвано конфликтом ресурсов памяти. Конфликтующей стороной была интегрированная видеокарта AMD, поставляемая с материнской платой. 1-й, 2-й, 3-й все указывают мой номер платы.

3-й не распознается из-за конфликтов.

После того, как я выключил его, я подключил все три платы, а затем снова включил его. В результате во время процесса запуска система снова перезапустилась после внезапного сбоя питания, а затем все три платы работали нормально. В это время обнаруживается, что адрес памяти видеокарты изменился

Я хочу знать, как разрешить конфликт? измените мой код драйвера или конфигурацию FPGA?

Перечисление PCIe должно решить проблемы с выделением памяти, однако есть пара проблем с реализацией, о которых следует знать. Например, я использовал Xilinx XDMA с 64-разрядной панелью размером 2 ГБ, и я буквально замуровал материнскую плату DELL XPS. Но я сделал то же самое с системой IBM, и это просто сработало. Дело в том, что перечисление может быть выполнено с помощью встроенного ПО, аппаратного обеспечения или события, управляемого ОС. Если вы используете диспетчер оборудования, это звучит как управляемый ОС, но когда я поджарил плату XPS, это была какая-то проблема FW, связанная с размером панели, что привело к постоянному сбою. 16 МБ невелики, и это не должно быть проблемой, но я бы рекомендовал сначала использовать значения по умолчанию Xilinx и показать надежность там. Я думаю, что это один БАР на 1 М. Я без проблем запускал 3x 64-битные бары по 1 МБ за штуку, но сохранял простоту и надежность. Затем двигайтесь вверх. Это поможет определить, является ли это системной ошибкой или нет.

Я видел, как некоторые системы используют перечисление на основе FW, которое появляется очень быстро, до настройки FPGA, и в этом случае нет цели PCIe для ID. Если вы часто обнаруживаете, что ваша FPGA не обнаруживается при включении питания, но обнаруживается при повторном сканировании, это может быть симптомом. Как решить эту проблему, немного сложно. В итоге мы использовали частичную реконфигурацию. Начните с интерфейса PCIe, затем выполните повторную настройку для загрузки оставшегося образа. Будем надеяться, что это не эта проблема

Следующее, о чем следует знать, — это ваш механизм сброса в FPGA. Вероятно, вы подключили сброс IP-адреса PCIe к сбросу шины, что здорово, однако в прошлом я также подключал этот сброс к внутренним сигналам блокировки PLL, которые могут быть недоступны. Для устранения неполадок сделайте этот сброс простым и избавьтесь от всего остального, чтобы показать, что в первую очередь надежен только IP-адрес PCIe сам по себе.

Вы также должны быть осторожны и здесь. Если вы удаляете вещи, убедитесь, что они чистые. Если вы игнорируете блокировку PLL и пытаетесь использовать драйвер Xilinx, такой как драйвер XDMA, у него есть процедура, в которой он пытается идентифицировать XDMA с транзакциями данных. Он ищет ПАНЕЛЬ DMA по одному столбцу за раз. Но когда это происходит, транзакция, которую он пытается выполнить, может прерваться на шине AXI, если ПАНЕЛЬ не является панелью управления XDMA. Если шина AXI не сброшена или не синхронизирована, когда это произойдет, вы заблокируете шину AXI, и я несколько раз блокировал окно Linux таким образом. AXI требует завершения транзакций, в противном случае он просто ждет.

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

Итак, пара вещей, на которые нужно обратить внимание.