Спецы, поясните суть процесса, представленного на рисунке. Почему чтение (см. datavalid) идет с такими большими промежутками?
система - Avalon-MM Master - clock crossing bridge - on-chip memory.
Если исключить clock crossing bridge (он добавлен для тестирования, так будет в реальной системе с DDR), то чтение идет непрервыно (оно и понятно...)

Если чтение из DDR, то нормально.

Не, не нормально. Ведь чтение идет по последовательным адресам. Если вместо clock crossing bridge поставить pipeline bridge, то все выглядит вполне нормально. Проблемы именно с clock crossing bridge

Для того чтобы читать по последовательным, там кажись нужно говорить что вы burst хотите. /* я мало читал про авалон */

Burst - это другое - там вроде как подаешь начальный адрес, указываешь длину пакета burstcount и он выдает данные. Увы, результат совершенно тот же...

Ну да. Вы указываете адрес. Указываете длинну пакета. Говорите "читать", и через некоторое (значительное) вы начинаете получать данные, причем уже с большой скоростью.

Дык в том и дело, что, как и видно из картинки, нихрена подобного не происходит (у меня не burst, а pipeline transfer, но это без разницы) - данные идут не пакетом, а побайтно с бооольшим промежутком...

На шине есть еще какой-нибудь мастер, подключенный к данному слэйву?

Нет, на данный момент никого больше на шине нет.
Вот, собственно, сам проект. Сейчас там в SOPC стоит pipeline brige (32 бита) и он-чип память (16 бит). Поглядите в симуляторе - все выглядит как и положено.
Добавьте clock crossing bridge - сразу будет что-то ужасное...

А у клок кроссинг бриджа есть режим пайплайн ? (Дома у меня квартуса нету)
А если есть, то включен ли он ?

А какая тактовая у самой памяти ?
Нет ничего удивительного, что clock crossing bridge работает с большой задержкой. Он теряет много тактов на ресинхронизацию данных между двумя тактовыми частотами, сначал адрес туда, потом данные оттуда. Но почему он не читает потоком, я сам не понимаю.

Вариант решения - собственная функция ресинхронизации. Могу выслать завтра.

У waitrequest на диаграмме активный уровень какой?
Если 0, по почему после того, как он ушел (в районе адреса 0x028) вы не убрали запрос на чтение? Хотите читать дальше? И почему адресом болтали все это время?
Если 1, то вы успели набросать десяток запросов, прежде чем пришел waitrequest, и 11 до datavalid. В мосте буфер большой?
Может у вас слишком большая разница частот в обоих доменах?

Моделируйте ХДЛ.

waitrequest - активный высокий (запрос ожидания). Поэтому адрес меняется пока не выставлен сигнал ожидания. Буфер там достаточный...
Ошибка там в системе SOPC - мостом разделяю тактовые, а для памяти тактовую задал неправильно (не совпадает с мостом). Поправил - вижу болееменее нормальный результат.

Теперь что касается сигнала чтения. Он выставляется независимо от waitrequest, а зависит от требований моего устройства. В устройстве стоит ФИФО, когда оно незаполнено - выставляется сигнал чтения, фактически это запрос чтения. Когда буфер заполняется, сигнал снимается. Чтобы сигнал чтения не мешал работать всем остальным мастерам на шине, уровни заполненности ФИФО, при которых он устанавливается и сбрасывается - разные...
А чё, надо сигнал чтения снимать, когда waitrequest = 1?

Ни в коем случае ! Того, кто вам это советует надо засадить читать спецификацию шины авалон ! Даже не читать - картинки смотреть!

Блин, проблема за проблемой . Теперь еще данные 32 бит надо в 24 бит преобразовавыть...