SG-DMA в режиме Stream To Memoy Опции

[Acvarif]

Есть необходимость перегружать кучу байт из пользовательской двухпортовой памяти в SDRAM+NIOS. Для этой цели в пользовательсой логике имеются импульсы периодом ~ 100 нс по фронтам которых предполагается организовать пересылку данных (16 бит) в SDRAM. Далее все компонуется и по Ethernet должно идти далее в комп.
Для этого попытался сворганить в SOPC SG-DMA (Stream To Memory) + Avalon Straming Source. Получил непонятные ошибки. Разрядность нин в SG-DMA и Avalon Straming Source поставил 16 бит.

Подскажите пожалуйста как правильно. Пробовал по разному (менял оличество бит источника приемника и др.) Не получается. Помог бы простой пример реализации в SOPC подобной схемы.
Нужен ли для этой цели еще и FIFO? Или можно будет обойтись только Avalon Straming Source+пользовательская логика полагаясь на внутреннюю FIFO SG-DMA?

[gosu-art]

Вот созданные дескрипторы до вызова alt_avalon_sgdma_do_async_transfer(брейкпойнт ща на нем).

Жмем "Resume" и все работает. alt_avalon_sgdma_do_async_transfer вызывается 1 раз

Теперь перезапускаю систему(в том числе конфигурирую плис) убираю брэйк с async_transfer и ставлю на передаче пакета. После нее, собственно (256 байт), и должен заводится SGDMA_RX.
Выполняю функцию:

Вроде все норм - 256 байт принял.

После этого снова посылаю пакет 256 байт, но теперь он должен обработаться, по идее, другим дескриптором.
Оправляю...


И ничего, SGDMA завис больше он работать не будет. Сигнал READY не выставляется, еще к тому же левый адрес выставился 0х00011200 а должен быть 0х00011000, но похоже это от предыдущей транзакции.

Может выравнивать чего нужно?

[alexPec]

Первое что в голову приходит - а почему размер-то передаваемых данных выставлен в ноль (bytes to transfer)?
Может из-за нулевого размера не тормозится трансфер и заезжает на область памяти, где переменные какие-нибудь лежат? Косвенно это подтверждается тем что адрес после трансфера меняется - не должно быть. Попробуйте размер корректный выставить. По вашей картинке значение должно лежать по моему в адресе 0x13818-0x1381B (для первого дескриптора). Дальше думать будем если не пойдет...

[gosu-art]

Первое что в голову приходит - а почему размер-то передаваемых данных выставлен в ноль (bytes to transfer)?
Может из-за нулевого размера не тормозится трансфер и заезжает на область памяти, где переменные какие-нибудь лежат? Косвенно это подтверждается тем что адрес после трансфера меняется - не должно быть. Попробуйте размер корректный выставить. По вашей картинке значение должно лежать по моему в адресе 0x13818-0x1381B (для первого дескриптора). Дальше думать будем если не пойдет...

Красным я выделил невыполнившийся дескриптор. а ниже со значением 0х100808(запуск начинается с него) это как раз предыдущий, тут все нормально. Что касается с заежанием на область памяти, то я специально сделал отдельную двухпортовую память. Одна сторона SGDMA вторая проц. Даже если превыситься размер буфера, то будет крутится внутри этого порта, только данные испортятся.
Но похоже он next дескиптор не прогружает т.к. сигнал READY не выставляется.
вот как должно быть, это когда с брэйкпойнтом:

Запись начинается с 0x11100. +256 в конце получаем 0х11200. ready находится в неактивном состоянии (прогружается дескриптор, я так понял) и потом поднимается обратно уже с необходимым следующим адресом 0х11000. Вот так все работает.
Сейчас же если не ставить брэйк то выполнятся 1 дескриптор который вызываю через do_async и на этом все и заканчивается. READY больше не активен после передачи.
Попробую еще в QSYSe собраться 12,1 Ща пока в SOPC работаю 11,1