Перед тем как делать большой проект лучше разобраться ху из ху. Вы путаете кислое с пресным.
Файл onchip_memory2_0.v является выхлопом генератора SOPC билдера и представляет из себя код нужной вам памяти на верилоге (иногда шифрованый). Собственно на его создании участие SOPC билдера заканчивается, дальше этот файл цепляет квартус и пытается компилировать.
Где-то внутри этого файла стоит ссылка на файл onchip_memory2_0.hex, либо любой другой, который вы укажете в SOPC билдере - см рисунок. При компиляции квартус пытается искать именно этот файл. А не какой либо другой. По умолчанию имя .hex файла равно имени .v файла и равно имени модуля в SOPC. Nios IDE по умолчанию генерит файл, прописанный в SOPC билдере. Просто сделайте чтобы они совпадали.

Первым делом туда полез


Это я все понимаю. вот мои настройки ончипа. Но почему квартус просит файлы boot_rom.v и boot_rom.hex? Может, чтоб куартус забыл про boot_rom нужно сделать clearProject или rebuildAll? Но не могу такого найти в квартусе.

Сообщение отредактировал juvf - May 16 2011, 09:13

А в сопц билдере генерацию делали после всех изменений?
Что написано в самом .v файле? Я там нашел строку - the_altsyncram.init_file = "onchip_memory.hex",

Конечно делал. Есть у меня такая строчка. Вот ещё что интересно - сделал поиск по всем файлам проекта текст "boot_rom.hex" .... вот что нашлось (см рис). В epcs_flash_controller.v нет boot_rom.hex, там найден epcs_flash_controller_boot_rom.hex
*.rpt - это выходные отчеты. *.qmsg - тоже. Почему квартус их просит? ???

Сообщение отредактировал juvf - May 16 2011, 09:51

он не просит, а пишет туда о проблемах. не может найти требуемые файлы.

Ну это понятно, я и говорю выходные. Например вот что есть в файле topLevel.map.rpt
Кто-нибудь может из этого понять от куда ноги растут? От куда boot_rom берётся?

Это хвост модификаций вашего проекта.
Отследите, где и какая память до сих пор ссылается на него.

как бы отследить то? В сопц ни кто не ссылается. По крайней мере в окошках не видно. Удалил всю папку dd - не помогло. по файлам текст поискал - нашел boot_rom только в выходных файлах.

Вкладка Tasks -> Analysis & Synthesis -> View Report
далее ищите RAM Summary. Вас должно интересовать, что за память и какой MIF используется.

Сегодня утром включил комп, запустил компиляцию - нету этих boot_rom больше. Решил всётаки разобраться что это было. переименовал ончипПамять в bootRom. переключил ресеты на bootRom, проверил чтоб инициализация была bootRom.hex. Пересобрал проект - вроде всё гладко. Пересобрал BSP и прогу для ниоса, сгенерировал новый hex, опять пересобрал в квартусе проект, залил sof и вуаля - всё работает и нет ворнингов. Ну вот оно вроде счатье. Удалил уже ни кому не нужные onchip_memory2_0.v и onchip_memory2_0.hex. При очередной сборке посыпались варнинги что нету onchip_memory2_0.hex. Опять тоже самое, опять какой-то хвост. опять все перепроверил, поползал по всем файлам, удалил папку dd, проверил репорт компиляции - не могу понять от куда квартус решил что ему нужно onchip_memory2_0.hex?

naliwator, сейчас в RAM Summary нет ни каких упоминаний про onchip_memory2_0.hex. Более того, квартус пытается найти их до того, как запустится Analysis & Synthesis, см рис. Походу баг в квартусе (10.1 + sp1). Попробуйте кто-нибудь переименовать ончип, сгенерировать новые v и hex, а потом удалить старые как не нужные.

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

Попробовал.
1. Переименовал память и .hex файл, сгенерировал систему.
2. Удалил с компьютера .v и .hex файлы предшествовавшей памяти.
3. Запустил полную компиляцию. Действительно, компилятор пытается найти удалённый .hex файл.
4. Удалил bsp проект с диска и собрал всё заново.
5. Получил .hex файл с новым именем, приложил его к проекту.
6. Запустил компиляцию. Печально, компилятор снова ссылается на не существующий .hex файл и запускает полную компиляцию вместо умной.
7. Смотрю в отчёт компилятора и нахожу, что в настройках компиляции остаются не существующие файлы.
8. Пробую удалить назначения проекта (Remove Assignents) и запускаю компиляцию - безрезультатно.
9. Папка инкрементной компиляции может хранить списки соединений (netlist) успешных компиляций. Эту папку рекомендовано удалять, когда нужно вернуться к исходникам. Удаляю папку. Компилирую. Закрываю Quartus II.
10. Открываю Quartus II и проект. Жму компиляцию - умная компиляция работает, т.к. .hex файл не был изменён, то время - 0, предупреждений - нет.
11. Меняю .hex файл, подсовываю проекту. Жму компиляцию - умная компиляция работает, предупреждений - нет.

ага, тоже заработало. только в 10-ом пункте после удаления папки инкрементной_db во время компиляции по прежнему были ворненги. закрыл открыл квартус - пропали. Вчера чистил проект удалил db папку, возможно и inc_db тоже удалил, но не перезапускал квартус. Спасибо за помощь!!!

не могу найти описание векторов прерывания в NIOS II. Например в SOPC билдере в процессоре указал вектор сброса на onchip-memory со смещением 0х00. Адрес onchip-memory = 0х1810000. Контроллер прерываний не добавлял. Что разместится по адресам 0х1810000 ... 0х1810020? Есть у альтеры описание векторов прерывания?

Сообщение отредактировал juvf - May 23 2011, 09:32

Посмотрите здесь.



Всё верно, внутренний контроллер прерываний поддерживает до 32 источников прерываний. Приоритет 0 - наивысший.

Посмотрел..... не нашел... Что разместится по адресам 0х1810000 ... 0х1810020? Конкретно.... по адресу 0х1810010 было значение 0х74. Потом стало 0х34. Что это значит? Как работает внутренний контроллер прерываний?