[billidean 0]

Создал систему 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.

И тут я ваще ни.. не понимаю, что делать.

 

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

[StewartLittle 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_ 0]

Это делается на совсем так.

Там выбираете 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 нет. Подскажите, пожалуйста, в чем ошибка?

[Копейкин 0]

В 9.1 этот файл .hex и нужно подставить для квартуса, вместо созданного ранее.

И перекомпилировать проект.

[billidean 0]

Это делается на совсем так.

В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.

Там выбираете mem_init_generate и жамкаете кнопку "Build".

Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init

Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.

После заливки вновь полученного sof'а проект должен сразу завестись.

 

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

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

[FLTI 0]

Это делается на совсем так.

В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.

Там выбираете mem_init_generate и жамкаете кнопку "Build".

Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init

Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.

После заливки вновь полученного sof'а проект должен сразу завестись.

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

P.S. Да разобрался.

 

[FLTI 0]

Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.

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

[StewartLittle 41]

Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.

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

 

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

Что-то я не постиг глубину мысли.

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

 

[FLTI 0]

Что-то я не постиг глубину мысли.

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

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

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

[StewartLittle 41]

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

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

Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки?

И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки?

Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось.

 

[krux 8]

для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.

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

Это если код программы в On-chip Memory.

 

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

[FLTI 0]

Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки?

И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки?

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

Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось.

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

 

 

для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.

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

Это если код программы в On-chip Memory.

Да, код программы в On-chip Memory.

Спасибо, я понял!

 

 

[FLTI 0]

Это делается на совсем так.

В 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 0]

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

[FLTI 0]

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

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