[xor.kruger 0]

а я чет бился бился, 64 и все... надо будет ручками потом покрутить,

Я в старых версиях EDK и SDK раньше долго боролся с проблемами которые связаны с генерацией файлов автоматически (тобиж индусскими скриптами). Сейчас использую 14.6 - но проблемы еще есть. Там где можно описать файлы самому ручками - пытаюсь описывать :) У Вас какая версия?

[aabmail 0]

У меня сегодня получилось в EDK14.5:

1. Для Спартан-6 добавить 3 брам-контроллера, каждый максимум на 64 кБайт. Больше не дает.

2. Для Кинтекс-7 добавить много брам контроллеров, каждый максимум на 128 кБайт. Больше не дает.

 

При этом в линкер-скрипте можно объединять брам-контроллеры в общую память и размещать в ней сегменты elf-файла как угодно. Поэтому, как я понял, нет смысла пытаться увеличивать память в одном брам-контроллере.

Привожу пример с объединением двух контроллеров в линкер-скрипте.

MEMORY
{
   microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x0001FFB0
   /*axi_bram_ctrl_0_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00020000
   axi_bram_ctrl_1_S_AXI_BASEADDR : ORIGIN = 0x41440000, LENGTH = 0x00020000
   axi_bram_ctrl_2_S_AXI_BASEADDR : ORIGIN = 0x41460000, LENGTH = 0x00020000*/
   axi_bram_ctrl_a_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00060000
}

[Golikov 0]

у меня 14.4 ваще... я не модный:)... вот потому наверное и упираюсь в 64 К.

 

про объединение в линкере, у вас 3 области которая идет одна за другой.

 

А когда вы просите какую-то секцию положить в область, вы ей какое имя секции указываете?

 

получится что все секции надо руками раскладывать, а большая все равно не влезет?

[_4afc_ 26]

про объединение в линкере, у вас 3 области которая идет одна за другой.

А когда вы просите какую-то секцию положить в область, вы ей какое имя секции указываете?

получится что все секции надо руками раскладывать, а большая все равно не влезет?

 

Насколько я понимаю секции могут быть в axi_bram_ctrl_a_S_AXI_BASEADDR длиной 0x00060000.

 

А что за проблема с раскладыванием руками? Мне в проекте где есть DDR постоянно приходится все секции после визарда

перекидывать из DDR в BRAM.

 

[aabmail 0]

у меня 14.4 ваще... я не модный:)... вот потому наверное и упираюсь в 64 К.

 

про объединение в линкере, у вас 3 области которая идет одна за другой.

 

А когда вы просите какую-то секцию положить в область, вы ей какое имя секции указываете?

 

получится что все секции надо руками раскладывать, а большая все равно не влезет?

 

В качестве ответа прикладываю линкер-скрипт целиком.

В общем случае для всех сегментов elf-файла нужно указать один и тот же memory region.

lscript________.txt

[xor.kruger 0]

у меня 14.4 ваще... я не модный... вот потому наверное и упираюсь в 64 К.

Размер брамки зависит реально не от версии ISE/EDK и скриптов которые чекают размер перед этапом синтеза (EDK), а от самого кристалла (как в нем расположена памяти) потому что имеется проблема обеспечить одинаковое время доступа ко всем регионам.

На Virtex6 (xc6vlx240t) максимальный размер блочной памяти подключаемый к брам контроллеру составляет 256 K.

[Golikov 0]

В качестве ответа прикладываю линкер-скрипт целиком.

В общем случае для всех сегментов elf-файла нужно указать один и тот же memory region.

 

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

[aabmail 0]

Уважаемые коллеги!

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

