WO2014147769A1

WO2014147769A1 - Control apparatus, device access method, device access program, and information processing apparatus

Info

Publication number: WO2014147769A1
Application number: PCT/JP2013/057911
Authority: WO
Inventors: 智里福井; 修司小川
Original assignee: 富士通株式会社
Priority date: 2013-03-19
Filing date: 2013-03-19
Publication date: 2014-09-25

Abstract

A learning table (141) stores a device access sequence such that a 12C multiplexer (104) is switched a minimum number of times. When an application (130) performs a device access initially stored in the learning table (141), a learning mechanism (143) executes speculative device access in the sequence stored in learning table (141). In addition, the learning mechanism (143) learns the device access performed by the application (130), and stores this in the learning table (141), which has been optimized such that the 12C multiplexer (104) is switched a minimum number of times. A decision table (142) stores information related to the first device access in the learned device access sequence.

Description

Control apparatus, device access method, device access program, and information processing apparatus

The present invention relates to a control apparatus, a device access method, a device access program, and an information processing apparatus.

Conventionally, an I2C bus has been used as a method of connecting an MPU (Micro-Processing Unit) and a device. In the I2C bus, there are a case where an I2C controller on the MPU side and a device are directly connected by a bus, and a case where an I2C multiplexer is sandwiched in the middle of the bus.

When the I2C multiplexer is sandwiched in the middle of the bus, the I2C library used to access the I2C device switches the I2C multiplexer bus before accessing the I2C device.

As a technique related to the I2C bus, a technique for optimizing the generation timing of the stop condition for each device connected to the same I2C bus has been developed (for example, see Patent Document 1). Here, the stop condition is data transmitted after the last data is transmitted when the controller transmits a plurality of data to the device.

JP 2008-242848 A

However, an application that accesses an I2C device is unaware of whether or not an I2C multiplexer is included in the middle of a bus path when continuously accessing a plurality of I2C devices by monitoring or reset processing. For this reason, depending on the access order of applications, there is a problem that the number of bus switching times of the I2C multiplexer increases and the access time to the I2C device increases.

The disclosed technique has been made in view of the above, and an object thereof is to provide a control device, a device access method, a device access program, and an information processing device that prevent an increase in access time due to bus switching of an I2C multiplexer. And

In one aspect, the control device disclosed in the present application includes an access order storage unit that stores an access order determined based on the number of switching of multiplexers when accessing a plurality of devices via a multiplexer. Further, the control device disclosed in the present application includes an execution unit that executes access to the plurality of devices in accordance with the access order stored in the access order storage unit.

According to one aspect of the control device, the device access method, the device access program, and the information processing device disclosed in the present application, it is possible to prevent an increase in access time due to I2C multiplexer bus switching.

FIG. 1 is a diagram illustrating the information processing apparatus according to the embodiment. FIG. 2 is a functional block diagram illustrating the configuration of the I2C library according to the embodiment. FIG. 3 is a diagram illustrating an example of the data structure of the learning table. FIG. 4 is a diagram illustrating an example of the data structure of the decision table. FIG. 5 is a diagram for explaining the operation of the I2C library during the learning and speculative execution period. FIG. 6 is a diagram illustrating a connection example of the I2C device. FIG. 7 is a diagram showing the difference in the number of switching times of the I2C multiplexer between the conventional device access in which learning is not performed for the connection example in FIG. 6 and the device access in the present embodiment in which learning is performed. FIG. 8 is a diagram for explaining the details of the access order learning process by the learning mechanism for the connection example of FIG. FIG. 9 is a diagram for explaining the details of the speculative execution process by the learning mechanism for the connection example of FIG. FIG. 10 is a flowchart showing the processing procedure of the I2C library. FIG. 11 is a flowchart showing the processing procedure of the function processing of the I2C library. FIG. 12A is a flowchart illustrating a processing procedure of learning and speculative execution by the learning mechanism. FIG. 12B is a flowchart illustrating a processing procedure of learning and speculative execution by the learning mechanism. FIG. 13 is a flowchart showing the procedure of the confirmation process. FIG. 14 is a diagram illustrating a configuration of a 5V power sensor and a 10V power sensor under the I2C multiplexer. FIG. 15 is a diagram showing a learning table before and after optimization. FIG. 16 is a diagram showing a determination table after learning. FIG. 17A is a sequence diagram illustrating the operation of the firmware during learning. FIG. 17B is a sequence diagram illustrating the operation of the firmware during speculative execution.

Hereinafter, embodiments of a control device, a device access method, a device access program, and an information processing device disclosed in the present application will be described in detail with reference to the drawings. Note that this embodiment does not limit the disclosed technology.

First, an information processing apparatus according to an embodiment will be described. FIG. 1 is a diagram illustrating the information processing apparatus according to the embodiment. As shown in FIG. 1, the information processing apparatus 1 includes a control board 100 and target boards 200 to 400.

The target boards 200 to 400 are server boards and the like, and are equipped with a CPU and a memory. The control board 100 monitors and controls the target boards 200 to 400. Although three target boards are shown here for convenience of explanation, the information processing apparatus 1 may include an arbitrary number of target boards.

The control board 100 includes an MPU 101, a memory 102, a control FPGA 103, an IC2 multiplexer 104, six I2C devices 105, and three I2C buses 106. For convenience of explanation, six I2C devices 105 and three I2C buses 106 are shown here, but the control board 100 may include any number of I2C devices and any number of I2C buses.

The MPU 101 is an arithmetic processing device that executes a program stored in the memory 102, and includes two I2C controllers 110. The I2C controller accesses the I2C device 105 by controlling the I2C bus 106.

The memory 102 stores firmware 120 that is a program executed by the MPU 101 and data used by the MPU 101 for calculation. The firmware 120 includes an application 130, an I2C library 140, and a driver 150.

In order to control the I2C device 105, the application 130 calls a READ / WRITE function together with data such as a device address to the I2C library 140. The I2C library 140 activates the driver 150 based on the data received by the function call from the application 130 and accesses the

I2C devices

105 and 205. The driver 150 drives the hardware to control access to the

I2C devices

105 and 205.

The I2C library 140 activates different drivers 150 for different types of I2C devices. When accessing the I2C device 105 via the I2C multiplexer 104, the I2C library 140 accesses the I2C device 105 after switching the bus of the I2C multiplexer 104. The I2C library 140 accesses the I2C device 205 mounted on the target boards 200 to 400 via the control FPGA 103 using an FPGA driver. That is, the I2C library 140 absorbs the difference in the instruction procedure for each

I2C device

105 and 205 by using the driver 150 and the procedure according to the type and connection of the

I2C devices

105 and 205 to be accessed.

The control FPGA 103 performs direct memory access (DMA) control on the control FPGA 203 mounted on the target boards 200 to 400 to control access to the I2C device 205 on the target boards 200 to 400.

The IC2 multiplexer 104 is connected to the two I2C buses 106, and enables switching to the I2C devices 105 connected to the I2C buses 106 by switching the internal buses.

The I2C device 105 is a device connected to the MPU 101 via the I2C bus 106. Examples of the I2C device 105 include a power supply sensor and an EPROM (Erasable Programmable Read Only Memory). The I2C bus 106 is a bus that connects the MPU 101 and the I2C device 105.

Since the target boards 200 to 400 have the same configuration except for the number of mounted I2C devices and the number of I2C buses, the target board 200 will be described as an example here. The target board 200 includes a control FPGA 203, four I2C devices 205, and two I2C buses 206.

The control FPGA 203 has two I2C controllers 210 and drives the I2C controller 210 under the DMA control of the control FPGA 103 to control the I2C device 205. The I2C device 205 is a device connected to the MPU 101 via the I2C bus 206 and the

control FPGAs

203 and 103. Examples of the I2C device 205 include a power supply sensor and an EPROM. The I2C bus 206 is a bus that connects the control FPGA 203 and the I2C device 205.

Next, the configuration of the I2C library 140 according to the embodiment will be described. FIG. 2 is a functional block diagram illustrating the configuration of the I2C library 140 according to the embodiment. In FIG. 2, an I2C driver 151 is a driver used when accessing the I2C device 105, and an FPGA driver 152 is a driver used when accessing the I2C device 205 via the control FPGA 203.

2, the I2C library 140 includes a learning table 141, a determination table 142, a learning mechanism 143, and a command issuing unit 144.

The learning table 141 stores the access order learned by the learning mechanism 143 for the

I2C devices

105 and 205. FIG. 3 is a diagram illustrating an example of the data structure of the learning table 141. As shown in FIG. 3, the learning table 141 stores an access number, an I2C library device address, a header, and prefetch information in association with each other.

The access number is information indicating the number of device access after the start of learning, and the I2C library device address is a device address passed from the application 130 to the I2C library 140. The format of the I2C library device address is 0xAABCCDDD. Here, 0x indicates a hexadecimal number, AA is an I2C controller number, BB is an I2C multiplexer address, CC is a multiplexer port number, and DD is an I2C device address. Therefore, it is determined whether or not switching of the I2C multiplexer 104 is necessary in the upper 3 bytes of the I2C library device address.

The header is offset information of the

I2C devices

105 and 205. For example, when the

I2C devices

105 and 205 are EPROMs, the EPROM is specified by the device address, and each byte in the EPROM is specified by the offset. The prefetch information is data read when the learning mechanism 143 executes speculation based on the learning content. Here, speculative execution means that the learning mechanism 143 accesses the device in the access order stored in the learning table 141 when an access request having an access number of 1 is received from the application 130. Details of speculative execution will be described later.

The determination table 142 stores information used for determining whether to access the

I2C devices

105 and 205 using the access order learned by the learning mechanism 143. FIG. 4 is a diagram illustrating an example of the data structure of the determination table 142. As illustrated in FIG. 4, the determination table 142 stores an I2C library device address, a header, a counter, and a pointer in association with each other.

The pointer is a pointer to the learning table 141, and the I2C library device address is the same information as the I2C library device address whose access number of the learning table 141 designated by the pointer is 1. The header is the same information as the header whose access number is 1 in the learning table 141 specified by the pointer.

The counter is information used for evaluating the weight of the learning table 141 designated by the pointer. Here, the weight of the learning table 141 being large indicates that there is a high possibility that the

I2C devices

105 and 205 are accessed in the access order recorded in the learning table 141.

If the counter value is equal to or greater than the threshold value, the learning mechanism 143 determines that the

I2C devices

