KR101934195B1 - Method of arbitrating for inter-connecting within a multi-processor system and apparatuses performing the same - Google Patents

Abstract

Disclosed are an arbitration method for interconnection in a multiprocessor system and apparatuses for performing the same. An arbitration method for inter-connecting in a multiprocessor system according to an embodiment includes determining a weight for a plurality of packets stored in a plurality of input ports based on a usage competition history for an output port, And arbitrating to use the output port for any one of the plurality of input ports based on the weight.

Description

TECHNICAL FIELD [0001] The present invention relates to an arbitration method for interconnection in a multiprocessor system and an apparatus for performing the interconnection method in a multiprocessor system.

The following embodiments relate to an arbitration method for interconnection in a multiprocessor system and devices for performing the same.

Interconnection networks have a significant impact on overall system performance and cost. Recently, research on interconnection networks has been of different types of interconnection networks in multi-socket systems that interconnect sockets within a server system.

Multi-socket servers are commonly used in high performance computing (HPC) and data centers. Each of the multi-socket servers may communicate with other sockets using a processor-interconnect.

Processor-interconnect refers to an interconnect technology that connects processors in a multi-processor system (or multi-socket system).

Processor-interconnect technologies are typically Intel Intel Quick Path interconnect (QPI) and advanced micro devices hypertransport.

Embodiments may provide a technique for arbitrating interconnections between local and / or remote processors based on a usage competition history.

In addition, embodiments may provide processor-interconnect technology to interleave a plurality of packets to fairly interconnect local and remote processors.

An arbitration method for inter-connecting in a multiprocessor system according to an embodiment includes determining a weight for a plurality of packets stored in a plurality of input ports based on a usage competition history for an output port, And arbitrating to use the output port for any one of the plurality of input ports based on the weight.

The determining step may include calculating the weight based on the number of source IDs of the sources corresponding to the plurality of packets stored in the history queue of the use competition history.

The calculating may comprise determining a weight for the plurality of packets in inverse proportion to the number of source IDs.

The calculating may include counting the number of source IDs from the history queue and inversely transforming the counted count values to determine a weight for the plurality of packets.

The determining may comprise swapping the number of source IDs to determine a weight for the plurality of packets.

Wherein the arbitration method further comprises the steps of: if there is a storage space in the history queue of the contention history, storing the source ID of the source corresponding to the packet stored in the history queue in the history queue; And deleting the source ID stored in the head of the history queue and storing the source ID of the source corresponding to the packet stored in the history queue in the history queue.

The arbitration method may further include updating at least one of a counter value of the source ID corresponding to the packet stored in any one of the packets and a counter value of the deleted source ID.

The packet stored in any one of the above may be the packet having the largest weight.

The arbitrating step may include a step of comparing the weights of the packets stored in each of the plurality of input ports and arbitrating the output port to use the output port for the input port corresponding to the packet having the largest weight.

The arbitrating step may include arbitrating for using the output port by performing probability arbitration using the weight and the random number stored in the look-up table.

A router for arbitrating inter-connecting in a multiprocessor system according to an embodiment may include a plurality of input ports storing a plurality of packets and a plurality of input ports, And a history based arbiter for determining a weight for a plurality of stored packets and for arbitrating to use the output port for any one of the plurality of input ports based on the weight.

The history-based arbiter can calculate the weight based on the number of source IDs of the source corresponding to the plurality of packets stored in the history queue of the usage history of the use.

The history-based arbiter may determine a weight for the plurality of packets in inverse proportion to the number of source IDs.

The history-based arbiter counts the number of source IDs from the history queue, and inversely transforms the counted count values to determine a weight for the plurality of packets.

The history-based arbiter may determine a weight for the plurality of packets by swapping the number of the source IDs.

Wherein the history-based arbiter stores the source ID of the source corresponding to the packet stored in any one of the history queues in the history queue of the use competition history in the history queue, and if the history queue has no storage space in the history queue, The source ID stored in the head of the queue is deleted, and the source ID of the source corresponding to the packet stored in the one is stored in the history queue.

The history-based arbiter may update at least one of a counter value of the source ID corresponding to the packet stored in the one and a counter value of the deleted source ID.

The packet stored in any one of the above may be the packet having the largest weight.

The history-based arbiter may include a weight calculator that compares weights of packets stored in each of the plurality of input ports, and arbitrates the input ports corresponding to the largest weighted packet to use the output ports first.

The history-based arbiter may include a weight calculator for arbitrating the output port to use the output port by performing probability arbitration using the weight and the random number stored in the look-up table.

1 shows an example for explaining a multiprocessor system according to an embodiment.
FIG. 2 is a view for explaining an example of a method for interprocessor interconnection arbitration shown in FIG. 1. FIG.
3 shows a schematic block diagram of a router according to one embodiment.
FIG. 4 shows an example of a schematic block diagram of the history-based arbiter shown in FIG.
FIG. 5 shows an implementation of the history-based arbiter shown in FIG.
Figs. 6A to 6C show examples for explaining the weight calculator shown in Figs. 3 and 4. Fig.
7 is a flowchart illustrating an operation of a router according to an embodiment of the present invention.

It is to be understood that the specific structural or functional descriptions of embodiments of the present invention disclosed herein are presented for the purpose of describing embodiments only in accordance with the concepts of the present invention, May be embodied in various forms and are not limited to the embodiments described herein.

Embodiments in accordance with the concepts of the present invention are capable of various modifications and may take various forms, so that the embodiments are illustrated in the drawings and described in detail herein. However, it is not intended to limit the embodiments according to the concepts of the present invention to the specific disclosure forms, but includes changes, equivalents, or alternatives falling within the spirit and scope of the present invention.

The terms first, second, or the like may be used to describe various elements, but the elements should not be limited by the terms. The terms may be named for the purpose of distinguishing one element from another, for example without departing from the scope of the right according to the concept of the present invention, the first element being referred to as the second element, Similarly, the second component may also be referred to as the first component.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between. Expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. It is to be understood that in the present context, terms such as "include" or "having" are intended to designate the presence of stated features, integers, steps, operations, elements, parts, or combinations thereof, , Steps, operations, components, parts, or combinations thereof, as a matter of principle.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the meaning of the context in the relevant art and, unless explicitly defined herein, are to be interpreted as ideal or overly formal Do not.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, the scope of the patent application is not limited or limited by these embodiments. Like reference symbols in the drawings denote like elements.

1 shows an example for explaining a multiprocessor system according to an embodiment.

Referring to FIG. 1, a multi-processor system 10 includes a plurality of processors 100, 200, 300, and 400. Although FIG. 1 shows a multiprocessor system 10 composed of four processors for convenience of explanation, the present invention is not limited thereto. In accordance with an embodiment, the multiprocessor system 10 may be implemented with two or more processors.

The multiprocessor system 10 further includes a router 500, an input / output unit 600, and a memory 700.

The multiprocessor system 10 uses processor-interconnect technology for inter-conneting a plurality of processors 100, 200, 300, and 400. For example, the processor-interconnect technology used by the multiprocessor system 10 may be an AMD microtransport (AMD HT).

Each of the plurality of processors 100, 200, 300, and 400 may be configured as an on-chip with a plurality of cores and a north bridge. For example, the north bridge may include a memory controller (MCT) (not shown), a last level cache (LLC) (not shown), a hypertransport (HT) 500). As shown in FIG. 1, each of a plurality of processors (or a plurality of nodes) in the multiprocessor system 10 may include a router 500.

The router 500 of each of the processors 100, 200, 300, and 400 determines the communication between the cores included in each of the processors 100, 200, 300, and 400, For example, sending and receiving packets).

That is, the multiprocessor system 10 arbitrates the transmission and reception of packets between the cores included in each processor 100, 200, 300, and 400 via the router 500 based on the use competition history, They can be interconnected fairly.

FIG. 2 is a view for explaining an example of a method for interprocessor interconnection arbitration shown in FIG. 1. FIG.

2, it is assumed that the interconnections between the first processor 100 and the second processor 200 are assumed to be interconnected, and that the processors 100 and 200 are implemented with six cores (or sources). It is also assumed that the processor-interconnect technology uses the Intel intel quick path interconnect (QPI) processor-interconnect technology.

