Service function integrated real-time processing device

Abstract

To provide a real-time processing apparatus that reduces a circuit scale by consolidating service functions into individual circuit modules instead of distributing them and comprises a mechanism for activating the service functions from tasks and a mechanism for arbitration if the service functions are requested from the plurality of tasks as well.SOLUTION: A real-time processing apparatus comprises a plurality of circuit modules and a service execution management circuit and is completely made into hardware without using a processor. In the circuit modules, all processing tasks that operate on the processor using a real-time OS are individually made into hardware. The service execution management circuit consolidates the services of the real-time OS used by the circuit module without duplication and makes it into hardware, receives service activation requests from the circuit modules in parallel, and arbitrates the plurality of simultaneous requests according to task states and task priorities to execute the requested service, and passes an execution result value of the executed service to the circuit module.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a real-time processing device that is a dedicated hardware that is functionally equivalent to a combination of a processor (CPU), a real-time OS (Operating System), and a processing program. [Background technology]

[0002] With the recent development of information and communication technology, the control systems embedded in devices are required to have increasingly high functionality and high response performance. In particular, extremely high response performance is required for the control of self-driving vehicles, unmanned aerial vehicles, robot control, etc., and how to implement such high-performance control systems has become an important issue.

[0003] Conventionally, a method of implementing real-time OS functions as hardware has been known as a method for improving the responsiveness of a system that uses a real-time OS. A real-time OS provides functions for implementing a system so that tasks and handlers complete their execution within a time constraint. However, with these methods, tasks and handlers are executed as software, and as systems become more sophisticated, there is a problem that response performance is not necessarily improved when the amount of calculation required for the processing is large. In reality, it is becoming more difficult to ensure the real-time nature of a system that uses a real-time OS.

[0004] On the other hand, it is known that high-level synthesis technology can be used to turn tasks that run on a real-time OS into hardware to speed up processing. Although there are system-level design methods that use this high-level synthesis technology to turn specified tasks into hardware, the reality is that it has not yet been possible to turn the entire system, including the real-time OS, into hardware.

[0005] In light of the above situation, the present inventor has already proposed a real-time processing device in which the entire system, including the real-time OS and tasks, is implemented as hardware (see Patent Document 1 and Non-Patent Document 1). The proposed real-time processing device includes a plurality of circuit modules in which all tasks that run on an arithmetic processing device using a real-time OS are implemented as hardware, a module execution mechanism that generates signals to start / stop the circuit modules, a shared memory that the circuit modules can access, and an arbitration mechanism that arbitrates between the circuit modules that access the shared memory, and is fully implemented as hardware including all the functions of the real-time OS services without using an arithmetic processing unit such as a CPU. In the creation of this real-time processing device, a program that runs on the real-time OS is input, and hardware equivalent in function to the processor that executes the program is automatically generated, and the tasks are synthesized into hardware that operates independently. Therefore, all tasks can be executed in parallel, there is no task switching overhead, and high response performance can be achieved.

[0006] However, there was a problem in that the circuit scale of the circuit module in which the tasks were implemented as hardware became large. This problem was caused by the fact that the tasks were implemented as hardware, including the service functions of the real-time OS. In other words, although the OS service functions required by a task usually differ depending on the processing content of each task, even if the same service function is used in different tasks, the same service function is included in the circuit module so that each task can operate independently. Therefore, there are circuits for duplicated service functions, which results in an increase in the circuit scale. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] JP 2019-144910 A [Non-patent literature]

[0008] [Non-Patent Document 1] N. Ishiura, et al., “Synthesis of Full Hardware Implementation of RTOS-Based Systems”, Proc. RSP 2018, pp. 1-7 (2018.10). Summary of the Invention [Problem to be solved by the invention]

[0009] As described above, in conventional real-time processing devices, tasks are implemented as hardware, duplicating the service functions of the real-time OS, resulting in the problem of increased circuit scale. If tasks are implemented as hardware, without including the service functions of the real-time OS, and a circuit is constructed by consolidating only the service functions, a mechanism is required for starting the service functions from the tasks, and since the tasks implemented as hardware operate independently, a mechanism is required for arbitration when multiple tasks request a service function at the same time.

[0010] In view of this situation, an object of the present invention is to provide a real-time processing device that reduces circuit size by consolidating service functions rather than distributing them among individual circuit modules, and that is equipped with a mechanism for initiating a service function from a task and a mechanism for arbitration when a service function is requested from multiple tasks. [Means for solving the problem]

