JP2009205585A - Information processor, control method of information processor, and control program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To improve the processing efficiency of an information processor as a whole while efficiently assigning a shared resource to the processor and reducing a load on each processor. <P>SOLUTION: The information processor 10 for performing control so that the shared resource to a plurality of CPU 11A to 11D is provided with: priority storage parts 12A to 12D for storing the level of processing priority executed by the respective CPU 11A to 11D for each of the CPUs 11A to 11D; and an exclusive control unit 13 for defining a CPU which receives an assignment request of the shared resource on the basis of the level of the priority of the respective CPUs 11A to 11D stored in the priority storage parts 12A to 12D when it receives the assignment request of the shared resource from any of a plurality of the CPUs. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

The present invention relates to an information processing apparatus, a control method for the information processing apparatus, and a control program. In particular, in a multiprocessor type information processing apparatus having a plurality of processors, each processor has shared resources such as hardware and data during multitask processing. It is related with the technology which allocates exclusively.

Conventionally, a multitask processor (multitask information processing apparatus) that includes a plurality of processors and processes a plurality of tasks at the same time is known.
In such a multitask processor, when performing exclusive control, for example, access restriction to a memory area to be subjected to exclusive control or bus access restriction is performed (for example, Patent Document 1 or Patent Document 2).
In such a case, for example, a semaphore is used as a technique for performing control for controlling synchronization between processes operating in parallel and control of interrupt processing.
It is used to prevent damage and inconsistency by accessing the memory area and files on the disk among multiple processes at the same time.
JP-A-5-54005 JP 2001-142861 A

In the technique described in Patent Literature 1, when a plurality of processors simultaneously request acquisition of a semaphore, the acquisition of the semaphore is simply performed based on the determination of the bus arbitration circuit, and a plurality of tasks currently being executed are not necessarily obtained. Among them, a processor executing a task with a high priority could not acquire a semaphore.
In the technique described in Patent Document 2, the priority of tasks executed by each processor is not considered.
Therefore, in any of the techniques, there is a problem that a semaphore, that is, a shared resource is not always assigned to a processor that executes a task with a high priority.
Accordingly, an object of the present invention is to provide an information processing apparatus, an information processing method, and a control capable of efficiently allocating / releasing shared resources and improving the processing efficiency of the entire information processing apparatus when performing exclusive control. To provide a program.

In order to solve the above-described problem, a first aspect of the present invention provides an information processing apparatus that performs control for exclusively allocating shared resources to a plurality of processors. When receiving a priority storage unit for each processor and the shared resource allocation request from any of the plurality of processors, the priority level of each processor stored in the priority storage unit is set. And a shared resource management unit that determines a processor that should accept the shared resource allocation request.

According to the above configuration, the priority storage unit stores the priority level of processing executed by each processor for each processor.
Thus, when the shared resource management unit receives a shared resource allocation request from any of the plurality of processors, the shared resource management unit allocates the shared resource based on the priority level of each processor stored in the priority storage unit. Define the processor that should accept the request.
Therefore, shared resources can be allocated in consideration of the priority level of the processing being performed, and shared resources can be allocated efficiently. As a result, the efficiency of the entire information processing apparatus can be improved.

According to a second aspect, in the first aspect, the shared resource management unit assigns a processor having a higher priority level to the processor based on the priority level of each processor stored in the priority storage unit. It is characterized in that it is determined as a processor that should accept a shared resource allocation request.
Therefore, a shared resource can be preferentially assigned to a processor performing processing with a higher processing priority, and a shared resource can be assigned more efficiently.

A third aspect is characterized in that, in the first aspect or the second aspect, the process executed by the processor includes an external interrupt process and a task process.
Therefore, more efficient shared resource allocation can be performed in consideration of external interrupt processing and task processing.

According to a fourth aspect, in any one of the first aspect to the third aspect, the request reception unit includes:
The shared resource release request is received from the processor, and the shared resource management unit assigns a higher priority level than the external interrupt process and the task process to the processor to which the shared resource is allocated, and the process When the request reception unit accepts a release request for the shared resource from the plurality of processors, each of the processors stored in the processing priority storage unit is stored in the priority storage unit. The priority levels are compared with each other, and a processor having a higher priority level is made to release the shared resource as a processor that should accept the shared resource release request.
Therefore, since a processor to which a shared resource has already been allocated can give priority to a request for releasing the shared resource, it is possible to efficiently reallocate the shared resource in the entire information processing apparatus. Can be assigned and used.

According to a fifth aspect, in any one of the first to fourth aspects, a semaphore is used as a storage unit for the exclusive allocation information of the shared resource.
Therefore, exclusive allocation of shared resources can be performed reliably. In this case, the semaphore may be either a software semaphore realized by software or a hardware semaphore realized by hardware.

According to a sixth aspect, in the fifth aspect, the semaphore is a hardware semaphore realized as hardware or a software semaphore realized as software.
Therefore, even if a shared resource allocation request is made simultaneously from a plurality of processors, processing can be performed quickly and reliably.

According to a seventh aspect, in a control method for an information processing apparatus that performs control to exclusively allocate shared resources to a plurality of processors, the priority level of processing executed by each processor is stored for each processor. The priority storage process, and when the shared resource allocation request from any of the plurality of processors is received, the shared resource allocation request should be received based on the stored priority level of each of the processors And a shared resource management process for defining a processor.
According to the above configuration, shared resources can be allocated in consideration of the priority level of the processing being performed, and efficient shared resources can be allocated. As a result, the efficiency of the entire information processing apparatus can be improved.

According to an eighth aspect of the present invention, there is provided a control program for controlling, by a computer, an information processing apparatus that has a storage unit that stores various types of information and performs control for exclusively allocating shared resources to a plurality of processors. The priority level of the process executed by the processor is stored in the storage unit for each processor, and when the shared resource allocation request from any of the plurality of processors is received, each stored in the storage unit Based on the priority level of the processor, a processor to receive the shared resource allocation request is determined.
According to the above configuration, shared resources can be allocated in consideration of the priority level of the processing being performed, and efficient shared resources can be allocated. As a result, the efficiency of the entire information processing apparatus can be improved.
In this case, the control program may be recorded on a computer-readable recording medium.

Next, preferred embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a schematic configuration block diagram of an information processing apparatus according to an embodiment.
The information processing apparatus 10 is configured as a multiprocessor system.
CPUs 11 </ b> A to 11 </ b> D as four processors that perform actual arithmetic processing, and each CPU 11
Corresponding to A to 11D, a priority storage unit 1 that stores the priority levels of the CPUs 11A to 11D
2A to 12D, exclusive control circuit 13 that performs exclusive control including exclusive control of shared resources of CPUs 11A to 11D, and external interrupt request receiving unit 1 that receives external interrupt (external interrupt) requests
4 and external interrupts received by the external interrupt request accepting unit 14 are assigned to the CPUs 11A to 11D.
And an external interrupt processing assigning unit 15 for assigning to.

FIG. 2 is a functional block diagram of the exclusive control circuit.
In the present embodiment, the exclusive control circuit 13 is configured by dedicated hardware that performs shared resource management control including CPU control, shared resource allocation control, and shared resource release control. The exclusive control circuit 13 may not be configured by hardware, but may be configured as a microprocessor unit having a ROM that stores various control programs in advance, a RAM that temporarily stores various data, and the like. is there.
In the exclusive control, the CPUs 11A to 11D are subjected to a coprocessor-like process such as a numerical processor.
The exclusive control circuit 13 is broadly divided to compare the priority levels stored in the priority value storage registers 16A to 16D constituting the priority storage units 12A to 12D, and the CPU having the highest priority as a comparison result. ID for specifying (highest priority CPU) (hereinafter referred to as CPUID)
That's it. ) And an ID for specifying a semaphore (Semaphore) that is an exclusive use right (exclusive use right of a shared resource) that one of the CPUs is trying to acquire or release (
Hereinafter, it is referred to as a semaphore ID. Based on the comparison result of the priority comparison circuit 21 and the stored contents of the semaphore register 22. Each CPU 11A-1 of resources
A semaphore operation circuit 23 that performs allocation control and release control to 1D and updates the semaphore register 22 based on the control result is provided.

Here, the semaphore register 22 will be described.
In this case, in this embodiment, it is assumed that there are eight shared resources.
The semaphore register 22 is roughly classified into a semaphore ID data (= 1 to 8) for specifying a shared resource and a CP that already has a shared resource specified by the semaphore ID data.
A valid data storage unit that stores “1” when acquired by U and stores “0” when no shared resource specified by the semaphore ID data is acquired, and valid data A CPUID storage unit that stores a CPUID for identifying a CPU that has acquired the corresponding shared resource when “1” is stored in the storage unit.
When “0” is stored in the valid data storage unit, the CPU ID stored in the corresponding CPU ID storage unit is the CPU ID of the CPU that acquired the corresponding shared resource last time. Does not affect.
More specifically, in the case of the example of FIG. 2, the shared resource corresponding to semaphore ID data = 1 is acquired by the CPU 11C specified by CPUID = 3, and the two corresponding to semaphore ID data = 5 and 8 are acquired. This shows a state in which one shared resource is acquired by the CPU 11B identified by CPUID = 2, and other shared resources are in an unallocated state (unused state).

In this case, the priority value storage register 16A stores the priority value (
In this embodiment, the register stores 7 bits), and the shared resource acquisition presence / absence storage unit 17A (
In this embodiment, the most significant bit) and the processing priority level storage for storing the priority level (interrupt level) of the external interrupt processing or the task processing priority level that the corresponding CPU 11A is actually processing. 18A (in this embodiment, lower 6 bits). Similarly, the priority value storage register 16B includes a shared resource acquisition presence / absence storage unit 17B and a processing priority level storage unit 18B. The priority value storage register 16C includes a shared resource acquisition presence / absence storage unit 17C and a process. A priority level storage unit 18C, and a priority value storage register 16D
Includes a shared resource acquisition presence / absence storage unit 17D and a processing priority level storage unit 18D.

Here, the priority level will be described.
FIG. 14 is an explanatory diagram of the priority level (processing priority level) of task processing and external interrupt processing.
Since the processing priority level is 6 bits as described above, the value is 0 to 63.
Up to 64 values can be taken. Furthermore, in this embodiment, the priority level of the external interrupt process is set to be higher than the priority levels of all task processes.
That is, in this embodiment, the priority level corresponding to the task process takes a value of 0 to 31, and the priority level corresponding to the interrupt process takes a value of 32 to 63. It is possible to easily determine which of the plurality of processes has a higher priority without considering whether the process is an external interrupt process or a task process simply by comparing the two.

