[1891ВМ12Я 0]

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

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

 

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

 

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

 

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

 

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

[StewartLittle 45]

... однако чтобы что-то делать в симуляции - надо иметь некий модуль над этим всем чтобы выполнять какие-то действия над системой.

Этот модуль "над всем этим" - и есть тестбенч :)

Описывайте в нем свое входное воздействие на систему.

[lostbegan 0]

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

 

Обвязку в квартусе. У каждого модуля может быть подмодуль. Однако в каждом проекте существует так называемый 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 пока глаза разбегаются еще больше. С этой программой сталкиваться вообще не приходилось. Организация самих сигналов, я не думаю, что сильно отличается от встроенного метода моделирования квартуса. Но вот создание тестбенча пока меня пугает

[1891ВМ12Я 0]

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

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

 

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

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

 

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

Это хорошо :)

 

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

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

 

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

reg clock50;
initial clock50 = 0;
initial forever #10 clock50 = !clock50;

[lostbegan 0]

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

 

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

[1891ВМ12Я 0]

Вообще изначально был выбран VHDL, с той задумкой, что на него есть стандарт

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

[lostbegan 0]

вроде дело плавно подходит к окончанию понимания согласованной работы сия проекта, однако есть один важный пробел. Попробовал протестировать ModelSim, нашел статейку https://marsohod.org/11-blog/118-modelsim ,сделал как в инструкции, после некоторых подгонок по времени заработало. Уже успех, уже значит что мой ModelSim на поем пк точно способен симулировать.

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

[lostbegan 0]

вроде дело плавно подходит к окончанию понимания согласованной работы сия проекта, однако есть один важный пробел. Попробовал протестировать ModelSim, нашел статейку https://marsohod.org/11-blog/118-modelsim ,сделал как в инструкции, после некоторых подгонок по времени заработало. Уже успех, уже значит что мой ModelSim на поем пк точно способен симулировать.

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

 

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

 

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

#include <stdio.h>
#include "altera_avalon_pio_regs.h"
#define PIO_IN_BASE 0x41000
#define PIO_OUT_BASE 0x41010 //Скопировал адреса с system.h

int main()
{
int in;

while(1) { // пусть бесконечно крутится для начала, а то отработает и замолчит
in = IORD_ALTERA_AVALON_PIO_DATA(PIO_IN_BASE);//Предполагаю в переменную записать число
in=in+1;//Минимальные действия с числом
IOWR_ALTERA_AVALON_PIO_DATA(PIO_OUT_BASE, in);//Вывод получившегося значения
}
 return 0;
}

[1891ВМ12Я 0]

Про симуляцию системы на базе Nios2 в моделсим к огромному сожалению подсказать не смогу.

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

 

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

 

P.S.

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

 

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

[lostbegan 0]

Про симуляцию системы на базе 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

#define PIO_OUT_HAS_IN 0
#define PIO_OUT_HAS_OUT 1
#define PIO_OUT_HAS_TRI 0

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

#define PIO_IN_HAS_IN 1
#define PIO_IN_HAS_OUT 0
#define PIO_IN_HAS_TRI 0

 

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

 

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

 

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

 

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

 

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

 

4. Замкнуто выход на вход вижу (не перепутано?)

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

 

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

"Переваривание" организуется не так сложно, опять же квартусам переваривает файл в *.v или *.vhdl

 

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

 

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

simulation_qsys.rar

simulation_after_compill.rar

[1891ВМ12Я 0]

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

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

 

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

"Переваривание" организуется не так сложно, опять же квартусам переваривает файл в *.v или *.vhdl

 

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

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

[lostbegan 0]

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

 

module ShemaNIOSII(
pin_name1,
pin_name2
);


input wire	pin_name1;
input wire	pin_name2;

wire	[7:0] SYNTHESIZED_WIRE_0;





app_NiosII	b2v_inst(
.clk_clk(pin_name1),
.reset_reset_n(pin_name2),
.pio_in_external_connection_export(SYNTHESIZED_WIRE_0),
.pio_out_external_connection_export(SYNTHESIZED_WIRE_0));


endmodule

[1891ВМ12Я 0]

`timescale 1ns / 1ps

module my_testbench;
// не может у тестбенча быть входов - в симуляции их просто неоткуда брать
// тестбенч это и есть замкнутый самодостаточный мир

reg clock50;
initial clock50 = 0;
initial forever #10 clock50 = !clock50;

reg reset;
initial begin
reset = 0;
#1000; // сначала 1 мкс будет держаться низкий уровень сброса, а потом нормальный режим работы
reset = 1;
end

wire	[7:0] my_super_wire;

app_NiosII b2v_inst(
.clk_clk(clock50),
.reset_reset_n(reset),
.pio_in_external_connection_export(my_super_wire),
.pio_out_external_connection_export(my_super_wire));

endmodule

[lostbegan 0]

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

[1891ВМ12Я 0]

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

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