[torik 0]

Всем привет.

Вот тут я тему про SOPC Builder разводил:

http://electronix.ru/forum/index.php?showtopic=39521

 

Теперь у меня возникла следующая проблема:

Также система состоит из памяти SDRAM и самодельного мастерпорта. Записываю пакетом по несколько байт. Все проходит хорошо, waitrequest только в начале на пару тактов устанавливается, затем больше не встревает - вобщем запись потоком, что и необходимо.

 

Но вот при чтении возникает проблема - waitrequest перед прочтением каждого байта устанавливается на много тактов (9). Но в даташите на компонент билдера типа "сдрам память" написано, что при чтении последовательных адресов чтение идет потоком (ну не считаем издержки). Почему же это не так?

 

Собственно еще одна проблема, которая может быть связана как-то:

память 4Мх16, т.е. по идее 22 разряда на шину адреса. Но памяти в билдере присваивается адрес от 000000h до 7F0000h, что соответствует 23-ем разрядам адреса. Ну и при чтении соответсвенно младший разряд игнорируется, приходится увеличивать адрес на 2. Почему так, неужели билдер предполагает использование сигналов ByteEnable?

 

 

Напоследок прилагаю сделанный мной "перевод", может пригодиться кому-то еще более ленивому чем я.

SOPC_Builder.rar

[Postoroniy_V 0]

Всем привет.

.......Почему же это не так?

 

Собственно еще одна проблема, которая может быть связана как-то:

память 4Мх16, т.е. по идее 22 разряда на шину адреса. Но памяти в билдере присваивается адрес от 000000h до 7F0000h, что соответствует 23-ем разрядам адреса. Ну и при чтении соответсвенно младший разряд игнорируется, приходится увеличивать адрес на 2. Почему так, неужели билдер предполагает использование сигналов ByteEnable?

000000h до 7F0000h 8 метров, что так и есть = 4Мх16

на 2 увеличивать потому что предполагается что Вы читаете по 16 бит за 1 обращение

тоесть 0 и 1 байты соответствуют 0 адресу при организации 4Мх16, если бы было 4Мх32 нужно было бы прибавлять 4 :)

byteenable играет свою рояль при записи, когда вы планируте записать скажем 1 байт, а 0-вой байт не хотите трогать, тогда и нужно byteenable дёргать. тогда

byteenable =2'b10; при организации 4Мх16,

а для 4Мх32 byteenable =4'b0010;

а вот почему

Но вот при чтении возникает проблема - waitrequest перед прочтением каждого байта устанавливается на много тактов (9).

видимо потому что Вы читаете по 1 байту :) , 9 тактов видимо получается из 3 такта на ras 3 такта на cas и 3 такта на "получите результат чтения" :)

[torik 0]

Благодарю, с байтами все ясно...

 

Остается вопрос о пакетном чтении. Что значит "читаю по одному байту"?

Я же устанавливаю read_n и не сбрасываю после прочтения каждого байта, т.е. все-таки пакетное чтение. Что тут можно поглядеть, как искать причину?

 

Не может ли причиной быть то, что сама память тактируется от 100 МГц, а контроллер - 50 МГц?

[Postoroniy_V 0]

Благодарю, с байтами все ясно...

 

......Не может ли причиной быть то, что сама память тактируется от 100 МГц, а контроллер - 50 МГц?

ууууу.....50->100 :07:

зачем Вы так? :) смысл?

запустите всё на 50 тогда уж :)

[torik 0]

Потому, это потому, вот...так получилось

Дык это может быть причиной?

[torik 0]

Ё-мое, выручайте!

Запустил все на 50 МГц - толку нет, картина не поменялась. Чтение идет побайтно :(

 

Что же не так я делаю?

[torik 0]

Значит такие дела: попробовал я вместо SDRAM просто on-chip память, результат, к сожалению тот же, только задержка меньше.

Диаграммы записи из сигналтаба в одном файле, чтение - в другом.

Может неправильно импульсы управления формирую?

 

write_n, read_n - сигналы записи/чтения на мастерпорт от внешней логики

waitrequest - сигнал запроса ожидания от мастерпорта

fifo_q - то что идет на writedata мастерпорта от внешней логики (с фифа)

address_0 - адрес куда записывать мастерпорту

read_data - данные от порта...

[Postoroniy_V 0]

Значит такие дела: попробовал я вместо SDRAM просто on-chip память, результат, к сожалению тот же, только задержка меньше.

Диаграммы записи из сигналтаба в одном файле, чтение - в другом.

Может неправильно импульсы управления формирую?

 

write_n, read_n - сигналы записи/чтения на мастерпорт от внешней логики

waitrequest - сигнал запроса ожидания от мастерпорта

fifo_q - то что идет на writedata мастерпорта от внешней логики (с фифа)

address_0 - адрес куда записывать мастерпорту

read_data - данные от порта...

тактовая на картинках где?

[torik 0]

Тактовая 50 МГц, она же строб для сигналтаба.

[Postoroniy_V 0]

Тактовая 50 МГц, она же строб для сигналтаба.

:07: а как вы собираетесь отследить измения сигналов при той же тактовой?

сигнал тап показывает х.з. что :(

[torik 0]

Что, мне стробировать с частотой, к примеру 150 МГц?

[torik 0]

Вот картинка чтения из on-chip памяти, полученная в результате функционального анализа.

CLOCK_50_f - тактовая частота.

Получается что waitrequest сразу же устанавливается независимо от того поледовательные адреса или нет...

Может как-то надо указать что необходимо пакетное чтение, как он определит что адреса идут последовательно?

[vetal 0]

Может как-то надо указать что необходимо пакетное чтение,

Сигнал burstcount или настроить арбитраж соответствующим образом на длину пакета.

[torik 0]

Я тут в документации на Avalon-MM вычитал фразу:

"Using the one-bit input signal readdatavalid defines a master port to be pipelined."

 

Я добавил сигнал readdatavalid, просто поглядеть на него и сразу получил пакетное чтение, картинку прилагаю. readdatavalid как бы заменяет waitrequest.

Утверждать пока рано, позже погляжу на железе, т.к. SDRAM не просимулировать... А арбитраж - зачем он мне, у меня один мастер, burstcount тоже вроде не приче (могу ошибиться).

 

 

 

Итак, результат на железе при чтении SDRAM выкладываю ввиде картинки.

Т.е. добавление сигнала datavalid решает проблему...

 

Теперь вернемся к тактовой частоте сигналтаба.

Postoroniy_V, вы говорите:

а как вы собираетесь отследить измения сигналов при той же тактовой?

сигнал тап показывает х.з. что

Вот в данном случае частота 50 МГц является тактовой как для мастерпорта, так и для сигналтаба. А какой смысл делать другую частоту, ведь анализируемые сигналы меня интересуют лишь на фронте. А при повышении частоты мы получим подобие временного анализа.

 

Поправьте меня, если я что-то не правильно говорю.

 

Тему не закрываю, мало ли еще какие проблемы вылезут :07: