Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: загрузка программы в NIOS
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
billidean
Создал систему Qsys в квартусе 11.1:
1. НИОС
2. on_chip_RAM - озу для НИОСа
3. сис.таймер
4. PIO - выходы, подключенные к лампочкам
RAM инициализирую hex-файлом по-умолчанию.
Компилю проект, получаю .sof-файл.
В NIOS II IDE создаю проект с использованием uC/OS, компилю, все ок.
Программирую квартусовским программером кристалл, заливаю из NIOS II IDE в НИОС программу, все тоже хорошо, лампочки мигают.

Задача: получить такой .sof-файл, чтобы не нужно было запускать программу НИОСа из NIOS II IDE.

Из доки "Developing NiosII Software" вычитал, что нужно расставить галочки в BSP Settings определенным образом, используя скрипт
"elf2hex <myapp>.elf <start_addr> <end_addr> --width=<data_width> <hex_filename>.hex" получить .hex-файл из .elf-файла,
в Qsys выставить инициализацию RAM своим сгенеренным .hex-ом, скомпилить, получить .sof-файл, и вроде как все.

Сделал все как там сказано, НО НИОС не заработал, лампочки не мигают.
<start_addr> и <end_addr> взял из Qsys, как begin и end для RAM-а.

Если после всех этих манипуляций я пытаюсь компилить проект в NIOS II IDE, то вылезает ошибка типа "multiple target ..." в файле mem_init.mk.
И тут я ваще ни.. не понимаю, что делать.

Кто занимался такими вещами ПЛЗЗЗ подскажите, в чем может быть мой косяк?
Stewart Little
Цитата(billidean @ Jun 5 2012, 13:41) *
Сделал все как там сказано, НО НИОС не заработал, лампочки не мигают.
<start_addr> и <end_addr> взял из Qsys, как begin и end для RAM-а.

Это делается на совсем так.
В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.
Там выбираете mem_init_generate и жамкаете кнопку "Build".
Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init
Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.
После заливки вновь полученного sof'а проект должен сразу завестись.
_Desh_
Цитата(Stewart Little @ Jun 5 2012, 18:22) *
Это делается на совсем так.
Там выбираете mem_init_generate и жамкаете кнопку "Build".
Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init
Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.
После заливки вновь полученного sof'а проект должен сразу завестись.


У меня в версии 9.1 такого пункта не было. Создал его вручную, в окне Create a new Make target в поле Target Name прописал mem_init, в поле Make Target прописал mem_init_generate. В поддиректории ..\mem_init создался файл .hex, но файла с расширением .qip нет. Подскажите, пожалуйста, в чем ошибка?
Копейкин
В 9.1 этот файл .hex и нужно подставить для квартуса, вместо созданного ранее.
И перекомпилировать проект.
billidean
Цитата(Stewart Little @ Jun 5 2012, 17:22) *
Это делается на совсем так.
В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.
Там выбираете mem_init_generate и жамкаете кнопку "Build".
Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init
Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.
После заливки вновь полученного sof'а проект должен сразу завестись.


Спасибо большое!
Ваши рекомендации рабочие (а Альтеровские - нет sad.gif )
FLTI
Цитата(Stewart Little @ Jun 5 2012, 22:32) *
Это делается на совсем так.
В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.
Там выбираете mem_init_generate и жамкаете кнопку "Build".
Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init
Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.
После заливки вновь полученного sof'а проект должен сразу завестись.

Предыдущие свои вопросы удалил, наверное дальше сам разберусь.
P.S. Да разобрался.
FLTI
Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.
Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )?
Stewart Little
Цитата(FLTI @ Jun 1 2014, 21:50) *
Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.

В создании elf-файла (и, соответственно, hex-а) sof никоим образом не участвует. Информацию об аппаратном составе системы компилятор получает из sopcinfo (как справедливо отмечено). А sof предназначен только для конфигурации FPGA.

Цитата(FLTI @ Jun 1 2014, 21:50) *
Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )?
Что-то я не постиг глубину мысли.
Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь???
FLTI
Цитата(Stewart Little @ Jun 2 2014, 14:15) *
Что-то я не постиг глубину мысли.
Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь???

Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл.
Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся?
Stewart Little
Цитата(FLTI @ Jun 2 2014, 14:29) *
Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл.
Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся?
Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки?
И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки?
Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось.
krux
для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.
т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может.
Это если код программы в On-chip Memory.

если есть EPCS Flash Controller то это отдельная история
FLTI
Цитата(Stewart Little @ Jun 2 2014, 14:38) *
Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки?
И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки?

Да, именно так.
Цитата(Stewart Little @ Jun 2 2014, 14:38) *
Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось.

Большое спасибо!


Цитата(krux @ Jun 2 2014, 14:45) *
для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.
т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может.
Это если код программы в On-chip Memory.

Да, код программы в On-chip Memory.
Спасибо, я понял!

FLTI
Цитата(Stewart Little @ Jun 5 2012, 18:22) *
Это делается на совсем так.
В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.
Там выбираете mem_init_generate и жамкаете кнопку "Build".
Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init
Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.
После заливки вновь полученного sof'а проект должен сразу завестись.

А если выполняемая программа хранилась бы не в OnChip Memory, а в EPCS, то приведённая Вами процедура остаётся такой же, только вектора NIOSа будут направлены не на OnChip Memory, а на EPCS Flash Controller?

И ещё вопрос - в чём разница хранения выполняемой программы в OnChip Memory и в EPCS с точки зрения расходования блочной памяти ПЛИС ( M9K )?
Ведь даже если выполняемую программу хранить в EPCS, то для непосредственного выполнения она всё равно будет загружаться в OnChip Memory и расход блочной памяти ПЛИС ( M9K ) в обоих случаях будет одинаковым?
Если так, то как сделать, чтобы выполняемую программу хранить в EPCS и при этом не выделять OnChip Memory размером с эту программу?

Другими словами, можно ли выполняемую программу хранить в EPCS и оттуда же её и запускать?
Golikov A.
почему обязательно в ончип? программу можно и в ДДР перетолкать, и работать оттуда.
FLTI
Цитата(Golikov A. @ Feb 27 2015, 10:15) *
почему обязательно в ончип? программу можно и в ДДР перетолкать, и работать оттуда.

У меня нет на плате ДДР, поэтому такой вариант не рассматриваю.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.