ELF хоть и создается, elfcheck хоть и проходит, а вот data2mem ругается ((.

 

Так что тема использования дополнительных BRAM по-прежнему актуальна.

 

Привожу пример с объединением двух контроллеров в линкер-скрипте.

MEMORY
{
   microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x0001FFB0
   /*axi_bram_ctrl_0_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00020000
   axi_bram_ctrl_1_S_AXI_BASEADDR : ORIGIN = 0x41440000, LENGTH = 0x00020000
   axi_bram_ctrl_2_S_AXI_BASEADDR : ORIGIN = 0x41460000, LENGTH = 0x00020000*/
   axi_bram_ctrl_a_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00060000
}

 

[misyachniy 0]

У меня есть схожий вопрос, задам здесь.

Текст программы рос, рос и вырос.

Теперь не помещается в сегмент ".text".

Попробовал все сегменты перегнать в отдельный контроллер BRAM.

Все равно, не достаточно места.

Порезал "ненужные" функции, программа работает со сбоями.

Есть подозрение, что стек наползает на код или данные.

 

Каким образом перекинуть часть функций из секции ".text"?

Может еще какие либо секции программ разместить в основном контроллере BRAM?

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

[aabmail 0]

Я бы посоветовал следующее:

 

1. Создать еще хотя бы один брам-контроллер (Если, конечно, есть "лишние" BRAMы). Разместить в нем .stack и .heap.

2. Увеличить размер стека. Скорее всего из-за этого и сбоит прграмма.

3. Секции .init и .fini также разместить в _d_bram_ctrl.

 

У меня есть схожий вопрос, задам здесь.

Текст программы рос, рос и вырос.

Теперь не помещается в сегмент ".text".

Попробовал все сегменты перегнать в отдельный контроллер BRAM.

Все равно, не достаточно места.

Порезал "ненужные" функции, программа работает со сбоями.

Есть подозрение, что стек наползает на код или данные.

 

Каким образом перекинуть часть функций из секции ".text"?

Может еще какие либо секции программ разместить в основном контроллере BRAM?

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

 

[misyachniy 0]

Я бы посоветовал следующее:

 

1. Создать еще хотя бы один брам-контроллер (Если, конечно, есть "лишние" BRAMы). Разместить в нем .stack и .heap.

2. Увеличить размер стека. Скорее всего из-за этого и сбоит прграмма.

3. Секции .init и .fini также разместить в _d_bram_ctrl.

 

 

В том то и вопрос, что секция ".text" больше чем 64К.

Код нужно разделить на две части.

Я то догадываюсь, что нужно директива pragma, но не нашел конкретного ответа.

Пробовал d_bram_ctrl объявить побольше, но для Spartan6 размер для одного контроллера ограничен в 64К

[aabmail 0]

Выделить более 64 кБайт для программы microBlaze возможно. Чтобы это сделать, нужно

 

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.

 

 

 

[pepelats 0]

Здравствуйте,

 

Скажете, сколько может весить самая простая программа для Microblaze в релизе и с оптимизацией. Например программа уровня Hello World. Схема при этом самая минимальная.

У меня получается ~14 кбайт. Это нормально? Можно как то уменьшить эти показатели?

[Golikov 0]

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

Если вы напишите программу, которая положит данные в буфер UART сама, то будет значительно меньше.

А с библиотеками это нормально...

 

П.С. В большинстве драйверов от ксалинкс по умолчанию отладка идет через pritf и им подобные, так что проверяйти их исходники, благо они доступны. И еще есть функция xil_printf или как то так, она не подтягивает за собой полную библиотеку, с ней программа поменьше...

[pepelats 0]

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

Если вы напишите программу, которая положит данные в буфер UART сама, то будет значительно меньше.

А с библиотеками это нормально...

 

П.С. В большинстве драйверов от ксалинкс по умолчанию отладка идет через pritf и им подобные, так что проверяйти их исходники, благо они доступны. И еще есть функция xil_printf или как то так, она не подтягивает за собой полную библиотеку, с ней программа поменьше...

 

да, забыл указать что не использую при этом printf и даже xil_printf. Использую print который вообще вроде как занимает копейки по сравнению с printf.

 

Function Size Limitations
-------------- ------- ------------------
printf() 51788 None, full featured
iprintf() 18294 No floating point, reentrant
xil_printf() 2953 No floating point, not reentrant(single thread only), no longlong(64 bit)
putnum() 284 Integer to HEX only, no other formats
print() 185 No numbers output, just strings

All of these functions can be prototyped by including <stdio.h>.

 

Программа Hello World создается из визарда в SDK. И выглядит так:

 

#include <stdio.h>
#include "platform.h"

void print(char *str);

int main()
{
    init_platform();

    print("Hello World\n\r");

    return 0;
}

 

и вот это у меня вытягивает на 14 кбайт