JP2007172311A - Processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a processor in which a conventional operating system used for a single processor is applied to a multi-processor, and processors included in the multi-processor are operated in parallel by the plurality of operating systems. <P>SOLUTION: The processor is constituted of unit processors P0 and P3 for executing tasks by an OS part, unit processors P1 and P2 for executing tasks by a multi-processor corresponding OS and a task arbitration part 210 and an interface area 220 for delivering/receiving task information relating to tasks to be executed by the unit processors P0 and P3 and tasks to be executed by the unit processors P1 and P2 to/from the other tasks. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a processor, and more particularly to a multiple processor in which a plurality of processors are operated by a plurality of operating systems.

  A processor used in a specific device is called an embedded system. In recent years, multiprocessors and multithread processors are often employed in embedded systems. The use of a multiprocessor is advantageous for reducing the clock of the device and improving the response. In particular, in a portable device, it is advantageous to reduce power consumption, and therefore it is desired to employ a multiprocessor.

  By the way, it takes time and cost to determine whether or not a newly developed processor operates normally. For this reason, in the field of software, if a processor with a proven track record as a result of use can be diverted, it is desirable to divert it. Therefore, when an embedded system is made into a multiprocessor, there is a demand for diverting the previously used single processor software.

For example, Patent Document 1 discloses a conventional technique for diverting a single processor to a multiprocessor. In the invention of Patent Document 1, an operating system for a single processor based on μITRON (registered trademark) is ported to a multiprocessor.
JP-A-8-2977581

  However, the above-described invention of Patent Document 1 has a drawback in that when a multiprocessor system is constructed with only a SMP (Symmetric Multi Processor) type processor, the amount of work of porting an application, which is a single processor asset, becomes enormous. is there. On the other hand, when a multiprocessor is operated only by a function distribution type operating system, it is difficult to operate a plurality of processors in parallel.

  In order to operate a plurality of processors in parallel, it is conceivable to operate a plurality of operating systems. However, in the prior art, it has not been considered to operate a plurality of operating systems on a multiprocessor. In the conventional single processor technology, when operating a plurality of operating systems, the operating systems are dynamically switched. For this reason, a loss time for switching the operating system occurs.

  The present invention has been made in view of the above points, and an operating system used in a conventional single processor is diverted to a multiprocessor, and the processors included in the multiprocessor are parallelized by a plurality of operating systems. An object is to provide a processor that can be operated.

  In order to solve the above problems, a processor of the present invention includes a first processor that executes a task by a first operating system, a second processor that executes a task by a second operating system, and a task that is executed by the first processor And task information communication means for exchanging task information concerning a task executed by the second processor with another task.

  According to such an invention, inter-task communication can be performed even when a plurality of processors process tasks using different OSs. Therefore, a plurality of processors incorporated in one processor can be operated in parallel using separate OSs. Therefore, the processor of the present invention can be operated by combining a plurality of processors and using a proven OS as the OS of each processor. The present invention provides a processor capable of diverting an operating system used for a conventional single processor to a multiprocessor and allowing the processors included in the multiprocessor to operate in parallel by a plurality of operating systems. it can.

The processor according to the present invention is characterized in that the task information communication means exchanges task information between tasks executed by the first operating system and between tasks executed by the second operating system.
According to such an invention, inter-task communication is possible between tasks executed by one OS. The present invention makes it possible to arbitrarily set a range of tasks for performing inter-task communication according to task contents, processor configuration, and the like.

The processor according to the present invention is characterized in that the task information communication means exchanges task information between a task executed by the first operating system and a task executed by the second operating system. .
According to such an invention, inter-task communication can be performed between a plurality of OSs. The present invention makes it possible to arbitrarily set a range of tasks for performing inter-task communication according to task contents, processor configuration, and the like.

In the processor of the present invention, the task information communication means assigns identification information for identifying the first operating system and the second operating system to the task information, so that the task information can be transmitted and received. It is characterized by setting.
The processor according to the present invention is characterized in that the task information communication means includes a storage area in which both the first processor and the second processor can read and write information.
According to such an invention, the first processor and the second processor can communicate with each other via the storage area. The present invention makes it possible to implement the processor of the present invention with a relatively simple configuration.

