не помогло к сожалению. Какая-то тут ошибка другая

Вообще-то, как оказалось, это широко известная в узких кругах проблема:



В свое время она мне тоже много крови попила и времени отъела. Подробности - на AlteraWiki.

Могу добавить, что это лишь зарегистрированная верхушка айсберга - на практике выявляется и много других проблем. Ну просто интерны когда-то эти программные компоненты написали, как-то все это немного проверили и пустили в оборот. Time-to-market, однако, что тут скажешь Поверяйте практикой любую теорию и не унывайте - эти Альтеровские тулы все же много для нас делают полезного, и в целом работают. Нужно только знать их слабые места.

Подскажите пожалуйста. Можно ли к DMA Controller в Nios в качестве устройства для чтения данных подключить не память, а входной параллельный порт?
То есть, как я понимаю, dma.read_master подключить к pio. При компиляции ошибки нет, но верно ли это?

Можно, если преобразовать параллельный порт в Avalon-ST (SgDMA) или Avalon-MM (SgDMA, DMA) на Ваш выбор.

а то, что у него интерфейс s1 имеет формат Avalom Memory Mapped Slave и у dma read_master имеет Avalom Memory Mapped Master недостаточно? А как нужно и через что еще преобразовать?

Здравствуйте, уважаемые. Есть вопрос, подведу издалека. Ранее в рамках бакалаврской выпускной разрабатывал немаленький проект по средствам языка VHDL в Altera Quartus II. Не было ничего особенно хитрого, несколько десятков ФБ, написанных на VHDL, которые побитово перемножали числа. Два автомата - управляющий и исполнительный. Работу проверял обычными в Q2 встроенными средствами - файлом диаграмм, которые подтверждали правильность функционирования. Научный рук. остался тот же и дал тему разработать проект с применением процессора NiosII, что я, что он пока очень смутно представляем что это за штука такая. Пытался читать английские инструкции, инструкции, переведенные на наш язык (огромное спасибо переводчику) ,нашел несколько так сказать тестовых проектов, и все они сводятся к зажиганию диодов на прожженной плисине. Вопрос в следующем, сейчас проект должен быть на что то вроде перемножении плавающих точек или даже матриц, пока точно не решено, возможно ли без покупки стенда создать процессор в SopcBuilder (фб для QII *.vhd), написать в него какую нибудь прошивку в IDE, и средствами QII бросить туда например числа (в пины), внутри прошивки перемножить, отпустить на output и сделать те же диаграммы? Возможно ли это?

Возможно!
Только для моделирования надо использовать среду ModelSim-Altera.
Ну и Qsys вместо SOPC Builder'а (по нынешним-то временам).

Да, это более чем реально, я такое делал. Для этого надо создать максимально простейшую систему на базе Nios 2, сделать ей "generate", затем Nios EDK создать простую программу дергающую выводами и сгенерировать ELF/HEX файл прошивки, затем в основном проекте назначить получившейся реализации этот файл прошивки.

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

P.S.
Можно поинтересоваться, что за ВУЗ, преподаватели которого имею такой свежий взгляд на вещи?

Ижевский государственный тех. университет, факультет ИВТ. Спасибо большое за ответы, может быть где нибудь есть какие нибудь методички или примеры на похожие темы?

Для отладки в симуляторе можно числа читать-писать из/в файл.
А для отладки в железе, можно для простоты дела числа наверняка можно сразу же записать в память, а результат выдавать на UART...


Если хотите, можем поговорить об этом по скайпу...

Разумеется, любая информация поможет. Логин в скайпе: lostbegan

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

Вообще существует ли пример проекта без участия Usb - бластера, диодов и самой платы? Какой нибудь элементарный, где например на схеме NIOS принимает значения, меняет (хоть элементарно инкрементирует значение одноразово) и дает что то на выход?

Пример чего?

Когда Вы работаете с Nios II, то у Вас есть:
1. аппаратная часть проекта, которая выполняется в Qsys (а ранее в SOPC Builder);
2. программная часть проекта (т.е. исполняемый код Nios II), который создается в Nios II SBT.

Даже если Вы собираетесь только моделировать, то Вам необходимы обе эти части.
При создании аппаратной части Вы можете сделать и тестбенч для моделирования.
А при создании программной часть - dat-файл, который будет инициализировать модель памяти при симуляции. И запускать симулятор Вы можете прямо из-под Nios II SBT.

