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

нет не кеши!
Кеши для работы из брама не нужны, это мы уже обсуждали.

Когда вы делаете систему с микроблайзом вас спрашивают сколько памяти хотите, там можно задать до 64К.
Если там не задали, а переделывать лень, то смотрите на ваш проц, в XPS там он, и к нему приделан память контроллер памяти их 2 на данные и на инструкции в них тык тык и меняйте размер адресов, они идут на порты BRAM. Вроде бы дальше все само происходит.

дальше танцы. После того как я изменил проц в проекте который уже был. Я делал так
В XPS Project->Clean All generated files
дальше генережка проца и экспорт в SDK
тут лучше день потерять зато потом за 5 минут долететь.

в SDK танец с малым бубуном
на все проекты Project->Clean и ребилд

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

если это не происходит танец с большим бубуном. Все софтварные проекты удалить (не удаляя с диска), и заново экспортнуть, клин, ребилд...

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






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


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

[Krys]

нет не кеши! Кеши для работы из брама не нужны, это мы уже обсуждали.

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

Когда вы делаете систему с микроблайзом вас спрашивают сколько памяти хотите, там можно задать до 64К.

Ну да, так получается нормально, я писал об этом выше:

Ещё пробовал создать полностью новый проект, где в визарде использовать только микроблэйз с нужными мне компонентами на плате (у меня отладка SP605) и никаких лишних корок. Память установить какого надо размера. Затем из старого проекта в новый скопировать через *.mhs все корки, которые у меня были. Он их автоматически подхватит.
Так данные о размере памяти нормально экспортируются в SDK, но тут ничего удивительного - проект то полностью новый, данные о размере не менялись в процессе.

Но это второй путь, более сложный.

Если там не задали, а переделывать лень, то смотрите на ваш проц, в XPS там он, и к нему приделан память контроллер памяти их 2 на данные и на инструкции в них тык тык и меняйте размер адресов, они идут на порты BRAM. Вроде бы дальше все само происходит.

Это и есть по инструкции по ссылке на форумы Xilinx из первого сообщения. Просто Вы говорили, что через визард как-то ещё можно поменять. Или Вы имели в виду визард при создании полностью нового пустого проекта с нуля? Я думал имеется в виду визард, которым можно менять параметры системы в действующем проекте. Предположительно, когда в XPS дважды кликаешь на микроблэйз там появляется визард. Вот там я и видел, что задаётся размер кэшей.

дальше танцы. После того как я изменил проц в проекте который уже был. Я делал так
В XPS Project->Clean All generated files
дальше генережка проца и экспорт в SDK
тут лучше день потерять зато потом за 5 минут долететь.

У меня такого пункта в XPS нету (использую ISE Planahead + XPS из пакета версии 14.7), но есть Hardware - Clean Netlist. Я так всегда и делал - не помогало. Но после Ваших строчек я решил напрячь мозги и подумать, где что ещё я могу подчистить. Дал такую команду:



После этого всё проделал как обычно по полной программе:

дальше генережка проца и экспорт в SDK
тут лучше день потерять зато потом за 5 минут долететь.

И тогда всё получилось. На картинке в первом сообщении появились правильные адреса. Я всё это делал и раньше, но вот команду как на картинке не давал. Теперь во избежание глюков буду так делать, спасибо за наводку!
В целом алгоритм для избежания потенциальных глюков я бы предложил такой.
1. Открываем XPS, даём команду Hardware - Clean Netlist.
2. Закрываем XPS, даём команду Reset Output Product.
3. Имплемент как обычно и Export Hardware for SDK.

в SDK танец с малым бубуном:)
на все проекты Project->Clean и ребилд
если происходит что-то странное, то зайти в bsp настройки, что-то поменять, сохранить выйти, клин - ребилд, вернуть настройки, клин ребилд

В моём случае ни перекомпиляция проекта через Project->Clean и ребилд (я так и делал всегда), ни перекомпиляция BSP с изменением его настроек не помогла бы. Дело в том, что BSP при компиляции берёт как исходник результаты экспорта, находящиеся тут (hw_platform и в частности из него system.xml):




А поскольку ошибка закралась уже в system.xml, то всё, что порождено от hw_platform, уже будет с ошибкой.

если это не происходит танец с большим бубуном. Все софтварные проекты удалить (не удаляя с диска), и заново экспортнуть, клин, ребилд... пока менялся проц я прям по последнему сразу пути шел, опять же лучше день потерять чем за 5 минут долететь.... Благо проц не часто надо править.
думаю ошибка связана с тем же. Где то какие-то файлы не обновились. В проекте одно, в дата ту мем попадает другое, эта смесь его и парит.

Спасибо, приму на вооружение такой бубен )))

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

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