Здравствуйте.
Зашел в тупик из которого пока не знаю где смотреть.
Работаю с CyclonV SoC.
Есть у меня проект для FPGA части сделанный на Quartus 16.1 без использования Qsys.
Хочу добавить HPS часть, чтобы хотя бы светодиодом помигать.

Открыл свой проект в квартусе.
Запустил Qsys.
Сохранил Qsys систему в поддиректории с именем <ПАПКА ПРОЕКТА>\HPS\HardProcSys.qsys
Добавил мегафункцию Hard Processor Sysytem.
Нажал кнопку "Generate HDL", и вышел из Qsys.
В результате на диске появились следующие файлы
<ПАПКА ПРОЕКТА>\HPS\HardProcSys\synthesis\HardProcSys.qip
<ПАПКА ПРОЕКТА>\HPS\HardProcSys\synthesis\HardProcSys.vhd

Вопрос - как мне теперь вставить HPS часть в свой проект FPGA на квартусе???

Я добавил в проект файл HardProcSys.qip
И хочу вставить в свой файл верхнего уровня компонент HardProcSys.vhd
Но дальше надо будет назначать пины.
А я помню, что когда я в PinPlaner пытался в FPGA проекте назначить пин из HPS части, то PinPlaner не позволял это сделать.

Как же прикрутить HPS часть???
Может для нее надо создавать отдельный проект и выбирать отдельную микросхему?
FPGA часть и HPS часть это части одного проекта в квартусе, или это должны быть два разных проекта?

Приветствую.

FPGA и HPS подсистемы единого чипа SoC могут работать как независимо друг от друга, так и совместно.
По крайней мере так указано в документах.

Сам пока что собирал только проект, в котором и ПЛИС, и процессоры HPS были вместе в одном QSys файле, так как взаимодействовали друг с другом.

Назначать пины для HPS компонента не нужно, в PinPlanner они не доступны, так как назначаются автоматически на основе настроек HPS компонента в QSys.

Завести ТОП уровень в него поместить файл .v .vhd сгенерированный QSYS, а рядом ваши модули, соединяются HPS и рукописные модули по одному из мостов, для FPGA мосты видятся, как Avalon. Пины соответсвенно назначаете для вашей рукописной части. Получается такая штука: ваша программа в HPS по мосту например лайтвейт записывает в рукописный модуль по шине Avalon значение по адресу, ваш рукописный модуль это дело анализирует и зажигает светодиод.

Но ведь модуль сгенерированный Qsys содержит например пины интерфейса DDR3, которые имеют имена типа mem_*
Куда мне девать эти ноги? Зачем он мне их выкатил?

Затем "выкатил", что HPS не может работать без внешней SDRAM памяти, она необходима.

В моём случае файл верхнего уровня имеет внешние пины для DDR3 памяти:

к которым подсоединяются выводы memory_* модуля HPS:


Роутер их подхватывает и автоматически разводит на нужное место, так как это hard controller.

Там ещё куча assigments для пинов памяти нужна:
Нажмите для просмотра прикрепленного файла

Как правило файлы с назначениями идут в комплекте с обучающими платами для разработок, там и примеры есть, на базе которых не так сложно разобраться...

Спасибо sonycman.
Я не мог понять зачем мне ноги памяти, если я не могу раскидать их в PinPlaner.
А если он умный и сам знает где они весят и сам их разводит, то зачем он мне их выписывает.
Сейчас стало понятно как дальше двигаться.

А вот это, кстати, не понятно, почему она именно необходима? Что мешает процу работать с OCM, тем более, что при старте он только так и работает? И ещё там QSys генерит пачку HDL исходников тоже на тему DDR контроллера, хотя в конфигурации со стороны ПЛИС никаких заявок на работу с DDR нет. Вот зачем это?

Я сделал такой вывод потому, что в настройках HPS модуля в разделе SDRAM нельзя отключить память.
Если инстанциируется HPS - то он будет вместе с DDR SDRAM.

Я бы вот также хотел бы видеть на рынке хорошую FPGA с менее "жирным" хардовым ARMом, и чтобы его память также была внутри чипа.
Но не судьба пока что, к сожалению.
Приходится "баловаться" с монстрами


При старте процессор, всё же, наверное выполняет код в ROM, так как в OCM пусто.

Вот это-то и странно! Впрочем, там хватает "странностей", начиная от упомянутых HDL файлов для DDR контроллера, хотя оный не заявлен для доступа со стороны ПЛИС, и заканчивая необходимостью проводить синтез (соответственно, и создавать HDL проект) только для того, чтобы получить файлы поддержки для процессора. Я отношу это сугубо к кривизне дизайна. При ровном дизайне Qsys и должен бы сгенерить все эти файлы. Подозреваю, что причины тянутся к NIOS'у - поскольку это софтовое ядро, то его по любому надо синтезировать, ну а генерацию файлов сделали на этапе ассемблера. Теперь хотя ядро железное, но файлы всё равно генерятся ассемблером, это вынуждает юзера проводить синтез, хотя по здравому смыслу это было бы не нужно - это подтверждается тем, что, например, в Vivado этого делать не надо, достаточно того, что генерит аналог Qsys - IP Integrator.


Вот есть с М3 Правда, не знаю, насколько это по вашим меркам хорошая FPGA. Но, имхо, она по мощи где-то соответствует Cortex-M3, т.е решение сбалансированное.


Да, прямо первые такты, конечно, из BOOTROM железно зашитый загрузчик, но дальше этот код грузит программу в OCM и дальше собственно пользовательская программа уже живёт в этой памяти. Я это имел в виду. И то, что какая-то жизнь без SDRAM всё же есть, поэтому жёсткое безусловное навязывание DDR контроллера выглядит грубым.

Есть вариации чипов с двумя хардовыми DDR SDRAM контроллерами - один (обязательный) для HPS, и второй (опциональный) для FPGA.
Может, это к нему относится?


А у Цинков можно использовать MPU без SDRAM контроллера?


Да, спасибо, тоже интересный вариант.

Да нет, там вообще ничего не было указано в Qsys насчёт DDR. Пустой компонент, только GPIO сконфигурированы (светодиодами помигать).


Там аналогично в IP Integrator создаётся блок-дизайн и про экспорте генерируются файлы для инициализации периферии (ps7init.h и ps7init.c), которых достаточно для этой задачи. Никакого синтеза проводить не надо. Т.е. можно ковыряться с процессорной частью независимо и без лишнего гемора. Ну, и конечно, можно абсолютно автономно работать только с OCM, которой там куда больше и которая подцеплена к ядрам поближе и продуманнее (в другой теме писал про это).