Prior to the introduction of the GeMRTOS operating system, the process of planning, creating, building, and maintaining an embedded multiprocessor system was complicated. Most designers found it difficult to integrate numerous processors with the goal of resource sharing and cooperative or competitive application execution.
Enter the GeMRTOS operating system, a game changer that changes the way we approach multiprocessor system design, building, and maintenance. It provides a versatile, user-friendly, and powerful solution for realizing the entire range of capabilities and benefits inherent in embedded multiprocessor applications.
GeMRTOS is provided as a collection of components meticulously crafted for Intel’s Platform Designer tool. These components are neatly structured within folders and can be effortlessly integrated into the /ip sub-directory of your Quartus Prime project. The fundamental structure of a GeMRTOS project directory will resemble:
When “Platform Designer” is open, the GeMRTOS_Multiprocessor component is available in the GeMRTOS group in the IP Catalog Library. Upon launching the “Platform Designer,” you’ll find the GeMRTOS_Multiprocessor component readily available within the GeMRTOS group in the IP Catalog Library. This integration streamlines the process and empowers you to harness the capabilities of GeMRTOS effortlessly.
The GeMRTOS_Multiprocessor component simplifies the configuration of multiprocessor system features. Aspects such as the number of processors, processor type, and processor parameters easily converge within the GeMRTOS component’s user-friendly GUI parameter setup. This consolidation captures all of the complicated features inherent in the design of a sophisticated multiprocessor system, effectively addressing problems that would otherwise necessitate much knowledge and effort.
Within the “System Contents” window, a distinctive characteristic of the GeMRTOS_Multiprocessor becomes evident. It is seamlessly interconnected, much like a “conventional” processor, featuring multiple memory buses that establish connections to various peripherals within the system. This integration facilitates a smooth and familiar interaction with peripherals, despite the underlying complexity of the GeMRTOS_Multiprocessor’s functionality.
The GeMRTOS framework smoothly integrates interrupt handling, matching the approach of a normal uniprocessor architecture. This unique perspective enables GeMRTOS to simplify the development of multiprocessor architectures within FPGA devices, providing an intuitive avenue for implementation.
For a more beginner-friendly introduction to GeMRTOS, a direct port can be effortlessly exported to connect inputs and outputs directly to the GeMRTOS memory map registers. These outputs can serve practical purposes, such as controlling LEDs to visually represent the execution of system tasks. This approach obviates the need for intricate PIO device configuration.
To bring the entire system to life, it’s imperative to generate the “Platform Designer” project. This project generation culminates in the creation of a component that can be seamlessly instantiated within your Quartus Prime hardware project, solidifying the integration of GeMRTOS into your FPGA design.
Building the Board Support Package #
The process for designing a GeMRTOS multiprocessor system parallels that of designing uniprocessor systems in FPGA devices. Nevertheless, owing to the unique characteristics of multiprocessors, it becomes necessary to configure the reset memory for the primary processor (processor with ID = 1) within a distinct memory space, separate from the memory allocated for the other system processors.
The GeMRTOS IP module integrates two on-chip memories, each designated for processor resets and exception sections respectively. This design approach ensures efficient management of processor-specific functionalities and exceptions within the multiprocessor framework.
Linker section | Memory device | Description |
.reset .exception | <GeMRTOS_instance_name>_rst1_and_exception_memory | The reset section for the processor with ID = 1, as well as the exception section for all system processors, should be associated with the memory device named “rst1_and_exception_memory.” |
rstaux | <GeMRTOS_instance_name>_rstaux_memory | The “rstaux” linker section needs to be linked with the memory device “rstaux_memory” to define the reset section for processors with IDs other than 1. |
The Software Build Tools for Eclipse can be employed to configure the exception and reset linker sections, similar to how it’s done in uniprocessor design workflows. A comprehensive hardware/software design process is outlined here.
Nevertheless, creating a hardware/software application necessitates the execution of numerous steps that need to be performed frequently. Upon instantiating the GeMRTOS multiprocessor component within a Platform Designer project, the “gemrtos_build.sh” script becomes accessible, automating the execution of all these necessary steps.
The gemrtos_build.sh script #
When the GeMRTOS module is instantiated within a design using the Platform Designer tool, it leads to the creation of the “gemrtos_build.sh” bash script in the root directory of the Quartus Prime project. This root directory includes the “/ip” subdirectory containing the GeMRTOS IP components.
The “gemrtos_build.sh” file is a bash script that executes all the essential steps to build a GeMRTOS application via the command line in the command shell. By default, it is set up with the parameters derived from the GeMRTOS module configuration.
- Platform Designer Project Name: The GeMRTOS component should be integrated into a Platform Designer project, and the associated .qsys file must reside in the main directory of the Quartus Prime project. The Platform Designer project name may be specified through the “Platform Designer project name” parameter in the GeMRTOS IP component’s parameter window.
- Quartus Prime Project Name: This designation identifies the Quartus Prime project in which the Platform Designer project, containing the GeMRTOS IP component, is instantiated. The Quartus Prime project name can be designated via the “Quartus Prime project name” parameter in the GeMRTOS IP component’s parameter window.
- Application project name: This determines the name of the application that the GeMRTOS multiprocessor architecture will execute. By default, a “hellogemrtos” project is created or considered within the “./software” directory, using a “hellogemrtos.c” template.
- BSP Project Name: This establishes the name for the Board Support Package (BSP) associated with the application. By default, it is produced and stored in the “hellogemrtos_bsp” subdirectory within the “./software” directory.
The execution of the “gemrtos_build” script encompasses the following steps:
- Generates the Platform Designer system, incorporating the GeMRTOS component.
- Compiles the Quartus Prime project that instantiates the Platform Designer system, leading to the creation of the “<quartus_project_name>.sof” file.
- Generates the BSP setting file and the BSP project directory, configuring memory sections for GeMRTOS processors.
- Establishes the “./software/hellogemrtos” directory, and if absent, includes the “hellogemrtos.c” template file.
- Compiles both the BSP and application projects, resulting in the creation of “hellogemrtos.elf.”
- Transfers the “<quartus_project_name>.sof” file to the FPGA utilizing the Quartus Prime Programmer tool.
- Opens terminals to establish connections with the GeMRTOS JTAG UARTs within the GeMRTOS component, encompassing a default STDIO, a default STDERR, and a JTAG UART for each system processor.
- Downloads and initiates the execution of “hellogemrtos.elf” on the target hardware.
Following these procedures, a multiprocessor application commences its execution on the FPGA device, and the connected terminals begin displaying welcome messages.
Overriding the default settings. #
The default settings may be overrided by passing command line arguments to the “gemrtos_build.sh” script. The script accepts the following arguments:
- [-qsys|–qsys-prj] <qsys_project_name>: Specifies the name of the Platform Designer project to generate without the file extension. This is the name of the Platform Designer project, and the associated “<qsys_project_name>.qsys” file should be present in the Quartus Prime project directory. By default, it takes the value configured in the “Platform Designer project name” parameter from the GeMRTOS Multiprocessor IP.
- [-qpr|–quartus-prj] <quartus_project_name>: Specifies the name of the Quartus Prime project to compile without the file extension. A “<quartus_project_name>.qpf” file should be present in the Quartus Prime project directory. By default, it takes the value configured in the “Quartus Prime project name” parameter from the GeMRTOS Multiprocessor IP.
- [-app|–app-name] <APPLICATION_project_name>: Specifies the name of the application project to be compiled/created. The application folder will be created in the software directory. The default is “hellogemrtos.”
- [-bsp|–bsp-name] <BSP_project_name>: Optional. Specifies the name of the BSP project to be compiled/created. By default, it’s “<APPLICATION_project_name>_bsp.”
- [-brd|–board] <board_code_name>: Optional. Specifies the name of the subdirectory in which the Quartus Prime directory is located. The default is the current directory (“./”).
- [-dir|–software-dir] <directory>: Optional. Specifies the name of the directory in which the software application will be created. If omitted, “software” will be used. Subdirectories “<BSP_project_name>” and “<APPLICATION_project_name>” will be created within this directory. The default is “./software.”
- [-e|–edit-qsys]: Optional. Invokes the Platform Designer GUI to edit the “<qsys_project_name>” project.
- [-f|–full-compilation]: Optional. Forces a full project compilation. If omitted, only outdated files are processed.
- [-sd|–sd-volume] <drive_letter>: Optional. Specifies the drive letter in which the SD for HPS booting is located.
- [-fat|–fat-volume] <drive_letter>: Optional. Specifies the drive letter in which the SD FAT partition for HPS booting is mounted.
- [-idir|–inc-dir] <include_path>: Optional. Specifies an additional include path for header files (.h). Multiple paths can be provided with multiple -idir arguments. Paths should be relative to the project directory.
- [-sdir|–src-dir] <source_path>: Optional. Specifies an additional source path for source files (.c). Multiple paths can be provided with multiple -sdir arguments. Paths should be relative to the project directory.
Utilizing the [-h|–help] option will display the help documentation for the germtos_build tool. This feature provides users with essential guidance and information about how to effectively use the tool, ensuring a comprehensive understanding of its functionalities and options.