В простейшем случае аппаратная часть может содержать только процессор и память; те "диоды", о которых вы пишете - это, скорее всего обычный PIO (периферия).

А USB Blaster нужен только для того, чтобы загрузить проект (обе его части!!!) в реальное железо (и отлаживать его там).

Насчет Sopc, Qsys понятно. SBT это я так понимаю старый IDE, для прошивки, тоже понятно. То что обе части будут обязательно участвовать тоже ясно. Что такое тестбенч в теории понимаю, но пока не прощупал. Что такое бластер и плата я тоже представляю. Но я не могу никак понять как набор аппаратной и программной части собрать в единое целое. При создании проекта прошивки он запрашивает информацию о ранее созданном процессоре в SOPC, есть контакт. прошивка вроде потом генерирует файл памяти, ну видимо тоже есть контакт. Пробел в том что я хочу собранный в SOPC NIOS разместить на схеме Quartus и чтобы он мог принимать какие то значения от внешних блоков на той же схеме. Я абстрактно представляю это так - я создаю какой нибудь функциональный блок, который например формирует число 3. Передает его в раннее созданный мной в sopc блок НИОС, там он эти значения как то принимает, и видимо в теле программного кода к примеру прибавляет к 3 еще 3. И выводит полученное число опять же в какой нибудь ФБ или обычный OUTPUT. Это вообще возможно или я сказки придумываю?

1. Для этого к системе надо добавить блок GPIO, и уже через него дергать при помощи специальных функций (или регистров процессора напрямую). Я как раз (чисто случайно) делаю проект в котором Nios2 чисто для отладки воткнул, вечером смогу подсказать конкретнее по программе.
Как сделать систему тоже могу подсказать, отвечу на любые конкретные вопросы.
2. Возможно я ошибаюсь, кажется мои слова справедливы лишь ядра Microblaze в среде Xilinx ISE. Но я подозреваю что в Quartus II это аналогично.

Где можно найти информацию по этим "специальным дергающим" функциям?
Если можете предложить помощь, буду рад совершенно любой информации, пока все никак не может собраться в общую картину

Тут Вы перемудрили.
Передать какую-либо величину в процессор проще всего через стандартное периферийное устройство - UART, PIO, и т.п. Тут ничего изобретать не надо - бесплатная библиотека наиболее ходовых периферийных устройств уже имеется в Qsys. Создаете систему с нужной Вам периферией (т.е. процессор+память+периферия) и все. Это все вместе - один модуль, который Вы можете использовать в квартусовском проекте.
Дальше все просто - приняли байт из периферийного устройства, обработали его, и выдали, например, в другое периферийное устройство (предупреждение - моделировать UART/SPI/I2C/<и т.п.> будет геморройно, лучше для начала PIO ограничиться).



Вся необходимая документация живет вот тут: https://www.altera.com/products/processors/support.html

Да, сам Nios2 в ПЛИСовом проекте добавляется как еще один модуль:
Отрабатывает программа (много тактов clockNmhz) и на шине out_value мы видим число "шесть".
Можно работать с одним GPIO блоком (параллельные линии ввода-вывода), но новичку я бы посоветовал использовать один только как входной, а второй только как выходной. При создании системы с Nios 2 также следует вызвать в менюшке assign addresses и оно само правильно раскидает блоки в адресом пространстве Nios2.

В самом же блоке my_nios2_cpu крутится прошивка (ELF/HEX/что угодно), и сформирована она должна быть в среде Eclipse (например). Там создается новый workspace и затем File->(new/create)->"Application and BSP" (как-то так). Указываем путь до файла SOPC (или *.qsys) и создаем там BSP-проект и hello world программку-пример. Всё это создастся автоматически. Затем мы собираем проект BSP и приступаем к редактированию программки своей (не BSP).

Там мы настраиваем при помощи доступа к регистрам процессора направления работы блоков GPIO (части процессора Nios2), считываем вход gpio_in (это допустим блок GPIO_0) видим там 3, прибавляем тройку и выводи в gpio_out (блок GPIO_1). Чтение с GPIO фактически это будут как беззнаковые числа, можно читать их в переменные типа unsigned int. При генерации BSP мы получили файлы system.h и ряд других - вот они то и содержат адреса блоков GPIO в адресом пространстве Nios2. Собрав проект программки получаем прошивку (тот самый ELF или HEX), которую (другие подскажут) подсовываем в главном ПЛИСовом проекте как прошивку для процессора.