The processor according to the present invention is characterized in that one of the first processor and the second processor is a symmetric multiprocessor, and the other constitutes a function distribution type processor.
According to such an invention, it is possible to configure a multiprocessor by combining a symmetric multiprocessor and a function-distributed processor, and to operate the combined processor using a conventional multiprocessor-compatible OS and a single processor OS. it can.

Hereinafter, an embodiment of a processor according to the present invention will be described with reference to the drawings. In the present embodiment, it is assumed that the processor of the present embodiment is configured as an embedded system applied to a mobile phone.
FIG. 1 is a block diagram showing a functional configuration of a mobile phone 1 according to the present invention. In FIG. 1, a mobile phone 1 includes a CPU (Central Processing Unit) 10, a flash ROM 20, a memory 30, a buffer 40, a radio unit 50, an IrDA (Infrared Data Association) unit 60, and an audio unit. 70, a timer 80, a USB (Universal Serial Bus) interface unit 90, a key operation unit 100, an LCD (Liquid Crystal Display) 110, and a camera unit 120. The CPU 10, the flash ROM 20, the memory 30, and the buffer 40 are connected by a bus. The wireless unit 50, IrDA unit 60, audio unit 70, timer 80, USB interface unit 90, key operation unit 100, LCD 110, and camera unit 120 are directly connected to the CPU 10.

  The CPU 10 controls the entire mobile phone 1 while processing a plurality of tasks in parallel, and an operating system program (OS) stored in the flash ROM 30 according to various instruction signals input from the key operation unit 100. : Operating System) and various application programs are read and executed, or an interrupt handler is executed in response to an interrupt signal input from a peripheral chip such as the wireless unit 50, the audio unit 70, or the camera unit 120.

For example, the CPU 10 processes tasks generated by the application in parallel. Further, when an interrupt signal is input from the peripheral chip, the program corresponding to the interrupt is executed by executing the interrupt handler. Since processing by an application is executed as a task managed by the OS task scheduler, an OS service call can be called. On the other hand, interrupt processing is processing that is not managed by the task scheduler (non-task processing). is there.
Further, the CPU 10 stores various processing results in the flash ROM 20 or the memory 30.

  FIG. 2 is a block diagram showing an internal configuration of the CPU 10. 2, the CPU 10 includes a plurality of unit processors P0 to P3, an interrupt control unit 11, a memory control unit 12, and a hardware semaphore unit 13. Note that the hardware semaphore unit 13 is configured to give a semaphore (referred to as a hardware semaphore in this embodiment) that is a right to become an OS to any unit processor.

  One of the unit processors 0 to 3 constitutes a symmetric multiprocessor (hereinafter referred to as SMP), and the other becomes a function distributed processor. SMP is a multiprocessor in which a plurality of processors share processing from an equivalent standpoint. Originally, in SMP, it is not necessary to be aware of which processor the task is executed on. On the other hand, the function-distributed processor is a single processor that operates specifically for specific processing such as communication control and image processing. In the function-distributed processor, task interrupts are processed for each processor.

In this embodiment, the unit processor P0 and the unit processor P3 are function distributed processors, and the unit processor P1 and the unit processor P2 constitute the SMP5.
As will be described later, the processor of this embodiment in which SMP and function-distributed processors coexist has a plurality of types of OSs. For this reason, the hardware semaphore unit 13 has a plurality of hardware semaphores. Each of the unit processors P0 to P3 acquires an OS corresponding to itself.

Further, the processor of the present embodiment includes a memory 30 serving as a shared area for the unit processors P0 to P3, and a memory control unit 12 that controls the memory 30. In this embodiment, the memory 30 and the memory control unit 12 are used as task information communication means, and information (task information) indicating the task execution state is exchanged between the unit processors P0 to P3. Of the memory control unit 12, a configuration related to the exchange of task information in particular is shown as a task arbitration unit 210. An area used for exchanging task information in the memory 30 is shown as an interface area 220.
Note that task information exchange by the task arbitration unit 210 and the interface area 220 will be described in detail later.

