JP2003186692A - Duplex system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that a duplex system has not been able to be constituted to perfectly copy one memory image of the two CPU modules to the other, when duplexing processing begins, if the CPUs of two CPU modules which constitute the duplex system are not the same. <P>SOLUTION: The types of the CPUs are detected, and if they are not mutually the same, data specific to the CPUs such as TLB (Translation Look-aside Buffer) data are stored to a storage in the old-type CPU format at the time of task dispatch; and when the data are read out, they are again converted to load to a register. Even if the types of the CPUs are mutually different, the duplex system can be constituted. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a duplex system, and more particularly to a duplex system suitable for use in a process control system.

[0002]

2. Description of the Related Art FIG. 13 shows the configuration of an FCU (Field Control Unit) used in a process control system. FIG.
, 51 and 52 are CPU modules, 4 is I
/ O interface module, which are connected by redundant backplane buses 61 and 62.

The I / O interface module 4 is an I
It provides an interface between an I / O module (not shown) connected by an I / O dedicated bus and the CPU modules 51 and 52. The I / O module has a function of transmitting / receiving data to / from a sensor or an actuator on the field and exchanging data, and in plant control, data is exchanged by a general data transmission protocol.

An FCS (Field Control Station) is composed of the above-mentioned FCU and an I / O module connected to this FCU by an I / O dedicated bus. The FCS has a function as a plant control device such as data exchange with field devices connected to a network, data retention, and calculation between these data.

The CPU modules 51 and 52 have a built-in microprocessor, and the
S (Operating System) operates. This OS is a multi-task OS, and implements an interface for tasks operating on this multi-task OS. A software module including such a multi-task OS and tasks is called a system program.

FIG. 14 shows the configuration of the CPU modules 51 and 52. The CPU module 51 has a built-in memory 511, and the CPU module 52 has a built-in memory 521. These CPU modules have an interface for shared memory access with other CPU modules connected to the same backplane bus.

That is, two CPU modules 51,
When 52 is mounted, as shown by the arrow in FIG. 14, read / write access can be performed to a part of each memory space. It is also possible to output an interrupt signal for interrupting between the CPU modules 51 and 52.

Utilizing such a function, each CPU
The OS operating on the module performs duplex processing by the simultaneous execution method. That is, the system of FIG. 13 is duplicated by the two CPU modules 51 and 52.

The duplicated CPU module operates separately on the control side (main operation side) and the standby side (slave operation side). The control side CPU module is preferentially granted access to the I / O interface. That is, the control operation for the field side can be directly executed.

Next, the operation of the CPU modules 51 and 52 will be described with reference to FIG. The CPU module 51 is on the standby side and the CPU module 52 is on the control side. The OS 522 of the CPU module 52 on the control side writes the same data to the memory 521 in the CPU module 51 on the standby side at the same time as writing to the memory 521 in its own module. That is, the memory 521 and the memory 5
The contents of 11 are always the same.

FIG. 16 shows a state when the CPU module 52 on the control side stops its operation. CPU module 5
When the CPU 2 stops operating, the CPU module 51 on the standby side is immediately switched to the control side. That is, the OS 512 accesses the memory 511 and continues the control operation. Of course, even if the CPU module on the standby side stops operating, it does not affect the control operation.

In order to construct such a duplicated system, the interfaces of the hardware resources to the platform for the system program of the CPU module, especially to the OS, must be the same.

A general multi-task OS has a task management function and provides a logical / physical mapping function of a task context. FIG. 17 shows the configuration of the logical / physical mapping function.

In FIG. 17, the microprocessor 71
Is TLB (Translation Look a side Buffer) register 7
2 to access the memory 73. The TLB register 72 converts the logical address output by the microprocessor 71 into a physical address.

The TLB register 72 is set by using a page table 731 constructed on the memory 73. The page table 731 is initialized when the system is initialized.
A page table entry is stored in the page table 731, and the microprocessor 71 is used when executing a task.
The OS loads the logical / physical mapping data into the TBL register 72 in accordance with the request of the above.

