[Krys 2]

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

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

 

а зачем до 64 по инструкции меняли? до 64 вроде через визард получается, просто для теста?

[Krys 2]

Просто, так нагуглил )) Я не умею через визард )) Это как? Что где запускать? В XPS двойным кликом на микроблэйз и там кэши команд и данных увеличить? Я видел это место, но не был уверен, что кэши это строго равно полный размер блочной памяти.

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

Так данные о размере памяти нормально экспортируются в SDK, но тут ничего удивительного - проект то полностью новый, данные о размере не менялись в процессе.

 

Чтобы измеить старый надо немного танцануть с бубнами.

Вот где танцевать? Может уже кто танцевал )))

 

 

А по поводу ошибки data2mem ничего не подскажете? Что с этим делать? Вроде и так работает, но вдруг потом наступлю на грабли... лучше сразу эти грабли убрать с дороги )

[Golikov 0]

нет не кеши!

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

 

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

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

 

дальше танцы. После того как я изменил проц в проекте который уже был. Я делал так

В XPS Project->Clean All generated files

дальше генережка проца и экспорт в SDK

тут лучше день потерять зато потом за 5 минут долететь.

 

в SDK танец с малым бубуном:)

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

 

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

 

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

 

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

 

 

 

 

 

 

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

 

 

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

[aabmail 0]

C linker script ИМХО все проще. После его генерации никаких автоматических изменений в нем не производится (что называется, по определению). Поэтому все делаем вручную.

Таким образом проще сгенерировать новый linker script и взять из него измененный кусок.

[Krys 2]

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

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

 

 

Когда вы делаете систему с микроблайзом вас спрашивают сколько памяти хотите, там можно задать до 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 которые разрешены по умолчанию процом. Потому что столько нюансов, а живем то как на вулкане. И так все глючит, а там еще предлагается руками какие-то файлы править...

... а потом и вообще отказались от микроблэйза в пользу аппаратного проца ))) Из-за вулканов )))

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

[Golikov 0]

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

 

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

 

Среда немного глючная - да, но с этим можно мириться и жить. Причины смена проца:

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

проц и периферия собран в одном корпусе и протестирован на рабочую частоту, нет сюрпризов

 

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

 

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

 

 

 

 

 

 

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

[Krys 2]

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

Хм... вот уж не знал... думал под кэш используются те же блоки, что и под память данных и команд (хотя тогда нельзя гарантировать, что прога влезет, если там ещё и кэш мешается). Меня сбило с толку, что шины микроблэйза есть под названием M_AXI_DC и M_AXI_IC. Поэтому я и подумал, что кэш на внешних блоках памяти, не проследил, что куда идёт. Оказывается эти шины как раз и подключаются к DDR, если там будет лежать программа или данные.

 

Ладно, в последнее время очень многое прояснилось. Большое Вам спасибо. В первую очередь помогли мне Вы. Ну и остальным тоже спасибо )

 

 

Ещё бы по ошибке data2mem из первого поста мне кто-нибудь что-нибудь подсказал... Можно ли игнорировать, почему возникло и что делать...

[Alex77 4]

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

Нормальное вхождение...

Нарисовал схему, частично смоделировал в симуляторе, правильно задал времянки, правильно развести питание итд

и всё работает.

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

Спасибо -- проходили.

PS: увы таковы реальности.

PS: однако что альтера что ксайлинкс тоже не без греха...

По мне "больше" развлечений было с gcc-компиляторм на основе суgwin (ещё та сволоч). До сих пор боремся с времён ise 12.

Изменено 23 декабря, 2014 пользователем Alex77

[Krys 2]

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

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

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

А в железном проце других условий быть не может. Разводка одинакова, проц всегда один и тот же.

Именно про это пишет Golikov A. в процитированном Вами же фрагменте.

 

[Alex77 4]

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

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

А в железном проце других условий быть не может. Разводка одинакова, проц всегда один и тот же.

Именно про это пишет Golikov A. в процитированном Вами же фрагменте.

Оффтоп

Идеала нет.

Кому что.

Я выбрал свой "путь" для своих задач. Надеюсь что не сильно ошибся и будет работать до 2020г когда снимут с производства плису.

Лично у меня заработало сразу в первой итерации готового изделия (про железо).

[Golikov 0]

Если работает то и славно. Мы же тут не пытаемся победить в святой войне%)....

 

ну а брамов сколько есть, столько и будет:) Если их на кеш пустить, то естественно на память программы не хватит%). Но при работе из ДДР без кеша - программа просто стоит... И да кешируется (если я правильно помню) только та память которая весит на специальных шинах.

 

 

[Krys 2]

Оффтоп

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

 

[Golikov 0]

ну еще осталась ваша ошибка data2mem

по ней предлагают вот что делать

http://www.xilinx.com/support/answers/58367.html

ссылка про вивадо, но вызов оттуда и общая проблема таже. Ваш модуль не попал в какие то xml файлы.

 

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

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

и только потом начал бы ручками их править;)

 

а вот забивать на ошибку... ну не знаю, мало ли где в каких чего это потом и как:)...

[Krys 2]

ну еще осталась ваша ошибка data2mem

Ой, я про неё и забыл... ))) (или забил пока)

 

 

по ней предлагают вот что делать

http://www.xilinx.com/support/answers/58367.html

Вот ещё хорошие ссылочки на эту тему:

http://forums.xilinx.com/xlnx/board/crawl_...essage.id=29113

http://www.xilinx.com/support/answers/51180.html

Короче в целом понятно. На стадии генерации битстрима запускается data2mem. Кто её просил? Ведь в настройках вот что:

 

 

Т.е. там пусто. Значит нечего и запускать. И не отключишь.

Но она запускает. При том подставляет тэг названия процессора (см. командную строку в логе из первого сообщения), не соответствующий действительности. Отсюда и ошибка. Думаю на это можно забить, т.к. меня не интересует результат выполнения data2mem на этапе окончания имплемента. При загрузке прошивки через SDK оно будет запущено повторно, все нужные файлы будут правильно подставлены, и тот результат, записанный в совершенно другую папку, меня уже и будет интересовать.

 

Разбираясь более подробно:

Среда подставляет тэг module_1_microblaze_0, хотя на самом деле у меня и у других, судя по ссылкам выше, тэг должен быть маленько другим: module_1_i_microblaze_0, где module_1_i - это название модуля, которое фигурирует в топовом файле module1_stub.v, которым обёртывается проект xps под названием module1.xmp. Топовый модуль генерируется автоматически по команде generate top-level. Предполагаю (ещё не проверял), что в этом топовом файле надо у названия модуля стереть _i, тогда тэги будут совпадать ))

Но это если кому надо обязательно устранить это сообщение об ошибке. Мне вот как оказалось не надо.

 

 

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

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

и только потом начал бы ручками их править;)

Мне помогло всё почистить и перегенерить, всё проделать "начисто". Ошибка по окончании имплемента не исчезла (забиваем), но ошибки при загрузке прошивки через SDK больше нет, и это главное.