Referring to FIG. 2, the first processor 100 includes a core 0 (C0), a first core (C1), a second core (C2), a third core (C3) C3, a fourth core (C4), a fifth core (C5), and a first multiplexer (110). The second processor 200 includes a sixth core C6, a seventh core C7, an eighth core C8, a ninth core C9, a core 10 (C10), a core 11 (C11), and a second multiplexer (210).

The first processor 100 and the second processor 200 include a router 500 including a router multiplexer 550. The first multiplexer 110 can receive packets from each of the cores C0 to C5. In addition, the first multiplexer 110 may transmit the packet to the router 500 of the first processor 100. [ For example, the packet may be one or more independent packets output from each of the cores C0 through C5.

The router 500 of the second processor 200 may transmit the packet to the router 500 of the first processor 100. [ For example, the packet may be one or more independent packets output from the core (C6, C7, C8, C9, C10, or C11).

The router 500 of the first processor 100 is connected to any one of the local cores C0, C1, C2, C3, C3, C4 or C5 and any one of the remote cores C6, C7, C8, C9, C10, Or C11). The packet output from the sixth core C6 is transmitted to the router 500 of the first processor 100 through the router 500 of the second processor 200 as shown in FIG.

That is, the first processor 100 and the second processor 200 may use an external concentration technique to minimize the complexity of the router 500 architecture.

However, when using external congestion techniques, the local and remote processors 100 and 200 can not be fairly interconnected to transmit and receive a plurality of packets.

The following describes a router 500 and a method of operation thereof for a processor-interconnect technology that fairly interconnects local and remote processors even when using external congestion techniques.

3 shows a schematic block diagram of a router according to one embodiment.

3, the router 500 includes a plurality of input ports 510, an arbiter based on history 530, and a router multiplexer 550. The router 500 includes a plurality of input ports 510, do.

The plurality of input ports 510 may include a first input port 510-1 to an nth input port 510-n. For example, n may be a natural number greater than or equal to one.

Each of the plurality of input ports 510 may include an input buffer or a virtual channel. For example, the input buffer or virtual channel may be a plurality of input buffers or a plurality of virtual channels.

Each of the plurality of input ports 510 may receive a packet and store the packets in their respective input buffers or virtual channels in the order received.

At this time, each of the plurality of input ports 510 may receive a packet transmitted from each of a plurality of sources (or cores). For example, the first input port 510-1 receives the packet output from the first source, the second input port 510-2 receives the packet output from the second source, (510-2) can receive the packet output from the nth source. The first source, the second source, and the nth source may be different cores, a core in a local processor and / or a core in a remote processor.

Each of the plurality of input ports 510 may output a request signal to the history-based arbiter 530 to use an output port connected to the router multiplexer 550 when the packet is received. For example, a request signal output from each of the plurality of input ports 510 may include a source identification (or a core number) of a source corresponding to a packet stored in each of the input ports 510.

The history-based arbiter 530 is configured to preferentially use the output port connected to the router multiplexer 550 for any one of the plurality of input ports 510 in response to the request signal output from each input port 510 You can arbitrate. For example, the history-based arbiter 530 may arbitrate to preferentially use the output port connected to the router multiplexer 550 based on the usage competition history for the output port connected to the router multiplexer 550 History-based arbiter 530 can determine weights for the packets stored in the plurality of input ports 510 based on the usage competition history for the output ports connected to the router multiplexer 550 have. Thereafter, the history-based arbiter 530 may arbitrate to preferentially use the output port connected to the router multiplexer 550 for any one of the plurality of input ports 510 based on the weights.

The usage competition history may refer to the past (or previous) winner history of the source (or core) that won the competition to use the output port connected to the router multiplexer 550.

For example, when packets are piled up on a plurality of input ports 510, a plurality of input ports 510 are used to compete for output ports connected to the router multiplexer 550 to output packets, . At this time, when the specific input port wins the competition and preferentially uses the output port, the source corresponding to the packet accumulated in the specific input port (i.e., the source that outputs (or generates) the packet) is determined as the winner. That is, the usage competition history means a winner history of a victorious source for outputting a packet through an output port connected to the router multiplexer 550 in the past (or before).

The history-based arbiter 530 is not necessarily limited to an arbitration operation considering a weight, and can perform an arbitration operation based on a history in consideration of various factors.

The history-based arbiter 530 transmits an arbitration signal for arbitrating the output port connected to the router multiplexer 550 to any one of the plurality of input ports 510 to the router multiplexer 550).