[0011] In order to achieve the above object, the real-time processing device of the present invention is characterized in that it includes a plurality of circuit modules and a service execution management circuit, and is entirely implemented in hardware without using a processor. In the circuit module, all processing tasks that run on a processor using a real-time OS are individually implemented in hardware. In addition, the service execution management circuit is implemented in hardware by aggregating services of the real-time OS used by the circuit modules without duplication, accepts service start requests from the circuit modules in parallel, arbitrates multiple simultaneous requests according to task states and task priorities, executes the requested services, and passes the execution result values ​​of the executed services to the circuit modules.

[0012] According to the above configuration, the service functions of the real-time OS can be consolidated, and all the functions of the processing tasks can be implemented in hardware. This not only achieves significantly faster response times, but also reduces the circuit scale. All circuit modules for processing tasks are implemented independently and run in parallel, eliminating the need for task scheduling. In other words, there is no need to perform parallel calculations on the processor by time sharing processing tasks, and there is almost no overhead associated with task switching, allowing for a significant reduction in system response time.

[0013] Here, a real-time system is defined as a system that responds to an input within a set time, for example in a control system. For example, an automobile control system would output a brake activation signal within a few microseconds when an input from a distance sensor indicates that the vehicle ahead is approaching. A real-time OS is an OS for efficiently implementing a real-time system, and is a program that handles starting and stopping processing tasks and communication between processing tasks. A system call refers to calling a service function of the real-time OS from a processing task program.

[0014] A processing task is defined as a process in which multiple processes are performed in parallel in a real-time system, for example, each of these processes such as detecting an obstacle with an image camera while controlling a traveling motor. In this specification, the processing task is used to include a processing handler. A processing handler is a type of task that temporarily suspends the task being executed and executes a specific process when a specific input is received in order to respond to a non-periodic input to the control system, for example, a sudden approach of an obstacle or an emergency signal from the outside. Task switching refers to switching from one processing task to another in a control system equipped with a processor. In a control system equipped with a processor, task switching requires the state of the currently executing processing task to be saved in memory, and then restored when the processing task is to be executed again. Since this processing is not the processing of the main purpose of the task, it is called overhead. Task scheduling refers to a function in a control system equipped with a processor that switches the processing task executed by the processor according to the situation. In order to meet constraints such as real time, task priorities (task priority levels) can be set for processing tasks, and the real-time OS performs task scheduling based on these priorities.

[0015] In the real-time processing device of the present invention, the circuit modules of the tasks are all implemented independently and all executed in parallel, so task switching and task scheduling are unnecessary. However, scheduling is required for requests for OS service functions, and arbitration is performed according to task priority, which will be described later. It is preferable that the circuit modules in the real-time processing device of the present invention are individually implemented as hardware by high-level synthesis. High-level synthesis is a technology that automatically generates a design description of equivalent hardware (logic circuit) from a program written in C language or the like.

[0016] As described above, in the service execution management circuit in the real-time processing device of the present invention, the services of the real-time OS used by the circuit modules are consolidated without duplication and implemented as hardware. A real-time OS service is an OS program executed by invoking a system call from a processing task program, and this is implemented as hardware, and is not implemented as an embedded circuit module as part of the task, but is implemented as hardware as part of the service execution management circuit, which is a circuit separate from the task circuit module. The service execution management circuit is configured to accept service start requests in parallel from each independent circuit module.

[0017] The service execution management circuit arbitrates multiple simultaneous requests according to the task state and task priority, executes the requested service, and passes the execution result value of the executed service to the circuit module. Here, the task state indicates whether a service function has been requested and whether the requested service is waiting for completion, and the task priority is used to arbitrate multiple simultaneous requests regarding requests for OS service functions. The execution result value of the executed service includes a value of the calculation result from the execution of the service and a value indicating the success or failure of the execution of the service (successful completion or error). A real-time OS system call (function) returns a value indicating the success or failure of the service execution (successful completion code or error code) to the calling processing program as the function return value. Some service calls may also pass data that is the result of the service processing in addition to the return value. The execution result value in the service execution management circuit is a combination of the return value and the processing result data, and the completion of the service function processing is notified by a separate control signal.