Далее запускаем симуляцию - как? Это отдельный вопрос, причем в отличие от САПР фирмы Xilinx, на мой взгляд у Altera это делается слишком сложно в самой среде и поэтому я бы попытался запустить в отдельно запущенном Modelsim Altera(Intel) Starter Edition.

В общих чертах всё именно так. Но я прекрасно понимаю что просто так по моим словам этого не сделать, придется много разбираться. Примеров в интернете очень много, ведь по ним я и учился, по статьям всяким с картинками. Но по сути всё предельно просто, главное уловить суть и тогда всё что касается процессоров типа Nios2 и Microblaze будет казаться примитивным.

то есть процессор+память можно обставить двумя PIO на вх/вых и программно в прошивке с них бросать данные, обрабатывать и посылать на второй PIO. Потом моделировать в modelSim? Тогда Quartus как участвует? BlockSchematicFile вообще предполагается при таком раскладе?

Когда в Nios EDK (или как там) будете формировать BSP, то эти фукнции там будут уже готовые, достаточно лишь header подключить к программе и указывать этим функциям BASE ADDRESS периферийного блока. Например ALT_GPIO_WR(GPIO_0, 0x1234); <- название функции от балды, но они как-то там называются, нужно просто покопать .h файлы в каталоге проекта BSP


Да да, именно так. Modelsim отдельно от Quartus. BlockSchematicFile не обязателен, я например в тексте это всё делаю

Огромное спасибо вам, постараюсь все переварить и прощупать. Кстати, какую лучше версию Quartus использовать? Сейчас есть QII 9.1sp2+AlteraModelSim к ней+для прошивки софт на WIN7x32. Так же есть Quartus Prime 16.1 Lite Edition на WIN10x64?

Лучше всего v16.1 на Win7 x64 (ну или а Linux x64).

при попытке построить в эклипсе hello_nios проект выдает ошибки:

[BSP build complete]
Info: Linking prosh.elf
nios2-elf-g++ -T'../prosh_bsp//linker.x' -msys-crt0='../prosh_bsp//obj/HAL/src/crt0.o' -msys-lib=hal_bsp -L../prosh_bsp/ -Wl,-Map=prosh.map -O0 -g -Wall -mno-hw-div -mno-hw-mul -mno-hw-mulx -mgpopt=global -o prosh.elf obj/default/proch.o -lm -msys-lib=m
c:/intelfpga_lite/16.1/nios2eds/bin/gnu/h-x86_64-mingw32/bin/../lib/gcc/nios2-elf/5.3.0/../../../../../H-x86_64-mingw32/nios2-elf/bin/ld.exe: address 0x86d0 of prosh.elf section `.rwdata' is not within region `onchip_memory'
c:/intelfpga_lite/16.1/nios2eds/bin/gnu/h-x86_64-mingw32/bin/../lib/gcc/nios2-elf/5.3.0/../../../../../H-x86_64-mingw32/nios2-elf/bin/ld.exe: address 0x9114 of prosh.elf section `.bss' is not within region `onchip_memory'
c:/intelfpga_lite/16.1/nios2eds/bin/gnu/h-x86_64-mingw32/bin/../lib/gcc/nios2-elf/5.3.0/../../../../../H-x86_64-mingw32/nios2-elf/bin/ld.exe: address 0x86d0 of prosh.elf section `.rwdata' is not within region `onchip_memory'
c:/intelfpga_lite/16.1/nios2eds/bin/gnu/h-x86_64-mingw32/bin/../lib/gcc/nios2-elf/5.3.0/../../../../../H-x86_64-mingw32/nios2-elf/bin/ld.exe: address 0x9114 of prosh.elf section `.bss' is not within region `onchip_memory'
collect2.exe: error: ld returned 1 exit status
make: *** [prosh.elf] Error 1

С чем связано? уже и объем подергал. в Qsys собрал следующее - самый дохлый ниос с первым дебаггером, рам на 16кб, два pio - генерация прошла успешно

Скорее всего или с адресным пространством и настройками bsp накосячили, или printf в имеющийся объем памяти не помещается.

Оно тупо не влезает... 16 Кбайт для такой ерунды не хватает - это правда.
Вместо printf я использую невесомую alt_putstr, вместо полноценных библиотек использую IORD_ALTERA_AVALON_UART_STATUS IORD_ALTERA_AVALON_UART_RXDATA и прочие функции (скорее макросы для обращения к регистрам Nios2 напрямую).

