Создал систему 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.
И тут я ваще ни.. не понимаю, что делать.

Кто занимался такими вещами ПЛЗЗЗ подскажите, в чем может быть мой косяк?

Это делается на совсем так.
В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.
Там выбираете 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 и нужно подставить для квартуса, вместо созданного ранее.
И перекомпилировать проект.

Спасибо большое!
Ваши рекомендации рабочие (а Альтеровские - нет )

Предыдущие свои вопросы удалил, наверное дальше сам разберусь.
P.S. Да разобрался.

Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.
Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )?

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

Что-то я не постиг глубину мысли.
Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь???

Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл.
Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся?

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

для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.
т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может.
Это если код программы в On-chip Memory.

если есть EPCS Flash Controller то это отдельная история

Да, именно так.

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



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

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

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

Другими словами, можно ли выполняемую программу хранить в EPCS и оттуда же её и запускать?

почему обязательно в ончип? программу можно и в ДДР перетолкать, и работать оттуда.

У меня нет на плате ДДР, поэтому такой вариант не рассматриваю.