A page table entry is prepared for each task and is mapped to a logical address unique to each task. This mapping is performed using the kernel reserved area reserved in the TLB register in advance.

The processing for the request of the microprocessor generated during the task operation is performed as follows. TLB
Capture the address of the miss in the context register,
A logical address from the miss address to the replacement page table entry is generated.

Next, using this logical address, the access is made again via the TLB register to load the acquired page table entry into an arbitrary position of the user entry in the TLB register, and the newly set entry data is loaded. To continue to access the address where the error occurred.

During task dispatch processing, the immediately preceding execution context saved in the register group of the microprocessor including the TLB register is saved in the immediately preceding execution task management area, and the register context is restored from the management area of the task to be executed immediately after. To do.

Since the TLB register is a part of a hardware mechanism that depends on the microprocessor, its context data differs depending on the specifications of the microprocessor. This will be described with reference to FIG.

In FIG. 18, the type 1 CPU sets the TLB entry using the entry data of the type 1 CPU. Similarly, the type 2 CPU sets the TLB entry using the type 2 entry data. Since the CPU specifications are different between type 1 and type 2, type 1
The CPU entry data does not match the type 2 CPU entry data.

FIG. 19 shows a duplex system using two CPU modules. 8 is a memory image of the CPU module on the control side, and the task control data 8
1 and OS control data 84 are created. Execution contexts 82 are created in the task control data 81 for each task, and a TLB storage area 83 is secured in these execution contexts 82.

A plurality of page tables are created in the OS control data 84. At the start of the duplication process, this memory image 8 is copied to the memory of the other (standby side) CPU module.

[0024]

However, such a duplex system has the following problems.

As shown in FIG. 19, the data of one CPU module was copied to the other as it is, but these data are data closely related to the specifications of the CPU. Hardware-dependent management data such as a page table and page table is different. Therefore, there is a problem in that a duplicated system cannot be realized unless the same CPU module is used.

Generally, a CPU has a short product life and its specifications are often changed in a short time. However, since the process control device is a product with a long product cycle, C
It may be necessary to change the PU module.
In such a case, there was also a problem that the system had to be reviewed, and in the worst case, a completely new system had to be constructed.

Therefore, the problem to be solved by the present invention is
An object of the present invention is to provide a duplex system that can be constructed by using CPU modules equipped with different types of CPUs.

[0028]

In order to solve such a problem, the invention according to claim 1 of the present invention comprises two CPU modules of a control side and a standby side, and these two CPU modules are provided. C is a dual system that is controlled so as to keep a predetermined part of the memory image of the CPU module equivalent, and the C system is built in these two CPU modules.
The type of PU is detected, and when these CPU types are different, when storing these CPU-specific data in the memory, they are converted into predetermined CPU data and stored. Is. Different type C
A duplex system can be constructed using a CPU module equipped with a PU.

According to a second aspect of the present invention, in the first aspect of the invention, the OS operating on this duplex system is a real-time OS, and the C at the time of task dispatch is used.
The data unique to the PU is stored in the memory. It is suitable for use in a real-time OS in which task dispatch frequently occurs.

According to a third aspect of the invention, in the invention of the first or second aspect, the predetermined CPU
Is the CP installed in the two CPU modules
It is characterized by being the CPU of the old type of U. It does not increase the load on the old CPU, which has a slow processing speed.

According to a fourth aspect of the present invention, in the first to third aspects of the invention, the CPU-specific data is TLB data.
It is very effective when used for TLB, which is the most important data for CPU operation.

According to a fifth aspect of the invention, in the invention according to the first to fourth aspects, the predetermined CPU
The CPU module which does not include the above-mentioned
The entry data of the kernel reserved area is copied to the TLB emulation buffer 23 when storing the data unique to the PU. This is because the logical / physical mapping information of the page table entry is included.

