Добрый день!
У меня в проекте есть xilinx ml605, microblaze, к нему elf ф-л и ddr, в котором хранится программа, куча и стек. Сейчас появилась задача уйти от DDR, вырезать его из MBZ и перенести elf, кучу и стек в BRAM. Программа в elf занимает 255 Кб. BRAM в MBZ доступно 128 кб. Оптимизируя и урезая программу сильно много места я не выиграю. Получается нужно увеличивать BRAM. Подскажите пожалуйста, возможно ли сделать BRAM = 512 Кб или около того? Если нет, то возможно есть какие то типовые решения данной проблемы? Если я чего то не правильно понимаю, пните в нужную сторону Спасибо всем!

ml605 -> XC6VLX240T -> 14976 Kb BRAM -> 1872KB. Возможно.
Надо в xps сконфигурировать компонент BRAM внешний, на шине (вот только не помню нет ли в нем ограничений).

К сожалению, ограничения есть. Не всю BRAM можно отвести под исполняемый код, а именно:
1. На шине памяти local memory bus (ILMB и DLMB) в XC6VLX240T можно адресовать не более 128 кБайт.
2. На шине AXI можно создавать BRAM-контроллеры в любом количестве.

Сегмент .text, .init, .fini можно располагать только в памяти на шине LMB.
Остальные сегменты можно располагать и в LMB, и в AXI.

Для Spartan-6 есть один замороченный метод, позволяющий увеличить размер LMB в два раза. Подозреваю, что и в Virtex можно сделать то же самое.
Если кому потребуется - изложу.

Думаю тут имеется ввиду код исполняемый непосредственно после старта, т.к. .text в DDR на AXI разместить можно.
Как вариант - в BRAM на LMB bootloader который грузит из внешнего флеша в BRAM на AXI и передает туда управление.
Bootloader у автора судя по всему есть, т.к. что-то в DDR программу ему грузит, только поменять DDR на BRAM.

Спасибо за ответы всем!
Я немного уточню задачу. Необходимо, чтобы при включении платы, автоматически загружался MBZ и с CompactFlash грузилась прошивка. Сейчас MBZ и *.elf устанавливаю через XSDK.
Так же, на данный момент, проект *.elf загружается в DDR, а нужно чтобы он грузился в BRAM. Можете одробнее описать алгоритм расширения BRAM? И у блока BRAM есть 2 выхода. Как этот блок прицепить на AXI правильно?

Как раскидать сегменты типа .text, .init итп, по шинам?

Автору необходимо уйти от использования DDR, следовательно, и bootloader как таковой не нужен. Т.е. имеющийся основной исполняемый файл грузится при включении платы. Его как-то нужно как-то разместить по BRAMs.


Предлагаю начать с добавления BRAM на AXI. BRAM-контроллер - это модуль, который позволяет присоединить BRAM-блоки к AXI. Для этого необходимо в EDK на вкладке IP-catalog дважды щелкнуть по AXI BRAM Controller. Далее устанавливаете его размер = 128 кБ на вкладке adresses. BRAM-блоки при этом присоединяться автоматически.
Ок?



Для начала хорошо посмотреть размеры секций Вашего ELF. Для это в SDK нужно дважды щелкнуть по .ELF-файлу.

Это уже 2 подход на моей памяти за этот год, где-то весной кто-то уже делал...
В спартане 6 для микроблайза под память программ и данных на брамах выделяют 64 кБайта, и все найденные способы это победить привели к тому что в итоге ничего не вышло (хотели без бутлоадера обойтись)

Единственное решение - это сделать проц с 64 кБайтами памяти, в которых будет загрузчик и что-то еще. А все остальные брамы собрать в один огромный массив и сделать из них память. Повесить ее на АКСИ шину, выделить адресное пространство и написать бутлоадер, точно также как в случае с ДДР. Прочие варианты с бубнами и без в итоге не заработали, а народ пару месяцев бился, даже какие-то файлы переписывали руками и пытались среду обмануть...

Таки нужен бутлоадер, и то не маленький - с CF грузить. А куда грузить - в DDR или BRAM на AXI на фоне обслуживания CF не имеет значения.