The router multiplexer 550 can output packets stored in any one of the plurality of input ports 510 in response to the arbitration signal, for example, under the control of the history-based arbiter 530.

Accordingly, any one of the plurality of input ports 510 may output the stored packet using the output port connected to the router multiplexer 550 first.

Hereinafter, for convenience of description, the history-based arbiter 530 that performs the arbitration function considering the weight values will be described.

FIG. 4 shows an example of a schematic block diagram of the history-based arbiter shown in FIG.

4, the history-based arbiter 530 may arbitrate to preferentially use the output port connected to the router multiplexer 550 for any one of the plurality of input ports 510 based on the weights .

The history-based arbiter 530 may include a history queue 531, a counter 533 and a weighted calculator 535.

The history queue 531 is a storage device, e.g., a queue, for storing past winner histories.

In response to the grant signal transmitted from the weight calculator 535, the history queue 531 is configured to use the output port connected to the router multiplexer 550, You can store the source ID. For example, the history queue 531 may include a queue corresponding to each source ID.

The acknowledgment signal may include the source ID contained in the request signal of the arbitrated input port. In addition, the acknowledge signal may push the source ID to the history queue 531.

The history queue 531 may determine whether to delete the stored source ID according to the storage space of the history queue 531 and store the source ID transmitted from the weight calculator 535. [

As an example, if there is a storage space, the history queue 531 may store the source ID sent from the weight calculator 535 without deleting the stored source ID.

As another example, if there is no storage space, the history queue 531 may delete the source ID stored in the head of the history queue 531 and store the source ID sent from the weight calculator 535. [

The counter 533 can output a count value obtained by counting the number of each source ID stored in the history queue 531 to the weight calculator 535. [ For example, the counter 533 may include a counter corresponding to a queue of each source ID.

For example, the counter 533 may count the number of each source ID stored in the history queue 531 under the control of the weight calculator 535. For example, the counter 533 may search for a source ID corresponding to the source ID included in the request signal among the source IDs stored in the history queue 531. [ Thereafter, the counter 533 may calculate the count value of the source ID by counting the number of the retrieved source IDs.

As another example, the counter 533 may store count values that count the number of each source ID stored in the history queue 531 in advance. The counter 533 may output the count value of the source ID among the count values stored in the counter 533 to the weight calculator 535 under the control of the weight calculator 535. [

The counter 533 may update the count values of each source ID stored beforehand.

In one example, the counter 533 may increase the counter value of the source ID in response to the grant signal sent from the weight calculator 535. [

As another example, the counter 533 may decrease the counter value of the source ID included in the erasure signal in response to the pop signal sent from the history queue 531. At this time, the delete signal may include information on the deleted source ID at the head of the history queue 531. [

The weight calculator 535 may control the overall operation of the history based arbiter 530. For example, the weight calculator 535 may control the operation of the history queue 531 and the counter 533.

The weight calculator 535 may obtain the counter values from the counter 533 in response to the request signal output from each input port 510. [ The counter values may be the count value of the source ID included in the request signal of each input port 510.

The weight calculator 535 may determine a weight for a plurality of packets stored in the plurality of input ports 510 based on the counter values output from the counter 533. [

The weight calculator 535 may determine the weight inversely and / or proportionally to the counter values. For example, the weight calculator 535 may determine the respective weights as opposed to the magnitude of the counter value of the source IDs. As another example, the weight calculator 535 may invert the counter value of the source IDs to determine the respective weights. As another example, the weight calculator 535 may swap the counter value of the source IDs to determine the weight.

The weight can be expressed by Equation (1).

는 소스 ID가 i인 패킷에 대한 소스 ID의 개수를 나타내고,

는 히스토리 큐의 깊이를 나타내고,

는 소스 ID가 i인 패킷에 대한 가중치를 나타낸다.In Equation (1)

Represents the number of source IDs for a packet whose source ID is i,

Represents the depth of the history queue,

Represents a weight for a packet whose source ID is i.

The weight calculator 535 may arbitrate to use the output port preferentially for any one of the plurality of input ports 510 based on the weights.

For example, the weight calculator 535 may compare the weights to arbitrate the output ports for the input ports corresponding to the plurality of packets having the largest weight.

The weight calculator 535 may perform probability arbitration when comparing a plurality of input ports 510 by comparing the weights. For example, the weight calculator 535 may use one of a plurality of input ports 510 by performing probability arbitration using a random number stored in each of the weights and a look-up table Can arbitrate to use the output port first. At this time, the random number may be generated in advance at the time of initialization of the router 500 and stored in the look-up table.

The weight calculator 535 may generate an arbitration signal to arbitrate the output port connected to the router multiplexer 550 to preferentially use the output port and output the arbitration signal to the router multiplexer 550. [ In addition, the weight calculator 535 generates an acknowledgment signal including the source ID of the victorious victor to use the output port first, and outputs an acknowledgment signal to the history queue 531 and / or the counter 533 .

FIG. 5 shows an implementation of the history-based arbiter shown in FIG.

In FIG. 5, it is assumed that a plurality of input ports 510 are composed of two input ports 510-1 and 510-2 for convenience of explanation.

5, the router 500 includes a first input port 510-1, a second input port 510-2, a history queue 531, a counter 533, a weight calculator 535, And a plexer 550.

The counter 533 of FIG. 5 is a counter 533 implemented by simplifying the hardware task of retrieving the source IDs stored in the history queue 510.

Each of the input ports 510-1 and 510-2 outputs a request signal to the weight calculator 535. [

The weight calculator 535 can obtain the counter value corresponding to the source ID included in each request signal from the counter 533 in response to the request signal output from each input port 510. [

The weight calculator 535 may determine weights for the packets stored in the input ports 510-1 and 510-2 based on the respective counter values.

The weight calculator 535 generates an arbitration signal to preferentially use the output port for any one of the input ports 510-1 and 510-2 based on the weight and sends the arbitration signal to the router multiplexer 550 Can be output. In addition, the weight calculator 535 generates an acknowledgment signal including the source ID of the source corresponding to the packet stored in any input port winning the competition for preferentially using the output port, and outputs an acknowledgment signal to the history queue 531 and / And outputs it to the counter 533.

The router multiplexer 550 first outputs packets stored in either the first input port 510-1 or the second input port 510-2 in response to the arbitration signal, Does not delete or delete the source ID corresponding to the winner history stored in response to the approval signal, and stores the source ID included in the approval signal. At this time, the history queue transmits a delete signal to the counter 533 when the source ID is deleted.

The simplified counter 533 increases and / or decreases the counter value of the source ID corresponding to the acknowledgment signal and the erase signal in response to the acknowledgment signal and the erase signal, thereby performing the update.

The weight calculation of the weight calculator 535 will be described in detail with reference to Figs. 6A to 6C.

Figs. 6A to 6C show examples for explaining the weight calculator shown in Figs. 3 and 4. Fig.

The weight calculator 535 of FIG. 6A determines a weight by inversely transforming the count value of the source ID of the source corresponding to the packet included in the first input port 510-1 and the second input port 510-2. Thereafter, the weight calculator 535 transmits the arbitration signal to the router multiplexer 550 based on the weight.

However, the operation on the inverse transformation of the weight calculator 535 of FIG. 6A requires a high hardware cost. Thus, Figures 6b and 6c can minimize the high cost of operations for inverse transformation through swapping.

The weight calculator 535 of FIG. 6B swaps the count value of the source ID of the source corresponding to the packet included in the first input port 510-1 and the second input port 510-2, . At this time, the weight calculator 535 can arbitrate the input ports 510-1 and 510-2 by performing probability arbitration.

FIG. 6C is a diagram illustrating in detail the probability arbitration performed by the weight calculator 535 of FIG. 6A. The weight calculator 535 of FIG. 6C may transmit the arbitration signal that has performed the probability arbitration to the router multiplexer 550 using the random number stored in the look-up table.

6A to 6C illustrate and illustrate a method of weighting an operation for weight determination of the weight calculator 535. However, the present invention is not necessarily limited to this, and the weight calculation operation and the method of weighting the operation may be various.

7 is a flowchart illustrating an operation of a router according to an embodiment of the present invention.

Referring to FIG. 7, the router 500 may receive a plurality of packets transmitted from a plurality of sources included in local and remote processes and store the packets in each of a plurality of input ports in a received order (S710).

The router 500 may determine a weight for a plurality of packets stored in the plurality of input ports based on a usage competition history for the output port (S730).

The router 500 may arbitrate to use the output port for any one of the plurality of input ports based on the weight for the plurality of packets (S750).

The router 500 may output the packet stored in the arbitrated input port to the output port (S770).

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the apparatus and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA) , A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For ease of understanding, the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG. For example, the processing unit may comprise a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (15)

1. A method for inter-connecting in a multiprocessor system, the method comprising:
Determining a weight for a plurality of packets stored in a plurality of input ports based on a source ID of a source corresponding to a plurality of packets stored in a history history queue of use competition for an output port; And
And arbitrating to use the output port for any one of the plurality of input ports based on the weight
The interconnection method comprising:
The method according to claim 1,
Wherein the determining comprises:
Calculating the weight based on the number of source IDs
The interconnection method comprising:
3. The method of claim 2,
Wherein the calculating step comprises:
Determining a weight for the plurality of packets in inverse proportion to the number of source IDs
The interconnection method comprising:
3. The method of claim 2,
Wherein the calculating step comprises:
Counting the number of source IDs from the history queue; And
Determining a weight for the plurality of packets by inversely transforming the counted counter values
The interconnection method comprising:
3. The method of claim 2,
Wherein the determining comprises:
Determining a weight for the plurality of packets by swapping the number of source IDs
The interconnection method comprising:
The method according to claim 1,
Storing a source ID of a source corresponding to a packet stored in the history queue of the use competition history in the history queue if there is a storage space in the history queue; And
Deleting the source ID stored in the head of the history queue if the history queue does not have a storage space and storing the source ID of the source corresponding to the packet stored in the history queue in the history queue
The interconnection method further comprising:
The method according to claim 6,
Updating at least one of a counter value of the source ID corresponding to the packet stored in any one of the packets and a counter value of the deleted source ID
The interconnection method further comprising:
The method according to claim 1,
Wherein the step of arbitrating comprises:
Arbitrating to use the output port first by performing probability arbitration using the weight and the random number stored in the look-up table
The interconnection method comprising:
1. A router for arbitrating inter-connecting in a multiprocessor system,
A plurality of input ports storing a plurality of packets; And
Determining a weight for a plurality of packets stored in the plurality of input ports based on a source ID of a source corresponding to a plurality of packets stored in a history history queue of use competition for an output port, Based arbiter for arbitrarily using the output port for any one of the plurality of input ports based on a history-based arbiter
.
10. The method of claim 9,
The history-based arbiter includes:
And calculates the weight based on the number of the source IDs.
11. The method of claim 10,
The history-based arbiter includes:
And determines a weight for the plurality of packets in inverse proportion to the number of the source IDs.
11. The method of claim 10,
The history-based arbiter includes:
And counting the number of source IDs from the history queue and inversely transforming the counted count values to determine a weight for the plurality of packets.
11. The method of claim 10,
The history-based arbiter includes:
And swapping the number of source IDs to determine a weight for the plurality of packets.
10. The method of claim 9,
The history-based arbiter includes:
If there is a storage space in the history queue of the usage competition history, store the source ID of the source corresponding to the packet stored in any one of the history queues in the history queue, and if there is no storage space in the history queue, And stores the source ID of the source corresponding to the packet stored in the one in the history queue.
10. The method of claim 9,
The history-based arbiter includes:
And a weight calculator for arbitrating the output port to use the output port by performing probability arbitration using the weight and the random number stored in the look-
.

Images