Слона то я и не заметил...
Вот с прерыванием длинной 1 клок на мастер
tmp22_fifo01.rar ( 1.97 килобайт )
Кол-во скачиваний: 113Далее
Цитата
прерывания Вы не используете, в таком случае Вы создаете какой-то аналог сигнала waitrequest?
расшифруйте, что вы имели ввиду? Потому как мне кажется, что у вас неправильное понимание назначения waitrequest.
Потом
Цитата
.wrusedw (av_wr_counter), // wr counter
...
.rdusedw (fifo_rd_counter) // rd counter
Это счётчики заполнения/опустошения, тактируемые своими клоками (могу и ошибаться, что это именно
wr/rdusedw, потому как давно с альтерой плотно не работал, но камент специально поставил

). Смотрите где они используются.
Идём дальше
Цитата
Принцип контроля за заполнением кадра для меня пока не ясен
А принцип контроля со сторы хоста простой - так как бурста нет, тогда пишем по одному байту и читаем флаг container_full (хотя это и не обязательно и я думаю избыточно в принципе - можно же вычитать stat/cfg регистр с длинной фифошки и в проге на сях для ниоса это учесть (если не он конфигурил), ну или в своём самописном мастере (опять же если не он конфигурил) - ну и дальше гнать данные по одному трансферу согласно вычитанного кода длинны). Если несколько разных мастеров работают, тогда каждый на начале трансфера должен записывать свой параметр длинны и по окончании записи нужного количества байт ждать прерывания и отдавать слейв другому мастеру, ну а тот повторяет процедуру...
Ну и наконец
Цитата
что происходит, когда заполнился первый кадр
- авалоновская машинка передаёт строб начала работы машинке отгрузки наружу, по опустошению фифо машинка отгрузки наружу переходит в состояние ожидания нового сигнала начала работы. Ну и выставляется интерупт хосту - что фифо готово к новой работе.
Вроде всё.