Further, when the shared resource is acquired, the most significant bit (MSB) as the shared resource acquisition presence / absence storage unit 17A is “1”. The priority level is set higher than the unacquired CPU. That is,
The priority level of the CPU that has acquired the shared resource takes a value of 64 to 127.
Therefore, the priority comparison circuit 21 can easily refer to the priority level and the semaphore register 22 stored in the priority value storage registers 16A to 16D when a shared resource acquisition request or release request is made, and can easily perform the CPU 11A. ˜11D, it can be easily determined which CPU's shared resource acquisition request or shared resource release request should be received and processed.

Next, the outline operation will be described.
In the following description, it is assumed that the semaphore register 22 is in the state shown in FIG.
First, a case where the CPU 11A executing the task process TA (priority level = “0001101”) makes a shared resource acquisition request under this situation will be described.
Here, the CPU 11B is executing an external interrupt process EB (priority level = “1011111”), the CPU 11C is executing a task process TC (priority level = “1010001”), and the CPU 11D is executing a task process. It is assumed that TD (priority level = “0000111”) is executed. In other words, the priority level of processing is
(High) External interrupt processing EB> task processing TC> task processing TA> task processing TD
Therefore, the priority level of the CPU is
(High) CPU11B>CPU11C>CPU11A> CPU11D (Low)
It has become.

First, a case where the CPU 11A makes a request for acquiring a shared resource with a semaphore ID = 2 will be described.
When the CPU 11A requests acquisition of the shared resource with semaphore ID = 2, the semaphore I
Since the shared resource with D = 2 is an unacquired resource for any CPU, the CPU with the highest priority level will acquire the shared resource with semaphore ID = 2.

That is, the CP that has requested acquisition of the shared resource with semaphore ID = 2 at the same time as the CPU 11A
When there is no U, or when the CPU that has made an acquisition request at the same time is the CPU 11D, the priority comparison circuit 21 determines that the CPU 11A is the most among the CPUs that have made an acquisition request for the shared resource with semaphore ID = 2 It is determined that the priority level is high, and the semaphore operation circuit 23 refers to the semaphore register 22 and determines that the shared resource with the semaphore ID = 2 has not been acquired.
Accordingly, the priority comparison circuit 21 gives the highest priority CPU to the semaphore operation circuit 23.
As the ID, CPUID = 1 corresponding to the CPU 11A is output, and semaphore ID = 2 corresponding to the shared resource to be acquired is output.
As a result, the semaphore operation circuit 23 assigns the shared resource with the semaphore ID = 2 to the CPU 11A, sets the valid data corresponding to the semaphore ID = 2 to “1”, and sets the corresponding CP.
Update to UID = "1".

On the other hand, when the CPUs that have made acquisition requests at the same time are the CPU 11B or the CPU 11C, the priority comparison circuit 21 has made a request to acquire a shared resource with a semaphore ID = 2.
Among the PUs, the CPU 11B or the CPU 11C determines that the priority level is the highest, and the semaphore operation circuit 23 refers to the semaphore register 22 and determines that the shared resource with the semaphore ID = 2 has not been acquired.
Accordingly, the priority comparison circuit 21 gives the highest priority CPU to the semaphore operation circuit 23.
As the ID, CPUID = 2 corresponding to CPU 11B = 2 or C corresponding to CPU 11C
In addition to outputting PUID = 3, semaphore ID = 2 corresponding to the shared resource to be acquired is output.
As a result, the semaphore operation circuit 23 assigns the shared resource with the semaphore ID = 2 to the CPU 11B or the CPU 11C and assigns the valid data corresponding to the semaphore ID = 2 to “2”.
"Or" 3 ", and the corresponding CPU ID is updated to" 2 "or" 3 ".

Next, a case where the CPU 11C makes a release request for the shared resource with semaphore ID = 1 will be described.
When the CPU 11C requests release of the shared resource with semaphore ID = 1, the CPU 11
CPU that issued a shared resource acquisition request simultaneously with C and CPU that issued a shared resource release request
If there is not, the CPU 11C determines that the priority level is the highest, and the semaphore operation circuit 23
Refers to the semaphore register 22 and determines that the shared resource of semaphore ID = 1 has been acquired by the CPU 11C.
Accordingly, the priority comparison circuit 21 gives the highest priority CPU to the semaphore operation circuit 23.
As the ID, CPUID = 3 corresponding to the CPU 11C is output, and semaphore ID = 1 corresponding to the shared resource to be released is output.
As a result, the semaphore operation circuit 23 releases the shared resource with the semaphore ID = 1, sets the valid data corresponding to the semaphore ID = 1 to “0”, and ends the process.

Further, at the same time when the CPU 11C makes a request for releasing the shared resource with the semaphore ID = 1, the CPU that makes the request for acquiring the shared resource or the request for releasing the shared resource makes the CPU 11A or C
In the case of the PU 11D, the priority comparison circuit 21 includes the CPU 11 among these CPUs.
It is determined that C has the highest priority level, and the semaphore operation circuit 23 refers to the semaphore register 22 and determines that the shared resource of semaphore ID = 1 has been acquired by the CPU 11C.
Accordingly, the priority comparison circuit 21 gives the highest priority CPU to the semaphore operation circuit 23.
As the ID, CPUID = 3 corresponding to the CPU 11C is output, and semaphore ID = 1 corresponding to the shared resource to be released is output.
As a result, the semaphore operation circuit 23 releases the shared resource with the semaphore ID = 1 and updates the valid data corresponding to the semaphore ID = 1 to “0”.
Therefore, thereafter, the shared resource with the semaphore ID = 1 is acquired by the CPU that intends to acquire the shared resource.

As described above, according to the present embodiment, the shared resource is the CP that has simultaneously requested acquisition.
Since U11A to 11D are assigned and acquired by the CPU having the highest processing priority, the processing can be performed efficiently, and as a result, the processing efficiency of the entire information processing apparatus can be improved.
Similarly, when the shared resource is released, the CPU 1 that has issued a release request (or acquisition request) at the same time.
1A to 11D are preferentially received from the CPU having the highest processing priority, in particular, the CPU that is currently acquiring the shared resource. Can be processed.

A specific embodiment will be described below.
[1] Configuration of Information Processing System FIG. 3 is a detailed block diagram of the information processing system.
The information processing system 100 is roughly divided into CPUs (processors) 101A to 101D as a plurality of processors, and an information processing apparatus according to this embodiment that performs arbitration such as task allocation and shared resource allocation in the plurality of CPUs 101A to 101D. Coprocessor (information processing apparatus) 102.

Here, the coprocessor 102 will be described.
The CPUs 101A to 101D in this embodiment include a CPU bus interface for performing communication via a normal CPU bus, and a coprocessor bus interface for performing communication with the coprocessor 102 via the coprocessor bus. Yes.
As a result, each of the CPUs 101A to 101D outputs the coprocessor instruction to the coprocessor 102 via the coprocessor bus and the data input via the coprocessor bus in parallel with normal data input / output via the CPU bus interface. Output is possible.
Since such a configuration is adopted, according to the coprocessor 102 of the present embodiment, each CP
The effect that the functions that U101A to 101D do not (standard) can be expanded flexibly in both hardware and software is obtained.

The coprocessor 102 receives a debug interrupt request from the outside and outputs a debug interrupt request signal, and an external interrupt that accepts an external interrupt request and outputs an external interrupt request signal An input reception circuit 111, a processing request reception circuit 112 that receives processing requests from a plurality of CPUs to a coprocessor and outputs processing request signals, and a debug interrupt request signal, an external interrupt request signal, and a processing request signal are input. , Processing request factor determination circuit 11 that performs priority determination for each request signal and notifies the control unit described later of the priority determination result for each request.
3, an allocation target determination circuit 114 that determines a CPU to be processed (task switch target) based on the contents of an individual register section described later, and an interrupt request based on the determination result of the allocation target determination circuit 114 Interrupt request generation circuit 1 for causing each CPU 11A to 11D to perform an interrupt process
15.

In addition, the coprocessor 102 manages a CPU that is a process allocation target (task switch target or external interrupt process allocation target), or a common register unit that has a common register that stores management data for managing an external interrupt state 116, the individual register unit 117 having individual registers for storing the processing priority level data and the state of each of the CPUs 11A to 11D, and the exclusive processing for maintaining the logical consistency of processing data such as allocation of shared resources An exclusive control unit 118 that performs exclusive control when processing is necessary, and the CPUs 101A to 101A
A decoder 119 that decodes a coprocessor instruction from an OS (operating system) operating in 101D, a sequencer 120 that performs sequence control of a command decoded by the decoder 119, and a command that is decoded under the control of the sequencer 120 And a control unit 121 for controlling the entire coprocessor 102.
The common register unit 116 is roughly divided into task switch target CPUID registers ttc.
r, an external interrupt status register isr, and an illegal operation detection register iodr.
The individual register unit 117 is roughly classified into a first register group 117A that stores data corresponding to the CPU 101A and a second register group 1 that stores data corresponding to the CPU 101B.
17B, a third register group 117C for storing data corresponding to the CPU 101C, and CP
And a fourth register group 117D for storing data corresponding to U101D.

[2] Input / output signals of the coprocessor Here, the input / output signals of the coprocessor will be briefly described.
FIG. 4 is an explanatory diagram of input / output signals of the coprocessor.
In FIG. 4, for example, the c33_co_din_i signal has a bit width of 32 bits, the input / output direction is the output direction (O), and it can be seen that it is a data output signal line to the CPU. Similarly, it can be seen that the clken signal is an input direction (I) in the input / output direction and is a clock enable signal of the coprocessor. Also, it can be seen that the c33_int_lv_i signal has a bit width of 4 bits, the input / output direction is the output direction (O), and is a signal representing the interrupt level to the CPU. Similarly, it can be seen that there are 8 output signals and 14 input signals.

[3] Configuration of Common Register Unit Here, each register configuring the common register unit will be described.
[3.1] External Interrupt Status Register FIG. 5 is an explanatory diagram of the bit format of the external interrupt status register.
External interrupt status register (Interrupt Status Register)
) Isr is a 32-bit register as shown in FIG.
The 19th to 16th bits of the external interrupt status register isr are fields in which the external interrupt level is stored. (Indicated by r in the figure, the same applies hereinafter).