[0018] In the real-time processing device of the present invention, the service execution management circuit specifically includes the following 1) to 4). 1) A port that accepts service startup requests for each circuit module. 2) Registers that store task states and task priorities; 3) A set of service modules that consolidate real-time OS services into hardware. 4) An arbitration mechanism that reads a service initiation request from a port, and if there are multiple simultaneous service requests, arbitrates based on the task state and task priority of each circuit module, initiates the service module for which activation was requested, and outputs the execution result and execution completion status of the service in the service module as execution result values ​​to the port corresponding to the circuit module in which the service is being activated.

[0019] The port in 1) above can also receive service start requests at a register as a form of service execution management circuit. A service start request can be made via a port or via a register. The service module group in 3) above refers to a collection of individual service modules, but some systems may have only one service module, and this is permitted.

[0020] The arbitration mechanism in 4) above compares the task priorities of tasks that have received a service start request from a task in a circuit module and are not in a stopped state, and passes to the service module the identification number of the task with the highest priority among the tasks compared, as well as the identification number and parameters of the service requested to be started by the task corresponding to the identification number. Here, the service identification number is a unique number of the requested service function, and corresponds to the function name of a conventional system call. Also, the parameters correspond to the arguments of a conventional system call.

[0021] In the real-time processing device of the present invention, the register 2) above stores task priority and task state, and the task priority and task state can be rewritten by the service module.

[0022] In the real-time processing device of the present invention, the processing tasks include tasks that are periodically started and tasks for non-periodic interrupts. Also, the circuit modules in the real-time processing device of the present invention are all implemented independently and all execute in parallel.

[0023] Next, a method for producing a real-time processing device of the present invention will be described. The method for producing a real-time processing device of the present invention comprises the following steps 1) to 7). 1) extracting from a given program configuration and setting parameters for a processing task that runs on a processor that uses a real-time OS; 2) replacing a system call of the real-time OS used by the processing task with a service start request process and a process for receiving the execution result value; 3) converting all of the processing tasks into multiple circuit modules, each of which is hardwired; 4) A step of aggregating the function bodies of the real-time OS system calls without duplication, and converting them into multiple service modules by implementing them individually in hardware. 5) starting a service module in response to a service start request, and when there are multiple simultaneous service requests, generating a circuit for an arbitration mechanism that arbitrates according to the task state and task priority of each circuit module; 6) generating a service execution management circuit configured by connecting a register for storing a task state and a task priority for each circuit module, a service module, and an arbitration mechanism; 7) connecting the circuit module to a service execution management circuit.

[0024] In 1) above, it is possible to scan a program (group of programs) that use a conventional real-time OS, extract information from it, and synthesize hardware fully automatically. The step 3) of converting into circuit modules can be implemented individually as hardware by high-level synthesis. Effect of the Invention

[0025] The real-time processing device of the present invention has an advantage that it is possible to reduce the circuit scale by consolidating the service functions instead of distributing them among individual circuit modules, while providing a mechanism for starting a service function from a task and a mechanism for arbitrating requests for the service function from multiple tasks, and also that it is possible to execute all processing tasks in parallel, thereby improving processing performance and response. [Brief description of the drawings]

[0026] [Figure 1] Schematic diagram of a real-time processing device of the present invention. [Diagram 2] FIG. 1 is a hardware configuration diagram of an embodiment of a real-time processing device according to the present invention. [Diagram 3] Functional block diagram of the service execution management circuit (1) [Figure 4] Functional block diagram of the service execution management circuit (2) [Diagram 5] Functional block diagram of the service execution management circuit (3) [Figure 6] Functional block diagram of the request arbiter (arbitration mechanism) [Figure 7] Flowchart of real-time processing device [Figure 8] 1 is a schematic diagram of another embodiment of a real-time processing device according to the present invention; [Figure 9] FIG. 1 is a hardware configuration diagram of another embodiment of the real-time processing device of the present invention. [Figure 10] Schematic diagram of the previously proposed real-time processing device DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] Hereinafter, an example of an embodiment of the present invention will be described in detail with reference to the drawings. Note that the scope of the present invention is not limited to the following examples and illustrated examples, and many modifications and variations are possible. EXAMPLES

