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

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






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

[Alex77]

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

Нормальное вхождение...
Нарисовал схему, частично смоделировал в симуляторе, правильно задал времянки, правильно развести питание итд
и всё работает.
Вот с живыми процессорами бывают "развлечения". Забудут упомянуть в документации что для запуска нужен резистор на +5 подтяжки и всё... имеешь месяц эротики. Пока письма в саппорт ходят - если ещё захотят возиться с вами...
Спасибо -- проходили.
PS: увы таковы реальности.
PS: однако что альтера что ксайлинкс тоже не без греха...
По мне "больше" развлечений было с gcc-компиляторм на основе суgwin (ещё та сволоч). До сих пор боремся с времён ise 12.

Сообщение отредактировал Alex77 - Dec 23 2014, 07:14

[Krys]

Вот с живыми процессорами бывают "развлечения". Забудут упомянуть в документации что для запуска нужен резистор на +5 подтяжки и всё... имеешь месяц эротики. Пока письма в саппорт ходят - если ещё захотят возиться с вами...

Вы описываете случай нового проца, когда его инженерный сэмпл только выбросили на рынок. Тем не менее когда проц уже не так нов, устоялся, то существует хорошая база знаний сообщества. При том если проблема вылезла - то она будет всегда.
В отличие от микроблэйза, где при одной разводке проблема вылезла, при другой не вылезла. При одном размере не вылезла, при объединении рамблоков допустим более 64кБ - вылезла. И хрен его знает кого винить - то ли разводку, то ли кривые настройки микроблэйза, то ли кривые настройки всего проекта XPS, то ли кривое понимание этого всего при синтезе... При том если вы вопрос напишете на форумах - то люди допустим пробовали этот режим, но при других условиях, и у них всё работало.
А в железном проце других условий быть не может. Разводка одинакова, проц всегда один и тот же.
Именно про это пишет Golikov A. в процитированном Вами же фрагменте.

[Alex77]

Вы описываете случай нового проца, когда его инженерный сэмпл только выбросили на рынок. Тем не менее когда проц уже не так нов, устоялся, то существует хорошая база знаний сообщества. При том если проблема вылезла - то она будет всегда.
В отличие от микроблэйза, где при одной разводке проблема вылезла, при другой не вылезла. При одном размере не вылезла, при объединении рамблоков допустим более 64кБ - вылезла. И хрен его знает кого винить - то ли разводку, то ли кривые настройки микроблэйза, то ли кривые настройки всего проекта XPS, то ли кривое понимание этого всего при синтезе... При том если вы вопрос напишете на форумах - то люди допустим пробовали этот режим, но при других условиях, и у них всё работало.
А в железном проце других условий быть не может. Разводка одинакова, проц всегда один и тот же.
Именно про это пишет Golikov A. в процитированном Вами же фрагменте.

Оффтоп
Идеала нет.
Кому что.
Я выбрал свой "путь" для своих задач. Надеюсь что не сильно ошибся и будет работать до 2020г когда снимут с производства плису.
Лично у меня заработало сразу в первой итерации готового изделия (про железо).

[Krys]

Оффтоп

Ничего. Проблему я уже в данной теме решил, так что можно и поофтопить )))