-
Постов
2 052 -
Зарегистрирован
-
Посещение
Весь контент Krys
-
Да, я держал в голове эту проблему, но у Вас не она. Это когда большой объём пересылки в несколько burst, то все бёрсты летят в те же адреса, что и первый бёрст, затирая прерыдущие бёрсты ))) Но у вас то даже один бёрст не хочет передаваться )) Совет: длинные исходники нужно прятать под теги codebox (хотя их и нет в стандартном наборе инструментов), модераторы мне обращали на это внимание. Посмотрел этот файл *.mhs, там у Вашего датамувера фифо команд 4 слова. Теоретически статус интерфейс наверное может в таком случае быть не подключенным. Сейчас посмотрел свой файл, у меня фифо команд 1 слово, т.е. его фактически нет. Попробуйте так. Может, доходить команды будут до датамувера, а не застаиваться в фифо. Только интерфейс статуса надо обязательно подключить, дать реади ему. Да, тут ничего необычного, всё в рамках уже полученных объяснений от Xilinx. Единственное, что на первой осциллограмме у Вас обе тактовых имеют одинаковую частоту, а на следующей уже разную. Это говорит о том, что Вы проводили эксперименты при разных условиях, а это неправильно (хотя в данном случае вряд ли в этом причина). Ну а что тут такого? Вы похоже, так и не поняли логику этой недокументированной фичи, которая является главным топиком в этой ветке ))) Попробуйте ещё раз перечитать или задавайте вопросы конкретно. Реади принимает нулевое значение не сразу, а только спустя 4 такта, т.е. успевает скушать 4 слова - всё как надо, всё как описано в первом сообщении. И по осциллограммам видно, что Вы не даёте данные в стрим датамувера, пока не пошлёте ему команду. Предлагаю попробовать естественным образом сделать (это может и не излечит проблему, но хотя бы придаст наглядности). Естественным для фифо я считаю, что Ваше фифо (которое даёт стрим датамуверу) уже заранее выставляет valid, ещё до всяких команд датамуверу, т.е. как в нём есть, что выдавать наружу, так и валид выставляется. А вот команду Вы даёте в датамувер только тогда, когда посчитаете, что фифо заполнен до достаточного уровня, для чего надо мониторить шину заполненности фифо. Кроме того предлагаю для наглядности оба сброса датамувера подсоединить к одному источнику, чтобы не было желания предполагать, что разница моментов сброса как-то влияет. Да и на одну тактовую можно для начала перейти в домене датамувера. Т.е. Вы можете оставить командный интерфейс асинхронным, но подать тактовую ту же самую, что и на интерфейс данных. А вообще может даже лучше для простоты пока отказаться от асинхронного интерфейса. Чтобы не ломать голову лишними причинами. И ещё у Вас используется сигнал tlast я смотрю. Предлагаю для начала его не использовать, и пересылать такие команды, чтобы датамувер на ласт не обращал внимания. У меня в начале в этом была загвоздка. А потом я понял, что ласт мне вообще не нужен, только лишняя логика. Вот Вы пишете s_axi_s2mm, а на самом деле наверняка должно быть s_axis_s2mm. Я потому и просил приводить полное имя сигнала, т.к. это разные вещи. _axi_ - это полная шина, которая идёт от датамувера к интерконнекту и далее в память. А _axis_ - это сигналы стрима. Их важно отличать. И ещё Вы ничего не рассказали про сигнал tkeep, зачем он Вам и вообще что он делает.
-
Да, я помню, потому мне это и показалось странным, если бы размер кэшей влиял на автоматически генерируемый объём блочной памяти. Именно поэтому я её видел в визарде, но посчитал, что это не то, и не стал трогать. Ну да, так получается нормально, я писал об этом выше: Но это второй путь, более сложный. Это и есть по инструкции по ссылке на форумы Xilinx из первого сообщения. Просто Вы говорили, что через визард как-то ещё можно поменять. Или Вы имели в виду визард при создании полностью нового пустого проекта с нуля? Я думал имеется в виду визард, которым можно менять параметры системы в действующем проекте. Предположительно, когда в XPS дважды кликаешь на микроблэйз там появляется визард. Вот там я и видел, что задаётся размер кэшей. У меня такого пункта в XPS нету (использую ISE Planahead + XPS из пакета версии 14.7), но есть Hardware - Clean Netlist. Я так всегда и делал - не помогало. Но после Ваших строчек я решил напрячь мозги и подумать, где что ещё я могу подчистить. Дал такую команду: После этого всё проделал как обычно по полной программе: И тогда всё получилось. На картинке в первом сообщении появились правильные адреса. Я всё это делал и раньше, но вот команду как на картинке не давал. Теперь во избежание глюков буду так делать, спасибо за наводку! В целом алгоритм для избежания потенциальных глюков я бы предложил такой. 1. Открываем XPS, даём команду Hardware - Clean Netlist. 2. Закрываем XPS, даём команду Reset Output Product. 3. Имплемент как обычно и Export Hardware for SDK. В моём случае ни перекомпиляция проекта через Project->Clean и ребилд (я так и делал всегда), ни перекомпиляция BSP с изменением его настроек не помогла бы. Дело в том, что BSP при компиляции берёт как исходник результаты экспорта, находящиеся тут (hw_platform и в частности из него system.xml): А поскольку ошибка закралась уже в system.xml, то всё, что порождено от hw_platform, уже будет с ошибкой. Спасибо, приму на вооружение такой бубен ))) ... а потом и вообще отказались от микроблэйза в пользу аппаратного проца ))) Из-за вулканов ))) Я думаю, не микроблэйз сам по себе как идея встраиваемых процов плохой, а плохая лишь поддержка конкретного встраиваемого проца конкретной конторой, бажный софт для разработки. Я думаю, если слепо по причине вулкана переходить на аппаратный проц, неважно какой, лишь бы аппаратный, то можно нарваться на те же проблемы плохой поддержки и бажного софта разработки. Проц процу рознь, даже если он аппаратный. Так получается...
-
Просто, так нагуглил )) Я не умею через визард )) Это как? Что где запускать? В XPS двойным кликом на микроблэйз и там кэши команд и данных увеличить? Я видел это место, но не был уверен, что кэши это строго равно полный размер блочной памяти. Ещё пробовал создать полностью новый проект, где в визарде использовать только микроблэйз с нужными мне компонентами на плате (у меня отладка SP605) и никаких лишних корок. Память установить какого надо размера. Затем из старого проекта в новый скопировать через *.mhs все корки, которые у меня были. Он их автоматически подхватит. Так данные о размере памяти нормально экспортируются в SDK, но тут ничего удивительного - проект то полностью новый, данные о размере не менялись в процессе. Вот где танцевать? Может уже кто танцевал ))) А по поводу ошибки data2mem ничего не подскажете? Что с этим делать? Вроде и так работает, но вдруг потом наступлю на грабли... лучше сразу эти грабли убрать с дороги )
-
Коллеги, прошу взглянуть на тему из плисочного раздела SoC, может кто сможет подсказать: Увеличил размер блочной памяти для Microblaze, но это не отразилось в SDK, смотрю в system.xml - там старые пределы так и остались
-
Здравствуйте. Увеличил размер блочной памяти для Microblaze с 8кБ до 64кБ по этой инструкции (сообщение 2), но это не отразилось в SDK, смотрю в system.xml - там старые пределы так и остались: Export Hardware to SDK естественно сделать не забыл. Физически память увеличилась, я проверил. В линкер скрипт вбил вручную новые адреса, скомпилил большую программу, она выполняется без сбоев на железе. Вроде и так всё работает. Но мне хочется докопаться до сути: почему размер памяти, указанный в SDK, не увеличился автоматически в соответствии с реальным новым количеством, заданным в XPS? Где подкрутить в XPS, чтобы информация всё же попала в SDK после операции Export Hardware to SDK? Ещё заметил, что после имплемента в Planahead в окошке Log - Implementation последние строки такие: *** Running data2mem with args -bm "module_1_stub_bd.bmm" -bt "module_1_stub.bit" -bd "D:/paul/svn_fft/fpga/planahead/fft_sp605/fft_sp605.srcs/sources_1/imports/microblaze/mb_bootloop_le.elf" tag module_1_microblaze_0 -o b "download.bit" -p xc6slx45tfgg484-3 ERROR:Data2MEM:80 - ADDRESS_SPACE or ADDRESS_MAP tag name 'module_1_microblaze_0' was not found. Some data may have not been translated. Но это сообщение я подмечал ещё до увеличения размера блочной памяти. При том когда я прошиваю прошивку в железку, я указываю только файл module_1_stub.bit из папки имплемента, а *.bmm вообще не указываю. Если указываю ещё и module_1_stub_bd.bmm, то при прошивке выдаёт по-моему ту же ошибку "ADDRESS_SPACE or ADDRESS_MAP..." Это может как-то влиять на отсутствие передачи нового размера памяти из XPS в SDK?
-
Пытаюсь разобраться по мере возможностей. Дайте пожалуйста *.mhs файл. Или кусок с датамувером, но лучше весь, чтобы не было лишних вопросов. А что за "схемаНтик" Вы упоминаете и используете? Не могу не начать холивар ))) Очень тяжело по этой схеме смотреть, что куда. Я понимаю, что схемы улучшают наглядность, но тогда надо хоть провода между блоками прокинуть, а то без проводов это ещё хуже текстового файла в плане наглядности. По текстовику хоть поиском пробежаться можно и подсветка одинаковых слов есть. А тут чото смотрю в книгу - вижу фигу ))) Ладно, это всё офтопик, не собираюсь Вас учить, как выполнять и оформлять проекты, просто личное мнение. Но, может, тогда выложите текстовый исходник на HDL, который получается в результате разбора схемы средой? Было бы легче анализировать. Разрешение картинки к стати маловато, сложно догадываться, что за сигналы подписаны и размыты, особенно постороннему человеку. Непонятно это: Назовите пожалуйста полное имя сигнала, а то их там одинаковых куча - запутаешься. И это непонятно: Что значит перекинуть на 1. И что за сигналы tkeep (я просто не знаю что это, не работал никогда с ними, у меня без них)? Вам они зачем? Может их не использовать? И я смотрю у интерфейс статуса никуда не подключен? В этом запросто может быть причина. Он должен быть подключен к фифо, при том фифо должно быть действующее, т.е. дающее реади когда надо. Это необязательно в том случае, если фифо есть внутри датамувера, но без *.mhs я не знаю, поставили ли Вы его туда. Короче нужна информация. Пока буду ждать, дальше уже не знаю, чо рыть.
-
Спасибо за науку, всё пригодится.
-
Советую снять чипскопом осциллограммы на его ногах, примерно как у меня в первом посте. Тогда будет понятнее. Ну и сюда киньте, вместе подумаем ) Командный интерфейс посмотреть, статусный. Та ли команда. Какой статус. Может память не готова принять, её сигналы тоже надо глянуть. Как Вы его не можете запустить? Т.е. что вы контролируете, чтобы констатировать, что он запущен? Описанные Вами условия запуска вроде верны, ничего больше припомнить не могу.
-
Спасибо. Где какие галочки поставить, чтобы был *.map, я не нашёл, но решил таким способом: http://electronix.ru/forum/index.php?s=&am...t&p=1300078 В принципе, если Вас не затруднит, киньте свой способ, чтобы так сказать народ знал. По поводу функции печати: меня print() устраивает по размеру. Но она не умеет числа печатать (мне нужны десятичные правда). В принципе мне достаточно найти функцию типа dec2str(), чтобы была нересурсоёмкая. Может кто подскажет такую. Тогда я подготовлю из числа строку, а её пошлю через print().
-
Мне просто помнится, что Вы писали выше, что в тексте хранятся тексты для дебага. Ну вот я попробовал эту галочку, у меня вообще размер файла никак не поменялся, не только одна секция текст. Вообще конечно странно: зачем программе-отладчику, выполняемой на мощном компе с кучей памяти, хранить какую-то вспомогательную для себя информацию прямо в прошивке? В прошивке и так бывает каждый байт экономят, а отладчик мог бы взять эту инфу у себя в куче памяти, ведь совершенно все исходники у него есть... Нелогично просто...
-
Ага, спасибо, надо было мне лучше сразу спросить, где про это прочитать. Читать то я непротив, особенно когда в каком-то источнике можно найти краткий, чётко локализованный ответ.
-
И вот тут ответ, как настроить, если таймаут загрузки истекает раньше, чем ваши данные успели прогрузиться: http://forums.xilinx.com/t5/Embedded-Proce...ht/false#M13864
-
Там галочки можно поставить только в General: В остальных разделах нет галочек, только вводить можно текстовые поля. Короче я в консоли смотрю результат запуска линкера, вот так печатает: 'Invoking: MicroBlaze gcc linker' mb-gcc -Wl.-Map=../src/test_paul.map -L../../fft_sp605_bsp/microblaze_0/lib -Wl,-T -Wl,../src/lscript.ld -L../../fft_sp605_bsp/microblaze_0/lib -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v8.50.c -mno-xl-soft-mul -Wl,--no-relax -Wl,--gc-sections -o "fft_sp605.elf" ./src/main.o ./src/platform.o -Wl,--start-group,-lxil,-lgcc,-lc,--end-group Т.е. в принципе эта опция туда пролазит по синтаксису нормально, и он на синтаксис вызова не ругается. Другое дело, что и файла не создаёт ))) Либо ещё как вариант: может он файл создаёт, а потом стирает как ненужный мусор? Путь к файлу пробовал указывать вообще без пути, пробвал по аналогии с остальными путями ставить не ../src, а ./src - результат тот же... Добавление: Решилась проблема, надо было запятую поставить, а не точку )))
-
К стати, если не связаны запретом на распространение трудов своего плода, не поделитесь исходником? ) А то чото жалко тратить 3кБ на xil_printf, а иногда хочется выводить не только строки, но и числа...
-
Попереключал галочку. Размер секции .text не изменился ни на байт. Вот тут говорится, что там только исполняемый код: Embedded System Tools Reference Manual, UG111 (v14.6) June 19, 2013, стр. 108 Непонятно: и чего эту секцию текстом назвали? Для запутывания вероятного противника? )))
-
Подскажите, пожалуйста, новичку, куда это вписывать? Я попробовал сюда: Не помогло, после сборки не нашёл такого файла.
-
Golikov A., Вы опять всё полностью угадали )) У меня в железе только перемножитель. Но я подумал, что оттого, что я разделю один раз одно число на другое, много съесться не должно, т.к. чисто физически в делении нет ничего сложного, что бы занимало килобайты кода )) Но я ошибался ))) Ладно, сделаю самописное деление для такого случая. Как это сделать? Я бы с радостью ) У меня та же проблема. Использую axi_timer, дак его библиотека xtmrctr.h съела 1,5 кБ кода, хотя там руками можно пару регистров прогрузить, чтобы всё заработало, и это займёт десятки байт максимум ))) Буду писать свою библиотечку для запуска и считывания таймера, зачем Xilinx стреляет из пушки по воробьям такими монструозными дровами для таких простых устройств - не понятно... Так ещё и не понял, как это сделать... Спасибо, нужная подсказка для новичка.
-
Спасибо, я не сразу увидел Ваше сообщение, сначала своё успел написать. Но Вы вобщем-то всё наперёд предсказали и угадали )) Накопал тут ещё тем касаемо моего вопроса http://electronix.ru/forum/index.php?showtopic=117966 http://electronix.ru/forum/index.php?showt...p;#entry1244345 Многое прояснилось. В частности, хорошая подсказка использовать print() - самое низкое потребление памяти. К стати, а эти функции не инлайновые? Ну там print(), printf(), xil_printf()... Мне показалось, что при каждом новом вызове код разрастается не на размер команды вызова подпрограммы ))) Может, ошибаюсь. 1. Хорошо, ошибался. 2. А куда это вписывать? В XMD Console? Попробовал, вот что выдало: can't read "(OBJ_DIR)": no such variable В теме по последней ссылке предлагают такой ключик: -Wl.-Map=имя_файла Я тоже не понял, куда его вписывать. Попробовал сюда: Не помогло, после сборки не нашёл такого файла.
-
Эта отмазка правда гнилая )) Так бы прямо и сказали, не приплетая ничего постороннего, что новичку так сразу сложно разобраться в тонне документации, и это нормально
-
Пожалуйста ) Обращайтесь ) Описанный алгоритм вроде должен работать.
-
Добавление: методом дихотомии обнаружил, что проблему составляло одно-единственное деление в дабле, именно оно отъедало кучу памяти. Т.к. видимо подключалась вся библиотека для работы с флоатом. Ещё printf очень прожорливый, вместо него надо xil_printf использовать, тогда потребление памяти в пределах разумного. Теперь у меня превышение есть, ошибка остаётся. Но уже не в 8 раз, а на пару килобайтов. Так что вопросы в принципе в силе. Как куда смотреть, что крутить. Т.е. какие приёмы программисты используют, чтобы понять, что не влазит, чтобы оценить, что занимает слишком много, что не должно столько занимать и т.д...
-
Данные утверждения все верные. Небольшие комментарии: Думаю асинхронное фифо городить самому - неблагодарное занятие. Синхронные - ещё куда ни шло... Лучше взять готовую корку из коргена, кучу времени сэкономите. Я такую не находил, взял AXI FIFO из коргена и обернул как User IP Core для XPS. Сейчас ещё раз прошёлся поиском по слову FIFO по компонентам в стандартном репозитории - ничего подходящего не предложило. С логикой реади из датамувера удалось разобраться после моих разъяснений?
-
вот тут ещё у меня вопрос программистский созрел: http://electronix.ru/forum/index.php?showtopic=124988
-
Здравствуйте. Не уверен, что выбрал правильный раздел. Если что - поправьте пожалуйста. В этом разделе в основном обсуждаются аппаратные проблемы использования встраиваемых систем, чистых программистов там мало похоже, судя по отсутствию ответов на мои вопросы начинающего. А проблема у меня чисто програмерская, нужно глубоко понимать, как что компилится и линкуется. Я новичок в программировании под Microblaze (ARM-ядро, если не путаю), работаю в SDK от Xilinx, это допиленный Eclipse, как я понимаю. Пользоваться толком не умею, поэтому, думаю, и проблемы. Проблема такая. На этапе компиляции всего проекта вылазят такие ошибки: fft_sp605.elf section `.text' will not fit in region `microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl' fft_sp605 C/C++ Problem region `microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl' overflowed by 63912 bytes fft_sp605 C/C++ Problem Всего мне отведено 8кБ памяти в ПЛИС. Моя программа небольшая реально, на пару страниц кода. Библиотеки почти не используются, ёмкие функции не вызываются. Почти уверен, что должна влезть в отведённую память. Ну хотя бы даже не влезть, но не в 8 же раз ей не хватает... Начал лазить по файлам, смотреть, кто чего сколько потребил. Вот тут накопал: файл main.o: architecture: MicroBlaze, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000034 2**0 ALLOC 3 .rodata 00000298 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .text.main 00000f5c 00000000 00000000 000002cc 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 5 .debug_frame 00000040 00000000 00000000 00001228 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 6 .debug_info 0000054d 00000000 00000000 00001268 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 7 .debug_abbrev 00000130 00000000 00000000 000017b5 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_loc 0000002e 00000000 00000000 000018e5 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_aranges 00000020 00000000 00000000 00001913 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 10 .debug_ranges 00000010 00000000 00000000 00001933 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 11 .debug_line 000006c4 00000000 00000000 00001943 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 12 .debug_macinfo 0000eb39 00000000 00000000 00002007 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_str 00000428 00000000 00000000 00010b40 2**0 Файл platform.o architecture: MicroBlaze, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000034 2**0 ALLOC 3 .text.enable_caches 00000040 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 4 .text.disable_caches 00000040 00000000 00000000 00000074 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 5 .text.init_uart 00000020 00000000 00000000 000000b4 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .text.init_platform 00000040 00000000 00000000 000000d4 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 7 .text.cleanup_platform 00000034 00000000 00000000 00000114 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 8 .debug_frame 0000009c 00000000 00000000 00000148 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_info 000000df 00000000 00000000 000001e4 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 10 .debug_abbrev 00000041 00000000 00000000 000002c3 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_loc 000000dc 00000000 00000000 00000304 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 12 .debug_aranges 00000040 00000000 00000000 000003e0 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 13 .debug_ranges 00000030 00000000 00000000 00000420 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 14 .debug_line 000000f3 00000000 00000000 00000450 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 15 .debug_macinfo 000100c2 00000000 00000000 00000543 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_str 00000169 00000000 00000000 00010605 2**0 CONTENTS, READONLY, DEBUGGING Тут видно, что секции debug слишком жирные. Я честно говоря вообще толком не знаю, где что правильно посмотреть и как настроить какие размеры сегментов. Даже не знаю, как посмотреть, сколько моя программа занимает отдельно, а сколько переменные отдельно и т.п. Логичным решением вроде является не использовать отладку, раз дебуг секция не лезет. Но, насколько я знаю, многие разработчики прекрасно отлаживаются с таким же объёмом памяти, так что проблема видимо, что я где-то что-то не так настроил. Если нужны ещё какие-то файлы, что-то где-то глянуть - спросите, я посмотрю, просто сразу не знаю, что вам показать, чтобы было понятно, как мне можно помочь. Заранее спасибо.
-
Большое спасибо, так гораздо понятнее. Но есть ещё туманности: Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза? А по поводу этого моего вопроса, не разъясните? Если опираться на то, что Вы сказали: , то получается, что после генерации из *.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, где указаны те, что нужны для микроблэйза. Размер ещё увеличивается. Что тут правильно, что не так?