The external interrupt level indicates an acceptable external interrupt level, and a settable value is 0 to 15 that can be expressed by 4 bits. The coprocessor masks external interrupts below the level specified in this field. For example, when the value of the set external interrupt level is 3, an external interrupt having a level of 4 or higher is accepted, and an external interrupt having a level of 3 or lower is masked and not accepted. Note that in this embodiment, when an external interrupt is accepted, the coprocessor 102 does not update this field, so the input of the external interrupt level is kept constant until the CPUs 101A to 101D start interrupt processing. There is a need.
The eighth bit of the external interrupt status register isr is a field for storing an external interrupt permission state flag. If this 8th bit is “1”, enable interrupts,
When it is “0”, interrupts are prohibited. When any arbitrary CPU is in the debug mode, the coprocessor masks the external interrupt regardless of the setting of the external interrupt permission state flag.

In addition, the 0th bit of the external interrupt status register isr is set to the other C when the BRK instruction (break instruction) is executed in any arbitrary CPU and transitions to the debug mode.
This is a field for designating ON / OFF of a hardware debug mode for designating a method for generating a debug interrupt for the PU. When the 0th bit is “1”, the hardware debug mode is turned on, and when the coprocessor detects that any arbitrary CPU has entered the debug mode, the coprocessor sends a debug interrupt to another CPU. Is generated. If the 0th bit is “0”, the hardware debug mode is turned off, and even if the coprocessor detects that any CPU has entered the debug mode, Do not generate a debug interrupt to the CPU. In this case, the CPU that has transitioned to the debug mode needs to transition the other CPU to the debug mode by executing an fbrk instruction (described in detail later) for generating a debug interrupt to the other CPU.
[3.2] Hardware Semaphore Register FIG. 6 is an explanatory diagram of the bit format of the hardware (HW) semaphore status register.
Hardware (HW) semaphore status register (Hardware Semaph)
or Status Register) hssr is a 32-bit register.
The 7th to 0th bits of the hardware semaphore status register hssr
Each bit is assigned to the corresponding hardware semaphore. For example, the seventh bit is assigned to the hardware semaphore with semaphore ID = 7, and the fourth bit is semaphore I.
Assigned to a hardware semaphore with D = 4. If the corresponding hardware semaphore has already been assigned to any CPU and acquired, the bit is set to “
1 "so that it can be easily grasped that it is in use.

[3.3] Task Switch Target CPUID Register FIG. 7 is an explanatory diagram of the bit format of the task switch target CPUID register.
Task switch target CPUID register (Taskswitch Target CP
(UID Register) ttcr is a 32-bit register as shown in FIG.
The 7th to 0th bits of the task switch target CPUID register ttcr are fields for storing a CPUID for specifying the task switch target CPU.
Each bit of this field can only be read.
The task switching target CPU indicates the following states (1) and (2).
(1) CPU in HALT state
(2) Next, a CPU to which an external interrupt process is assigned (a CPU in a HALT state)
Is not present)

Here, when there are a plurality of CPUs that match the same condition, the coprocessor determines one of them and sets the task switch target CPU ID.
Among the above states, when there is a CPU in the HALT state, the ID of the CPU in the HALT state is represented in the range of 0 to 126.
Further, when there is no CPU in the HALT state, it indicates the ID of the CPU to which the next external interrupt processing is assigned in the range of 128 to 254. This value is the ID of the target CPU. 128 is added (for example, CPUID is “1”)
In this case, “129” is set as the CPUID).
If the coprocessor cannot set an appropriate CPU ID, a value of 127 or 255 is set as the error pattern.

[3.4] Unauthorized Operation Detection Register FIG. 8 is an explanatory diagram of the bit format of the unauthorized operation detection register.
Illegal operation detection register (Illegal Operation Detection)
Register) iodr is a 32-bit register, as shown in FIG.
The second bit of the illegal operation detection register iodr is set when an internal interrupt instruction is executed.
This is an internal interrupt failure flag that becomes “1” when the target CPU cannot generate an internal interrupt because the internal interrupt is prohibited, and writing and reading are possible.
The first bit of the illegal operation detection register iodr is “1” when a hardware semaphore that has not been acquired is released by a frs instruction for releasing the hardware semaphore.
This is an illegal release flag of the hardware semaphore that can be written and read.
The 0th bit of the illegal operation detection register iodr is a coprocessor undefined instruction execution flag that becomes “1” when an instruction code not defined by the coprocessor is executed.
Can be written and read.

[4] Individual Register Unit Next, each register constituting the individual register unit 117 will be described with reference to FIG. 3 again.
The first register group 117A of the individual register unit 117 includes a priority value holding register 131A that stores processing priority level data of task processing or external interrupt processing that the CPU 101A is processing, and a CPU that represents the operating state of the CPU 101A. CPU for storing state data
Status register 132A.
The second register group 117B includes a priority value holding register 131B for storing processing priority level data for task processing or external interrupt processing being processed by the CPU 101B, and CP
And a CPU status register 132B that stores CPU status data representing the operating status of the U101B.

The third register group 117C includes a priority value holding register 131C for storing processing priority level data of task processing or external interrupt processing being processed by the CPU 101C, and CP
And a CPU status register 132C that stores CPU status data representing the operating status of the U101C.
The fourth register group 117D includes a priority value holding register 131D that stores processing priority level data of task processing or external interrupt processing being processed by the CPU 101D, and CP
And a CPU status register 132D that stores CPU status data representing the operating status of the U101D.

Here, tisr and CP function as priority value holding registers 131A to 131D.
A specific configuration of the CPU status register csr functioning as the U status registers 132A to 132D will be described.
[4.1] Task / interrupt status register tisr
FIG. 9 is an explanatory diagram of the bit format of the task / interrupt status register.
Task / interrupt status register (Task / Interrupt Status)
(Register) tisr is a 32-bit register as shown in FIG.
The 31st to 16th bits of the task / interrupt status register tisr are
This is a control bit for software. As a field that can be used arbitrarily by software,
Can be written and read.
The 12th bit of the task / interrupt status register tisr is set to RUN / HA.
This LT state flag indicates the state of the corresponding CPU. This flag is updated only by the coprocessor 102 and can only be read from the CPU side. CP
U's SLEEP state is not reflected. This flag is “1” when the CPU is in the HALT state.
Set to "".

The eighth bit of the task / interrupt status register tisr is an internal interrupt permission flag, which controls an interrupt from the coprocessor 102 to the CPU, and is set to “1” when interrupt is permitted. When an internal interrupt is generated, the coprocessor 102
This flag is set to “0” to set interrupt disable. Furthermore, the flag is not updated if the internal interrupt fails. When assigning external interrupt processing, the coprocessor 102 sets this flag to disable interrupts.
The sixth bit of the task / interrupt status register tisr is a flag indicating whether or not the CPU is in a debug state, and can only be read from the CPU side. This flag is updated only by the coprocessor 102 and is set to “1” in the debug state.
The fifth bit of the task / interrupt status register tisr is an interrupt / task status flag indicating whether the process being executed by the CPU is an interrupt process or a task process. “1” is set in the case of an embedded process. This flag can be written and read.
When executing task processing and when returning from interrupt processing to execution of task processing, it is updated by software, and when interrupt processing is assigned to a CPU executing task processing, it is updated by coprocessor 102 Will be. It is not updated for internal interrupts.

The fourth to first bits of the task / interrupt status register tisr are C
This is a field indicating the priority (in the case of a task) or the interrupt level (in the case of external interrupt processing) of processing executed in the PU. In this field, possible values are values of 0 to 15 in either case of task processing or interrupt processing.
When executing task processing and when returning from interrupt processing to execution of task processing, it is updated by software. When assigning interrupt processing to a CPU that is executing a task, it is updated by the coprocessor 102. It is not updated for internal interrupts.
The 0th bit of the task / interrupt status register tisr is a multiple interrupt flag indicating whether or not the interrupt processing being executed by the CPU is a multiple interrupt, and is set to “1” at the time of multiple interrupts. The
When the interrupt / task status flag indicates task processing ("0"), even if this multiple interrupt flag is set to "1", it is invalid.
The multiple interrupt flag is updated by software when returning from multiple interrupt processing to non-multiple interrupt processing or when generating a multiple interrupt in a CPU in a non-multiple interrupt processing state.

[4.2] CPU status register csr
FIG. 10 is an explanatory diagram of the bit format of the CPU status register.
The CPU status register (CPU Status Register) csr is a 32-bit register as shown in FIG.
The 23rd to 16th bits of the CPU status register csr are fields indicating a hardware semaphore that has been successfully acquired by the CPU. When the 23rd bit is “1”, the seventh hardware semaphore (semaphore) ID = 7), and when the 22nd bit is “1”, the sixth hardware semaphore (semaphore ID =
6) is obtained, and in the same manner, when the 16th bit becomes “1”, the 0th
Indicates that the second hardware semaphore (semaphore ID = 0) has been acquired.
This field is updated when a tas instruction (to be described later) or an frs instruction to be described later is executed, and is set to “1” during successful acquisition of the hardware semaphore or during acquisition.
The 7th to 0th bits of the CPU status register csr are fields for specifying a target CPU ID when an operation (load / store) is performed on a register specific to each CPU. Is 0-126. This field
Can be written and read.

[5] Exclusive Control Unit FIG. 11 is a schematic configuration block diagram of the exclusive control unit.
The exclusive control unit 118 is roughly classified into a semaphore register 140 that stores the state of the hardware semaphore, and a semaphore reservation block unit 141 that stores information for the CPUs 101A to 101D that could not acquire the semaphore to reserve acquisition of the semaphore. And a semaphore operation unit 142 that performs a semaphore operation based on the state of the hardware semaphore status register hssr and the semaphore reservation block unit 141.

[5.1] Semaphore Register FIG. 12 is a schematic configuration block diagram of a semaphore register.
The semaphore register 140 includes eight semaphore information storage units 143-0 to 143-7 respectively corresponding to eight shared resources (semaphore ID = 0 to 7).
Each semaphore information storage unit 143-0 to 143-7 has the same configuration, and semaphore I
When the semaphore corresponding to D is acquired, it is “1”, and when the semaphore is not acquired, it is “0”. The semaphore acquiring flag 144A and the semaphore corresponding to the semaphore ID are acquired and the semaphore is being acquired A semaphore acquiring CPUID storage unit 144B that stores a CPU ID for identifying the CPU that has acquired the semaphore as the CPU ID acquiring semaphore when the flag 144A is “1”;

