Еще раз повторю. Поток тестировался БЕЗ AXI-interconnect и DDR, они были добавлено ТОЛЬКО ПОСЛЕ того, как проблема решилась и передача прошла успешна.
Был подключен и выход H2C на вход C2H – не заработало. Решили, что не работает H2C, поэтому сделали генерацию данных на ПЛИС и подключили к входу C2H – не заработало. Еще раз повторю, что были различные способы изоляции компонент.
Да, loop такой. Именно так и велась работа – поиска места, где все ломается. Да, что-то не так могло быть и с AXI-модулями. Все компоненты, на сколько возможно, изолировались и проверялись.
Сразу SG, потому что такой такой DMA предоставляет SGDMA-контроллер. Выбор либо он, либо 6-8 зашифрованных модулей из демопримера (ну или своя реализация и открытые DMA-модули, не завязанные на вендора).
Не знаю, как локализовать точнее, ведь система и так была сведена к минимальной конфигурации: PCIe-контроллер, SGDMA-контроллер и проверяющая логика (или сумматор). Первые два блока обязательны для любой передачи данных в принципе, а проверяющая логика была нужна, чтобы вообще увидеть эффект от передачи (и считывать некоторые сигналы). AXI Interconnect, оба AXI DMA-контроллера, DDR3-контроллер и сумматор, читающий из DDR3, появились в системе только после того, как была найдена и исправлена проблема с порядком байт.
LLM использовалась в контексте: агент GitHub Copilot, модель Gemini 3 Pro. Вопросы задавались не абстрактно, а с описанием конкретных сценариев и поведения системы (статусы регистров). В контекст агента также передавались документация Gowin IP и структура проекта. То есть агент видел весь проект. Например: запись в BAR2 и чтение из него работали корректно, но при попытке начать передачу данных возникало зависание, а в отдельных случаях — краш ПК. На основе всего этого агент делал вывод, что аппаратная часть в минимальной и корректно подключенной конфигурации, и предлагал гипотезы со стороны хоста.
До GAO проверялся запуск C2H без AXI-interconnect и без DDR – не заработал. Потом нашлась проблема с порядком байт и все компоненты вернулись. После исправлений C2H без AXI-interconnect не проверялась и работает в полноценной системе при передаче до 8 КБ данных.
Не совсем понятен вопрос про LLM. Она использовалась всегда, но полноценно проблему не смогла решить. Вопросы были и по демопроекту, и по SGDMA-контроллеру, и по драйверу. Также были вопросы "как там у Xilinx".
Да, проверяли. В начале ничего кроме PCIe-контроллера и сумматора не было. Потом и SGDMA-контроллер добавился, но основные проверки были без DDR и AXI4-компонент. Были и проверки только C2H-передачи, путем добавления генератора на ПЛИС. Только потом начался анализ с GAO. Постепенно область сужалась.
Из-за нехватки опытности было множество попыток поиска проблем и со стороны хоста: несколько раз менялись опции и функции в драйвере, порядок записи и чтения регистров в хост-программе.
Работа с SGDMA-контроллером заняла лишь 1/3 потраченного времени, до этого был только демопример с 5-8 зашифрованными модулями разбора TLP-пакетов и их адресации внутри ПЛИС. Не так просто изолировать и проверять их по отдельности. В добавок к этому была хост-программа с неочевидным пайплайном взаимодействия и в достаточно сыром виде, и никакой документации не было.
В том то и дело, что в документации IP ничего про порядок байт не говорится. А процесс поиска мест, где нужно использовать измененный порядок, занял большую часть времени.
Еще раз повторю. Поток тестировался БЕЗ AXI-interconnect и DDR, они были добавлено ТОЛЬКО ПОСЛЕ того, как проблема решилась и передача прошла успешна.
Был подключен и выход H2C на вход C2H – не заработало. Решили, что не работает H2C, поэтому сделали генерацию данных на ПЛИС и подключили к входу C2H – не заработало. Еще раз повторю, что были различные способы изоляции компонент.
Да, loop такой. Именно так и велась работа – поиска места, где все ломается. Да, что-то не так могло быть и с AXI-модулями. Все компоненты, на сколько возможно, изолировались и проверялись.
Сразу SG, потому что такой такой DMA предоставляет SGDMA-контроллер. Выбор либо он, либо 6-8 зашифрованных модулей из демопримера (ну или своя реализация и открытые DMA-модули, не завязанные на вендора).
Не знаю, как локализовать точнее, ведь система и так была сведена к минимальной конфигурации: PCIe-контроллер, SGDMA-контроллер и проверяющая логика (или сумматор). Первые два блока обязательны для любой передачи данных в принципе, а проверяющая логика была нужна, чтобы вообще увидеть эффект от передачи (и считывать некоторые сигналы). AXI Interconnect, оба AXI DMA-контроллера, DDR3-контроллер и сумматор, читающий из DDR3, появились в системе только после того, как была найдена и исправлена проблема с порядком байт.
LLM использовалась в контексте: агент GitHub Copilot, модель Gemini 3 Pro. Вопросы задавались не абстрактно, а с описанием конкретных сценариев и поведения системы (статусы регистров). В контекст агента также передавались документация Gowin IP и структура проекта. То есть агент видел весь проект. Например: запись в BAR2 и чтение из него работали корректно, но при попытке начать передачу данных возникало зависание, а в отдельных случаях — краш ПК. На основе всего этого агент делал вывод, что аппаратная часть в минимальной и корректно подключенной конфигурации, и предлагал гипотезы со стороны хоста.
До GAO проверялся запуск C2H без AXI-interconnect и без DDR – не заработал. Потом нашлась проблема с порядком байт и все компоненты вернулись. После исправлений C2H без AXI-interconnect не проверялась и работает в полноценной системе при передаче до 8 КБ данных.
Не совсем понятен вопрос про LLM. Она использовалась всегда, но полноценно проблему не смогла решить. Вопросы были и по демопроекту, и по SGDMA-контроллеру, и по драйверу. Также были вопросы "как там у Xilinx".
Да, проверяли. В начале ничего кроме PCIe-контроллера и сумматора не было. Потом и SGDMA-контроллер добавился, но основные проверки были без DDR и AXI4-компонент. Были и проверки только C2H-передачи, путем добавления генератора на ПЛИС. Только потом начался анализ с GAO. Постепенно область сужалась.
Из-за нехватки опытности было множество попыток поиска проблем и со стороны хоста: несколько раз менялись опции и функции в драйвере, порядок записи и чтения регистров в хост-программе.
Работа с SGDMA-контроллером заняла лишь 1/3 потраченного времени, до этого был только демопример с 5-8 зашифрованными модулями разбора TLP-пакетов и их адресации внутри ПЛИС. Не так просто изолировать и проверять их по отдельности. В добавок к этому была хост-программа с неочевидным пайплайном взаимодействия и в достаточно сыром виде, и никакой документации не было.
В том то и дело, что в документации IP ничего про порядок байт не говорится. А процесс поиска мест, где нужно использовать измененный порядок, занял большую часть времени.