105 and 205 are likely to be accessed in the access order recorded in the learning table 141, and overwrites the learning table 141. Not performed. On the other hand, if the value of the counter is smaller than the threshold value, the learning mechanism 143 is not learning, or is unlikely to be accessed by the

I2C devices

105 and 205 in the access order recorded in the learning table 141. And the learning contents are overwritten in a new order.

The counter is “0” when the decision table 142 is in the initial state, and is initialized with a threshold when the association with the learning table 141 is performed. The counter is counted up when the speculative execution is successful, and is counted down when the speculative execution fails.

The decision table 142 is accessed using the lower 4 bits of the I2C library device address as an index. Therefore, the number of entries in the decision table 142 is 16. Note that the number of bits used as an index may be other than 4, and the number of entries in the determination table 142 varies depending on the number of bits.

The learning mechanism 143 determines whether to access the

I2C devices

105 and 205 in the order stored in the learning table 141. When the learning mechanism 143 accesses in the order stored in the learning table 141, the learning mechanism 143 accesses the

I2C devices

105 and 205. Execute speculation.

On the other hand, if the access is not performed in the order stored in the learning table 141, the learning mechanism 143 determines whether to learn the access order to the

I2C devices

105 and 205, and if so, learns the learning result. Record in Table 141. When learning is completed, the learning mechanism 143 optimizes the access order recorded in the learning table 141 so that the number of times of switching of the I2C multiplexer 104 is minimized. Details of learning by the learning mechanism 143 will be described later.

The application 130 accesses the

I2C devices

105 and 205 in order by monitoring the control board 100 and the target boards 200 to 400. Therefore, the application 130 can efficiently access the

I2C devices

105 and 205 by optimizing the access order recorded in the learning table 141 by the learning mechanism 143 so that the switching frequency of the I2C multiplexer 104 is minimized. .

On the other hand, when learning is not performed, the learning mechanism 143 accesses the

I2C devices

105 and 205 as in the conventional case. Note that the period during which the learning mechanism 143 performs learning and speculative execution is specified by the application 130.

The command issuing unit 144 issues a command corresponding to the function call from the application 130 to the

I2C devices

105 and 205.

FIG. 5 is a diagram for explaining the operation of the I2C library 140 during the learning and speculative execution period. In FIG. 5, dotted arrows indicate processing without learning, dashed arrows indicate access order learning processing, and solid arrows indicate speculative execution processing. As shown in FIG. 5, the application 130 controls the I2C library 140 including whether or not the I2C library 140 performs learning and speculative execution.

When receiving an access request to the device from the application 130, the learning mechanism 143 refers to the determination table 142 and determines whether or not speculative execution is possible. As a result, when speculative execution is not possible, the learning mechanism 143 refers to the determination table 142 and determines whether to newly learn the access order to the

I2C devices

105 and 205. As a result, when learning is not performed, the learning mechanism 143 causes the command issuing unit 144 to issue a command so as to access the

I2C devices

105 and 205 as in the prior art (1).

On the other hand, in the case of learning, the learning mechanism 143 causes the command issuing unit 144 to issue a command and performs a learning process (2). As a learning process, the learning mechanism 143 registers (3) the decision table 142 and associates the decision table 142 with the learning table 141 (4). The learning mechanism 143 records the access order to the learning table 141 for the access to the I2C devices 105 and 205 (5). Then, the learning mechanism 143 optimizes the access order after learning so that the number of times of switching of the I2C multiplexer 104 is minimized.

On the other hand, when speculative execution is possible, the learning mechanism 143 performs speculative execution (6). That is, the learning mechanism 143 refers to the decision table 142 (7) and acquires a pointer to the learning table 141. Then, the learning mechanism 143 causes the command issuing unit 144 to issue access requests to the

I2C devices

105 and 205 in the order stored in the learning table 141 (8).

Next, examples of learning and speculative execution will be described with reference to FIGS. FIG. 6 is a diagram illustrating a connection example of the I2C device. In FIG. 6, devices A to T are I2C devices, and MUX ₁ and MUX ₂ are I2C multiplexers.

Device A to Device D are connected to MUX ₁ at port ₁ , Device E to Device H are connected to MUX ₁ at port ₂ , Device I is connected to MUX ₁ at port ₃ , and Device J is connected to MUX ₁ at port ₄ Connected with. MUX ₁ is connected to the I2C controller ₁ .

The I2C device addresses of the devices A to D are “0xA0” to “0xA3”, and the I2C device addresses of the devices E to H are “0xA0” to “0xA3”. The I2C device address of device I is “0xAC”, and the I2C device address of device J is “0x30”. For the port of MUX ₁ , the multiplexer port number of port ₁ is “0x01”, and the multiplexer port number of port ₂ is “0x02”. The multiplexer port number of port ₃ is “0x04”, and the multiplexer port number of port ₄ is “0x08”. The multiplexer address of MUX ₁ is “0xE0”, and the I2C controller number of I2C controller ₁ is “0x01”.

Similarly, device K to device N are connected to MUX ₂ at port ₁ , device O to device R are connected to MUX ₂ at port ₂ , device S is connected to MUX ₂ at port ₃ , and device T is connected to MUX ₂ Connected to port ₄ . The MUX ₂ is connected to the I2C controller ₂ .

The I2C device addresses of the devices K to N are “0xA4”, “0x42”, “0xC4”, and “0x5C”, respectively, and the I2C device addresses of the devices O to R are “0xA4”, “0x42”, and “0xC4”, respectively. "," 0x5C ". The I2C device address of the device S is “0x5A”, and the I2C device address of the device T is “0x5A”. For the port of MUX ₂ , the multiplexer port number of port ₁ is “0x01”, and the multiplexer port number of port ₂ is “0x02”. The multiplexer port number of port ₃ is “0x04”, and the multiplexer port number of port ₄ is “0x08”. The multiplexer address of MUX ₂ is “0xE0”, and the I2C controller number of I2C controller ₂ is “0x02”.

FIG. 7 is a diagram showing a difference in the number of switching times of the I2C multiplexer between the conventional device access in which learning is not performed with respect to the connection example in FIG. 6 and the device access in this embodiment in which learning is performed. For example, in the connection example of FIG. 6, when access is performed in the order of devices A → E → J → B → F → I → C → G → D → H, switching of the I2C multiplexer to access all devices The number of times is the highest.

The learning mechanism 143 learns this access example and accesses devices A → B → C → D → E → F → G → H → I → J so that the number of times of switching of the I2C multiplexer is minimized. Optimize access order. As a result, in the second access after the learning process, as shown in FIG. 7, the switching frequency of the I2C multiplexer is reduced from 10 times to 6 times to improve access performance.

FIG. 8 is a diagram for explaining the details of the access order learning process by the learning mechanism 143 for the connection example of FIG. In FIG. 8, it is assumed that the determination table 142 is in an initial state. That is, for all entries, the I2C library device address is empty (EMPTY), the header is empty, the counter is “0”, and the pointer is empty.

If access is performed in the order of device A → E → J → B → F → I → C → G → D → H, the learning mechanism 143 executes the access order learning process (1) and is accessed. Registered in the learning table 141 in the order of access. That is, the learning mechanism 143 registers the device A in the learning table 141 with the access number “1”, and registers the device E in the learning table 141 with the access number “2”. Similarly, the learning mechanism 143 registers devices in the learning table 141 in the order of J → B → F → I → C → G → D → H.

Then, after registering the last accessed device H in the learning table 141 with the access number as “10”, the learning mechanism 143 registers a new entry in the index “0” of the decision table 142. Specifically, the learning mechanism 143 determines, as a new entry, an entry in which the I2C library device address is “0x01E001A0”, the header is “0xF0”, the counter is “2”, and the pointer is the start address of the learning table 141. 142. The reason for registering in the index “0” of the decision table 142 is that the lower 4 bits of the I2C device address of the device A accessed first is “0”.

Thereafter, the learning mechanism 143 optimizes the learning table 141 (2). That is, the learning mechanism 143 sorts the access order recorded in the learning table 141 so that the number of times of multiplexer switching is minimized. The I2C library device address is identified by the upper 3 bytes of the I2C controller number, multiplexer address, and multiplexer port number. For this reason, the learning mechanism 143 can optimize the learning table 141 in an order that minimizes the number of times of switching of the I2C multiplexer by sorting the information by the upper 3 bytes of the I2C library device address. In FIG. 8, the learning table 142 is optimized so that access is performed in the order of devices A → B → C → D → E → F → G → H → I → J.

FIG. 9 is a diagram for explaining the details of the speculative execution processing by the learning mechanism 143 for the connection example of FIG. In FIG. 9, it is assumed that the learning process 141 shown in FIG. 8 is registered in the learning table 141 and the decision table 142.

When the application 130 accesses the device A, the learning mechanism 143 refers to the corresponding index of the decision table 142, that is, the index “0” (1). Then, since the I2C library device address and the header information in the decision table 142 match the access instruction from the application 130, the learning mechanism 143 performs speculative execution processing (2).

In the speculative execution process, the learning mechanism 143 uses the learning table 141 to issue in advance an access command to the device in the order optimized by the access order learning process. Then, the learning mechanism 143 records the information obtained from each device by the pre-issuance in the prefetch information of the learning table 141. In FIG. 9, commands are issued in the order of device A → B → C → D → E → F → G → H → I → J. For example, “1” is obtained from device A, and device B “2” is obtained from the record, and the obtained value is recorded in the learning table 141 as the respective prefetch information.

The learning mechanism 143 performs speculative execution processing when the first access from the application 130 is executed, and returns the prefetch information of the entry whose access number in the learning table 141 is “1” to the application 130 (3). Then, the learning mechanism 143 does not perform actual device access when the I2C library device address and the header information recorded in the learning table 141 in the second and subsequent accesses match the information given from the application 130. Returns prefetch information obtained in advance issue. On the other hand, if the information does not match the information from the application 130, the learning mechanism 143 discards the pre-read information of the subsequent access numbers and executes the conventional device access process.

In FIG. 9, the application 130 accesses devices A → E → J → B → F → I → C → G → D → H in this order, but the I2C library 140 is changed to the device A → B by speculative execution processing. Access is made in the order of C → D → E → F → G → H → I → J.

Note that the WRITE access changes the state of the hardware and has a high risk of being unrecoverable, so the speculative execution target is the READ access. For example, if the I2C library issues an I2CWRITE to a register that indicates some hardware operation based on the prediction, and an operation different from the prediction is detected later, the started operation is not recovered. Even for WRITE data, if the status latch is set or the retained data is written to the I2C storage device, the data can be recovered by overwriting again. However, generally, writing to them is a store of some state / data change, and only the upper side of the I2C library knows how it changes (what WRITE data is issued). The value after change is unpredictable. Therefore, speculative execution is not performed for WRITE access.

Next, the processing procedure of the I2C library 140 will be described. FIG. 10 is a flowchart showing the processing procedure of the I2C library 140. Here, it is assumed that the I2C library 140 receives a function call for accessing the

I2C devices

105 and 205 in a state where the learning mechanism start instruction is received from the application 130.

As shown in FIG. 10, the I2C library 140 acquires the I2C library device address specified by the function call (step S1). Then, the I2C library 140 focuses on the I2C library device address and refers to the determination table 142 (step S2).

Then, the I2C library 140 determines whether or not speculative execution is possible (step S3). If not, it determines whether or not to learn the access order to the I2C devices 105 and 205 (step S4). . As a result, when the access order is not learned, the I2C library 140 performs a process without learning as in the prior art (step S5).

On the other hand, when learning the access order, the I2C library 140 performs a learning process, that is, an access order recording process. Specifically, the I2C library 140 receives a function call from the application 130 and performs processing, and records the access order to the

I2C devices

105 and 205 in the learning table 141 (step S6).

When receiving an instruction to end the learning mechanism from the application 130, the I2C library 140 registers an entry in the determination table 142, and determines the order in which the number of times of switching the I2C multiplexer 104 is minimized. That is, the I2C library 140 sorts the recorded contents of the learning table 141 based on the I2C library device address (step S7). Note that the entry may be registered in the decision table 142 at the start of learning.

On the other hand, if speculative execution is possible, the I2C library 140 performs speculative execution (step S8) and determines whether or not speculative execution is successful (step S9). As a result, when the speculative execution is successful, the counter value of the determination table 142 is counted up (step S10), and when the speculative execution is not successful, the counter value of the determination table 142 is counted down (step S11). ).

As described above, the I2C library 140 performs learning and speculative execution using the learning table 141 and the decision table 142, thereby shortening the access time when sequentially accessing the

I2C devices

105 and 205. it can.

Next, the function processing of the I2C library 140 will be described. FIG. 11 is a flowchart showing the processing procedure of the function processing of the I2C library 140. The function process is a process performed in step S5 in FIG. 10, and is also performed as a part of the process in step S6.

As shown in FIG. 11, the I2C library 140 determines whether or not the accepted function call is WRITE (step S31). As a result, when the accepted function call is WRITE, the I2C library 140 determines whether or not there is MUX switching, that is, whether or not switching of the I2C multiplexer 104 is necessary (step S32), and is necessary. In this case, MUX switching is performed.

Specifically, the I2C library 140 performs a WRITE activation process for MUX switching as the MUX switching process (step S33), and waits for completion of WRITE (step S34). When WRITE is completed, the I2C library 140 performs WRITE completion processing (step S35).

Then, the I2C library 140 performs a WRITE process. That is, the I2C library 140 performs WRITE activation processing as WRITE processing (step S36), and waits for completion of WRITE (step S37). When WRITE is completed, the I2C library 140 performs WRITE completion processing (step S38).

On the other hand, if the accepted function call is not WRITE, the I2C library 140 determines whether or not the accepted function call is READ (step S39). As a result, if the accepted function call is not READ, the I2C library 140 terminates the processing. If it is READ, it determines whether or not there is MUX switching (step S40). Performs MUX switching.

Specifically, the I2C library 140 performs WRITE activation processing for MUX switching (step S41) as MUX switching processing, and waits for completion of WRITE (step S42). Then, when the WRITE is completed, the I2C library 140 performs a WRITE completion process (step S43).

Then, the I2C library 140 performs a READ process. That is, the I2C library 140 performs a READ activation process as a READ process (step S44) and waits for completion of the READ (step S45). When the READ is completed, the I2C library 140 performs a READ completion process (step S46).

Thus, the I2C library 140 performs MUX switching processing when there is MUX switching. Therefore, when accessing the

I2C devices

105 and 205 in order, the I2C library 140 can shorten the access time by reducing the number of MUX switching.

Next, processing procedures for learning and speculative execution by the learning mechanism 143 will be described. FIG. 12A and FIG. 12B are flowcharts showing the processing procedure of learning and speculative execution by the learning mechanism 143.

As shown in FIG. 12A, the learning mechanism 143 determines the index of the determination table 142 from the first I2C device address designated by the application 130 (step S51). Then, the learning mechanism 143 compares the first device access specified by the application 130 with the device access specified by the index in the determination table 142 (step S52), and determines whether or not they match.

As a result, if they do not match, that is, if access to another device is registered or learning is not performed, the learning mechanism 143 uses the weight of the recording information corresponding to the index in the decision table 142. Is determined (step S53). Specifically, the learning mechanism 143 determines whether or not the value of the counter specified by the index in the determination table 142 is greater than or equal to a threshold value.

As a result, when the value of the counter is not equal to or greater than the threshold value, the learning mechanism 143 determines that the weight of the recorded information is small and the learning table 141 should be overwritten, and performs learning. That is, the learning mechanism 143 records device access in the learning table 141 (step S54), performs MUX switching as necessary (step S55), and performs device access (step S56).

Then, the learning mechanism 143 determines whether or not the device access has ended (step S57), and if not completed, returns to step S54 to process the next device access. On the other hand, if completed, the learning mechanism 143 performs registration in the determination table 142 (step S58), and sorts the learning contents based on the I2C device library address to optimize the learning table 141 (step S59). . The learning mechanism 143 receives the learning mechanism end instruction from the application 130 and determines that the device access has ended.

On the other hand, when the value of the counter is equal to or greater than the threshold value, the learning mechanism 143 determines that the weight of the recorded information is large and that the learning table 141 is not overwritten, and performs a conventional process that does not perform learning. Specifically, the learning mechanism 143 performs MUX switching as necessary (step S60) and performs device access (step S61).

Then, the learning mechanism 143 determines whether or not the device access has ended (step S62). If it has not ended, the learning mechanism 143 returns to step S60 to process the next device access, and when the device access has ended. Ends the process.

If it is determined in step S52 that the first device access specified by the application 130 matches the device access specified by the index in the determination table 142, the learning mechanism 143 performs the process shown in FIG. 12B. That is, the learning mechanism 143 compares the counter values (step S63). If the counter value is smaller than the threshold value, the learning table 141 has a small weight, and learning is performed for temporary recording in order to perform overwriting by learning. A table is prepared (step S64).

Then, the learning mechanism 143 starts issuing commands in advance from the information in the learning table 141 (step S65). That is, the learning mechanism 143 performs MUX switching (step S66) and accesses the device (step S67). Then, the learning mechanism 143 stores the read contents in the corresponding prefetch information field of the learning table 141 (step S68), and determines whether all addresses have been accessed based on the learning table 141 (step S69).

As a result, when all addresses have been accessed, the learning mechanism 143 ends the command issuance, and performs a confirmation process (step S70). On the other hand, if there is an address that has not been accessed, the learning mechanism 143 compares the MUX address, that is, compares the multiplexer address (step S71). Then, the learning mechanism 143 returns to step S66 if they do not match, and returns to step S67 if they match because the MUX switching is unnecessary.

In this way, the learning mechanism 143 can shorten the access time when accessing the

I2C devices

105 and 205 in order by performing learning and speculative execution processing using the learning table 141 and the decision table 142. it can.

Next, the processing procedure of the confirmation process will be described. FIG. 13 is a flowchart showing the procedure of the confirmation process. As shown in FIG. 13, the learning mechanism 143 accepts a device access function call of the application 130 after the command issuance is completed (step S81), and determines whether or not a temporary recording learning table is prepared. (Step S82). As a result, when the learning table for temporary recording is prepared, the learning mechanism 143 records the access information in the learning table for temporary recording (step S83).

Then, if the device access function call from the application 130 is n-th, the learning mechanism 143 compares the n-th access with the n-th access in the learning table 141 (step S84) and determines whether or not they match. judge.

As a result, if they match, the device access functions are called in the learned order, so that the learning mechanism 143 returns the prefetch information recorded in the learning table 141 by the prior issue of the command (step S85). ). Then, it is determined whether or not all accesses have been completed (step S86). If there is an access that has not been completed, the learning mechanism 143 returns to step S81 to process the next device access function call.

On the other hand, if all accesses have been completed, the learning mechanism 143 determines whether or not all access information has been returned from the prefetch information (step S87). When all the access information is returned from the prefetch information, the learning mechanism 143 increments the corresponding counter of the decision table 142 because the device access function call has been completed in the learned order (step S89). ). On the other hand, when the prefetch information not returned is in the learning table 141, the learning mechanism 143 decrements the corresponding counter of the determination table 142 (step S88), and proceeds to step S97.

In step S84, if the nth access does not match the nth access in the learning table 141, the learning mechanism 143 decrements the corresponding counter in the decision table 142 (step S90). Here, the case where the n-th access and the n-th access in the learning table 141 do not match each other is a case where the application 130 is accessing differently from the learning table 141.

Then, the learning mechanism 143 receives the device access function call of the application 130 (step S91), and determines whether or not a temporary recording learning table is prepared (step S92). As a result, when a learning table for temporary recording is prepared, the learning mechanism 143 records access information in the learning table for temporary recording (step S93).

The learning mechanism 143 performs MUX switching as necessary (step S94) and performs device access (step S95). Then, the learning mechanism 143 determines whether or not all device accesses have been completed (step S96). If not completed, the learning mechanism 143 returns to step S91 to process the next device access.

On the other hand, when all the device accesses are completed, the learning mechanism 143 compares the counter value with the threshold value (step S97). If the counter value is smaller than the threshold value, the learning mechanism 143 replaces the learning table 141 with the temporary recording learning table (step S98), sorts the learning contents by the I2C library device address, and stores the learning table 141. Optimize (step S99).

As described above, the learning mechanism 143 can correctly respond when the function call corresponding to the previously issued command is performed from the application 130 by performing the confirmation process.

Next, learning and speculative execution when the monitoring application reads the values of the 5V power sensor and the 10V power sensor under the I2C multiplexer will be described with reference to FIGS. 14 to 17B.

