JPH0638251B2 - Online method for multiple processors - Google Patents

Description

Description: TECHNICAL FIELD The present invention relates to an online system in a multiprocessor for connecting a bus of a firmware CPU and a host CPU online at a high speed.

[Conventional technology]

As a simple communication between computers, a local area network, a vising method, an online method using a telephone line, etc. have been developed.

However, as for communication between buses in a short distance, no appropriate technology has been developed at present.

[Problems to be solved by the invention]

There is an extreme speed gap between the firmware CPU, which is written in assembler and is pipeline controlled, and the host CPU, which mainly uses high-level languages and whose main task is data processing. Transferring, for example, executing a multi-processing system using the vising method will result in an inefficient system with a great deal of CPU latency. The present invention aims to perform efficient online processing.

[Means for solving problems]

In order to achieve the above object, the present invention provides an interface including a receiving command buffer, a transmitting command buffer, and a large-capacity data transmitting common buffer on the firmware CPU side in a method of connecting a firmware side and a host computer online. 4 is provided,
An interface including a command buffer for transmission, a command buffer for reception, and a common buffer for receiving large-capacity data is provided on the host CPU side, and the two interfaces are connected by a transmission line.
A ring buffer is provided on the side to send a variable length command consisting of an index indicating the type of command and an argument part for notifying the number of data words and a data part from the command buffer on the host side to the command buffer on the firmware side, and between the two interfaces. In addition to performing data communication, the variable length command sent from the host CPU side is accumulated in the ring buffer and the commands in the ring buffer are sequentially processed.

[Action]

The host CPU side sends a command regardless of the command processing situation on the firmware CPU side, and this command is stored in the ring buffer on the firmware CPU side. The firmware CPU side fetches a command in the ring buffer as necessary and processes it. Therefore, the command is efficiently processed regardless of the difference in processing speed between the two CPUs, and one of the CPUs does not play.

〔Example〕

Hereinafter, the configuration of the present invention will be described in detail with reference to the accompanying drawings.

The hardware configuration of the present invention is as shown in FIG.
The firmware parallel interface 4 on the side of the firmware CPU 2 and the host CPU parallel interface 8 on the side of the host CPU 6 are memory-mapped 1/0.
The mapping process and the like due to the difference in memory management among the 6 are hardware logic. Next, the inside of the interfaces 4 and 8 will be described with reference to FIG.

In FIG. 1, the command buffers 10, 12, 14,
Reference numeral 16 is for giving an instruction to the partner CPU or sending a reply, of which Writes 12 and 14 are for sending to the partner side and Reads 10 and 16 are for receiving from the partner CPU. Command buffer Writ of one CPU
As shown in the figure, the information of e is handled so that it will come to the Read buffer for the partner CPU. In the common buffers 20 and 22, where a huge amount of image-processed data coming from a well-known hole position coordinate automatic reader enters, the common buffer 20 on the firmware CPU side is only Write,
The common buffer 22 on the host CPU side is configured only for reception. The ring buffer 24 on the firmware side is configured to buffer commands from the host CPU 6. The common buffer 20 transfers the data in the firmware CPU 2 in blocks. Therefore, when online, there is no need to rewrite in the online buffer, and high speed is pursued. The common buffers 20 and 22 connected by a transmission line constitute a shared memory, and the data transmitted from the common buffer 20 is directly sent to the common buffer 2 without being sent to 1/0.
2 is transferred.

Next, the command will be described.

There are three types of commands.

First, the first one is only an instruction to the firmware CPU 2 by the host CPU 6, and the used buffers are a host command buffer (Write) 14 and a firmware command buffer (Read) 10 as shown in the figure. In the figure, the index of A indicates the type of command. A
In the argument part of, the number of words of B data is notified. B is the data delivered to the firmware CPU2. When a command comes from the host CPU 6, the firmware CPU
2 pushes the command to the ring buffer 24, pops the command by the buffer 24, and fetches and processes the data by the word designated by the argument portion of the command.