According to a sixth aspect of the present invention, in the first to fifth aspects of the invention, the CPU module is a CPU type handler 13 for detecting the CPU types of the own module and the counterpart CPU module, and the CPU-specific data is stored in a memory. It has interface sections 11 and 12 each containing an interface corresponding to each CPU type stored in and retrieved from a memory, and selects these interfaces according to the CPU type detected by the CPU type handler 13. . The best interface can be selected automatically.

The invention according to claim 7 is characterized in that, in the invention according to claims 1 to 6, the duplex system is a process control device. It is particularly effective when used in process control equipment that has a long product life and cannot be stopped.

The invention described in claim 8 is characterized in that, in the invention described in claims 1 to 6, the duplex system is an online information processing device. It is particularly effective when used in an online information processing device that cannot be stopped.

According to a ninth aspect of the invention, in the first to eighth aspects of the invention, the CPU-specific data is data related to exception processing or interrupt processing. These are also data having different formats depending on the type of CPU and have a great effect.

According to a tenth aspect of the present invention, in the first to eighth aspects of the invention, the CPU-specific data is data related to the MMU. These are also data having different formats depending on the type of CPU and have a great effect.

[0038]

DESCRIPTION OF THE PREFERRED EMBODIMENTS As described above, it was difficult to realize the duplication processing by the same system program on different platforms, but the application specification of Japanese Patent Application No. 2001-353101 by the present applicant shows that The basic concept of the method to realize the duplication processing by the same system program on different platforms has been proposed. The proposal will be described below.

To this end, (1) The microcodes executed by the microprocessors are compatible between the platforms. (2) A function that can uniquely identify the platform from the microprocessor is installed. Will be required.

When these conditions are satisfied, the system program can operate on different platforms by using the same program, and at the same time, the OS and the context format of the task by the OS and the interface on the hardware side are controlled. It becomes possible to choose.

The present invention was inspired by this proposal to provide TLB
The present invention proposes a duplication system that can perform duplication processing by using CPU modules each having a different mechanism mounted therein.

Usually, the OS is equipped with a function for detecting a difference in architecture from the processor revision. With this function, the type of the processor mounted on the CPU module can be detected.

The memory of each CPU module holds the processor type information of the CPU of its own module. Further, as described above, it has a function of reading the memory data of the other party's module.

By utilizing these functions, the CPU types of the own module and the counterpart module can be known. This processor type is included in the OS operating mode, an identifier that contains other features related to the operation of the system program.

Here, it is assumed that there are two types of processors, type 1 and type 2, and a CP of type 1 is used.
A CPU module containing U is an old CPU module, and a CPU module containing a type 2 CPU is a new CPU module. TLB for these two types of processors
The mechanism is different.

The present invention uses the control logic of the TLB mechanism for the task context and the TLB register for the CPU.
Implement a virtual interface that switches depending on the type.

Further, the emulation function is implemented in the hardware-specific interface section in the OS and the hardware-specific interface section of the section not dependent on the hardware such as task management.

In this manner, CPU modules each having a built-in CPU having an architectural difference that does not satisfy the above conditions (1) and (2) are used, and partially different contexts are held on the memory image of each CPU module. Realize duplication in the state.

FIG. 1 is a flow chart for explaining the operation of one embodiment of the duplex system according to the present invention. This flowchart shows the operation when an exception occurs. In this embodiment, the context of each task is saved in the form of a CPU of type 1 which is an old type CPU.

In FIG. 1, when an exception occurs, it is checked whether a CPU module equipped with a CPU of a different type is installed. For this purpose, the functions of the OS described above are used. If all CPUs are of the same type, exception processing is performed in the usual way.

If different types of CPUs are mounted, it is checked whether the CPU in which the exception has occurred is the type 2 CPU. Since the context of each task is stored in the type 1 format, exception processing is performed in the usual manner unless the CPU is a type 2 CPU.