[5.2] Semaphore Reservation Block Unit FIG. 13 is a schematic configuration block diagram of the semaphore reservation block unit.
The semaphore reservation block unit 141 has eight semaphore reservation queues 145-0 to 145-7 that correspond to the eight semaphores, respectively. These 8 semaphore reservation queues 1
45-0 to 145-7 have the same configuration, and three-stage FIFO (First In First Out) type reservation information storage units 146-1 to 146-1 are provided so that three CPUs can each make a semaphore reservation. 146-3.
Each reservation information storage unit 146-1 to 146-3 has the same configuration, and a semaphore reservation flag 147 for determining whether or not it is in a reservation state, and a CPU performing reservation for semaphore acquisition.
And a semaphore reservation CPUID field 148 for storing a CPUID for specifying the ID.

[5.3] Processing Priority Level Data Next, processing priority level data stored in the individual register 25 will be described.
FIG. 14 is an explanatory diagram of an example of the data format of the processing priority level data.
The processing priority level data 40 is 6-bit data, and a 1-bit processing type flag I / T and a 4-bit priority level field PR from the upper bit (MSB) side to the lower bit (LSB) side. And a 1-bit multiple interrupt level flag IN.
The process type flag I / T is data indicating whether the process target is a task process or an external interrupt process. In the case of this embodiment, if the process target is a task process, the process type flag I / T
If it is = 0 and external interrupt processing, the processing type flag I / T = 1.
The priority level field PR is data representing the priority of processing, and is 0 to 15 (0h to
Fh: h represents a hexadecimal number. same as below. ) Value. Priority level data = 0 is the lowest priority, and priority level data = 15 is the highest priority.
The multiple interrupt level flag IN is data indicating whether or not an external interrupt process (multiple interrupt process) is further performed during the interrupt process. When the multiple interrupt level flag IN = 0, it indicates that the multiple interrupt has not been made, and when the multiple interrupt level flag IN = 1, it indicates that the multiple interrupt has been made.

[5.4] Memory Map of Coprocessor Next, a memory map of the coprocessor will be described.
FIG. 15 is an explanatory diagram of a memory map of the first mode of the coprocessor 102.
In addition to this, in a multiprocessor configuration, a stack area is provided for each CPU for the CPU to save the register by executing a debug interrupt or a brk instruction. The size of each stack is 256 bytes. These areas are, in order from the top of the memory address, a CPU 101A (shown as CPU0 in the figure), a CPU 1014B (in the figure,
Shown as CPU1. ),... And the number of CPUs are assigned in the lower address direction.
As shown in FIG. 15, the areas assigned to the CPUs 101A to 101D are reserved areas (Reserved).
It cannot be used and the lower 8 bits of the address are 0x10h to 0xFFh.
It can be used freely in the debug routine.

FIG. 16 is an explanatory diagram of a memory map of the second aspect of the coprocessor.
Compared to the first mode, the reserved area is increased, but the debug area to be secured is the same.
As shown in the memory maps of FIGS. 15 and 16, in this embodiment, a debug stack area is provided for each CPU. When the software accesses the stack area, it is accessed by a common address from any of the CPUs 101A to 101D. It needs to be possible.
Therefore, in the present embodiment, an address decoder is provided as hardware that offsets the addresses output from the CPUs 101A to 101D according to the CPU.

FIG. 17 is an explanatory diagram of addresses of the stack area for debugging corresponding to the four CPUs 101A to 101D when the memory map of the first aspect is used.
FIG. 17 shows that the debug base address specified by the CPU dbbr register is “0x0”.
“00600000h” and the address of the stack area for debugging for each CPU in the 4-CPU configuration. In FIG. 17, the address corresponding to the CPU 101A shown in the broken line circle is used by each software as a representative address corresponding to the actual address of the other CPUs 101B to 101D. Thereby, the address decoder supports a function of converting the address of the representative value generated by the software into an address corresponding to the CPUs 101A to 101D that are processing the software. As a result, by designating this address representative value, the software is guaranteed to be converted into an appropriate address regardless of which CPU 101A to 101D is executed.

On the other hand, since the debug exception processing vector is common to all the CPUs 101A to 101D, no address offset is performed for this. The data of the addresses corresponding to the PC and R0 is stored in each CPU 101A when the brk instruction is executed or when a debug interrupt is generated.
Since the addresses are automatically saved in the debug modules included in each of the devices 101 to 101D, no address offset is performed for these addresses.

[6] Instruction Set Next, the instruction set of the coprocessor will be described.
In this embodiment, the instruction set of the coprocessor is roughly divided into three types: store instructions, load instructions, and other instructions.
When the CPUs 101A to 101D request the coprocessor 102 to execute an undefined instruction, an error occurs and the coprocessor undefined instruction execution flag UI of the illegal operation detection register iodr is set. However, although an error occurs, it is not an exception, and an ack signal is returned to the CPU that has requested the coprocessor process without affecting anything else.

[6.1] Store system instruction set FIG. 18 is an explanatory diagram of an instruction format of a store system instruction.
As store instructions, there are the following 11 instructions as shown in FIG. Details will be described later.
(1) st. isr instruction (2) st. sist instruction (3) st. scsr instruction (4) st. ptisr instruction (5) st. pcsr instruction (6) st. iodr instruction (7) csw instruction (8) ivk instruction (9) haltcpu instruction (10) tas instruction (11) frs instruction

[6.2] Load Instruction Set FIG. 19 shows an instruction format of a load coprocessor.
There are the following nine instructions as load instructions. Details will be described later.
(1) ld. isr instruction (2) ld. hssr instruction (3) ld. sist instruction (4) ld. scsr instruction (5) ld. ptisr instruction (6) ld. pcsr instruction (7) ld. iodr instruction (8) ld. pcpuid instruction (9) ld. ttcr instruction

[6.3] Other Instruction Set FIG. 20 shows the instruction format of other coprocessors.
As other instructions, there are the following two instructions. Details will be described later.
(1) fbrk instruction (2) iaack instruction

[7] Task priority / interrupt level In the task / interrupt status register tisr provided for each CPU, the priority or interrupt level of the currently executed task is written.
The priority level field PR indicating the task priority or the interrupt level is 4 bits wide, and a value from 0 to 15 can be set.
In addition, in order to express the distinction between tasks and interrupt processing, I / T (Interrupt /
Task) flag.
In the case of interrupt processing, IN (Interrupt) is used to indicate whether or not there are multiple interrupts.
(Nesting) flag is used.

Here, description will be given with reference to FIG. 13 again.
In FIG. 13, when the highest priority of the task is 0, the lowest priority is 15, the highest interrupt level is 15, and the lowest level is 0, the priority when the task and the interrupt are handled consistently in the coprocessor. Shows about.
In this case, when the interrupt levels are the same, the multiple interrupt has a higher priority in the coprocessor. Further, there is no combination of I / T flag = 0 and IN flag = 1, and in such a case, the interpretation is made as I / T flag = 0 and IN flag = 0.

FIG. 21 is an explanatory diagram of the CPU vector table corresponding to the internal interrupt instruction.
This reserved interrupt vector (vector) is assigned to each of the three internal interrupt instructions listed above and redefined as shown in FIG.

[8] Coprocessor Trap Factor Next, the trap processing of the coprocessor 102 will be described.
FIG. 22 is an explanatory diagram of the trap factor of the coprocessor.
When a plurality of trap factors occur simultaneously, the coprocessor 102 performs trap processing based on the priority order. When the trap factor is reset (Reset), the trap processing is immediately accepted regardless of the state of the coprocessor 102. The highest priority among trap factors other than reset is the internal interrupt processing request (Internal Inter
rupt). The next highest priority is the request from the coprocessor (Co-Proce
ssor Request).
When the trap factor is a debug exception, a debug interrupt signal is immediately output even when an instruction is being executed by the coprocessor. this is,
The fact that the coprocessor 102 cannot move to the next operation is used during the coprocessor processing request.

For other trap factors (NMI and Maskable Interrupt), if an instruction is being executed in the coprocessor, the instruction is suspended until the end, and after the coprocessor instruction is completed, the priority of the factor is determined and the process proceeds to trap processing. If the coprocessor instruction is not executed, the process immediately moves to trap processing.

[9] Interrupt processing Next, the operation at the time of interruption will be described.
FIG. 23 is an explanatory diagram of a comparison outline of interrupt processing.
[9.1] Maskable Interrupt First, maskable interrupt (INT) will be described.
Priority conditions (1) to (4) for assigning interrupt processing to each of the CPUs 101A to 101D when a maskable interrupt occurs are shown.
(1) CPU in HALT state
(2) CPU executing a lower priority task
(3) C executing interrupt processing at a lower interrupt level, including multiple interrupts
PU
(4) In ascending order of CPU ID (when task priorities being executed by all CPUs are all the same)

When assigning an interrupt process, the coprocessor 102 appropriately updates the interrupt / task status flag I / T and the priority level field PR of the task / interrupt status register tisr of the CPU to which the interrupt process is assigned.
Also, the internal interrupt permission flag IIE of the task / interrupt status register tisr is set to disabled. This is because the software updates the interrupt flag IN and prevents updates due to other factors. After updating the interrupt flag IN, the internal interrupt permission flag IIE is reset to permitted. This resetting is desirably performed at the end of the entrance processing in the interrupt processing routine.

On the other hand, when the CPU 101A to 101D finishes the interrupt process and returns to the execution of the task, the lower 6 bits of the task / interrupt status register tisr are appropriately updated by software.
Furthermore, it is necessary to update the interrupt / task status flag I / T from interrupt to task. Similarly, when exiting the multiple interrupt state, it is necessary to update the interrupt flag IN from a multiple interrupt to a non-multiple interrupt. In the case of multiple interrupts, the number of multiple interrupts must be managed on the software side.
In addition, CPUs that meet the following conditions (1) and (2) are excluded from the allocation targets for the interrupt process.
(1) CPU that is acquiring HW semaphore
(2) CPU prohibiting internal interrupts

If an interrupt process cannot be assigned, the task switch target CP
An error pattern is set in the UID register ttcr. Especially all CPU101A ~ 101D
In the case where the internal interrupt is prohibited, the coprocessor 102 masks the maskable interrupt.
Next, acceptance of interrupt processing will be described.
In the interrupt processing routine executed by the CPUs 101A to 101D, the interrupt generation source (for example, an external peripheral device) is directly notified that the interrupt processing has been accepted.
That is, the CPU that receives the interrupt process request issues an acceptance notification, the interrupt generation source is notified of the interrupt request, and the coprocessor 102 is notified in the order of interrupt process allocation completion notification.