[0028] Fig. 1 shows a schematic diagram of a real-time processing device of the present invention. Meanwhile, Fig. 10 shows a schematic diagram of a prior proposed real-time processing device disclosed in Patent Document 1. In Figs. 1 and 10, T1 to T3 represent circuit modules 2 which are hardware for executing tasks, and S1 to S4 represent service modules 6 which are hardware for processing service functions. 10, the previously proposed real-time processing device 100 is composed of a circuit module 200 and a module execution mechanism (manager) 300. In the real-time processing device 100, the processing of the service functions of the real-time OS is high-level synthesized not on the module execution mechanism (manager) 300 side but on the circuit module 200 side, i.e., as part of the program on the task side, and therefore the same service functions existed duplicated in multiple circuit modules 200.

[0029] 1, in the real-time processing device 1 of the present invention, the processing of service functions is not carried out on the circuit module 2 side, i.e., on the task side, but is instead concentrated on the service execution management circuit 3 side, thereby eliminating this duplication. A service function is started by the circuit module 2, which is a task, outputting to ports 41 (TFi, TAi) the identification number and parameters (arguments) of the service to be started. When multiple tasks, i.e., multiple circuit modules 2, simultaneously request the initiation of multiple services, the service execution management circuit 3 determines which service to process first according to the task priority at that time of the requesting task, and starts the corresponding service module 6. When the execution of the started service module 6 is completed, the service execution management circuit 3 stores the execution completion value output by the service module 6 in TAi, writes a value indicating the completion of execution in TFi, and notifies the task of the completion.

[0030] 2 shows a hardware configuration diagram of an embodiment of a real-time processing device of the present invention. As shown in FIG. 2, the real-time processing device 1 is made up of a circuit module 2 and a service execution management circuit 3. The circuit module 2 is a hardware implementation of all processing tasks that run on a processor (CPU) using a real-time OS. The service execution management circuit 3 includes a service module group in which services of the real-time OS used by the circuit module 2 are aggregated and hardware implemented without duplication, and a request arbiter (RA) 5 that receives service start requests from the circuit module 2 in parallel, arbitrates multiple simultaneous requests according to the task state and task priority, executes the requested service, and delivers the execution result value of the executed service to the circuit module 2.

[0031] In the service execution management circuit 3, TFi and TAi are ports 41 that notify the service execution management circuit 3 of a service for task Ti (hereinafter, tasks T1 to T3 will be referred to as Ti, where i represents 1 to 3), and status[Ti] is a register group 42 that stores the state variables of task Ti. Meanwhile, status[G] is a register group 42 that stores the state variables of the entire system of the real-time processing device. The port 41 that notifies the service execution management circuit 3 of a service may be directly connected to the circuit module of task Ti, or may be connected via a bus. Also, the port 41 may be a register. The request arbiter (RA) 5 is an arbitration mechanism that arbitrates when there are requests for processing a plurality of service functions. S1 to S4 are hardware modules (service modules 6) that perform service processing. Each of S1 to S4 is a module that performs a different service processing, and each is assigned a different identification number. XF, XA, and XT are registers 43 that mediate between the service execution management circuit 3 and the service module 6. The service module 6 reads and writes the status register group 42 to execute the processing of the service function. TFi and XF are encoded with the presence or absence of a service request and the identification number of the service module 6 that processes the service function. TAi and XA are register arrays, and the number of parameters (arguments) required for the requested service is written. The identification number of the task that made the service request is encoded and written in XT.

[0032] The specific operation flow of the circuit module 2 and the service execution management circuit 3 will be described with reference to Figures 3 to 6. Figures 3 to 5 show functional block diagrams of the real-time processing device of the present invention, where arrows indicate main data flows and control signals are omitted. Also, Figure 6 shows a functional block diagram of a request arbiter, which is an arbitration mechanism of the real-time processing device of the present invention. First, task Ti requests the service execution management circuit 3 to start a service function by writing a parameter (argument) to TAi and an identification number of the service to TFi. Fig. 3(1) shows an example in which task T1 writes a parameter (argument) to TA1 and an identification number of the service to TF1. As shown in Fig. 3 (2), the request arbiter (RA) monitors TFi, and when there is a service request from task Ti, the request arbiter (RA) writes TFi, TAi, and i to XF, XA, and XT, respectively, as shown in Fig. 3 (3). If there are multiple service requests from multiple tasks at the same time, or if there is a service request while a service function request is waiting to be processed, the request arbiter (RA) selects one of them according to the task priority and writes XF, XA, and XT. Other service requests wait for the completion of the currently running service.