Можно в Spartan-6 расширить 64к в два раза.
Можно в Spartan-6 разместить все сегменты кроме .text, .init, .fini в дополнительных axi_bram_controllers.

Проверено. Работает.




У Автора есть CF??

Ну, так пишет :-)

Да. Проглядел. ))
Так тоже, наверное, можно сделать.

Но все-таки в случае 255 кБ можно и без CF обойтись.

И обойтись при этом без бутлоадера? Научите!
Можно для начала с того как 64К в 2 раза расширить. В среде 14.4 и младших вроде как ничего не вышло.

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

Кстати учитывая наличие CF так может даже проще, в основной памяти, той что легко и непринужденно грузиться сама разместить прожку которая подымает CF, проверяет и копирует образ с нее во "внешнюю память" (массив брамов) и передает туда управление. Это даже проще чем когда исходную прошивку вычитывают из загрузочной флэши ПЛИС...

1. Добавить новые BRAM-controllers на шины LMB (а не на AXI).
2. Generate bitstream. Отредактировать system_bd.bmm: добавить ADDRESS_RANGEs, как написано в UG658 в гл. Combined address spaces.
3. Export to SKD. Заменить в linker script два bram-контроллера на один контроллер двойного размера. Расположить в нем все сегменты elf. ProgramFPGA. Enjoy.
4. Зафиксировать в UCF расположение BRAM, чтобы не приходилось всякий раз редактировать BMM. Хотя вообще говоря, редактирование BMM-файла - при использовании totalcmd в буквальном смысле 5 секунд.

Это, конечно, интересная мысль использовать BRAMs в качестве "внешней памяти". Особенно, когда много BRAMs, и они не нужны .

и можно кеш выключить и его брамы тоже туда отправить, доступ то наибыстрейший

надо будет попробовать по рецепту собрать контроллер с 2 брамами. А также с 4 можно собрать? Ведь с 2 можно, че с 4 нельзя?

В смысле "кеш выключить"? Он и не мог бы быть включен при отсутствии DDR.



Больше чем с 2-мя в Спартане не работает. Проверял.

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

Какой тогда смысл от axi bram, если основной листинг программы лежит в text?
Спасибо.

.text можно на AXI, но процессор туда сам не пойдет - надо его носом ткнуть. И сделать это должна программа .text которой находится на LMB - как правило бутлоадер.

Ок. Действительно кеш в процессоре включить можно. Правда, если запустить Base System Builder, то при отсутствии внешней памяти кеш недоступен (ну это ладно).
Тогда вопрос возникает, стоит ли делать кеш в случае, если BRAMs используются как внешняя память?

Может помочь, т.к. транзакция AXI достаточно "дорогая", чтоб прочитать одно слово надо делать дополнительные телодвижения.
Из более экзотических примеров - если шина интенсивно используется для DMA и процессор имеет низкий приоритет - кеш тоже поможет.

все же БРАМ через АКСи сильно быстрее ДДР (как мне показалось), так что можно кеш сделать минимальным. Вот прога в ДДР без кеша - ваше стоит, а тут может и поедет

Спасибо за советы!
Все работает) Единственное, столкнулся с проблемой, что блок .text не влазит ни в один раздел полностью. Его размер около 153 кб, а максимальный размер одного раздела BRAM можно сделать до 128кб. Оптимизировать код почти на 30кб, это довольно трудоёмкая задача. Есть ли возможность разделить блок .text на 2 блока AXI BRAM или формировать 2 раздела *.text и раскидывать их по разным AXI BRAM?

Вы booloader сделали?

судя по тому что хотят секцию текст затолкать в 128 Кбайт, то - нет

П.С. дебуг инфу отключите, и printff, сразу станет легче секция...

Дебаг отключил. Пока блок текста весит 175 кб. Проблема в том, что у меня используется в проекте управление через консоль. простое вычленение printf не спасёт, потому что используются библиотеки stdio и stdargs. Они сами по себе довольно жирные. Наверняка ведь есть какие то технологии хранения блока .text в разных адресных пространствах.

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