FIG. 14 is a diagram illustrating an example of a 5V power supply sensor and a 10V power supply sensor under the I2C multiplexer. As shown in FIG. 14, 5V power sensor A and 10V power sensor A are connected to port ₁ of I2C multiplexer 501, and 5V power sensor B and 10V power sensor B are connected to port _{2 of} I2C multiplexer 501. . The I2C multiplexer 501 is connected to the I2C controller 502.

Further, the I2C device address of the 5V power supply sensor A is “0x01”, and the I2C device address of the 10V power supply sensor A is “0x02”. The I2C device address of the 5V power supply sensor B is “0x01”, and the I2C device address of the 10V power supply sensor A is “0x02”. The multiplexer address of the I2C multiplexer is “0x01”, the multiplexer port number of port ₁ is “0x01”, and the multiplexer port number of port ₂ is “0x02”. The I2C controller number of the I2C controller 502 is “0x01”.

The I2C library 140 reads the values of the 5V power sensor and the 10V power sensor by driving the I2C controller 502 based on an instruction from the monitoring application. Since the monitoring application performs monitoring in the order of the 5V power sensor and the 10V power sensor, the device access function of the I2C library 140 is called in the order of 5V power sensor A → 5V power sensor B → 10V power sensor A → 10V power sensor B. In addition, the monitoring application issues a learning mechanism start and end instruction to the I2C library 140.

FIG. 15 is a diagram showing the learning table 141 before and after optimization. As shown in FIG. 15, the pre-optimal learning table 141 records device accesses in the order of 5V power sensor A → 5V power sensor B → 10V power sensor A → 10V power sensor B accessed by the monitoring application. On the other hand, in the learning table 141 after optimization, device access is performed in the order sorted using the I2C library device address, that is, in the order of 5 V power sensor A → 10 V power sensor A → 5 V power sensor B → 10 V power sensor B. Is recorded.

FIG. 16 is a diagram showing the determination table 142 after learning. As shown in FIG. 16, the I2C library 140 records the I2C library device address, header, counter, and pointer of the 5V power supply sensor A that is accessed first. The counter value is initialized to “2” which is a threshold value, and “0x80000000” which is the address of the learning table 141 is stored in the pointer.

Then, as shown in FIG. 15, the I2C library 140 performs I2C multiplexer switching and device access while recording the access number, device address, and header in the learning table 141. Here, the case where registration to the decision table 142 is performed when the first device access is performed is shown, but as shown in FIG. 12A, the decision table 142 is entered when all device accesses are completed. May be registered.

FIG. 17A is a sequence diagram illustrating the operation of the firmware 120 during learning, and FIG. 17B is a sequence diagram illustrating the operation of the firmware 120 during speculative execution.

As shown in FIG. 17A, the monitoring application performs a learning mechanism start operation on the I2C library 140 (step S201), and the I2C library 140 responds to the monitoring application to start the learning mechanism (step S202).

Then, the monitoring application calls the READ function with the I2C library device address “0x01010101” as an argument (step S203). Then, the I2C library 140 determines the index of the determination table 142, registers it in the determination table 142 (step S204), and associates it with the learning table 141 (step S205).

Then, the I2C library 140 records the access order in the learning table 141 (step S206), and switches to port ₁ (step S207). Then, the I2C library 140 reads the value of the 5V power supply sensor A (step S208) and returns the value to the monitoring application (step S209).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010201” as an argument (step S210). Then, the I2C library 140 records the access order in the learning table 141 (step S211), and switches to port ₂ (step S212). Then, the I2C library 140 reads the value of the 5V power supply sensor B (step S213) and returns the value to the monitoring application (step S214).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010102” as an argument (step S215). Then, the I2C library 140 records the access order in the learning table 141 (step S216), and switches to port ₁ (step S217). Then, the I2C library 140 reads the value of the 10V power supply sensor A (step S218) and returns the value to the monitoring application (step S219).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010202” as an argument (step S220). Then, the I2C library 140 records the access order in the learning table 141 (step S221), and switches to port ₂ (step S222). Then, the I2C library 140 reads the value of the 10V power supply sensor B (step S223) and returns the value to the monitoring application (step S224). Then, the monitoring application performs a learning mechanism end operation on the I2C library 140 (step S225). Then, the I2C library 140 optimizes the learning table 141 (step S226), and returns a learning mechanism end response to the monitoring application (step S227).

Further, as shown in FIG. 17B, the monitoring application performs a learning mechanism start operation on the I2C library 140 (step S261), and the I2C library 140 responds to the monitoring application to start the learning mechanism (step S262).

Then, the monitoring application calls the READ function with the I2C library device address “0x01010101” as an argument (step S263). Then, the I2C library 140 determines the index of the determination table 142, refers to the determination table 142 (step S264), and acquires a pointer to the learning table 141 (step S265).

Then, the I2C library 140 switches to port ₁ (step S266), reads the value of the 5V power supply sensor A based on the learning table 141 (step S267), and reads the value of the 10V power supply sensor A (step S268). ). The I2C library 140 then switches to port ₂ based on the learning table 141 (step S269), reads the value of the 5V power supply sensor B (step S270), and reads the value of the 10V power supply sensor B (step S271). ). Then, the I2C library 140 returns the value of the 5V power supply sensor A to the monitoring application (step S272).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010201” as an argument (step S273). Then, the I2C library 140 refers to the learning table 141 (step S274) and acquires prefetch information (step S275). Then, the I2C library 140 returns the acquired prefetch information to the monitoring application (step S276).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010102” as an argument (step S277). Then, the I2C library 140 refers to the learning table 141 (step S278) and acquires prefetch information (step S279). Then, the I2C library 140 returns the acquired prefetch information to the monitoring application (step S280).