Next, the end of the interrupt process will be described.
In the interrupt processing routine executed by each of the CPUs 101A to 101D, the end of the interrupt processing is notified to the coprocessor 102 by the following operation.
When returning from a non-multiple interrupt to a task, the interrupt / task status flag I / T of its own task / interrupt status register tisr is updated to the task, and the priority level field PR is set to the priority of the task before the interrupt is generated. Return to degrees.
When returning from a multiple interrupt to a non-multiple interrupt, the interrupt flag IN of its own task / interrupt status register tisr is updated to a non-multiple interrupt, and the priority level field PR field is set to the interrupt level before the multiple interrupt. Return to.
When returning from a multiple interrupt state of three or more times to a multiple interrupt state of two or more times, the priority level field PR of its own task / interrupt status register tisr is set to the interrupt level of the previous multiple interrupt. return.

Next, mask conditions will be described.
The interrupt level of the generated interrupt factor is less than the interrupt level set in the IL field of the external interrupt status register isr, and one of the following conditions (1) to (5
), The interrupt is masked regardless of the setting of the IE flag of the external interrupt status register isr.
(1) In a hard debug state.
(2) Task / interrupt status register tisr of all CPUs 101A to 101D
The internal interrupt enable flag IIE is set to disable internal interrupts.
(3) An interrupt signal INT is being output to any of the CPUs 101A to 101D.
(4) The interrupt level of the new interrupt factor is less than the interrupt level of the interrupt factor currently being processed.
(5) The value of ttcr is an error pattern.

[9.2] NMI
Next, NMI (Non-Maskable Interrupt) will be described.
Only one NMI port is provided outside the coprocessor 102 regardless of the number of CPUs. Therefore, when an NMI is generated from the outside of the coprocessor 102, the NMI is generated simultaneously from the coprocessor 102 to all the CPUs 101A to 101D. In the present embodiment, such a special operation is performed. Therefore, when the NMI occurs, the coprocessor 102 sets the external interrupt permission flag IE of the external interrupt status register isr to interrupt disabled.
External interrupts are prohibited.
In this embodiment, the software needs to reset the external interrupt permission flag IE in order to permit the external interrupt again after the end of the NMI.
In the case of NMI, unlike the maskable interrupt, the C to which interrupt processing is assigned.
The lower 6 bits of the PU task / interrupt status register tisr are not updated.

When accepting an NMI interrupt process, as in the case of a maskable interrupt, the interrupt source is directly notified that the interrupt has been accepted within the interrupt processing routine executed by the CPU.
That is, the CPU that receives the interrupt process request issues an acceptance notification, the interrupt generation source is notified of the interrupt request, and the coprocessor 102 is notified in the order of interrupt process allocation completion notification.
Also, at the end of the NMI interrupt process, unlike the maskable interrupt, the end of the interrupt process is not notified.
NMI is an interrupt that is not originally masked, but the following conditions (1), (2
) Is masked only when this holds true.
(1) Hard debug state.
(2) An NMI signal is being output to the CPU.

[9.3] Internal interrupt processing Next, internal interrupts will be described.
By executing an internal interrupt command, an interrupt is generated for the target CPU. When an interrupt is generated from the coprocessor 102 to the CPUs 101A to 101D, the interrupt level is set to the minimum. In this case, as in NMI, the lower 6 bits of the task / interrupt status register tisr are not updated. The coprocessor 102 also uses the internal interrupt permission flag I in the task / interrupt status register tisr of the CPU that is the target of the internal interrupt.
IE is disabled.
When the internal interrupt processing is finished, the task execution is resumed by a predetermined instruction (csw instruction, ivk instruction), or the CPUs 101A to 101D change to the HALT state by a predetermined instruction (cpuhalt instruction).

For this reason, at the end of the internal interrupt process, it is necessary to set the internal interrupt permission flag IIE to be permitted by a predetermined instruction.
When accepting an internal interrupt process, an internal interrupt acceptance instruction i is executed in the interrupt process routine.
iack is executed.
On the other hand, when ending the internal interrupt processing, the internal interrupt processing is executed by executing the internal interrupt acceptance instruction iaack and notifying that the internal interrupt has been accepted, and then setting the internal interrupt permission flag IIE to enable. Notify that you have finished.
When internal interrupts are prohibited, that is, when the CPU that is the target of the internal interrupt instruction has prohibited internal interrupts, the coprocessor 102 does not generate an internal interrupt and sends it to the instruction issuing CPU. An ack signal is returned. Further, the coprocessor 102 sets the internal interrupt failure flag IF of the unauthorized operation detection register iodr.
Further, when an interrupt signal INT is being output to any of the CPUs, an internal interrupt is masked.

[9.4] Other Operations in Interrupt Processing In this embodiment, NMI is not generated during execution of a coprocessor instruction in interrupt processing.
Also, interrupt processing allocation and coprocessor instruction execution are not performed simultaneously.

[10] Coprocessor processing request Next, a coprocessor processing request will be described.
When coprocessor processing requests from the CPUs 101A to 101D compete, the coprocessor 102 receives the requests according to the following priority conditions (1) to (3).
01D is determined.
(1) The hardware semaphore is acquired. (2) The priority of the task / interrupt processing being executed is high. (3) The CPUID value is small. For the CPUs 101A to 101D that have received the coprocessor processing request, The coprocessor 102 notifies the end using a predetermined port (c33 co ack port). C
CPU requests that have not been accepted due to conflicting processing requests between PUs are suspended.
After the current coprocessor process is completed, the coprocessor 102 again determines the CPUs 101A to 101D that accept the request according to the priority condition.

[11] Hardware semaphore In this embodiment, as described above, the coprocessor 102 includes the CPUs 101A to 101D.
A hardware semaphore is provided as a means for realizing exclusive access to resources shared between resources.
In the present embodiment, a semaphore generally realized by software is realized by hardware. The reason for this is to prevent semaphore acquisition requests from occurring simultaneously with the increase in the number of multiprocessors, and in the case where the semaphore is realized by software, it may be impossible to cope with it.
As described above, the coprocessor 102 of this embodiment includes eight (0 to 7) hardware semaphores, and executes dedicated instructions for acquiring and releasing the hardware semaphores.

[11.1] Acquisition of Hardware Semaphore In order to acquire the hardware semaphores for each of the CPUs 101A to 101D, a tas instruction is executed. The tas instruction specifies a hardware semaphore number to be acquired as an argument. For example, the operation for acquiring hardware semaphore No. 3 is as follows.
#Macro TAS $ 1
ld. c 14, $ 1
#Endm
ld. w% r0, 0x03; register r0 = 3
tas% r0; HW semaphore No. 3 acquisition request After executing the tas instruction, it is necessary to check whether or not the requested hardware semaphore has been acquired. The execution result of the tas instruction is the CPU status register csr of its own CPU.
Because it is reflected in, it is read.
The operation is as follows, for example. If the result of the last cmp instruction is 0, acquisition of a hardware semaphore has failed, and if it is not 0, acquisition has succeeded.
#Macro LD. PCSR $ 1
ld. c $ 1, 5
#Endm
LD. PCSR% r1; value of CPU status register csr
Assign to register r1 ld. w% r2, 0x08; generation of mask pattern with bit 3 being 1 and% r1,% r2; r1 = r1 & 0x00000008
cmp% r1, 0x00; r1-0x00000000
Since the coprocessor 102 checks only the lower 3 bits of the register specified by the argument, if a number other than 0 to 7 is specified as the hardware semaphore number, only the lower 3 bits are valid without causing an error. Become.

[11.2] Release hardware semaphore To release the acquired hardware semaphore, execute the frs instruction. The frs instruction specifies the hardware semaphore number to be released, like the tas instruction. For example, the operation for releasing hardware semaphore No. 4 is as follows.
#Macro FRS $ 1
ld. c 15, $ 1
#Endm
ld. w% r0, 0x04; register r0 = 4
FRS% r0; Release HW semaphore No. 4 Note that when the frs instruction is executed specifying a hardware semaphore number that has not been acquired by the own CPU, regardless of whether the corresponding hardware semaphore is unused An error occurs and the hardware semaphore illegal release flag (HR) of the illegal operation detection register iodr is set. If the target hardware semaphore has been acquired by another CPU,
It remains as it is without being released.

[11.3] Restrictions on Hardware Semaphore In this embodiment, the following restrictions are provided for hardware semaphores.
(1) Only OS tasks can use hardware semaphores.
Since the coprocessor 102 cannot determine the type of task (whether it is an OS task or not), it is necessary for the software designer to be able to use only the OS task.
(2) When acquiring a hardware semaphore, a semaphore number is designated and acquisition confirmation is performed by a flag.

[11.4] Reserving a hardware semaphore As described above, in order to acquire a hardware semaphore, a processing request (in this case, a tas instruction) is made to the coprocessor 102. As described above, the coprocessor 102 A processing request from the CPU having the highest overall priority of each condition at that time is accepted. For this reason, the acquisition of hardware semaphores is performed by each CPU 101A-101D.
Depending on the timing at which the as instruction is executed, there is a possibility that the hardware semaphore cannot be acquired and the processing cannot be advanced for a long time.

Therefore, in this embodiment, when an acquisition request is made for each hardware semaphore, if the target semaphore has already been acquired by another CPU, the CPU that has made the acquisition request uses this hardware semaphore. "make a reservation. When the hardware semaphore is released, the reserved CPU acquires the hardware semaphore regardless of the priority at that time.
As a result, hardware semaphores are acquired in the order in which the requests were received, even if there were requests from multiple CPUs. Nevertheless, it is possible to prevent a situation in which a CPU that cannot acquire a hardware semaphore indefinitely appears.

[11.4.1] Hardware Semaphore Reservation Operation Next, a hardware semaphore reservation operation will be described.
When a tas instruction is executed to acquire a hardware semaphore, but the hardware semaphore to be acquired has already been acquired by another CPU, the CPU that could not acquire the hardware semaphore is assigned to the hardware semaphore to be acquired. Register in the reservation list (semaphore reservation block unit 141). In order to prevent double registration of the same CPU, the following conditions (1
) And (2) do not register in the list.
(1) When the same CPU is already registered (2) When the hardware semaphore to be acquired is already acquired

[11.4.2] Hardware semaphore transfer operation CP currently acquiring hardware semaphores with reservations from the CPUs 101A to 101D
When U releases the hardware semaphore by the frs instruction, the other CPU at the head of the reservation list is made to acquire the hardware semaphore simultaneously with the release.
At this time, the TASResult field of the CPU status register csr is appropriately updated. That is, the CPU that executed the frs instruction (the CP that released the hardware semaphore
U) Clears the target hardware semaphore bit field of the CPU status register csr and sets the bit field of the target hardware semaphore of the CPU status register csr of the CPU that is at the head of the reservation list and newly acquires the hardware semaphore. To do. Of course, when an unauthorized release operation is performed on a hardware semaphore, the transfer operation is not performed.

[12] Debugging Next, debugging will be described.
In the information processing system 100 which is the multiprocessor system of the present embodiment, all CPUs
The specification is such that all CPUs 101A to 101D are required to transition to the debug mode when any CPU transitions to the debug mode from the state in which the 101A to 101D is in the non-debug mode.
For this reason, the coprocessor 102 of this embodiment is provided with two debug modes, a hardware debug mode and a software debug mode.
Switching between the two debug modes is performed by setting a hardware debug mode flag HD in the external interrupt status register isr.
In the hardware debug mode, when the coprocessor detects that any CPU has transitioned to the debug mode, a debug interrupt is immediately generated for all the CPUs 101A to 101D.

In the software debug mode, hardware support is not performed even if an arbitrary CPU enters the debug mode, and the CPU that first transits to the debug mode performs an fbrk instruction (debug interrupt generation instruction) in the debug processing routine. To cause other CPUs to transition to debug mode.
However, in the debug mode, for example, in an operation state in which control complexity is assumed as in step execution, only the hardware debug mode is used.
[12.1] Notification of Acceptance of Debug Interrupt In this embodiment, c33_c of the CPUs 101A to 101D is received by a debug interrupt.
The pu_dbgmd signal becomes active. In the coprocessor, after a debug interrupt occurs,
The c33_cpu_dbgmd signal output from each of the CPUs 101A to 101D is monitored, and a change from inactive to active is detected and regarded as a debug interrupt acceptance notification.

[12.2] Notification of end of debug interrupt The CPUs 101A to 101D execute a retd instruction when transitioning from the debug mode to the non-debug mode. By executing this retd instruction, the internal state of the CPU returns from the debug mode and is reflected in the c33_cpu_dbgmd signal. Coprocessor 102
In this case, it is detected that the c33_cpu_dbgmd signal changes from active to inactive, and is regarded as a debug interrupt end notification.
[12.3] Operation of Coprocessor in Debug Mode In this embodiment, when an arbitrary CPU is in the debug mode in the hardware debug mode, the coprocessor 102 is also in the debug mode. In this case, the coprocessor 102 does not accept any trap factors other than a reset and a coprocessor processing request. Similarly, when all the CPUs 101A to 101D return from the debug mode, the coprocessor 102 also returns from the debug mode.

[12.4] Coprocessor debug interrupt signal control After any CPU 101A-101D transitions to debug mode, the coprocessor 102
All the CPUs 101A to 101D shift to the debug mode by the debug interrupt generated by. However, the return timing from the debug mode is determined by the CPUs 101A to 101A.
Since there is a difference depending on D, when a debug interrupt occurs continuously (for example, step execution), it is impossible to determine which CPU functions as a debug interrupt factor.
Therefore, the coprocessor 102 according to the present embodiment copes with the following procedures (1) to (7).
(1) Any CP from a state in which all the CPUs 101A to 101D are in the non-debug mode
U transitions to debug mode.
(2) The coprocessor 102 is one of the CPUs that first entered the debug mode.
Record the CPUID.
(3) The coprocessor 102 generates a debug interrupt for all the CPUs 101A to 101D.
(4) All the CPUs 101A to 101D complete the transition to the debug mode.
(5) The coprocessor 102 cancels the debug interrupt request for all the CPUs 101A to 101D.
(6) In the process of (2), the CPU in which the CPU ID is recorded returns from the debug mode.
(7) The coprocessor 102 accepts a new debug interrupt.

After the coprocessor 102 cancels the debug interrupt request to all the CPUs 101A to 101D in the process (5), each of the CPUs 101A to 101D ends the debug processing routine and returns from the debug mode. After a CPU other than the CPU that caused the debug interrupt generation returns from the debug mode, it can become a new debug interrupt cause by executing the brk instruction. The coprocessor 102 holds the debug interrupt request for all the CPUs by this new debug interrupt factor until the CPU that has become the first debug interrupt factor returns from the debug mode.

FIG. 24 is an explanatory diagram of the pending state of the debug interrupt request.
Specifically, as shown in FIG. 23, the coprocessor 102 receives the CPU 1 at time t1.
When 01D (CPU3) becomes the first debug interrupt factor and the CPU 101D (CPU3) returns from the debug mode at the time t3 when the CPU 101D (CPU3) returns to the debug mode at the time t2, all the CPUs return from the debug mode at the time t4. Until this time, the debug interrupt request is suspended, and the debug interrupt suspension period is from time t3 to time t4.
[12.5] Other operations in debug mode When multiple brk instructions are executed at the same time, the software uses the hardware semaphore to execute one brk instruction at the same time to prevent contention. Yes.

[13] Coprocessor Instructions Next, all instructions defined in the coprocessor 102 of this embodiment will be described.
[13.1] Store system instructions First, the store system instructions will be described.
[13.1.1] st. isr% rs
The function of this instruction is to store a value in the external interrupt status register isr, and the clock cycle is one cycle.
By executing this example, the value of the register specified by% rs is changed to the external interrupt status register i.
Store to sr.
Specific usage examples are as follows.
#Macro ST. ISR $ 1
ld. c 0, $ 1
#Endm
ST. ISR% r0; coprocessor isr <-r0

[13.1.2] st. stisr% rs
The function of this instruction is to store in a task / interrupt status register tisr other than its own CPU, and the clock cycle is one cycle.
By executing this instruction, the CPU task / interrupt status register ti specified in the register operation target CPUID field HCID of the CPU status register csr of the CPU itself is executed.
The value of the register designated by% rs is stored for sr. If the HCID is the same as its own CPUID, st. The operation is equivalent to the ptisr instruction.
Also, by using bits 15 and 14 which are undefined bit fields of the task / interrupt status register tisr as control bits, only the IIE flag can be updated (bit fields other than the internal interrupt permission flag IIE). Will not be affected). This can be realized by setting bits 15 and 14 of the register value designated by% rs.
bit15 bit14 Operation 0 0 Update all bits 0 1 Set IIE only to 0 (internal interrupt disabled)
Only 1 0 IIE is set to 1 (internal interrupt enabled)
1 1 Update all bits

Here, it is necessary to perform an operation using the control bit. The software updates the interrupt / task status flag I / T, the priority level field PR, and the multiple interrupt flag IN when returning from the multiple interrupt processing. It is a time. In order to prevent these fields from being automatically updated by the coprocessor 102 due to assignment of new external interrupt processing or the like, only the internal interrupt permission flag IIE is set to be prohibited by using a control bit.
Specific usage examples are as follows.
#Macro LD. PCSR $ 1
ld. c $ 1, 5
ST. STISR $ 2
ld. c 2, $ 2
#Endm
LD. PCSR% r0; coprocessor r0 <-(own CPU) csr
ld. w% r1, 0x02; r1 = 0x00000002
and% r1,% r0; r1 = r1 & r0
ST. STISR% r0; tisr <-r0

[13.1.3] st. scsr% rs
The function of this instruction is to store data in a CPU status register csr other than its own CPU, and the clock cycle is one cycle.
By executing this instruction, the value of the register specified by% rs is stored in the CPU status register csr of the CPU specified by the register operation target CPUID field HCID of the CPU status register csr of the own CPU. If the CPUID field HCID is the same as its own CPUID, st. The operation is equivalent to the pcsr instruction.
Specific usage examples are as follows.
#Macro LD. PCSR $ 1
ld. c $ 1, 5
ST. SCSR $ 2
ld. c 3, $ 2
#Endm
LD. PCSR% r0; r0 <-csr (of own CPU)
ld. w% r1, 0x02; r1 = 0x00000002
and% r1,% r0; r1 = r1 & r0
ST. SCSR% r0; csr2 <-r0

[13.1.4] st. ptisr% rs
The function of this instruction is to store in the task / interrupt status register (tisr) of its own CPU, and the clock cycle is one cycle.
By executing this instruction, the task / interrupt status register tisr of its own CPU is
Stores the value of the register specified by% rs.
Further, by using the bits 15 and 14 which are undefined bit fields of the task / interrupt status register tisr as control bits, it is possible to update only the internal interrupt permission flag IIE (internal interrupt permission flag IIE). Other bit fields are not affected). This can be realized by setting bits 15 and 14 of the register value designated by% rs.
bit15 bit14 Operation 0 0 Update all bits 0 1 Set IIE only to 0 (internal interrupt disabled)
Only 1 0 IIE is set to 1 (internal interrupt enabled)
1 1 Update all bits

The operation using the control bit needs to be performed when the software updates the interrupt / task status flag I / T, the priority level field PR, and the multiple interrupt flag IN when returning from the multiple interrupt processing. In order to prevent these fields from being automatically updated by the coprocessor due to assignment of a new external interrupt process or the like, only IIE is set to be prohibited by using a control bit.
Specific usage examples are as follows.
#Macro ST. PTISR $ 1
ld. c 4, $ 1
#Endm
ST. PTISR% r0; coprocessor tisr <-r0

[13. . 1.5] st. pcsr% rs
The function of this instruction is to store in the CPU status register csr of its own CPU, and the clock cycle is one cycle.
By executing this instruction, the value of the register designated by% rs is stored in the CPU status register csr of its own CPU.
Specific usage examples are as follows.
#Macro ST. PCSR $ 1
ld. c 5, $ 1
#Endm
st. pcsr% r0 /

[13.1.6] st. iodr% rs
The function of this instruction is to store in the illegal operation detection register iodr, and the clock cycle is one cycle.
By executing this instruction, the value of the register specified by% rs is stored in the illegal operation detection register iodr. Used to clear the detection flag.
Specific usage examples are as follows.
#Macro ST. IODR $ 1
ld. c 8, $ 1
#Endm
ST. IODR% r0; coprocessor iodr <-r0

[13.1.7] csw% rs
The function of this instruction is to generate a context switch internal interrupt, and the clock cycle is two cycles.
By executing this command, a context switch internal interrupt is generated for the CPU having the number specified by% rs. When the CPU specified by% rs has set the internal interrupt permission flag IIE to be prohibited by tisr, the internal interrupt failure flag IF of the illegal operation detection register iodr is set.
Specific usage examples are as follows.
#Macro CSW $ 1
ld. c 11, $ 1
#Endm
ld. w% r1, 0x02; Set target CPU to No. 2 CSW% r1; Coprocessor Context switch internal allocation
Occurrence