Next, the internal configuration of the unit processors P0 to P3 will be described. Since the unit processors P0 to P3 are configured similarly, the internal configuration of the unit processor P0 will be described as a representative.
The unit processor P0 includes a fetch unit 101, a decode unit 102, an ALU (Arithmetic and Logical Unit) 103, a register file 104, and a program control unit 105. The fetch unit 101 reads out an instruction code from a memory address indicated by a program counter of the program control unit 105 described later, and outputs the instruction code to the decoding unit 102.

The decoding unit 102 decodes the instruction code input by the fetch unit 101, and outputs a decoding result (instruction content, source register, destination register address, etc.) to the ALU 103.
The ALU 103 performs a predetermined operation in accordance with the decoding result input by the decoding unit 102 and writes the operation result to the register file 104 or the branch destination address that is the operation result of a branch instruction or the like to the program control unit 105. Output.

The register file 104 is a register group that stores data read from the memory 30 by a load instruction and data that is an operation result of the ALU 103.
The program control unit 105 controls the entire unit processor P0, and stores a status register (PSR) that stores the status of the unit processor P0 (for example, an interrupt enabled / disabled state, an overflow occurrence state in the unit processor P0), The unit processor P0 includes a program counter (PC) that stores a memory address in which an instruction to be executed next is stored. Then, when the unit processor P0 shifts to interrupt processing, the program control unit 105 changes the value of the program counter to the branch destination when the PSR value is changed to the interrupt processing prohibited state or a branch instruction is executed. Or change the address to

  In addition, when a hardware semaphore acquisition request is output by a task being executed, the program control unit 105 first receives a hardware semaphore acquisition result, and an area indicating the hardware semaphore acquisition result in the status register (hereinafter, referred to as a hardware semaphore acquisition result) , “Semaphore acquisition result register”) is updated with a flag indicating that the acquisition has succeeded (a flag indicating that the transition to the OS is permitted). On the other hand, if acquisition of the semaphore fails, a flag indicating failure in acquisition (a flag indicating that the migration to the OS has been rejected) is written, the hardware semaphore acquisition is temporarily stopped and break away.

  Furthermore, the program control unit 105 includes an eviction prohibition flag 106. The eviction prohibition flag 106 is a mechanism for prohibiting a task from being ejected from a unit processor when task switching or an external interrupt occurs in a designated unit processor. Setting the eviction prohibition flag 106 to 1 prohibits the task currently in the unit processor from being switched to another task. A state in which task eviction in the unit processor is prohibited is hereinafter referred to as a locked state.

  When an interrupt signal is input from a peripheral chip such as the wireless unit 50, the interrupt control unit 11 arbitrates the interrupt signal and then outputs a predetermined interrupt signal to the unit processor P0. The memory control unit 12 is provided between the CPU 10 and the memory 30 and controls the memory 30 to input / output data when the CPU 10 reads / writes data from / to the memory 30.

  The hardware semaphore unit 13 has a mechanism that realizes exclusive control. When a semaphore acquisition request is received from the unit processors P0 to P3, if the semaphore has already been acquired, the semaphore unit 13 responds to a new request. Notify acquisition failure. On the other hand, if the semaphore has not been acquired before that, it has a function of returning a notification of successful semaphore acquisition to the unit processor.