[0033] A service module monitors XF, and when the identification number of its own service is written in XF, it starts processing, reads XA and XT, and executes the processing of the requested service function. In the example shown in FIG. 4(1), the identification number of the service module S1 is written in XF, so the service module S1 starts processing, reads XA and XT, and executes the processing of the requested service function. As shown in FIG. 4(2), the service module S1 accesses the task state register as necessary to refer to and update the state variables of the task and the system. Also, as shown in FIG. 4(2), when the processing of the service function is completed (including the case where an error occurs during the execution of the service), it writes the execution result value of the service function in the register of XA and issues a completion signal to the request arbiter (RA). The request arbiter (RA), as shown in Fig. 4 (3), recognizes the requested task number from the value of XT, and as shown in Fig. 5 (1), outputs the execution result value of XA to the TA1 port of the requested task 1, and outputs a value indicating completion of execution (completion notification) to TF1 to notify the completion of processing to task 1. As shown in Fig. 5 (2), task T1 receives the execution result value of the service function and a completion notification (not shown) from the ports TF1 and TA1.

[0034] When multiple service module start requests occur simultaneously, the request arbiter 5 determines the service module to be executed next, and starts the corresponding service module 6 via the XF, XA, and XT registers 43. The selection of a service module is based on the task priority at that time. In other words, among the tasks that have issued start requests, the request to start the service function of the task that is currently being executed and has the highest priority at that time is selected. Note that the task state and task priority may change between the time a request to start a service function is issued and the time processing of the service module begins.

[0035] Figures 6(1) and (2) show functional block diagrams of the arbitration mechanism (request arbiter). As shown in Figure 6(1), when a service function start request is made to TFi (i=1 to 3), the task priorities of tasks whose execution is not stopped are compared, and the identification number of the task with the highest priority is written to XT, and the identification number and parameters (arguments) of the corresponding service module requested to be started are written to XF and XA. That is, when the stall signal line in the status[Ti] representing the task state is "1" (task state is stalled), the input from the status[Ti] of the AND circuit is "0", so the output of the AND circuit is always "0". On the other hand, when the stall signal line in the status[Ti] representing the task state is "0" (task state is not stalled), the input from the status[Ti] of the AND circuit is "1", and if the request signal line representing the service function startup request is "1" (startup request present), the output of the AND circuit is "1", and the task priority is input to the priority comparator via the selector, and the identification number of the task with the highest priority is selected. priority task) is output to XT. For example, as shown in FIG. 6(2), when tasks T1 and T3 (not shown) respectively request TF1 and TF3 to start a service function, status[T1] and status[T3] are referenced, and if the task state is not stopped, the task priorities of tasks T1 and T3 are compared, and the identification number of the task with the higher priority is written to XT (for example, if the priority of task T1 is higher than that of task T3, the identification number of task T1 is output to XT), and the identification number and parameters (arguments) of the corresponding service module requested to be started are written to XF and XA.

[0036] TFi and TAi indicate the service identification number and necessary parameters (arguments) that are written when task Ti wants to start a service function. status[Ti] is a group of registers that store various states of task Ti. stalli is "1" when task Ti is stopped, i.e., not in a running state, and "0" otherwise. priorityi is the task priority of task Ti at that time. The priority is not fixed, but changes during execution as a service function is started. Here, the larger the number, the higher the priority, and "1" is the lowest priority. Priority´i is equal to the task priority (priorityi) when task Ti in a running state is requesting the start of a service, and is "0" otherwise. requesti is "1" when task Ti is requesting the initiation of a service function, and "0" otherwise. Here, TFi can be encoded so that the specific bit becomes requesti. stalli is "1" when task Ti is not in an execution state, and "0" otherwise. selector selects and outputs the input specified by the selection signal (the signal input from the side in the figure). Priority comparator outputs the i (task number) with the largest priorityi. XT contains the priority The output of the comparator is set, and XF and XA are set to XFi and TAi of the selected task Ti.

