MicroBlaz + DDR3 + AXI

[zuuuuk 0]

добрый день.

я использую сартет кид.

http://www.xilinx.com/products/boards-and-...6NITX-LX75T.htm

я собрал в едк проект и подключил microblaz + ddr3 + bram. На AXi.

bram внутренняя..

Использовал при этом только визард.

 

при обращении , через xmd, к внутр. памяти все нормально. пишет читает.

но вот при обращении к ddr3 проц зависает.

 

http://s019.radikal.ru/i604/1304/fb/ee312c51e5e3.jpg

 

нужно ли инициализировать сам MCB?

Подскажите в каком направлении копать?

 

благодарю за внимание.

[Golikov 0]

Вот прям пару недель назад решал подобную задачу.

 

я подключал так. Обычная шина у меня идет на АХИ-лайт, ДДР я повесил на шину с кешем, обязательным условием чтобы это все работало в таком раскладе необходимо поставить галки всегда использовать кэш для данного адресного пространства. Замечу что это не означает что память будет кешироватся, это означает только то что когда проц обращается в адресное пространство ДДР он будет использовать кешированную шину. Включение - отключение кеша отдельная процедура.

 

Все дальше синтез, и все работает. Тесты памяти и прочее...

 

судя по вашей картинки вы тоже подключаете кэш, и адрес кешируемый я так понимаю как раз адрес ДДР, но тогда на него должна идти не обычная шина а та что с буковкой C, кэшированная... От того у вас и повисает, что проц ломиться в это адресное пространство по другой шине.

[rsv2007 0]

Инициализировать ничего не надо. Отлаживаться проще в sdk, при помощи стандартного проекта hello world с stdio через mdm. Сначала сложить все в брамку, проверить на работоспособность. Потом сложить в ddr. Если все хорошо, то будет работать также как и из брамки. Если все плохо, то возможно два варианта:

1. Программа тупо не грузится и sdk виснет - ддрка не прошла все стадии калибровки и повисла где-то посередине.

2. Программа грузится, но в итоге sdk говорит что elfcheck failed.

Оба бага носят аппаратный характер. Первый вариант - что-то напутано в ucf, таиминги там, распиновка. Там много сто напутать можно. Второй вариант - совсем хардварный. Типа плохого контакта модуля sodimm, был такой вариант в моей практике.

Дебажить согласно документации на mig, те довольно муторно. Через кореген создаем ip ядро контроллера ddr, в структуре папок ip ядра находим example design. Правим его согласно своим потребностям ( как минимум клоки, ucf и вытаскивать нужные сигналы на чипскоп - calib done и error). Запускаем и смотрим что и где валится. Если на калибровке - смотрим стадию, читаем даташит, действуем по ситуации. Если на записи-чтении тестовых паттернов - пытаемся играть паттернами и адресами чтобы обнаружить где не работает. Но перво-наперво проверить ucf и свой дизайн. Не забыли ли сгенерировать адрес ддр, все ли нужные клоки подключены ( там, кроме шинного, еще куча нужна: половинная частота, сдвинутая на 90 градусов, 200 мгц)

[zuuuuk 0]

судя по вашей картинки вы тоже подключаете кэш, и адрес кешируемый я так понимаю как раз адрес ДДР, но тогда на него должна идти не обычная шина а та что с буковкой C, кэшированная... От того у вас и повисает, что проц ломиться в это адресное пространство по другой шине.

 

дело в том, что я использовал визард при подключении ddr3 И axi.

 

вопрос:

*Неужели визард неправильно подключил ddr + microblaz?

*Я так понимаю надо настраивать Axi шину, что бы она стала кешированной?

[Golikov 0]

не совсем так.

 

У микроблайза выходит 3 шины

внутренняя идет в брам, по умолчанию по ней идет программа

дальше шина выходящая наружу Шина данных и инструкций M_AXI_DP и M_AXI_IP

дальше вторая выходящая кешированная шина данных и инструкций M_AXI_DC и M_AXI_IC

 

Эти шины идут через все адреса памяти, но! если вы объявляете какой либо пространство кешируемым, то обращение в него пойдет через DC и IC. Там есть некоторый нюанс с битами использовать кэш или нет, то есть можно сделать так что в кешируемое пространство вы залезете по обычной шине, но по умолчанию в обычное пространтсво - обычная шина, в кешируемое - кешевая шина.

 

 

Дальше на какую шину визард повесил память не знаю, думаю по умолчанию на обычную, А вы включив кешировать пространство памяти заставляете проц видя обращения в это пространство использовать кешированную шину, на которой нет вашего ДДР. Думаю как то так.

 

 

Попробуйте пойти по более легкому и стабильному пути, использовать platform studio для создания процессора, и SDK для проверки.

 

 