That is, in this embodiment, only the unit processor that has acquired the hardware semaphore obtains the right to execute the task processing while occupying the OS. For this reason, since only one of the unit processors P0 to P3 can shift to the OS, exclusive control for preventing competition between the OSs can be realized. Then, it is possible to prevent problems such as interruption of processing because a predetermined area of the memory 30 used by the OS is simultaneously accessed.
In the present embodiment, the eviction prohibition flag 106 can prohibit the task from being expelled until the OS service call ends.

  Furthermore, in the present embodiment, execution of interrupt processing by the processor is prohibited during execution of exclusive control. In the present embodiment, the interrupt control unit 11 prohibits execution of interrupt processing. That is, the interrupt control unit 11 includes a status register (not shown) in which the statuses of the unit processors P0 to P3 are written. By setting the status of the status register to “no interrupt”, the interrupt control unit 11 can prohibit interrupt processing for a desired unit processor.

  FIG. 3 is a diagram illustrating the coupling of unit processors in the SMP referred to in the present embodiment. Each of the SMPs shown in FIGS. 3A and 3B is configured by coupling a plurality of unit processors Pu so as to share a memory. The configuration shown in (a) is a configuration called a multiprocessor, and the configuration shown in (b) is called a multithread processor. The multi-thread processor is said to be tightly coupled to the unit processor Pu in that it shares an arithmetic unit more than the multi-processor. Note that the processor of the present embodiment can be configured by adopting either a multiprocessor or a multithread processor as the SMP.

  As shown in FIG. 4A, the SMP processes a plurality of user tasks t1 to t3 in parallel by the multiprocessor-compatible OS 401 corresponding to the multiprocessor. In the function distributed processor, as shown in (b), each processor processes a plurality of tasks (task group) by an interrupt by the OS unit (for example, the OS unit 403a uses the interrupt handler 402). A plurality of tasks included in the user task group t11 are processed).

  The processor of this embodiment forms a multiprocessor by combining a part of a plurality of unit processors. For this reason, the SMP and the function distribution type processor coexist in the processor, and the SMP is operated by the OS 401 corresponding to the multiprocessor. The function distribution processor is operated by the OS unit 403a and the like. Therefore, a plurality of OSs operate on the processor of this embodiment. FIG. 5 shows a state where the processor is operated by a plurality of OSs.

In this embodiment, the unit processor 0 and the unit processor 3 correspond to first processors that execute tasks by the OS units 403a and 403c, which are first operating systems. The unit processor 1 and the unit processor 2 constituting the SMP 5 correspond to a second processor that executes a task by the multiprocessor-compatible OS 401 that is the second operating system.
In addition, as described above, in this embodiment, the task arbitration unit 210 stores task information related to tasks executed by the unit processor 0 and the unit processor 3, tasks executed by the unit processor 1 and the unit processor 2, and the like. I am exchanging with the task.

Next, task arbitration of the processor of this embodiment will be described.
The processor according to the present embodiment exchanges task information with other processors through inter-task communication, and arbitrates tasks. Communication between tasks is generally executed by an event flag, a semaphore, a message queue, a mailbox or the like. In addition, the processor of this embodiment shall perform communication between tasks by an event flag among the methods mentioned above. However, the present embodiment is not limited to such a configuration, and can be realized by adopting any inter-task communication method.

  Inter-task communication by event flag is performed by a processor that is a task information transmission source, an instruction (command) to a processor that is a processing request destination, ID information for specifying the request destination processor, and data for executing the instruction. Etc. as task information and sent to the interface area. On the other hand, the processor that has received the task information returns it by writing the data indicating the execution result of the command and the end code as task information to the interface area. The request source processor waits by polling or the like until the status flag of the interface area to which the request destination processor performs writing ends.

  In the present embodiment, the range of tasks to which task information is exchanged is set by adding OS identification information. That is, inter-task communication is conventionally performed by specifying a task ID in a service call. In this embodiment, the ID of the task is extended, and an ID that also specifies the OS used by the processor that processes the task is set in addition to the task. The OS unit in the processor that has received the ID writes information in the interface area and generates a processor interrupt only when it is determined to transmit information to a processor that uses another OS based on the ID.

