Увеличил размер блочной памяти для Microblaze, но это не отразилось в SDK, смотрю в system.xml - там старые пределы так и остались Опции

[Krys]

Здравствуйте. Увеличил размер блочной памяти для 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?

[Golikov A.]

Ну да, у меня 14.4 было, там нет таких пунктов как у вас. У вас нет таких как у меня. Мало сделать глючную среду, надо еще постоянно менять названия пунктов и их положение

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

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

у меня даже был момент когда я проц-микроблайз обкладывал льдом То есть заметил подвисание программы, трогал пальцем проц - становилось легче, сначала думал не пропай, менял плату тоже самое, еще и неустойчиво. Пока делали радиатор набрал в мешочек льда и положил на кристал, сразу отпустило... Потом добавлял регистры на шины в проце, стало легче, а потом опять подвисло. Заново переделывал проц, двигал PLL, заводил память на отдельный как требовалось в описании, но игнорировалось клок визардом. От этого в очередной раз стало легче. А потом начал глючить LwIP или что-то типа того делая временами паузу в обработке пакетов.

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






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