The second one is firmware C by the host CPU 6.
It sends a command to PU2 and gets a reply from firmware CPU2. The buffers used are host command buffers (Read) (Write) 16 and 14, and firm command buffers (Read, Write) 10 and 12. The command is sent from the host CPU to the firmware CPU as shown in FIG. 4a. This transmission processing procedure is the same as that of the first command. The firmware CPU 2 which has processed the data transmits the data to the host CPU in the same format as in FIG. 3 as shown in FIG. 4b.
The host CPU waits until this data comes.

In the third type, as shown in FIG. 5, the host CPU sends a command to the firmware CPU, and the firmware CPU sends large-capacity data such as image data to the host C.
Send to PU. The used buffers are command buffers (Read) (Write) 14 and 16 and common buffers (Read) 22 on the host side. On the firmware side, command buffers (Read) (Write) 10, 12 and common buffer (Writ)
e) 20. The host CPU 6 sends a command to the firmware CPU 2 via the command buffers (Write) (Read) 14 and 10, and the firmware CPU
In 2, when it is determined that the request is image data transmission, the data is block-transferred to the common buffer (Write) 20, the command that the image data is received is transmitted to the command buffer (Read) 16, and the host CPU 6 is notified.
Next, the image data is block-transferred to the common buffer (Read) 22. Next, the processing completion code is transferred to the command buffer (Read) 16. It is to be noted that various commands are made into a subroutine, packaged, and the host CPU and the firmware CPU are used in a modularized form.

The gist of the present invention is a combination of the above command and the ring buffer 24. Generally, the firmware CPU 2 has a high data processing speed, and the host CPU 6 side uses a high-level language, so that the data processing speed is slow. Therefore, when the interfaces 4 and 8 are simply connected online, it is impossible to process the commands issued and the commands sent back in real time between the interfaces.
Therefore, the host CPU side must wait for the firmware CPU to process the command and send the command each time, and the CPU waiting time becomes long, while one of the CPUs is idle. It becomes inefficient. However, due to the presence of the ring buffer 24, the host CPU side sequentially sends commands to the firmware side and stores them in the ring buffer 24 regardless of the result of the command processing on the firmware side. On the other hand, the firmware CPU 2 side sequentially processes the commands stored in the ring buffer 24 at the processing speed of the firmware CPU side as necessary to perform highly efficient work. Since the command of this embodiment is a variable length command having only necessary data, the data amount is extremely small,
Therefore, a large number of commands can be stored in the ring buffer 24, and the commands have only necessary data, which enables high-speed data processing without waste.

〔effect〕

Since the present invention has the ring buffer on the firmware side as described above, the difference in the processing speed between the processors does not pose a problem, and since the variable record length is used to manage the mutual communication data with the argument, the fixed length is set. No redundancy,
High-speed and efficient communication is possible. Furthermore, since the parallel interface is used as the interface and the large capacity data is a block transfer method and is a shared memory, there is no need to rewrite the data to the online buffer because it is online, and there is an effect that it can achieve extremely high speed. .

[Brief description of drawings]

FIG. 1 is a block diagram, FIG. 2 is a block diagram, and FIGS. 3 to 5 are diagrams. 2 ... Firmware CPU, 4 ... Interface, 6 ... Host CPU, 8 ... Interface, 1
0, 12, 14, 16 ... Command buffer, 20, 2
2 …… Common buffer, 24 …… Ring buffer

Claims (1)

[Claims] 1. In a method of connecting a firmware side and a host computer online, the firmware CPU side is provided with an interface 4 consisting of a reception command buffer, a transmission command buffer and a large capacity data transmission common buffer, and the host CPU An interface consisting of a command buffer for transmission, a command buffer for reception, and a common buffer for receiving large-capacity data is provided on the side, the two interfaces are connected by a transmission line, and a ring buffer is provided on the side of the firmware CPU to specify the type of command. A variable length command consisting of an index part and a data part that indicates the number of words of the data shown is sent from the command buffer on the host side to the command buffer on the firmware side to exchange data between the above two interfaces. Along with the form to Migihitsuji, host CP
An online system in a multiprocessor characterized in that the variable length command sent from the U side is stored in the ring buffer and the commands in the ring buffer are sequentially processed.