In the case of the type 2 CPU, the miss address of the context register is taken out in (1) and the logical address of the PTE (Page Table Entry) corresponding to this miss address is calculated in (2). The offset from the logical address of this PTE to the top logical address of the page table and the corresponding PTE in this page table can be uniquely determined.

Next, in (3), the TLB emulation buffer is searched, the head pointer of the page table is taken out, the obtained offset in the page table is added, and the PTE is taken out.

Then, in (4), the corresponding entry data is converted into the native mode format of the type 2 processor by the TLB entry data conversion function, and in (5) the TLB is converted.
The entry data is loaded into the register.

In this way, by converting to the native mode format of the type 2 based on the memory image of the native mode of the type 1 stored when the processor types are mixed, the processors of different types are mixed. It is possible to realize dual system. When saving the context of the type 2 CPU module, the context is converted to the type 1 context and saved.

FIG. 2 is a block diagram of a CPU module having a type 2 CPU. It is assumed that the other party configuring the duplication is a CPU module having a type 1 CPU. In FIG. 2, 1 is a TLB miss handler, and a TLB miss exception is input.

Reference numeral 11 denotes a virtual interface for the TLB register 3, which is a type 1 emulation 1
11 are included. An entry data interface 12 includes a type 1 emulation 121.

Reference numeral 2 is a memory, in which a task context 21, a page table entry 22 and a TLB emulation buffer 23 are constructed. 13 is a CPU type handler, and its own CPU
The type and the type of the CPU incorporated in the partner CPU module are detected using the mutual access function of the memory.

The CPU of the module of the CPU type handler 13 is type 2, and the CPU of the other module is C.
If the PU is detected to be of type 1, the task context 21 and page table entry 22
Entry data is created, and the data in the TLB register 3 is converted into type 1 entry data.

The sizes of the task context 21 and the TLB emulation buffer 23 are as large as those required by the type 1 or type 2 CPU.

FIG. 3 is a block diagram of a CPU module having a type 1 CPU. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted. As described above, since the context of each task is stored in the form of the type 1 CPU, the CPU module having the type 1 CPU does not perform the conversion work.

In FIG. 3, 112 is a type 1 TLB.
Interface, TLB interface 11
Is built into. The type 1 TLB interface 112 inputs / outputs data to / from the TLB register 3 (not shown) without conversion.

Reference numeral 122 is a type 1 entry data interface.
Built in 2. The type 1 entry data interface 122 also outputs data to and reads data from the memory 2 (not shown) without performing any particular conversion work.

FIG. 4 is a configuration diagram in the case where all the CPUs incorporated in the duplicated CPU module are type 2. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted. In this case, since the CPU types are the same, there is no need to convert the context data.

In FIG. 4, 113 is a type 2 TLB.
Interface, TLB interface 11
Is built into. The type 2 TLB interface 113 inputs / outputs data to / from the TLB register 3 without performing conversion.

Reference numeral 123 is a type 2 entry data interface.
Built in 2. The type 2 entry data interface 123 also outputs data to and reads data from the memory 2 without performing any particular conversion work.

In this way, the CPU type handler detects the CPU type of the CPU module of itself and the CPU module of the other party, and automatically selects the most suitable TLB interface and entry data interface. Further, emulation processing is performed on a hardware-specific part in the OS and a hardware-specific interface part for task management.

FIG. 5 is a block diagram for explaining the operation of the embodiment of FIG. 2 in more detail. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted. In FIG. 5, since the data stored in the task context 21 of the memory 2 is the entry data of the type 1 CPU, the type 2 CPU
Must be converted when used in.

CPU type handler 13 is type 2CP
When U is detected, type 1 emulation logic 12
Select 1. Type 1 emulation logic 12
1 refers to the task context 21 and the page table entry 22 to create type 2 entry data from type 1 entry data and sort them. Then, it outputs to the register of the type 2 CPU.

