Jump to content

    
Sign in to follow this  

Recommended Posts

добрый день.

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

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

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

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

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

 

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

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

ee312c51e5e3.jpg

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

Инициализировать ничего не надо. Отлаживаться проще в 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 мгц)

Share this post


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

 

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

 

вопрос:

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

 

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

 

 

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

 

 

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

 

 

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

 

Share this post


Link to post
Share on other sites
не совсем так.

 

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

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

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

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

 

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

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

a33eb5e8503at.jpg

 

Адресация

c68d65686e44.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 я проверил.

 

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

 

 

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

 

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

 

Share this post


Link to post
Share on other sites

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

 

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

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

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

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

-g UnusedPin:PullNone

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

Share this post


Link to post
Share on other sites
Я всех благодарю за помощь.

 

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

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

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

 

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

 

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

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

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, да... это очень распространенная ошибка :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this