периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку, ошибки частенько разные Опции

[Krys]

Здравствуйте. Периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку и не запускается. При том это начинается на пустом месте, ни с того ни с сего. Уже 2й раз заловил. Потом мучился-мучился, как-то заработало. Работало-работало, потом перестала. Чото делал-делал, один раз заработало, потом опять не работало...
При этом DEBUG AS работает нормально.
Программа у меня целиком в DDR, и данные, и код. Вот линкер скрипт:

CODE

/*******************************************************************/
/* */
/* This file is automatically generated by linker script generator.*/
/* */
/* Version: Xilinx EDK 14.7 EDK_P.20131013 */
/* */
/* Copyright © 2010 Xilinx, Inc. All rights reserved. */
/* */
/* Description : MicroBlaze Linker Script */
/* */
/*******************************************************************/

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x989680;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x5F5E100;

/* Define Memories in the system */

MEMORY
{
microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x00001FB0
mcb_ddr3_S0_AXI_BASEADDR : ORIGIN = 0xA8000000, LENGTH = 0x08000000
}

/* Specify the default entry point to the program */

ENTRY(_start)

/* Define the sections, and where they are mapped in memory */

SECTIONS
{
.vectors.reset 0x00000000 : {
KEEP (*(.vectors.reset))
}

.vectors.sw_exception 0x00000008 : {
KEEP (*(.vectors.sw_exception))
}

.vectors.interrupt 0x00000010 : {
KEEP (*(.vectors.interrupt))
}

.vectors.hw_exception 0x00000020 : {
KEEP (*(.vectors.hw_exception))
}

.text : {
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
} > mcb_ddr3_S0_AXI_BASEADDR

.init : {
KEEP (*(.init))
} > mcb_ddr3_S0_AXI_BASEADDR

.fini : {
KEEP (*(.fini))
} > mcb_ddr3_S0_AXI_BASEADDR

.ctors : {
__CTOR_LIST__ = .;
___CTORS_LIST___ = .;
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
__CTOR_END__ = .;
___CTORS_END___ = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.dtors : {
__DTOR_LIST__ = .;
___DTORS_LIST___ = .;
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
PROVIDE(__DTOR_END__ = .);
PROVIDE(___DTORS_END___ = .);
} > mcb_ddr3_S0_AXI_BASEADDR

.rodata : {
__rodata_start = .;
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r.*)
__rodata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sdata2 : {
. = ALIGN(8);
__sdata2_start = .;
*(.sdata2)
*(.sdata2.*)
*(.gnu.linkonce.s2.*)
. = ALIGN(8);
__sdata2_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sbss2 : {
__sbss2_start = .;
*(.sbss2)
*(.sbss2.*)
*(.gnu.linkonce.sb2.*)
__sbss2_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.data : {
. = ALIGN(4);
__data_start = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d.*)
__data_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.got : {
*(.got)
} > mcb_ddr3_S0_AXI_BASEADDR

.got1 : {
*(.got1)
} > mcb_ddr3_S0_AXI_BASEADDR

.got2 : {
*(.got2)
} > mcb_ddr3_S0_AXI_BASEADDR

.eh_frame : {
*(.eh_frame)
} > mcb_ddr3_S0_AXI_BASEADDR

.jcr : {
*(.jcr)
} > mcb_ddr3_S0_AXI_BASEADDR

.gcc_except_table : {
*(.gcc_except_table)
} > mcb_ddr3_S0_AXI_BASEADDR

.sdata : {
. = ALIGN(8);
__sdata_start = .;
*(.sdata)
*(.sdata.*)
*(.gnu.linkonce.s.*)
__sdata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sbss (NOLOAD) : {
. = ALIGN(4);
__sbss_start = .;
*(.sbss)
*(.sbss.*)
*(.gnu.linkonce.sb.*)
. = ALIGN(8);
__sbss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.tdata : {
__tdata_start = .;
*(.tdata)
*(.tdata.*)
*(.gnu.linkonce.td.*)
__tdata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.tbss : {
__tbss_start = .;
*(.tbss)
*(.tbss.*)
*(.gnu.linkonce.tb.*)
__tbss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.bss (NOLOAD) : {
. = ALIGN(4);
__bss_start = .;
*(.bss)
*(.bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
. = ALIGN(4);
__bss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

_SDA_BASE_ = __sdata_start + ((__sbss_end - __sdata_start) / 2 );

_SDA2_BASE_ = __sdata2_start + ((__sbss2_end - __sdata2_start) / 2 );

/* Generate Stack and Heap definitions */

.heap (NOLOAD) : {
. = ALIGN(8);
_heap = .;
_heap_start = .;
. += _HEAP_SIZE;
_heap_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.stack (NOLOAD) : {
_stack_end = .;
. += _STACK_SIZE;
. = ALIGN(8);
_stack = .;
__stack = _stack;
} > mcb_ddr3_S0_AXI_BASEADDR

_end = .;
}

Вот тут кое-какой ответ есть: http://www.xilinx.com/support/answers/45834.html
Но мне такой ответ не подходит, т.к. у меня это не всегда не работает, а периодами. И я не хочу, как там советуют, использовать Debug As, мне надо Run As, т.к. конфигурация не Debug, а Release, и инструмент запуска должен быть соответствующий. Я не уверен, но предполагаю, что неправильно конфигурацию Release запускать через Debug As, т.к. может что-то не так работать или быстродействие будет ниже (мне крайне важно быстродействие при обмене по DDR, заметил, что оно хуже для конфигурации Debug и запуска через Debug As примерно в 2 раза). Если я неправ, то поправьте, пожалуйста.

Я новичок во встраиваемых системах, поэтому вполне допускаю, что я просто "не умею их готовить".

Заодно вопрос почти по теме (возможно ещё и в этом загвоздка): когда я загружаю прошивку, я могу указать бинарник либо system.bit, либо download.bit. И *.bmm файл могу указывать, а могу и нет. Я так понял, что в *.bmm лежит дамп того, что требуется залить в блочную память. Если у меня все сегменты расположены в DDR, то и *.bmm мне вообще не нужен?
Как вообще здесь правильно надо какие файлы подставлять?

[aabmail]

Если программа в Вашем случае будет исполняться из DDR, тогда она и не может находиться в прошивке. Если же идет речь об исполнении программы из BRAM, то тогда используются download.bit и system_bd.bmm. В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС. Все .bmm не являются исходниками, а генерируются программами ngdbuild и par на основе mhs.

[Krys]

Большое спасибо, так гораздо понятнее. Но есть ещё туманности:

В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС.

Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?


А по поводу этого моего вопроса, не разъясните?

При том в папке .srcs лежат такие же файлы, как и в .runs, но меньшего размера. Я посмотрел по размеру, получается, что в SDK_EXPORT попадает файл из .runs.

Если опираться на то, что Вы сказали:

Все .bmm не являются исходниками, а генерируются программами ngdbuild и par на основе mhs.

, то получается, что после генерации из *.mhs "правильные" *.bmm лежат в папке

Код

planahead\fft_sp605\fft_sp605.srcs\sources_1\edk\module_1\implementation\

. Но в SDK_EXPORT то получается файлы берутся из .runs. Я могу предположить следующую логику:
1. из *.mhs под названием module_1 в .srcs получается *.bmm под названием module_1.
2. Но весь проект - это не только module_1, т.к. он входит в топовый файл module_1_stub.v
3. Поэтому для всего проекта на основе module_1.bmm получается общая *.bmm под названием module_1_stub.bmm.
4. Какая логика происходит, когда module_1_stub.bmm из .srcs попадает в .runs - я не знаю, но размер увеличивается примерно в 2 раза. Собственно прошу это и пояснить.
5. Если в module_1_stub.bmm в .runs хранятся все рам-блоки, то на его основе подготавливается module_1_stub_bd.bmm, где указаны те, что нужны для микроблэйза. Размер ещё увеличивается.

Что тут правильно, что не так?

[aabmail]

Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?

Оба .bmm описывают одни и те же Block-RAM-блоки, находящиеся в адресном пространстве микропроцессора (или -ов). System_bd.bmm содержит более подробную информацию о них - их двумерные адреса в ПЛИСе. Более подробно о BMM можно почитать в UG437.