Смотрите раздел Reducing Code Footprint in Embedded Systems в Nios II Gen2 Software Developer's Handbook
И рекомендацию уважаемого AVR относительно alt_putstr (ну или alt_printf) - см. тот же документ.

Расширил память до 128кб. Проект построился, *.elf сформировался.
1. Как я понимаю это именно файл прошивки?
2. Увидеть приветствие применяя Run AS NiosII Hardware не удалось, так как нет подключенных устройств, но я так понимаю это не самая большая проблема.
3. Теперь нужно в этом файле прошивки, который *.С нужно соорудить оперирование с регистрами NIOS'а и уже непосредственно организовать какой то конкретный алгоритм после чего моделировать МоделСим?

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

Направление абсолютно верно, двигаемся дальше
0. "Расширил память до 128кб" - и правильно, ведь это не железо, можно какой угодно размер увеличить
1. Да, но точнее это https://ru.wikipedia.org/wiki/Executable_and_Linkable_Format - формат универсальный, и для прошивок микроконтроллеров годится, из него можно в другой преобразовать если надо
2. Да, это только для живых ниосов в работающей ПЛИС, подключенных через JTAG например
3. Да, нужно оперировать регистрами. Конкретно для параллельных GPIO в Nios2 нужно читать ug_embedded_ip.pdf раздел 11 PIO core. Там есть еще Register Map, это значит что по смещению 1 лежит регистр для настройки "направления" работы порта GPIO: на вход или на выход. Смещение - от чего оно? От того адреса что мы автоматически назначили в Nios2 и теперь видим в файле system.h проекта BSP, это так называемый базовый адрес (base address, например #define PIO_0_BASE 0x5020) периферийного блока. В файле типа altera_avalon_pio_regs.h можно увидеть эти смещения, для удобства они в виде констант там. Ну а дальше работаем через функции (макросы на самом деле) IORD_ALTERA_AVALON_PIO*** указывая при обращении базовый адрес (ведь оно же должно знать с каким блоком PIO работаем, ведь их может быть много, а есть не только PIO).
4. Да, а потом этот ELF файл назначаем процессору Nios2, чтобы при загрузке прошивки и старте ПЛИС (или старте симуляции) в ней уже была программа по которой ей работать, ведь как "загрузить в симуляцию" прошивку для Nios2 я не знаю как делается если это возможно, поэтому задаем заранее жестко эту привязку процессора и прошивки. Затем моделируем в Modelsim

Так, конечно, тоже можно. Но это не лучший вариант, т.к. он предполагает запуск квартусовского P&R, ну или, в лучшем случае, ассемблера. А это дополнительное время.

Обычно для проведения моделирования в ниосовском эклипсе создают таргет mem_init_geneate, который преобразует elf в hex- и dat-файлы. Dat-файл нужен для моделирования (он содержит данные, которыми при старте моделирования будет проинициализирована модель памяти).

"Прочитал" файл, что вы советовали. В кавычках, потому что английский, к сожалению не хватает знаний языка для того что бы вникнуть. Возможно есть что то похожее не русском? И что то мне подсказывает что должна быть инструкция по конкретным методам обращения к регистрам. Пока только понял что altera_avalon_pio_regs.h подключается библиотекой, которая и содержит методы. Но есть ли по ним какое то обьяснение, желательно на русском? или на русский в этой теме можно не рассчитывать

Ну вот документ: https://www.altera.com/en_US/pdfs/literatur...rst_nios_sw.pdf Там написано про IOWR_ALTERA_AVALON_PIO_DATA(base, data) это записывает данные в параллельный порт, а IORD считывает (WR write, RD read). Аналогичные функции для настройки направления работы параллельных портов.

Документацию и научные статьи я бы рассчитывал видеть лишь в англоязычном варианте.

Ну в общем то с PIO вроде обстановка примерно понятна. У меня два блока в Qsys'е собиралось вх/вых. В коде попытался каждый дернуть. Теперь буду пробовать симулировать. Вот только вопрос, для того что бы в IORD_ALTERA_AVALON_PIO_DATA(PIO_0_BASE); что то бросить, надо же создавать схему (уже в Квартусе) и там каким то образом подсовывать значения?

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

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

Код я бы немного изменил:

я не очень понимаю. Обвязку в самом квартусе составлять? если так то у меня в *.bsf, который после Qsys, только один вход clk, то есть pio нет. И первый кусок кода, который вы написали, в какой файле находиться должен?

Обвязку в квартусе. У каждого модуля может быть подмодуль. Однако в каждом проекте существует так называемый TOP-модуль (топ, модуль самого верхнего уровня). Зачастую именно для top-модуля назначают привязку линий к выводам ПЛИС.

Куда может быть помещен модуль содержащий Nios2? В принципе, в любое место. Однако в данном случае я бы его разместил внутри модуля верхнего уровня: (top(nios2)).

Помимо BSF там можно сформировать файлы для языка например Verilog: <имя>_inst.v - это пример добавления Nios2 в код модуля верхнего уровня, <имя>_bb.v - поясняет что вход что выход и т.д. Эти два файла лишь примеры, их никуда подключать не надо.

Почему только clk? Потому что линии из проекта QSys должны быть экспортированы. Ни один туториал не обходит этот вопрос мимо. clk, reset и еще другое должно быть помечено как "выходящее на улицу". У каждого периферийного модуля может быть много выходов, в том числе тех которые не нужны в проекте, поэтому QSys предлагает разработчику самому ответить что же ему нужно снаружи.

P.S. Чтобы не путать мысль, скажу отдельно что проект QSys сам по себе может быть модулем верхнего уровня, который можно сразу пихать в ПЛИС или в симуляцию, однако чтобы что-то делать в симуляции - надо иметь некий модуль над этим всем чтобы выполнять какие-то действия над системой.

Этот модуль "над всем этим" - и есть тестбенч
Описывайте в нем свое входное воздействие на систему.

Спасибо вам огромное, что наталкиваете на правильные мысли.



Насчет топ-модуля, насколько я понимаю, имеется в виду установка какого либо файла проекта "set as top level entity". Насколько я понимал, это нужно для компиляции по кускам проекта.

Вторая часть по поводу размещения модуля Nios, пока не так понятна. Однако скажу, что по итогам Qsys получал помимо bsf еще vhdl-файл. Видимо там и нужно втыкать тот кусок кода.

Насчет экспорта разобрался, все было на поверхности, просто, так сказать, глаза разбегаются. Слишком много всяких точек, связей, схем, кода Когда ищешь конкретное слово, конечно оно сразу находится. Вывел на схему оба своих PIO.




А вот насчет тестбенчей и в целом ModelSim пока глаза разбегаются еще больше. С этой программой сталкиваться вообще не приходилось. Организация самих сигналов, я не думаю, что сильно отличается от встроенного метода моделирования квартуса. Но вот создание тестбенча пока меня пугает

Set as top - задает где кисточка винограда крепится к лозе (где лоза - печатная плата на которой есть много разных кистей, и эта ПЛИС в том числе). Можно отщипнуть в кисточке часть (которая станет своим маленьким топчиком), но у нее тоже останутся под-модули

Нет, эти файлы лишь для примера, они не являются искомыми окружениями для Nios2.

Это хорошо

Тяжело в учении - легко в бою. Тут тестбенч простой - тупо клоки подавать и всё.

Мы так и не определились на каком языке HDL идут попытки осилить ПЛИС? У меня в подписи значится Verilog - там ссылка на самоучитель. Я его никому не навязываю, но этот язык я люто обожаю. Если Verilog, то тестбенч будет состоять лишь из формирования клока нужной частоты (а вообще любой), например 50 МГц:

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

Verilog IEEE 1364-2005 и SV IEEE P1800-2005 - четкие конкретные стандарты

вроде дело плавно подходит к окончанию понимания согласованной работы сия проекта, однако есть один важный пробел. Попробовал протестировать ModelSim, нашел статейку https://marsohod.org/11-blog/118-modelsim ,сделал как в инструкции, после некоторых подгонок по времени заработало. Уже успех, уже значит что мой ModelSim на поем пк точно способен симулировать.
Возвращаясь к моему проекту, не понимаю один момент. Вспоминая слова "Если Verilog, то тестбенч будет состоять лишь из формирования клока нужной частоты (а вообще любой), например 50 МГц", понимаю, что это одна из составляющих для моделирования, а вторая должна содержать информацию непосредственно о проекте. Понимаю все так - после Qsys, то есть проектирования апп части получаю *.sopcinfo. На него успешно ссылаюсь создавая прошивку, то есть вот она нить связи апп и прог части - логично. Организую прошивку на языке Си, судя по всему она должна разломаться на машинный код и последовательно разместиться в памяти (вроде как в памяти ибо больше негде), чему свидетельствует файл hex. Но вот вопрос - ведь это не итоговый файл согласованного описания работы апп и прогр части? И если не он то тогда какой? Правильно ли я понимаю что для составления моделирования мне еще нужно сгенерировать какой то файл? И этот файл, в теории, которая сложилась в моей голове, должен содержать и информацию об апп части, и учитывать махинации, которые производятся в тексте прошивки

Вопрос уже не полностью актуален. Удалось провести компиляцию после добавления в проект *.qip *.hex и *.bsf. Создалась автоматически папка simulation. Теперь понятно где соприкасаются все части проекта. Вот только для моделирования все таки надо что то прописывать вручную? я про тестбенч. Или автоматически сгенерированных файлов хватит, просто надо знать какой скомпилировать.

Прикреплю скрин и код C, ну и проект на verilog таки пересобрал.

Про симуляцию системы на базе Nios2 в моделсим к огромному сожалению подсказать не смогу.
Однако вот в тестовой программе я совершенно не вижу настройки направления работы портов. Хоть какие-то порты могли быть при конфигурировании настроены как output-only, но один из них точно двунаправленный. Откуда системе знать в каком направлении надо данные качать? Правильно, нужно ей сказать direction. Этот регистр лежит в PIO_OUT_BASE или PIO_OUT_BASE + некое смещение, описанное в документации на PIO.

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

P.S.
Вижу картинку, подразумевается что это тестбенч - это верно. Однако где же формируется тактовый сигнал и где reset? Не берутся ли они в симуляции из космоса? Замкнуто выход на вход вижу (не перепутано?). Я бы это написал лучше на Verilog а не в схематике - так бы я смог подсказать и помочь. А как сформировать клоки и резеты в схематическом тестбенче - не знаю.

У меня есть подозрение что чтобы просимулировать такой графический тестбенч в моделсиме его надо переварить в Verilog всё равно, что лишь усложняет задачу новичку.

1. Однако вот в тестовой программе я совершенно не вижу настройки направления работы портов. Хоть какие-то порты могли быть при конфигурировании настроены как output-only, но один из них точно двунаправленный. Откуда системе знать в каком направлении надо данные качать? Правильно, нужно ей сказать direction. Этот регистр лежит в PIO_OUT_BASE или PIO_OUT_BASE + некое смещение, описанное в документации на PIO.

1. PIO_Out у меня output only

Соответственно PIO_IN работает Input only


Смещения вроде как указаны после автоматического задания адресов, то есть однозначно понятно в каких адресах вход, в каких выход, из-за указания констант.

2. А тестбенч - это некое окружение вокруг системы, в данном случае оно будет замыкать выход Nios2 на его вход, а в добавок давать жизненно важный сигнал - тактовый.

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

3. Вижу картинку, подразумевается что это тестбенч - это верно.

Картинка это схема же, разве она связана с тестбенчем?

4. Замкнуто выход на вход вижу (не перепутано?)
Разве можно перепутать? я думаю квартус в силах разобраться в этом самостоятельно

5. У меня есть подозрение что чтобы просимулировать такой графический тестбенч в моделсиме его надо переварить в Verilog всё равно, что лишь усложняет задачу новичку.
"Переваривание" организуется не так сложно, опять же квартусам переваривает файл в *.v или *.vhdl

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

Прикреплю папку simulation после сбора апп части, которую сделал квартус или qsys и папку simulation, которую квартус сделал после успешной компилляции (при создании самого проекта квартуса поставил галки для моделирования).

Это философское понятие что считать тестбенчем. Вот для того Nios2 внутри эта схема может считаться тестбенчем. Однако, в моих представлениях, тестбенч это нечто что эмулирует внешнее окружение от интерфейсов до простых тактов.

Предлагаю переписать тестбенч на Verilog и там будут такты и reset. Как будто Nios2 погрузится в реальную схему реальной платы.

И кстати вот, что после переваривания схемы в верилог

Это я так понимаю тестбенч и есть, его нужно компиллировать с файлами проекта, а не просто в одиночку?

Да, всё верно. Это тестбенч. И файлы всего остального проекта тоже крайне нужны.