Such ID setting represents, for example, a number for dividing a ID into upper 16 bits and lower 16 bits, and identifying a task as usual by the lower 16 bits. Further, it can be realized by expressing the class name (the identification number of the OS used by the processor that processes the task) by the upper 16 bits.
The OS identification information can be represented by numbers unique to the OS units 403a and 403c and the multiprocessor-compatible OS 401, for example. In this embodiment, “1” is assigned to the OS unit 403a, “3” is assigned to the OS unit 403c, and “2” is assigned to the multiprocessor-compatible OS 401. The OS identification number can be defined by setting parameters in the initial system. The parameter can be set by boot processing, for example.

  When the identification information “1” is added to the class name, the task information is communicated between tasks executed by the unit processor P0 that operates using the OS unit 403a. When the identification information “2” is added to the class name, the task information is communicated between tasks executed by the unit processors P1 and P2 that operate using the multiprocessor-compatible OS 401. Furthermore, when the identification information “3” is added to the class name, the task information is communicated between tasks executed by the unit processor P3 that operates using the OS unit 403c.

  The designation of such identification information is determined by the type of task. That is, the tasks executed by the processor of this embodiment include a task that cannot receive a message from an OS other than the OS that runs on the processor, and a task that can receive a message from another OS. A task that can receive a message from another OS is referred to as an inter-OS network task, and a task that can receive a message from another OS is referred to as an intra-OS local task.

The inter-OS network task can communicate with any unit processor in an SMP or function distributed processor. The local task in the OS can be communicated only between the unit processors P1 and P2 in SMP, and in the function distributed processor, communication can be performed only between tasks executed by each processor.
Under the above-described conditions, in the present embodiment, arbitrary identification information indicating the OS used by the processor to be communicated is added to the task information of the inter-OS network task. Further, identification information indicating an OS used by a communicable processor is assigned to the task information of the local task in the OS, and a communication range is designated.

  FIG. 6 is a diagram for explaining an interface area 220 to which task information according to this embodiment is exchanged. The illustrated area includes a status flag area 601 for writing a status flag, a command area 602 for writing a command, and an end information area 606 indicating that communication has ended. Among these, the status flag area 601 represents the interface area 220. Examples of the contents set in the status flag area include the following.

• During idling (IDLE) Indicates the initial state and is set when the requesting task recognizes the end state.
Requesting: The requesting task (OS) of the process sets the process when requested.
-During execution: Set when a process execution destination task (OS) receives a process.
End state: Set when the task (OS) that executed the process ends.

  The command area 602 includes an area 603 where a command ID is written, an area 604 where a resource ID is written, and a data area 605. The command ID is information indicating, for example, a write request, a read request, and the like. The resource ID is information for identifying what request the command ID is, and indicates, for example, event flag generation, semaphore acquisition, message queue, and the like. The data area 605 is an area for supplementing data necessary for the command. For example, a write area pointer or a write area pointer is written therein.

The end information area 606 is an area for indicating information when a command is executed by the execution destination task (OS), and for example, information indicating normal end and an error code are written therein.
With the above configuration, the task arbitration unit 210 and the interface area 220 of this embodiment can exchange task information between tasks executed by the OS units 403a and 403c and the multiprocessor-compatible OS 401. The task arbitration unit 210 and the interface area 220 exchange task information between the OS units 403a and 403c, and between tasks executed by the OS units 403a and 403c and tasks executed by the multiprocessor-compatible OS 401. be able to.

  Further, the present embodiment is not limited to attaching identification information of 1, 2, and 3. As other identification information, for example, identification information 0 may be set. The identification information 0 indicates that communication is performed within the OS used by the unit processor that executed the task, regardless of the task information of any task. With this configuration, the unit processor can determine the communication range in a short time without determining the OS or the unit processors P0 to P3 specified from the identification information given to the task information. .

FIG. 7 is a diagram for explaining an interrupt to the requested unit processor. In FIG. 7, a unit processor that transmits task information (requests processing) by inter-task communication is referred to as a requesting processor. A unit processor that is requested to process is referred to as a requested processor.
The requesting processor performs task communication by writing task information in the interface area 220. Then, interrupt processing for the requested processor is executed. The requested processor determines whether or not to accept an interrupt request, and if so, temporarily terminates the currently executed task. Then, task information indicating completion of the task is written in the interface area.

FIG. 8 and FIG. 9 are flowcharts for explaining operations related to inter-task communication among the operations of the processor of the present embodiment described above. Among these, FIG. 8 is a flowchart showing the operation of the requesting processor. FIG. 9 is a flowchart for explaining the operation of the requested processor.
As shown in FIG. 8, the requesting processor sets a request for a task being performed by the requesting processor in the interface area 220. The setting is performed by writing task information in the interface area 220 (S701). Then, an interrupt request is made to the requested processor (S702), and it is determined by polling whether the task information written in the interface area 220 indicates the end of the task (S703).