[0037] (How to make a real-time processing device) FIG. 7 shows a flow of a method for producing a real-time processing device of the present invention. First, the configuration and setting parameters of a processing task that runs on a processor that uses a real-time OS are extracted from a program (step S01). Here, extraction from a program can also be performed automatically. Next, the invocation of a system call of the real-time OS used by the processing task is replaced with a service start request process and an execution result value reception process (step S02). Then, all of the processing tasks are individually converted into hardware and converted into multiple circuit modules (step S03). A circuit module is created by steps S01 to S03. Next, a service execution management circuit is created. First, the function bodies of the system calls of the real-time OS requested to be started by the circuit modules are collected without duplication, and converted into multiple service modules by individually implementing them as hardware (step S04). Then, a service module is started in response to a service start request, and if there are multiple simultaneous service requests, an arbitration mechanism that arbitrates according to the task state and task priority of each circuit module is generated (step S05), and a service execution management circuit is generated by connecting a register that stores the task state of each circuit module, the service module, and the arbitration mechanism (step S06). Finally, the fabricated circuit module is connected to the fabricated service execution management circuit (step S07). In the flow of FIG. 7, the steps of fabricating the circuit module (steps S01 to S03) and the steps of fabricating the service execution management circuit (steps S04 to S06) may be performed in parallel, and finally, the fabricated circuit module and the fabricated service execution management circuit may be connected (step S07).

[0038] In the method of creating a real-time processing device of the present invention, a processing task program using a system call of a real-time OS is input, and the processing task and all of the service functions of the real-time OS are synthesized into hardware. The service functions of the real-time OS are specifically functions described in the function body of the system call of the real-time OS. By synthesizing the processing task and all of the service functions of the real-time OS into hardware, a hardware device is created that is functionally equivalent to a processor that executes a function program of the OS kernel. Furthermore, in the method for manufacturing a real-time processing device of the present invention, each processing task is synthesized into a single independent hardware circuit module and all processing tasks are executed in parallel, thereby improving processing performance and response, eliminating the need for the task scheduling function of the real-time OS, and controlling the system with lightweight hardware.

[0039] Here, a specific example of converting the processing task of 3) above into a circuit module will be described. For example, high-level synthesis can be used as a method of converting a processing task into a circuit module. High-level synthesis is a technology that automatically generates a description of a hardware design from a description of software processing operations written in a programming language such as C. By creating a circuit module using high-level synthesis, designers can design circuit functions at a high level of abstraction without having to be particularly aware of clock frequencies and signal timings, as compared to a language for designing logic circuits called a hardware description language (HDL), and there is an advantage in that debugging can be performed using software development know-how. A system for creating a circuit module using high-level synthesis can use a commercially available tool such as Xilinx's "Vivado HLS".

[0040] (About the implementation and experimental results) We will explain the hardware implementation of the sample program "sample1" that comes with TOPPERS / ASP3 based on the configuration of the real-time processing device of the present invention. TOPPERS / ASP3 is an extension and improvement of the TOPPERS / ASP kernel, and was developed as the foundation for the third generation kernel of TOPPERS (a real-time OS for embedded devices based on the ITRON (Industrial The Real-time Operating-system Nucleus) system).

[0041] This program consists of a task for overall control (MAIN_TASK), a task for handling exceptions (EXC_TASK), and three tasks that run in parallel (TASK1, TASK2, TASK3). MAIN_TASK receives messages via serial communication and calls and executes OS service functions. The service execution management circuit of the real-time processing device of the present invention was designed in Verilog (a hardware description language (HDL) standardized as IEEE 1364). As for the service module, 28 service functions related to calls from tasks out of the 178 service functions of TOPPERS / ASP3 were supported. The circuit module of the task was synthesized by high-level synthesis using ACAP. For details of ACAP, refer to the inventor's paper "ACAP: Binary Synthesizer Based on MIPS Object Codes" (Proc. ITC-CSCC 2014, pp.725-728). In high-level synthesis using ACAP, the machine code obtained by converting a program written in C language or the like using gas (assembler) or gcc (compiler) is used as input, and this is converted into CDFG (Control Data-Flow Graph), which is a standard internal data structure for high-level synthesis. The CDFG is optimized, scheduled, and bound to determine the control logic, and finally the hardware description language is output. These designs were synthesized using the commercially available Xilinx “Vivado HLS” (April 2016) tool, targeting the Xilinx FPGA Artix-7 (xc7a100tcsg324-3).

[0042] In this experiment, the circuit scale of each module, the propagation delay time of the critical path of the circuit, and the number of execution cycles and delay time of each task for the real-time processing device (embodiment) of the present invention that was logically synthesized are summarized in Tables 1 and 2. Tables 1 and 2 also show the circuit scale and delay time of the prior proposed real-time processing device (comparison example) shown in the above-mentioned Patent Document 1, so as to enable comparison with the embodiment. In Table 1, LUT is an abbreviation for "Look Up Table," which is a logic block that can realize any logic function with a certain number of inputs or less, and FF is a flip-flop.