On the contrary, FIG. 6 illustrates the operation of storing the data of the type 2 CPU in the memory. In addition,
The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted.
In FIG. 6, the CPU type handler 13 is a type 2C.
Upon detecting the PU, the type 1 emulation logic 111 is selected.

Type 1 emulation logic 111
Reads out the data from the TLB register 3 of the type 2 CPU, converts it into the format of the type 1 CPU and sorts it, and creates the type 1 entry data. Then, this data is stored in the task context 21.

FIG. 7 is a diagram showing that the data stored in the task context 21 cannot be used as it is for the type 2 CPU. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted.

The task context 21 has a type 1 CP
Data is stored in the U format. Therefore, type 2
In the case of a CPU, even if it is loaded into its own TLB register 13, this data cannot be directly output to the TLB register 13.

Each entry data of the kernel reserved area includes PTE logical / physical mapping information of each task determined at the time of task activation. Therefore, in the case of the type 2 CPU, the entry data of the kernel reserved area is not loaded into the TLB register at the time of task dispatch, but is copied to the TLB emulation buffer 23 which is a fixed area on the CPU module.

FIG. 8 illustrates this operation. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted. In FIG. 8, 211 and 212 are the entry to the kernel and the entry to the user, which are secured in the task context 21, respectively.

At the time of task dispatch, the TLB miss handler 1 converts the data in the entry 211 to the kernel and stores it in the TLB emulation buffer 23,
Convert the data in entry 212 to user to TLB
It is stored in the entry of the register 3 excluding the kernel area.

The size of the TLB emulation buffer 23 is the same as the total data size of the kernel reserved entry used in the process of extracting the PTE for replacement when the TLB miss exception occurs in the TLB entry data.

FIG. 9 illustrates this operation in more detail. The same elements as those in FIG. 2 are designated by the same reference numerals and the description thereof will be omitted. In the task context 21 of the next task
Since Entry K1 and Entry K2 are entry data of the kernel reserved area, they are copied to the TLB emulation buffer 23.

Since Entry U1 and Entry U2 are entries to the user, they are stored in the TLB register 3. That is, only the entry data in the kernel reserved area is copied to the TLB emulation buffer 23.

FIG. 10 shows the operation when the TLB miss exception occurs. When a TLB miss exception occurs, the TLB miss handler fetches the miss address from the context register. This miss address is temporarily stored in the register or stack of the CPU.

Subsequently, the TLB miss handler fetches this miss address and calculates the logical address of the PTE. As described above, the page table head pointer and offset, which are the addresses of the Entry Kx, can be uniquely determined from this logical address.

FIG. 11 shows the procedure for searching the PTE from the address and offset of Entry Kx. The upper part of the memory 2 in FIG. 11 is the TLB emulation buffer, and the lower part is the Kx page table.

Using the address of Entry Kx as a key, the TLB emulation buffer is searched to find the start address of the page table of Entry Kx. Since the page table has PTEs arranged in the order of offsets, the PTE at the offset th is the PTE to be obtained.

FIG. 12 shows a method of loading TLB entry data of the type 2 CPU into the TLB register. Figure 1
The PTE obtained in 1 is input to the TLB miss handler to obtain the type 2 PTE, and this PTE is loaded into an arbitrary TLB register by the TLB miss handler.

In this way, the context data is stored in the old type 1 format regardless of the CPU type, and in the case of the type 2 CPU, the type 2 data is stored when the context data is read.
By converting the format into the above format, a duplex system can be constructed using CPU modules having CPUs having different architectures.

An online revision function of the system program has been developed. Use this feature
If the running system program is changed to the system program of the present invention, the CPU module can be replaced with a CPU module equipped with a new CPU without stopping the plant control device.