[13.1.8] ivk% rs
The function of this instruction is to generate a CPU activation internal interrupt, and the clock cycle is two cycles.
By executing this command, a CPU activation internal interrupt is generated for the CPU having the number designated by% rs. When the CPU specified by% rs has set the internal interrupt permission flag IIE to be prohibited by tisr, the internal interrupt failure flag IF of the illegal operation detection register iodr is set.
Executing an ivk instruction on a CPU that is already in a non-HALT state has no effect (however, the internal interrupt failure flag IF is not set).

The coprocessor starts clock supply to the target CPU or activates the clock enable signal after a prescribed cycle after execution of this instruction.
Specific usage examples are as follows.
#Macro IVK $ 1
ld. c 12, $ 1
#Endm
ld. w% r1, 0x02; Set target CPU to No. 2 IVK% r1; Coprocessor CPU start internal interrupt occurrence

[13.1.9] haltcpu% rs
The function of this instruction is to generate a HALT state internal interrupt, and the clock cycle is two cycles.
By executing this command, a CPUHALT state internal interrupt is generated for the CPU having the number specified by% rs. If the CPU specified by% rs has set the internal interrupt enable flag IIE to be disabled at tisr, the internal interrupt failure flag IF of the unauthorized operation detection register iodr is set.
Executing a haltcpu instruction on a CPU that is already in the HALT state has no effect (however, the internal allocation failure flag IF is not set).

The coprocessor 102 stops the clock supply to the target CPU or deactivates the clock enable signal after a prescribed cycle after execution of this instruction.
Specific usage examples are as follows.
#Macro HALTCPU $ 1
ld. c 13, $ 1
#Endm
ld. w% r1, 0x02; Set the target CPU to No. 2 HALTCPU% r1; Coprocessor CPU start internal interrupt occurrence

[13.1.10] tas% rs
The function of this instruction is to request acquisition of a hardware semaphore, and the clock cycle is two cycles.
By executing this command, a hardware semaphore with the number specified by% rs is requested to be acquired. More specifically, it is confirmed whether or not the designated hardware semaphore has already been acquired by another CPU. As a result, if it is an empty state that has not been acquired from any CPU, it is acquired. When the acquisition of the hardware semaphore is successful by executing this instruction, the bit corresponding to the designated hardware semaphore number is set in the hardware semaphore acquisition field TASResult of the own CPU status register csr.

Therefore, the execution of this instruction does not guarantee the acquisition of the specified hardware semaphore. Therefore, after the execution of this instruction, the specified hardware semaphore is acquired by referring to the hardware semaphore acquisition field TASResult of the CPU status register csr. It is necessary to check whether it was possible.
Specific usage examples are as follows.
#Macro TAS $ 1
ld. c 14, $ 1
LD. PCSR $ 2
ld. c $ 2, 5
#Endm
ld. w% r1, 0x02; r1 = 0x00000002
TAS% r1; Coprocessor hardware semaphore 2
Acquisition request LD. PCSR% r2; Load csr of own CPU

[13.1.11] frs% rs
The function of this instruction is to release the acquired hardware semaphore, and the clock cycle is 4 cycles.
By executing this example, the hardware semaphore with the number specified by% rs is released. Execution of this instruction clears the bit corresponding to the designated hardware semaphore number in the hardware semaphore acquisition field (TASRResult) of the CPU status register (csr).
If this instruction is executed by specifying a hardware semaphore number that has not been acquired by the own CPU, an error occurs, and the unauthorized release flag HR of the hardware semaphore in the unauthorized operation detection register iodr is set.

In this case, the specified hardware semaphore is not released. This error is another CP
The hardware semaphore acquired by U is of course also applied to a case where a free hardware semaphore not acquired from any CPU is released.
Specific usage examples are as follows.
#Macro FRS $ 1
ld. c 15, $ 1
#Endm
ld. w% r1, 0x02; r1 = 0x00000002
FRS% r1; Coprocessor hardware semaphore No. 2
release

[13.2] Load system instructions Next, load system instructions will be described.
[13.2.1] ld. isr% rd
The function of this instruction is to load the external interrupt status register isr, and the clock cycle is one cycle.
By executing this instruction, the external interrupt status register isr is added to the register specified by% rd.
Load the value of.
Specific usage examples are as follows.
#Macro LD. ISR $ 1
ld. c $ 1, 0
#Endm
LD. ISR% r0; coprocessor r0 <-isr

[13.2.2] ld. hssr% rd
The function of this instruction is to load the hardware semaphore status register hssr, and the clock cycle is one cycle.
By executing this instruction, the value of the hardware semaphore status register hssr is loaded into the register specified by% rd.
Specific usage examples are as follows.
#Macro LD. HSSR $ 1
ld. c $ 1, 1
#Endm
LD. HSSR% r0; coprocessor r0 <-hssr

[13.2.3] ld. stisr% rd
The function of this instruction is to load a task / interrupt status register tisr other than its own CPU, and the clock cycle is one cycle.
By executing this instruction, the CPU task / interrupt status register ti specified in the register operation target CPUID field HCID of the CPU status register csr of the CPU itself is executed.
sr is loaded into the register specified by% rd. If HCID is the same as its own CPUID,
ld. The operation is equivalent to the ptisr instruction.
Specific usage examples are as follows.
#Macro LD. STISR $ 1
ld. c $ 1, 2
#Endm
LD. STISR% r0; coprocessor r0 <-tisr

[13.2.4] ld. scsr% rd
The function of this instruction is to load a task / interrupt status register tisr other than its own CPU, and the clock cycle is one cycle.
By executing this instruction, the CPU status register csr of the CPU designated by the register operation target CPUID field HCID of the CPU status register csr of the own CPU is changed.
Load the register specified by% rd. Register operation target CPUID field HCI
If D is the same as its own CPUID, ld. The operation is equivalent to the pcsr instruction.
Specific usage examples are as follows.
#Macro LD. SCSR $ 1
ld. c $ 1, 3
#Endm
LD. SCSR% r0; coprocessor r0 <-csr

[13.2.5] ld. ptisr% rd
The function of this instruction is to load the task / interrupt status register tisr of its own CPU, and the clock cycle is one cycle.
By executing this instruction, the task / interrupt status register tisr of its own CPU is set to% rd.
Load the register specified by.
Specific usage examples are as follows.
#Macro LD. PTISR $ 1
ld. c $ 1, 4
#Endm
LD. PTISR% r0; coprocessor r0 <-tisr
[13.2.6] ld. pcsr% rd
The function of this instruction is to load the CPU status register csr of its own CPU, and the clock cycle is one cycle.
Execution of this instruction loads the CPU status register csr of its own CPU into the register specified by% rd.
Specific usage examples are as follows.
#Macro LD. PCSR $ 1
ld. c $ 1, 5
#Endm
LD. PCSR% r0; coprocessor r0 <-pcsr

[13.2.7] ld. iodr% rd
The function of this instruction is to load the unauthorized operation detection register iodr, and the clock cycle is one cycle.
By executing this instruction, the illegal operation detection register iodr is loaded into the register specified by% rd.
Specific usage examples are as follows.
#Macro LD. IODR $ 1
ld. c $ 1, 8
#Endm
LD. IODR% r0; coprocessor r0 <-iodr

[13.2.8] ld. pcpuid% rd
The function of this instruction is to load the CPUID of its own CPU, and the clock cycle is one cycle.
By executing this command, the CPU ID of the CPU is loaded into the register specified by% rd.
Specific usage examples are as follows.
#Macro LD. PCPUID $ 1
ld. c $ 1, 9
#Endm
LD. PCPUID% r0; Coprocessor r0 <-CPUID

[13.2.9] ld. tt ttcr% rd
The function of this instruction is to load the task switch target CPUID register ttcr, and the clock cycle is one cycle.
By executing this instruction, the task switch target CPUID register ttcr is loaded into the register specified by% rd.
Specific usage examples are as follows.
#Macro LD. TTCR $ 1
ld. c $ 1, 10
#Endm
LD. TTCR% r0; coprocessor r0 <-ttcr

[13.3] Other Instructions Next, other instructions will be described.
[13.3.1] fbrk
The function of this instruction is to generate a debug interrupt, and the clock cycle is 1
Cycle.
By executing this instruction, a debug interrupt is generated for the CPU specified in the register operation target CPUID field HCID of the CPU status register csr of its own CPU. If the specified CPU is already in debug mode, the coprocessor masks the debug interrupt.
Even if a coprocessor makes a debug interrupt signal output request by executing the fbrk instruction while the debug interrupt signal is being output to an arbitrary CPU, the coprocessor masks it, so be careful when executing the fbrk instruction continuously. is required.
Specific usage examples are as follows.
#Define FBRK do. c 0
FBRK: Generates coprocessor debug interrupt

[13.2.10] iaack
The function of this instruction is to notify that an internal interrupt has been accepted, and the clock cycle is one cycle.
By executing this instruction, the CPU that is the target of the internal interrupt notifies the coprocessor that the internal interrupt has been accepted. By executing this instruction, the coprocessor stops generating an internal interrupt signal to the CPU that has requested execution of this instruction.
If this instruction is executed when no internal interrupt signal is generated from the coprocessor to the CPU, nothing happens.
Specific usage examples are as follows.
#Define IIACK do. c 1
IIACK // [COPRO] Accept internal interrupt

Next, the operation of the embodiment will be described.
In the following description, for the sake of simplicity, the acquisition and release of semaphores
It is assumed that the CPU 101A is considered, and the exclusive control unit 118 grasps the states of the other CPUs 101B to 101D.

FIG. 25 is a processing timing chart when a semaphore is acquired.
First, when the CPU 101A is performing its own processing (task processing, external interrupt processing, etc.) and it is necessary to acquire a shared resource, the CPU 101A attempts to acquire it as shown in FIG. A semaphore ID for specifying a semaphore corresponding to the shared resource is set (step S11), and a semaphore acquisition request is made to the coprocessor 102 (step S12).
As a result, the semaphore operation block 114 of the exclusive control unit 118 causes the semaphore register 1
40 (step S13), it is determined whether any of the CPUs 101B to 101D has already acquired a semaphore corresponding to the semaphore ID set by the CPU 101A (step S14).