Да еще вспомнил, в контроллере DDR можно выбирать ножку для ZIO и для RZQ сигналов DDR, проверьте что там выбраны верные ножки. те к которым физически подрублена память

 

[zuuuuk 0]

не совсем так.

 

У микроблайза выходит 3 шины

внутренняя идет в брам, по умолчанию по ней идет программа

дальше шина выходящая наружу Шина данных и инструкций M_AXI_DP и M_AXI_IP

дальше вторая выходящая кешированная шина данных и инструкций M_AXI_DC и M_AXI_IC

 

Я проверил подключение еще раз:

http://i047.radikal.ru/1304/ff/00fc8bf74a55.jpg

 

Адресация

ну и генерация ddr3

http://s16.radikal.ru/i190/1304/ed/1bd34d140ee7.jpg

http://s019.radikal.ru/i609/1304/f5/506ec30b0b40.jpg

http://s019.radikal.ru/i605/1304/f4/7d3043a5393c.jpg

http://i020.radikal.ru/1304/86/d5645a70e3d4.jpg

http://s43.radikal.ru/i101/1304/c4/9c193c56bbf6.jpg

http://s54.radikal.ru/i143/1304/77/0de05f757f31.jpg

 

Пин RZQ подтянут к земле через резистор.

Фаил .ucf я проверил.

 

Вот где я могу здесь ошибаться?

 

 

[rsv2007 0]

Настроен ли микроблейз на кеширование адресного пространства ddr? Это в настройках микроблейза смотреть надо

[Golikov 0]

еще надо поглядеть есть ли клоки на ддр

ему надо клок шины (хорошо бы чтобы 100 МГц)

и общий клок мегагерц на 600, и еще такой же но сдвинутый на 180 градусов.

 

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

 

ну и в настройках проца как вам сказали поставить галочку использовать кэш данных и кэш инструкций, это 3-4 закладка в адванцед моде

 

 

[Last_point 0]

у меня была такая проблема, решилась при помощи указания расположения PLL в system.ucf

 

INST "clock_generator_0/clock_generator_0/PLL0_INST/Using_PLL_ADV.PLL_ADV_inst" LOC = "PLL_ADV_X0Y2";

 

[zuuuuk 0]

Я всех благодарю за помощь.

 

Я разобрался...

Проблема была в том, что в генераторе .bit файла стояли настройки PUL UP

Нужно было поставить флоат.

 

Свойства ген файла->конфигурация-> пин IO -> флоат

 

 

[xor.kruger 0]

Только что сам столкнулся с подобной проблемой как и zuuuuk. Действительно, проблема была в настройках не подключенных пинов.

Т.к. у меня Top-level был в EDK, то все решилось строкой

-g UnusedPin:PullNone

в файле bitgen.ut, которая переводит пины в высокоимпедансное состояние.

[ilyge 0]

Я всех благодарю за помощь.

 

Я разобрался...

Проблема была в том, что в генераторе .bit файла стояли настройки PUL UP

Нужно было поставить флоат.

 

Свойства ген файла->конфигурация-> пин IO -> флоат

 

Это не должно влиять на работу DDR. Скорее всего забыли в TOP вынести какой-то сигнал управления.

Советую проверить вначале работу DDR через JTAG, используя MIG. Заодно и UCF разберетесь.

[xor.kruger 0]

Это не должно влиять на работу DDR. Скорее всего забыли в TOP вынести какой-то сигнал управления.

Советую проверить вначале работу DDR через JTAG, используя MIG. Заодно и UCF разберетесь.

Ничего подобного!!! На самом деле очень распространенная ошибка, в поддержке ксайлинкса советуют всегда применять данную опцию. В моем случае когда топ-level был в EDK данная проблема все равно всплыла и решилась именно через UnusedPin:PullNone.

Если бы какой-то сигнал не был заведен в ТОПе, то ошибки были бы еще на этапе синтеза, а если проблема в LOC'ах, то при имплементации были бы сообщения о сбитых времянках, так что Ваши советы здесь абсолютно не уместны!

[ilyge 0]

AVNET: MIG parameters for SP6 LX75T.

 

"The issue with running your MIG-generated design may be a BOARD-LEVEL ISSUE. The errata for this board (posted on the DRC) describes a known problem with the DDR3 interface and the default bitgen settings. By default the bitgen settings for any XPS project attach pulldowns to any unused signals on the FPGA. This breaks the FPGA designs using the MCBs. To fix this, change the bitgen settings to allow unused pins to float. Add this line to the bitgen settings file (bitgen.ut) of your project:

 

-g UnusedPin: Pullnone (remove the space between the ':' and 'P')

 

This should fix the problem."

 

Xor.kruger, да... это очень распространенная ошибка :)