Soc linux cyclone v
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio
Latest commit
Git stats
Files
Failed to load latest commit information.
README.md
Cyclone V SoC examples
Examples using the FPSoC chip Cyclone V SoC. All these examples were tested on DE1-SoC board. However most of them are easily ported to other boards including Cyclone V SoC chips because they do not interact with the hardware in the board.
This repository contains:
Starting-guides: guides on how to start with Cyclone V SoC boards. Currently only a guide for DE1-SoC board is available. However the process to start with any Cyclone V SoC board is similar and this guide can be used regardless the Cyclone V SoC board used.
Baremetal-applications: Stand-alone applications without Operating System.
- DMA_transfer_FPGA_DMAC: This example shows how to use a DMA controller in the FPGA to read and write the HPS memories. Transfers can be done with cache switched ON through ACP and with cache switched OFF through the L3-to-SDRAMC port.
- DMA_transfer_PL330_ACP: This is a complete example on moving data using the HPS Direct Memory Access Controller (DMAC) PL330. Data can be moved from a buffer in processor to another buffer in processor or to the FPGA. This example also shows how to switch on the cache memories L1 and L2 and how to configure the ACP port to access cache memories from L3 when caches are on.
- Second_counter_PMU: This example uses a counter in the Performance Monitoring Unit (PMU) timer to measure seconds and build a second counter. It stands as an example on how to use PMU to measure time in baremetal.
FPGA-hardware: Quartus projects describing the FPGA hardware needed in some of the examples.
- DE1-SoC: Hardware for Terasic´s DE1-SoC board.
- FPGA_DMA: it implements a DMA controller in the FPGA and a 1kB on-chip memory. Using this DMA it is possible to move data between HPS and FPGA using the FPGA as master.
- FPGA_OCR_256K: this hardware project includes a 256kB On-Chip memory in the FPGA, implemented using 10Mb memory blocks. This memory is hanging at the beginning of the address space of the HPS-to-FPGA bridge.
Linux-applications:
- Test_DMA_PL330_LKM: it shows how to use the DMA_PL330_LKM module.
- DMA_transfer_FPGA_DMAC: It transfers data from an On-Chip RAM in FPGA to On-Chip RAM in HPS and viceversa using a DMA Controller in FPGA.
- DMA_transfer_FPGA_DMAC_driver: It transfers data from an On-Chip RAM in FPGA to a Buffer in the application using a DMA Controller in the FPGA and the Alloc_DMAble_buff_LKM module.
Linux-modules: Linux Loadable Kernel Modules (LKM).
- Alloc_DMAble_buff_LKM: This driver allocates up to 5 physically contiguous buffers in kernel space and provides its physical addresses through sysfs and access to the buffer through character device interface. These buffers are intended to work as intermediate buffers in DMA transfers. Linux_applications/DMA_transfer_FPGA_DMAC_driver shows how to use it.
- DMA_PL330_LKM_Basic: stand-alone module that makes a data transfer using the PL330 DMAC (available in HPS) when inserted into the operating system. It can be configured to move data between: FPGA memory, HPS On-chip RAM, uncached buffer in processor´s RAM and cached buffer in processor´s RAM (through APC). It is a complete example that can be used as starting point for developing a DMA module for a specific application.
- DMA_PL330_LKM: module to make transfers between an application and the FPGA using PL330 DMAC. It uses char device driver interface to copy the data from application to a uncached or cached (through ACP) buffer in driver´s memory space. Later it uses PL330 DMAC to copy that buffer to FPGA. A /dev/dma_pl330 entry is created so writing in the FPGA is so easy as writing to a file. Linux_applications/Test_DMA_PL330_LKM shows how to use it.
- Enable_PMU_user_space: this module permits access to the Performance Monitoring Unit (PMU) from user space. By default the access from user space is forbidden and a bit must be setting from kernel space to later have access from user space. This module accomplishes that task.
Useful-scripts: Linux shell scripts to ease configuration of the board.
- fixed_mac_dhcp.sh: fixes MAC and asks IP using DHCP protocol.
SD-baremetal: This brief tutorial explains how to build a SD card to run the baremetal examples provided in this repository.
SD-operating-system: It explains how to build an SD card with Operating System from scratch. All the files needed are also provided to save time. Currently the OS that have been tested are:
- Angstrom-v2013.12.
- Angstrom-v2016.12. This tutorial also explains MAC spoofing (to set-up MAC on start-up), custom driver installation and running applications on start-up.
Распределённая система управления на базе SoC FPGA
В распределенной системе управления приходится решать множество разных задач на разных уровнях.
Некоторые задачи целесообразно решать на уровне встраиваемого ПК с полноценной ОС. Полноценная ОС хороша тем, что в ней уже реализовано и отлажено много полезных инструментов, таких как многопоточность, готовые драйвера, библиотеки, разные фреймворки и прочее. И все это можно разрабатывать на языках высокого уровня, особо не вдаваясь в детали реализации на нижнем уровне.
Есть задачи, которые удобно решать на уровне микроконтроллера (далее – МК), либо вообще без ОС (bare-metal), либо с минималистичными ОС реального времени. Здесь ключевую роль играет возможность отладки софта внутри ОС по JTAG и отслеживание происходящего на уровне периферии МК на любом break-point`е.
И есть задачи, которые стоит решать уже на уровне ПЛИС, так как никакого микроконтроллера может не хватить для грамотного параллельного управления разной высокочастотной электроникой, например, драйверами шаговых приводов с обработкой данных энкодеров и регуляторами скоростей. В таких задачах процессор бывает просто лишним.
Количество исполнительных устройств и их различных функций в системе управления сильно возрастает, если речь идет о разработке прибора, например, с трех-степенным манипулятором, парой-тройкой серводвигателей, дюжиной дискретных устройств, кучей периферии на всех популярных интерфейсах (SPI, I2C, UART и т.д.) и сложной логикой с математическим анализом внутри. И всю систему управления очень удобно расположить вообще на одном кристалле, что собственно и будет сделано. В итоге все три уровня управления ПК-МК-ПЛИС и их взаимодействия переместятся внутрь кристалла.
В таком случае неизбежно возникает задача создания транспортного уровня, связывающего всю эту сложную логику между собой. Для связки МК-ПЛИС это решается, фактически, созданием очередного периферийного устройства на общей шине МК со своим набором регистров. Но задача создания транспортного уровня ПК-МК будет решаться немного иначе.
Для экспериментов нам понадобится реальная или виртуальная машина с Ubuntu 16.04 на борту.
Исходные тексты всех программ доступны на GitHub.
Архитектура системы управления
Представим, что все исполнительные устройства системы управления ПК-МК-ПЛИС сводятся к параллельным портам ввода-вывода. Для примера в качестве датчиков и исполнительных устройств ограничимся набором кнопок и светодиодов, а управлять ими будем из командной строки терминала.
Все элементы ПЛИС, в том числе МК, будем синтезировать. Часть ПК уже интегрирована в чип и выполнена на базе Cortex A9, шины которого выведены в ПЛИС и могут быть использованы напрямую. Поэтому все, что придется сделать, это подключить к ядру ОС модули, необходимые для связи с синтезированными узлами в ПЛИС через стандартные средства.
В качестве аппаратной платформы используем комплект DE0-Nano-SoC.
Получение прошивки ПЛИС
Возьмем за основу базовый проект my_first_hps-fpga_base из набора DE0-Nano-SoC CD-ROM (rev.B0 / rev.C0 Board). Проект содержит в себе предварительно настроенную среду с правильно выставленными портами ПЛИС, готовым блоком Cyclone V Hard Processor System с настроенными параметрами памяти и набором вспомогательных элементов в Qsys. Для работы с проектом нам понадобится Quartus Prime 15.1 с пакетом поддержки Cyclone V и SoC Embedded Design Suite.
Внесем некоторые изменения в проект. Добавим ядро NIOS, память для него (16 Кб 32-битной ширины) и порт JTAG. Укажем в параметрах NIOS адреса векторов из добавленной памяти.
Avalon Mailbox является симплексным, поэтому нам нужно два модуля (наподобие RX и TX линий обычного UART). Сигнал прерывания каждого из модулей нужно подключить на тот процессор, для которого модуль является приемным.
Добавим по одному порту (8 бит) ввода и вывода для дальнейшего тестирования системы.
После добавления всех элементов можно сделать автоматический подбор адресов и прерываний.
Создадим порты для кнопок и светодиодов в коде верхнего модуля.
Подключим порты к soc_system.
Соберем проект и получим прошивку ПЛИС, на базе которой будем дальше работать.
Алгоритм
Итак, создадим систему, которая будет делать следующее:
На стороне МК
В среде NIOS II EDS, которая по сути – Eclipse со всеми нужными плагинами, создадим новый проект soc_nios из шаблона “NIOS II Application and BSP”. В результате получится два проекта: непосредственно прошивка и BSP.
В первую очередь нужно сразу собрать BSP, но не традиционным способом. Вместо этого в контекстном меню проекта soc_nios_bsp нужно выбрать в меню NIOS II пункт BSP Editor и включить опции enable_small_c_library и enable_reduced_device_drivers, чтобы прошивка особо не разрасталась. Затем собрать, нажав Generate. В дальнейшем, так как параметры сборки сохранятся, пересобрать BSP можно просто выбором в меню NIOS II пункта Generate BSP.
В файле system.h из проекта BSP можно увидеть все параметры периферии МК, которые были добавлены ранее в схему Qsys.
Более подробно о NIOS и о том, как собирать для него проекты, можно почитать тут.
Для решения задачи на уровне МК нам понадобятся:
- Обработчик прерываний от таймера;
Обработчик прерываний от Mailbox;
Осталось собрать проект. Размер прошивки NIOS должен составить меньше 16 Кб.
Для тестирования прошивки на железе нужно создать новую конфигурацию отладчика. После прошивки ПЛИС из Quartus Programmer в меню Debug Configurations выбираем вариант NIOS II Hardware, обновляем все интерфейсы и во вкладке Target Connections находим jtaguart_1. Это тот самый JTAG для NIOS, который мы ранее добавили в Qsys.
Теперь можно запускать отладку из Eclipse. Если все сделано правильно, в консоли NIOS II должно появится сообщение «Turn the switch ON to activate the timer».
На стороне ПК
Установка ОС Linux на плату
Подробным образом весь процесс описан здесь в разделах с 1 по 10. Рекомендуется использовать более свежие свежие версии тулчейна, бутлоадера и ядра, чем те, которые можно найти по ссылке. Обратите внимание, что для сборки данной версии бутлоадера не подойдет тулчейн с компилятором выше 6-й версии.
Для генерации device tree вместо предложенной утилиты sopc2dts лучше использовать скрипт sopc2dts.jar, причем можно указать сразу —type dtb.
Для получения системы настоятельно рекомендуется использовать самый свежий Buildroot. Для сборки необходимо принудительно указать переменные окружения CC как путь к arm-linux-gnueabihf-gcc и CXX как путь к arm-linux-gnueabihf-g++ из тулчейна. Далее ввести используемые версии компилятора, ядра и библиотеки (их подскажет сама система в процессе сборки). В настройках тулчейна при конфигурации Buildroot надо обязательно указать путь к тулчейну, а также префикс $(ARCH)-linux-gnueabihf и включить поддержку SSP, RPC и C++.
Для удобства можно добавить в Buildroot пакеты nano, mc и openssh.
Далее, собирать весь софт верхнего уровня будем в Eclipse с плагином GNU MCU Eclipse plug-in. Создадим новый workspace для ARM проектов и в глобальных настройках Eclipse в разделе Workspace Tools Path укажем соответствующий путь к установленной версии Linaro.
Драйвер
Первым делом сделаем драйвер для Mailbox`ов. Создадим в Eclipse новый проект nios_mailbox из шаблона «Hello World ARM C Project».
В настройках проекта выключим опции «Use default build command» и «Generate Makefiles automatically», так как для сборки модуля ядра понадобится команда make TARGET=nios_mailbox TARGET_DIR=Default. Добавим в переменные окружения две новых записи CROSS_COMPILE и KDIR, указывающие на полный путь с префиксом тулчейна и путь к исходникам ядра соответственно. В список дефайнов надо добавить __GNUC__, __KERNEL__ и MODULE. Всё. Теперь можно писать код.
Модуль ядра будет реагировать на прерывание из железа и должен как-то сообщать об этом миру приложений. Для этой цели нам понадобится создать свой сигнал.
Драйвер будем создавать на базе platform_device, каждый Mailbox будет как miscdevice, а в конечном итоге в системе будет виден как файл устройства в каталоге /dev. Более подробно о драйверах и вообще можно почитать тут. Важно понимать, что Mailbox`ов у нас может быть теоретически сколько угодно, а драйвер на всех один, и он должен все их инициализировать и пронумеровать.
Если особо не вдаваться в детали, то разработка драйвера сводится к реализации стандартных операций чтения и записи в файл, плюс небольшой бонус в виде специальной функции ioctl(), которая нужна для проброса драйверу id процесса, который его использует. Это нужно для того, чтобы знать, какому процессу в системе сигнализировать о возникновении аппаратного прерывания. Сам обработчик прерывания выглядит довольно просто и очень похож на свой аналог в NIOS.
Осталось собрать проект. Для этого нам нужно написать специальный Makefile. Выглядеть он будет так.
И еще нам понадобится создать файл Kbuild с одной строчкой.
Соберем проект традиционным способом. В результате получим модуль ядра nios_mailbox.ko, который скопируем на систему и установим при помощи insmod. Если все сделано правильно, в консоли Linux, открытой по USB, при нажатии соответствующей кнопки на плате должно появится сообщение от ядра «[ . ] NIOS Mailbox new mail!».
Конечно, в драйвер надо бы добавить буфер для принимаемых данных по прерыванию, так как чтение прикладной программой может не успевать за потоком данных от железа. И сам драйвер лучше собирать с опцией stripped, для экономии места в embedded-системе. Однако, эти вопросы оставим читателю для самостоятельного изучения.
Приложение
Вот мы и добрались до написания консольного приложения. Создадим в Eclipse новый проект soc_test из шаблона «Hello World ARM C++ Project». В разделе Settings в Target Processor выберем архитектуру cortex-a9, в Cross ARM GNU G++ Linker добавим -pthread. Во вкладке Build Artifact можно убрать расширение файла. Все остальные настройки можно оставить по-умолчанию.
Для решения задачи на уровне приложения нам понадобятся:
Парсер сообщений от Mailbox;
Функция отправки сообщений в Mailbox;
Процедура настройки с файлами устройств, которые появились после установки драйвера;
Осталось собрать проект. В результате получим исполняемый файл для архитектуры ARM-9, который скопируем на систему. Если все сделано правильно, то после запуска в консоли появится сообщение «Enter command (»read»(«r»), «write»(«w»), «reverse»), «q» to exit».
Запуск и проверка системы
Инсталляцию модуля ядра добавляем в автозагрузку Linux.
Соберем новую версию прошивки NIOS, убрав из программы весь отладочный вывод в JTAG. Преобразуем прошивку в hex формат запуском в SoC EDS 15.1 Command Shell команды «elf2hex —input=soc_nios.elf —output=soc_nios.hex —width=32 —base=0x4000 —end=0x7fff —record=4». Полученную прошивку нужно добавить как файл инициализации для памяти NIOS в Qsys, затем пересобрать Qsys, пересобрать проект ПЛИС и записать новую прошивку на карту памяти.
Загружаемся и сразу запускаем тестовое приложение. И если все было сделано правильно, то получаем рабочую систему.
Выводы
Не бойтесь использовать такие сложные связки как ПЛИС-МК-ПК на основе SoC в своих проектах. В данной статье продемонстрировано, что реализовать такую систему не так уж и сложно. Можно даже добавить несколько микроконтроллеров и связать их вместе подобным образом.
Система управления, созданная на базе изложенных выше принципов, была внедрена автором в один из электронных приборов и доказала свою работоспособность в реальном мире.