If it is determined in step S14 that the semaphore corresponding to the semaphore ID set by the CPU 101A has not yet been acquired (step S14; No), since no CPU uses the semaphore, the semaphore register 140 The corresponding semaphore acquiring flag 144A is set (= “1”), and the semaphore acquiring CPUID storage unit 14
A semaphore assignment process for updating with the CPU ID of the CPU is performed in 4B (step S15).
Next, the value of the CPU status register (CPU status register 132A in this example) corresponding to the set CPUID is set to the semaphore acquisition state (step S17). In this case, as described above, it is determined whether or not there is another CPU simultaneously requesting acquisition of the same semaphore. If there is another CPU, the processing priority is set. In comparison, the CPU ID of the CPU having the highest processing priority is the CPU ID storage unit 1 of the semaphore register 140.
44B is set, and the corresponding CPU status register is selected. At the same time, it is determined whether there is another CPU requesting acquisition or release of another semaphore,
When there is another CPU having a higher processing priority, the processing corresponding to the other CPU having the higher priority is performed first.

As a result, the CPU 101A confirms with reference to the CPU status register 132A corresponding to itself (step S18), and determines whether or not the value of the PU status register 132A) is in the semaphore acquisition state (step S19).
In this case, in the determination in step S19, the CPU 101A can know that the CPU 101A has acquired the semaphore (step S19; Yes), so that processing is performed using the shared resource corresponding to the acquired semaphore. Become.

On the other hand, in step S14, the semaphore I set by the CPU 101A is determined.
If the semaphore acquisition flag 144A corresponding to D is already set (= “1”) (step S14; Yes), another CPU has already used the shared resource corresponding to the semaphore ID. Then, the semaphore reservation flag 147 of the semaphore reservation queue corresponding to the set semaphore ID is set (= “1”), and semaphore reservation processing for storing the CPU ID set in the corresponding semaphore reservation CPUID field 148 is performed (step S16).
).

Next, the value of the corresponding CPU state register (in this example, the CPU state register 132A) is set to the semaphore unacquired state (step S17).
As a result, the CPU 101A confirms with reference to the CPU status register 132A corresponding to itself (step S18), and determines whether or not the value of the CPU status register 132A) is in the semaphore acquisition status (step S19).
In this case, in the determination of step S19, the CPU 101A can know that the CPU 101A has failed to acquire the semaphore (step S19; No). Steps S18 and S19 are performed until the above.

FIG. 26 is a processing timing chart when a shared resource (semaphore) is released.
First, when the CPU 101A performs its own processing (task processing, external interrupt processing, etc.) using the shared resource, when the use of the shared resource ends and the release becomes necessary, As shown in FIG. 11, a semaphore ID for specifying a semaphore to be acquired is set (step S21), and a semaphore release request is issued to the coprocessor 102 (step S22).
As a result, the semaphore operation block 114 of the exclusive control unit 118 causes the semaphore register 1
40 (step S23), it is determined whether or not a semaphore corresponding to the semaphore ID set by the CPU 101A has already been acquired by the CPU 101A (step S24).

If it is determined in step S24 that the corresponding semaphore is not already acquired by the CPU 101A (step S24; No), it is regarded as an illegal operation and the value of each register is not updated, and the illegal operation is performed. An error process is performed to notify that the process has been completed, and the process ends (step S25).
On the other hand, in the determination of step S24, the semaphore I set by the CPU 101A.
When the semaphore corresponding to D has already been acquired by the CPU 101A (step S
24; Yes), semaphore release processing for resetting the semaphore acquisition flag 144A of the semaphore register 140 is performed (step S26).

Next, the value of the corresponding CPU status register (in this example, the CPU status register 132A) is set to the semaphore unacquired state (step S27). In this case, as described above, it is determined whether or not there is another CPU simultaneously requesting acquisition or release of the semaphore. If there is another CPU, the processing priority is set. In comparison, a semaphore is acquired or released for a CPU having the highest processing priority.
As a result, the CPU 101A confirms the status with reference to the CPU status register 132A corresponding to itself (step S28).

As a result of the status confirmation, if the CPU 101A succeeds in releasing the semaphore acquired by itself, the CPU 101A shifts to normal processing (step S29).

As described above, according to the present embodiment, each CPU 10 constituting the multiprocessor.
When 1A to 101D acquire or release shared resources, it is easy and quick to determine the CPU (processor) to which shared resources should be allocated or released according to the priority of processing of each CPU. As a result, the allocation of shared resources of each CPU can be performed efficiently and quickly, and a reduction in processing efficiency is suppressed by the load and waiting caused by the allocation processing of the shared resources, and the entire information processing apparatus is efficiently performed. Processing can be performed.

In the above description of the embodiment, the case where there are four processors (CPUs) and the case where there are eight shared resources has been described.
In the above description, the case where the control program for realizing the above functions is stored in the ROM in advance has been described. However, the control program may be recorded on a computer-readable recording medium. With such a configuration, when the program is read from the storage medium by the computer and the computer executes processing according to the read program, the same operation and effect as those of the image information processing apparatus of the above-described embodiment can be obtained.
Here, the storage medium is a semiconductor storage medium such as RAM or ROM, a magnetic storage type storage medium such as FD or HD, an optical reading type storage medium such as CD, CDV, LD, or DVD, or a magnetic storage type such as MO. / Optical reading type storage medium, and any storage medium can be used as long as it can be read by a computer regardless of electronic, magnetic, optical, etc. .

It is a general | schematic block diagram of the information processing apparatus of embodiment. It is a functional block diagram of an exclusive control circuit. It is a configuration block diagram of a more detailed information processing system. It is explanatory drawing of the input / output signal of a coprocessor. It is explanatory drawing of the bit format of an external interrupt status register. It is explanatory drawing of the bit format of a hardware (HW) semaphore status register. It is explanatory drawing of the bit format of a task switch object CPUID register. It is explanatory drawing of the bit format of an unauthorized operation detection register. It is explanatory drawing of the bit format of a task / interrupt status register. It is explanatory drawing of the bit format of a CPU status register. It is a general | schematic block diagram of an exclusive control part. It is a general | schematic block diagram of a semaphore register. It is a general | schematic block diagram of a semaphore reservation block part. It is explanatory drawing of an example of the data format of process priority level data. It is explanatory drawing of the memory map of the 1st aspect of the coprocessor. It is explanatory drawing of the memory map of the 2nd aspect of a coprocessor. It is explanatory drawing of the address of the stack area for debugging corresponding to four CPU101A-101D at the time of the memory map of a 1st aspect. It is explanatory drawing of the command format of a store type | system | group command. This is the instruction format of the load coprocessor. It is an instruction format of other coprocessors. It is explanatory drawing of the vector table corresponding to internal interrupt instruction response. It is explanatory drawing of the trap factor of a coprocessor. It is comparison summary explanatory drawing of an interruption process. It is explanatory drawing of the pending | holding state of a debug interruption request. It is a processing timing chart at the time of acquisition of a shared resource (semaphore). It is a processing timing chart at the time of releasing a shared resource (semaphore).

Explanation of symbols

11A to 11D ... CPU (processor), 12A ... priority storage unit, 13 ... exclusive control circuit (shared resource management unit), 14 ... external interrupt request accepting unit, 15 ... external interrupt process allocation unit, 16A-
16D: Priority value storage register, 17A-17D: Shared resource acquisition presence / absence storage unit, 18A-1
8D: Processing priority level storage unit (priority storage unit), 21 ... Priority comparison circuit, 22 ... Semaphore register, 23 ... Semaphore operation circuit, 100 ... Information processing system, 101A to 101D
... CPU, 102 ... Coprocessor, 110 ... Debug input receiving circuit, 111 ... External interrupt input receiving circuit, 112 ... Processing request receiving circuit, 113 ... Processing request factor determining circuit, 114 ... Allocation target determining circuit, 114 ... Semaphore operation Block 115 interrupt request generation circuit 116 common register unit 117 individual register unit 118 exclusive control unit (shared resource management unit) 11
DESCRIPTION OF SYMBOLS 9 ... Decoder, 120 ... Sequencer, 121 ... Control part, 131A-131D ... Priority value holding register (priority storage part), 132A-132D ... CPU status register, 140 ... Semaphore register, 141 ... Semaphore reservation block part, 142 Semaphore operation unit 143 semaphore information storage unit 144A semaphore acquisition flag, hssr hardware semaphore status register

Claims (8)

In an information processing apparatus that performs control to exclusively allocate shared resources to a plurality of processors,
A priority storage unit that stores a priority level of processing executed by each processor for each processor;
When the shared resource allocation request from any of the plurality of processors is received, the shared resource allocation request should be received based on the priority level of each processor stored in the priority storage unit A shared resource manager that determines the processor;
An information processing apparatus comprising: The information processing apparatus according to claim 1,
The shared resource management unit determines a processor with a higher priority level as a processor that should accept the shared resource allocation request, based on the priority level of each processor stored in the priority storage unit.
An information processing apparatus characterized by that. The information processing apparatus according to claim 1 or 2,
The information processing apparatus characterized in that the processing executed by the processor includes external interrupt processing and task processing. The information processing apparatus according to any one of claims 1 to 3,
The request accepting unit accepts a request to release the shared resource from the processor,
The shared resource management unit assigns a higher priority level than the external interrupt processing and the task processing to the processor to which the shared resource is allocated, and stores the priority level in the processing priority storage unit. When a request to release the shared resource from a plurality of the processors is received, the priority levels of the processors stored in the processing priority storage unit are compared with each other, and a processor with a higher priority level To release the shared resource as a processor that should accept the shared resource release request,
An information processing apparatus characterized by that. The information processing apparatus according to any one of claims 1 to 4,
An information processing apparatus using a semaphore as storage means for exclusive allocation information of the shared resource. The information processing apparatus according to claim 5,
The information processing apparatus, wherein the semaphore is a hardware semaphore realized as hardware or a software semaphore realized by software. In a control method of an information processing apparatus that performs control to exclusively allocate shared resources to a plurality of processors,
A priority storage process for storing a priority level of processing executed by each processor for each processor;
A shared resource management process for determining a processor that should receive the shared resource allocation request based on the stored priority level of each of the processors when receiving the shared resource allocation request from any of the plurality of processors; When,
An information processing apparatus control method comprising: In a control program for controlling, by a computer, an information processing apparatus that has a storage unit that stores various types of information and performs control to exclusively allocate shared resources to a plurality of processors,
Storing the priority level of processing executed by each processor in the storage unit for each processor;
When the shared resource allocation request from any of the plurality of processors is received, a processor to receive the shared resource allocation request is determined based on the priority level of each of the processors stored in the storage unit. ,
A control program characterized by that.

Images