[0043] [Table 1]

[0044] [Table 2]

[0045] As shown in Table 1, when comparing the circuit scale of each logically synthesized module, in the real-time processing device of the present invention, the circuit scale of the three tasks executed in parallel (TASK1, TASK2, TASK3) was reduced compared to the previously proposed real-time processing device, but the service module and request arbiter were newly required, so the overall circuit scale could not be significantly reduced. This is because the sample1 program used in the experiment uses a light-weight service function process, even when compared to a general practical program, and the effect of the reduction in circuit scale did not greatly exceed the increase in circuit scale due to the service module and request arbiter. The effect of reducing the circuit scale becomes more noticeable as the number of tasks increases and the number of types of service functions required increases.

[0046] Furthermore, as shown in Table 2, when comparing the number of execution cycles from when each service function is requested to be started until its state is updated, the real-time processing device of the present invention was able to reduce the number of cycles to less than half that of the previously proposed real-time processing device. Also, with the real-time processing device of the present invention, the delay time from when a task requests the start of a service function to when the execution result value of the service function is actually sent was within 200 ns for all service functions.

[0047] (Other Examples) (1) FIGS. 8 and 9 show a schematic diagram and a hardware configuration diagram of another embodiment of the real-time processing device of the present invention. As shown in the figures, the real-time processing device 1a may be provided with, as a circuit module, in addition to tasks (T1 to T3), handlers (H1, H2) which are tasks that temporarily suspend an executing task and execute a specific process when a specific input is received.

[0048] (2) In Figures 1 to 6, the port 41 may be a register. In the case of a register, since it is mapped to the memory space of the task, the task can start a service function and receive the execution result value by reading and writing to the address.

[0049] (3) The circuit modules for all processing tasks may be created automatically using high-level synthesis or may be designed and created manually using a hardware description language such as RTL (Register Transfer Level), and circuit modules created automatically using high-level synthesis and manually designed circuit modules may be mixed. It is also possible to replace the circuit modules with processors that execute programs that operate in the same way as conventional devices (for example, the programs themselves that are input to the high-level synthesis system). [Industrial Applicability]

[0050] The present invention is useful as a control device for autonomous vehicles, unmanned aerial vehicles, robot control, and the like. [Explanation of symbols]

[0051] 1,1a,100 Real-time processing device 2,200 circuit modules 3 Service Execution Management Circuit 5 Request Arbiter (RA) 6 Service Module 41 Port 42 Registers 43 Register 300 Module Execution Mechanism (Manager)

Claims

1. A plurality of circuit modules in which all processing tasks operated by a processor using a real-time OS are individually implemented as hardware; a service execution management circuit including: a port for receiving a service start request for each of the circuit modules; a register for storing a task state and a task priority; a group of service modules in which services of a real-time OS are aggregated and implemented as hardware; and an arbitration mechanism for reading a service start request from the port, and if there are multiple simultaneous service requests, arbitrating according to the task state and the task priority of each of the circuit modules, starting the service module in which the start is requested, and outputting an execution result and an execution completion state of the service in the service module as an execution result value to the port corresponding to the circuit module in which the service is being implemented, wherein the services of the real-time OS used by the circuit modules are aggregated and implemented as hardware without overlap, receiving service start requests from the circuit modules in parallel, arbitrating the multiple simultaneous requests according to the task state and the task priority, and executing the requested service, and transferring the execution result value of the executed service to the circuit module; 2. A real-time processing device comprising: a processor that performs all of the above steps;

2. 2. The real-time processing device according to claim 1, wherein the arbitration mechanism compares the task priorities of tasks for which a service start request has been made from a task of the circuit module and the task state is not in a stopped state, and passes to the service module an identification number of the task with the highest priority among the compared tasks, and an identification number and parameters of the service requested to be started by the task corresponding to the identification number.

3. The register stores the task priority and the task state; 3. The real-time processing device according to claim 2, wherein the task priority and the task state can be rewritten by the service module.

4. 4. The real-time processing device according to claim 1, wherein the processing tasks include a task that is activated periodically and a task for a non-periodic interrupt.

5. 5. The real-time processing device according to claim 1, wherein the circuit modules are all independently implemented and can all be executed in parallel.

Images