Further, the present invention is not limited to the plant control apparatus, but can be used for other long-term continuous operation such as an online information processing apparatus.
It can be applied to a system that operates continuously. Also,
It can be applied not only to the TLB mechanism but also to exception processing, interrupt processing, and the like. Furthermore, it is also applicable to control processing of a system controller, MMU (Memory Management Unit), and the like.

[0088]

As is apparent from the above description,
According to the present invention, the following effects can be expected. According to the first aspect of the present invention, there is provided a duplex system including two CPU modules on a control side and a standby side, which are controlled so as to keep a predetermined portion of a memory image of these two CPU modules equivalent. , Detects the type of CPU built in these two CPU modules, and when these CPU types are different, these C
When storing the data unique to the PU in the memory, the data is converted into the data of the predetermined CPU and stored.

CPU in which CPUs of different types are mounted
Since you can build a redundant system using modules,
Even in a system with a long product life, it is possible to use the CPU module equipped with the latest CPU, and it is possible to improve the system performance.

According to the present invention, it is possible to realize the duplication processing by the synchronous execution waiting method between different platforms satisfying a certain condition in the same node.

Further, since different types of CPUs can be mixed, it is not necessary to replace two CPU modules at the same time, and therefore maintenance costs can be reduced.

Further, since the CPU type is detected and the data is converted only when the CPU types are different, there is an effect that the system performance does not deteriorate when the CPUs of the same type are used.

In recent years, the progress of parts such as CPU has been remarkable,
And the product life is shorter than the system life. Therefore, maintenance problems such as having to stock maintenance parts have occurred. The present invention always has the latest CP
Since the U module can be used, there is also an effect that it is not necessary to stock the maintenance parts.

Furthermore, there is an effect that the performance can be improved without stopping the system by replacing the CPU module with a new high-performance CPU by using the CPU module which can be hot-plugged and unplugged.

According to the invention described in claim 2, in the invention described in claim 1, O which operates on this duplex system is used.
S is a real-time OS, and the data unique to the CPU is stored in the memory at the time of task dispatch.

The real-time OS is highly effective because task dispatch frequently occurs. In addition, since many systems that use a real-time OS generally cannot be stopped for a long period of time, maintenance work can be reduced,
There is also an effect that the reliability of the system is improved.

According to the invention of claim 3, in the invention of claim 1 or 2, the predetermined CPU is one of the CPUs mounted in the two CPU modules, which is an older model. It is characterized by being a CPU.

Since the processing capacity of the old CPU is generally lower than that of the new CPU, the performance of the entire system will not be deteriorated by not increasing the load of the old CPU.

According to the invention described in claim 4, in the invention described in any one of claims 1 to 3, the CPU-specific data is TLB data. TLB
Since the data is the most important data for the operation of the CPU, it is particularly effective.

According to the invention of claim 5, in the inventions of claims 1 to 4, the predetermined C
The CPU module which does not include the PU has the TLB emulation buffer 23 in the built-in memory, and the entry data of the kernel reserved area is copied to the TLB emulation buffer 23 when the CPU-specific data is stored. .

The entry data in the kernel reserved area is the logical value of the page table entry determined at task startup.
Since the physical mapping information is included, a dedicated storage area is provided on the memory, and copying to this area has the effect of not lowering performance.

According to the invention described in claim 6, in the invention described in claims 1 to 5, the CPU module is a CPU type handler 13 for detecting the CPU type of its own module and the counterpart CPU module, and the C type.
It has interface units 11 and 12 that include interfaces corresponding to CPU types that store and retrieve PU-specific data from the memory, and select these interfaces according to the CPU type detected by the CPU type handler 13. I did it.

Since the optimum interface is automatically selected according to the CPU type, the CP installed
It has the effect of always exerting the maximum ability regardless of U. Further, by using the CPU module that can be hot-plugged and unplugged, there is an effect that the CPU module can be replaced and the performance can be improved without stopping the system.