If it is determined that the task information is in a state indicating termination (S703: Yes), the requesting processor writes task information indicating that its own task communication is terminated in the termination information area of the interface area 220 (S704). .
If the request set in the interface area 220 is addressed to a task corresponding to the OS of the own device, the requesting processor does not generate an interrupt because it is handled as communication addressed to the local task.

  On the other hand, when receiving the interrupt request, the requested processor saves the register at the time of occurrence of the interrupt for returning from the interrupt as shown in FIG. 9 (S901). Then, the command, task ID, etc. included in the task information are checked (S902). As a result, if the command is not properly accepted (S902: NG), the fact that an error has occurred is written in the interface area 220 (S909). ). Then, the saved register data is restored to the state before the occurrence of the interrupt (S910), and the processing of the task executed before the occurrence of the interrupt is continued (S911).

If it is determined in step S902 that the command, task ID, and the like have been properly received (S902: OK), the requested processor registers the requested task in the command queue and the READY queue (S903). Then, a determination process for determining whether or not to generate a task switch is executed (S904).
As a result of the determination in step S905, when task switching is performed (S905: Yes), the context of the task executed before the occurrence of the interrupt is saved (S912). In addition, it is set by writing in the interface area 220 that the task has been completed successfully (S913). Further, the task context registered in the READY queue is extracted (S914), and the task context is switched (S915).

  According to the present embodiment as described above, one multiprocessor can be configured by arbitrarily combining SMPs and function distributed processors. At this time, the SMP and the function-distributed processor can each be operated by an OS that has been conventionally used. For this reason, it is not necessary to construct a new application specialized for a multiprocessor combining an SMP and a function distributed processor. Therefore, this embodiment can contribute to the spread of processors by improving the reliability of the processors and suppressing the development cost.

It is a block diagram which shows the function structure of the mobile telephone concerning this invention. FIG. 2 is a block diagram illustrating an internal configuration of a CPU illustrated in FIG. 1. It is the figure which illustrated the coupling | bonding of the unit processor in SMP said by one Embodiment of this invention. It is a figure for demonstrating general SMP OS and OS of a function distribution type processor. It is the figure which showed the state in which the processor of one Embodiment of this invention operate | moves by several OS. It is a figure for demonstrating the interface area to which the task information of one Embodiment of this invention is transferred. It is a figure for demonstrating the interruption process in the communication between tasks of one Embodiment of this invention. It is the flowchart which showed operation | movement of the request origin processor of one Embodiment of this invention. It is a flowchart for demonstrating operation | movement of the processor of the request destination of one Embodiment of this invention.

Explanation of symbols

5 SMP 11 interrupt control unit, 12 memory control unit, 13 hardware semaphore unit, 30 memory, 210 task arbitration unit, 220 interface area, 401 multiprocessor compatible OS, 403a, 403b, 403c OS unit, 601 status flag area, 602 Command area, 603, 604, 605 area, 606 End information area, P0, P1, P2, P3 Unit processor

Claims (6)

A first processor executing a task with a first operating system and a second processor executing a task with a second operating system;
Task information communication means for exchanging task information related to a task executed by the first processor and a task executed by the second processor with another task;
A processor comprising:   The processor according to claim 1, wherein the task information communication unit exchanges task information between tasks executed by the first operating system and between tasks executed by the second operating system.   2. The processor according to claim 1, wherein the task information communication unit exchanges task information between a task executed by the first operating system and a task executed by the second operating system.   The task information communication means sets a range of tasks to which task information is exchanged by giving identification information for identifying the first operating system and the second operating system to the task information. Item 4. The processor according to any one of Items 1 to 3.   The processor according to claim 1, wherein the task information communication unit includes a storage area in which both the first processor and the second processor can read and write information.   6. The processor according to claim 1, wherein one of the first processor and the second processor is a symmetric multiprocessor, and the other constitutes a function distribution type processor. .

Images