Thereafter, the monitoring application calls the READ function with the I2C library device address “0x01010202” as an argument (step S281). Then, the I2C library 140 refers to the learning table 141 (step S282) and acquires prefetch information (step S283). Then, the I2C library 140 returns the acquired prefetch information to the monitoring application (step S284).

Then, the monitoring application performs a learning mechanism end operation on the I2C library 140 (step S285). Then, the I2C library 140 sends a learning mechanism end response to the monitoring application (step S286).

As described above, in this embodiment, the learning table 141 stores the device access order so that the number of times of switching the I2C multiplexer 104 is minimized. When the device access stored in the learning table 141 is first performed by the application 130, the learning mechanism 143 performs speculative execution of device access in the order stored in the learning table 141. Therefore, the I2C library 140 can prevent an increase in access time due to the bus switching of the I2C multiplexer 104.

Also, in this embodiment, the learning mechanism 143 learns device access by the application 130, optimizes the switching frequency of the I2C multiplexer 104, and stores it in the learning table 141. Therefore, the I2C library 140 can automatically create the learning table 141.

In this embodiment, the determination table 142 stores information related to the first device access in the learned device access order. Therefore, when the device 130 is first accessed by the application 130, the learning mechanism 143 can easily determine whether or not speculative execution is possible with reference to the determination table 142.

Also, in this embodiment, the learning mechanism 143 determines whether or not the prior issue of the access command to the device matches the actual access from the application 130. Then, the determination table 142 stores the weight that is increased or decreased based on the determination result by the learning mechanism 143 for each device access order. Therefore, the learning mechanism 143 can evaluate the reproducibility of the learned device access order using the weight, and can control the update of the learning table 141 based on the evaluation result.

In this embodiment, the I2C bus has been described. However, the present invention is not limited to this, and can be similarly applied to a bus that connects a controller and a device with a multiplexer interposed therebetween.

In the present embodiment, the case where the learning mechanism 143 performs speculative execution has been described. However, the present invention is not limited to this, and can be similarly applied to a case where device access is executed when a function call from the application 130 is received without performing speculative execution.

In this embodiment, the information processing apparatus 1 having the control board 100 and the target boards 200 to 400 has been described. However, the present invention is not limited to this. That is, the present invention can be similarly applied to an information processing apparatus that includes a CPU, a memory, a controller, a multiplexer, and a device, and the device is bus-connected to the controller via the multiplexer.

1 Information processing apparatus 100 Control board 101 MPU
102

Memory

103, 203 Control FPGA
104

I2C multiplexer

105, 205 I2C device 106, 206

I2C bus

110, 210 I2C controller 120 Firmware 130 Application 140 I2C library 141 Learning table 142 Decision table 143 Learning mechanism 144 Command issuing unit 150 Driver 151 I2C driver 152 FPGA driver 200-400 Target Board 501 I2C multiplexer 502 I2C controller

Claims

An access order storage unit that stores an access order determined based on the number of switching multiplexers in accessing a plurality of devices via the multiplexer;
And an execution unit that executes access to the plurality of devices according to an access order stored in the access order storage unit.
It further comprises a learning unit that learns the access order performed on the plurality of devices, replaces the learned access order so that the number of multiplexer switching is minimized, and stores the learning order in the access order storage unit. The control device according to claim 1.
A determination unit for determining the presence or absence of an access order stored in the access order storage unit by the learning unit;
The execution unit executes access to the plurality of devices according to the access order when the determination unit determines that the access order is present,
The learning unit learns the access order when the determination unit determines that the access order is not present, and replaces the learned access order so that the number of multiplexer switching is minimized, and the access order storage unit The control device according to claim 2, wherein the control device is stored in the control device.
The determination unit determines the presence or absence when access to the first device is requested,
The execution unit speculatively executes access to the plurality of devices according to the access order, stores an execution result, accepts an access request for a device that has speculatively accessed from the application after speculative execution, The control apparatus according to claim 3, wherein the stored execution result is responded.
The execution unit determines whether or not a speculative execution order matches an access request order from an application, and controls updating of the access order storage unit based on a determination result. Item 5. The control device according to Item 4.
In an access to a plurality of devices via the multiplexer, the access order determined based on the switching number of the multiplexer is stored in the access order storage unit,
A device access method comprising: performing a process of accessing the plurality of devices according to an access order stored in the access order storage unit.
In an access to a plurality of devices via the multiplexer, the access order determined based on the switching number of the multiplexer is stored in the access order storage unit,
A device access program for causing a computer to execute a process of accessing the plurality of devices in accordance with an access order stored in the access order storage unit.
In an information processing apparatus including a target device that is a control target and a control device that controls the target device,
The controller is
An access order storage unit that stores an access order determined based on the number of switching multiplexers in accessing a plurality of devices via the multiplexer;
An information processing apparatus comprising: an execution unit that executes access to the plurality of devices according to an access order stored in the access order storage unit.