According to the invention of claim 7, in the invention of claims 1 to 6, the duplex system is a process control device. Since process control equipment has a long product life and cannot be stopped for a long time,
Especially effective.

According to the invention described in claim 8, in the invention described in any one of claims 1 to 6, the duplex system is an online information processing apparatus. It is particularly effective when used in an online information processing device that cannot be stopped for a long period of time.

According to a ninth aspect of the present invention, in the first to eighth aspects of the invention, the CPU-specific data is data related to exception processing or interrupt processing. Since these data also differ greatly depending on the CPU, the effect is great.

According to the invention of claim 10, claim 1
The data unique to the CPU is data related to the MMU. These are also data having different formats depending on the type of CPU and have a great effect.

[Brief description of drawings]

FIG. 1 is a flowchart showing an embodiment of the present invention.

FIG. 2 is a configuration diagram of an embodiment of the present invention.

FIG. 3 is a configuration diagram when only a type 1 CPU is used.

FIG. 4 is a configuration diagram when only a type 2 CPU is used.

FIG. 5 is a diagram for explaining data conversion.

FIG. 6 is a diagram for explaining data conversion.

FIG. 7 is a diagram for explaining data conversion.

FIG. 8 is a configuration diagram for explaining a TLB emulation buffer.

FIG. 9 is a configuration diagram for explaining a TLB emulation buffer.

FIG. 10 is a diagram showing an operation when a TLB miss exception occurs.

FIG. 11 is a diagram showing a PTE search procedure.

FIG. 12 is a diagram showing a procedure for loading TLB entry data into a TLB register.

FIG. 13 is a configuration diagram of an FCU.

FIG. 14 is an explanatory diagram of shared memory access.

FIG. 15 is a diagram illustrating an operation of a CPU module.

FIG. 16 is a diagram illustrating an operation of a CPU module.

FIG. 17 is an explanatory diagram of a TLB register.

FIG. 18 is an explanatory diagram of entry data.

FIG. 19 is a configuration diagram of a duplex system.

[Explanation of symbols]

1 TLB miss handler 11 TLB interface 111 121 Type 1 emulation logic 12-entry data interface 13 CPU type handler 2 memory 21 task context 22 page table entries 23 TLB emulation buffer 3 TLB register

Claims (10)

[Claims] 1. A duplex system comprising two CPU modules, one on a control side and the other on a standby side, and controlled so as to keep a predetermined part of a memory image of these two CPU modules equivalent. Detects the type of built-in CPU and detects these CP
When these U-types are different, a predetermined CP is stored when storing these CPU-specific data in the memory.
A duplex system characterized in that it is converted into U data and stored. 2. An OS operating on the duplex system is a real-time OS, and the C at the time of task dispatch.
2. The duplex system according to claim 1, wherein the data unique to the PU is stored in the memory. 3. The duplex system according to claim 1, wherein the predetermined CPU is an older one of the CPUs mounted on the two CPU modules. 4. The duplex system according to claim 1, wherein the CPU-specific data is TLB data. 5. A C which does not include the predetermined CPU.
The PU module has a TLB emulation buffer on a built-in memory, and when storing the CPU-specific data, the entry data of the kernel reserved area is copied to the TLB emulation buffer. The duplex system according to any one of claims 1 to 4. 6. The CPU module detects the CPU types of its own module and the counterpart CPU module by C.
A PU type handler and an interface unit corresponding to each CPU type for storing and retrieving data specific to the CPU in the memory, and selecting the interface unit according to the CPU type detected by the CPU type handler The duplex system according to any one of claims 1 to 5, characterized in that 7. The duplex system according to claim 1, wherein the duplex system is a process control device. 8. The duplex system according to claim 1, wherein the duplex system is an online information processing device. 9. The duplex system according to claim 1, wherein the CPU-specific data is data related to exception processing or interrupt processing. 10. The duplex system according to claim 1, wherein the CPU-specific data is data related to an MMU.