CN117707426A

CN117707426A - Core particle, IO resource sharing method, system on chip and electronic equipment

Info

Publication number: CN117707426A
Application number: CN202311711712.XA
Authority: CN
Inventors: 刘勋; 王立萍
Original assignee: Haiguang Information Technology Co Ltd
Current assignee: Haiguang Information Technology Co Ltd
Priority date: 2023-12-13
Filing date: 2023-12-13
Publication date: 2024-03-15

Abstract

The embodiment of the application provides a core particle, an IO resource sharing method, a system-on-chip and electronic equipment, wherein the core particle comprises: IO resources, wherein the IO resources are connected with the packaging pins; the arbitration logic is at least used for receiving the access requests of the IO resources sent by the plurality of functional modules and arbitrating the use rights of the IO resources for the access requests of the plurality of functional modules; wherein the plurality of functional modules includes: a functional module within the core particle, and a functional module within any pair of end core particles interconnected with the core particle; the transmission path for the functional module in the opposite core to send the access request to the arbitration logic comprises at least: a logical path between the opposite core particle and the core particle; wherein access requests to functional modules within a peer core are transferred from the peer core to the core through a logical path. The embodiment of the application supports the sharing of the IO resources by a plurality of core grains, and can improve the sharing efficiency of the IO resources under the condition of guaranteeing the sharing reliability of the IO resources.

Description

Core particle, IO resource sharing method, system on chip and electronic equipment

Technical Field

The embodiment of the application relates to the technical field of chips, in particular to a core particle, an IO resource sharing method, a system on a chip and electronic equipment.

Background

A Chip (Chip) is a unit Chip capable of realizing a certain function, and a plurality of chips are interconnected to form a Chip System such as an SOC (System On Chip). The core particle is provided with an Input/Output (IO) resource for performing Input and Output operations on the core particle and the peripheral device, for example, the core particle can perform Input and Output on external devices (simply referred to as peripheral devices) such as a storage device, a network interface, an external sensor and the like through the IO resource.

In order to save hardware resources, a plurality of core particles have the requirement of sharing IO resources, so when chip design is performed, how to provide the core particles capable of supporting sharing IO resources so as to improve the sharing efficiency of IO resources under the condition of guaranteeing the sharing reliability of IO resources becomes a technical problem to be solved by those skilled in the art.

Disclosure of Invention

In view of this, the embodiments of the present application provide a core, an IO resource sharing method, a system on chip, and an electronic device, which support sharing of IO resources by multiple cores, and can improve sharing efficiency of IO resources under the condition of guaranteeing sharing reliability of the IO resources.

In order to achieve the above purpose, the embodiments of the present application provide the following technical solutions.

In a first aspect, embodiments of the present application provide a core particle comprising:

IO resources, which are connected with the packaging pins;

the arbitration logic is at least used for receiving access requests of the IO resources sent by a plurality of functional modules and arbitrating the use rights of the IO resources for the access requests of the functional modules;

wherein the plurality of functional modules comprises: a functional module within the core, and a functional module within any pair of end cores interconnected with the core; the transmission path for the functional module in the peer-to-peer core to send an access request to the arbitration logic includes at least: a logic path between the pair of end-pellets and the pellet; wherein access requests of functional modules within the pair of end-pellets are transferred from the pair of end-pellets to the pellets through the logic path.

In a second aspect, an embodiment of the present application provides a method for sharing IO resources, which is applied to the core particle in the first aspect, where the method includes:

receiving an access request of IO resources sent by a plurality of functional modules;

arbitrating the use rights of the IO resources for the access requests of the plurality of functional modules;

and the functional module is used for authorizing the use right of the IO resources so as to acquire the use right of the IO resources and perform data interaction with the peripheral equipment by using the IO resources.

In a third aspect, embodiments of the present application provide a system on a chip comprising a plurality of interconnected core particles, some or all of the plurality of core particles being core particles as described in the first aspect above.

In a fourth aspect, embodiments of the present application provide an electronic device comprising a system on a chip as described in the third aspect above, and/or a core as described in the first aspect above.

Embodiments of the present application provide a core particle, which may include: IO resources, which are connected with the packaging pins; the arbitration logic is at least used for receiving access requests of the IO resources sent by a plurality of functional modules and arbitrating the use rights of the IO resources for the access requests of the functional modules; wherein the plurality of functional modules comprises: a functional module within the core, and a functional module within any pair of end cores interconnected with the core; the transmission path for the functional module in the peer-to-peer core to send an access request to the arbitration logic includes at least: a logic path between the pair of end-pellets and the pellet; wherein access requests of functional modules within the pair of end-pellets are transferred from the pair of end-pellets to the pellets through the logic path.

It can be seen that the core particle provided by the embodiment of the present application can support the functional module in the core particle and any pair of functional modules in the end core particle interconnected with the core particle, and share the IO resource of the core particle; for the functional module of the opposite-end core particle, the embodiment of the application supports the realization of transmitting the access request of the functional module of the opposite-end core particle to the IO resource through the logic path between the opposite-end core particle and the core particle where the IO resource is located, so that the functional module of the opposite-end core particle can share the IO resource by the functional modules of a plurality of core particles. Meanwhile, an arbitration logic is arranged at a request inlet of the IO resources of the core grain, and the arbitration logic can arbitrate the use rights of the IO resources for the access requests of the plurality of functional modules when the plurality of functional modules send the access requests of the IO resources; because the arbitration logic is in a hardware form, the embodiment of the application can allocate the use right of the IO resources for a plurality of functional modules sharing the IO resources in a hardware arbitration mode, so that the use right of the IO resources is prevented from being allocated by software, the problem of lower sharing efficiency of the IO resources caused by the participation of the software can be avoided, and the sharing efficiency of the IO resources is improved on the basis that the sharing reliability of the IO resources is ensured by the arbitration logic in the hardware form. Therefore, the embodiment of the application can support the function modules of the plurality of core particles to share the IO resources, and can improve the sharing efficiency of the IO resources under the condition of guaranteeing the sharing reliability of the IO resources.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings may be obtained according to the provided drawings without inventive effort to a person skilled in the art.

Fig. 1 is a diagram illustrating an example interconnection of multiple die within a package.

Fig. 2A is another illustration of an interconnection of multiple die within a package.

Fig. 2B is a diagram of yet another example of the interconnection of multiple die within a package.

Fig. 3 is an exemplary diagram of sending an access request by a package core according to an embodiment of the present application.

Fig. 4 is another exemplary diagram of sending an access request by a package die according to an embodiment of the present application.

Fig. 5 is a diagram illustrating another example of sending an access request by a package die according to an embodiment of the present application.

FIG. 6 is a diagram of an example of arbitration logic provided in an embodiment of the present application.

Fig. 7A is an exemplary diagram of a request register according to an embodiment of the present application.

Fig. 7B is an exemplary diagram of an authorization register provided in an embodiment of the present application.

Fig. 7C is an exemplary diagram of an address list provided in an embodiment of the present application.

Fig. 8 is a contention timing diagram of IO resources according to an embodiment of the present application.

Fig. 9 is a flowchart of an IO resource sharing method provided in an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

The core particle is a small chip bare chip, after a plurality of core particles with different functions or different processes are interconnected, the chip particle can be integrated and packaged into a chip system (a chip system such as an SOC chip) through advanced packaging forms (such as 3D packaging), namely, a plurality of core particles can be packaged to form the chip system after being interconnected, and part of core particles in the interconnected core particles can have different functions or adopt different processes.

The core grains are divided according to functions, and can be divided into IO core grains, storage core grains, processor core grains (such as CPU core grains) and other core grains of different types.

The IO core particle is a core particle for realizing the IO function of the chip system, and is used for managing the input and output of the chip system. For example, the IO core may interface with a communication manner such as network communication, USB (Universal Serial Bus ) communication, PCIE (Peripheral Component Interconnect Express, high-speed serial computer expansion bus standard) communication, etc. to implement a communication connection such as network communication connection, USB communication connection, PCIE communication connection, etc. of the chip system; various interfaces and control circuits may be provided in the IO core to support different types of communication connections.

The memory core grain is a core grain for realizing the memory function of the chip system, is used for data storage of the chip system, and provides processing functions such as data reading and writing. The memory core can support different types of memory devices, such as random access memory, read-only memory, flash memory, solid state disk, etc.; in one example, a Memory module such as a DIMM (Dual-Inline Memory Modules) may be provided on the Memory die.

A processor core die is a die that performs the processor core functions of a chip system, and is a type of die for executing instructions and operations of a computer program, such as a CPU core die, etc. It should be noted that the chip system may have a plurality of processor cores, and one processor core may be regarded as an independent processing unit, and disposed in one processor core die.

The different functional die may be produced by different processes, for example, the IO function, the memory function, and the processor core function may be provided on different die and produced by different processes because the area and the power consumption are reduced differently according to the process improvement when the corresponding die is produced and manufactured.

Taking the production and manufacturing of the core particles corresponding to the IO function and the processor core function as an example, the reduction degree of the area and the power consumption corresponding to the production and manufacturing of the core particles with the process improvement is lower than that of the area and the power consumption corresponding to the production and manufacturing of the core particles with the processor core function with the process improvement; that is, the area and power consumption of the IO function core particle are reduced to a lower extent with process improvement during manufacturing, while the area and power consumption of the processor core function core particle are reduced to a higher extent with process improvement during manufacturing. Based on the method, the process of maturity, low flow sheet cost and low logic density can be used for producing the IO functional core particle, so that the IO core particle is obtained, and the IO core particle can be also called as an IO sheet (IO Die) because the core particle is a small chip bare chip; the Core of the processor Core function may be manufactured using a more advanced, more costly and more logic intensive process to obtain the processor Core, which may also be referred to as a Core Die (Core Die) because it is a chiplet Die.

After the production of the cores such as the IO core (IO chip), the processor core (core chip), the memory core, etc., a plurality of cores (at least two different types of cores may exist in the plurality of cores) may be integrated in the same Package (Package), so as to obtain a chip system (for example, an SOC chip), so that the production and production costs of the chip system are optimized.

For ease of understanding, fig. 1 illustrates an exemplary diagram of interconnection of multiple core particles within a package, as shown in fig. 1, where core particle 101 and core particle 102 are two core particles interconnected within a package, interconnection may be understood as the presence of a connection between the core particles and the possibility of information interaction, that is, there may be a connected path between core particle 101 and core particle 102, and information interaction between core particle 101 and core particle 102 may occur through the connected path.

Taking the interconnection of multiple processor core kernels with IO core kernels as an example, fig. 2A illustrates another interconnection example diagram of multiple core kernels in a package, and as shown in fig. 2A, in the case where 4 processor core kernels are interconnected with 1 IO core kernel, the processor core kernels 210, 220, 230, and 240 may be connected with the IO core kernels 250, respectively.

It should be noted that, in the package of the chip system (for example, SOC chip), the interconnected core may be any type of core, for example, any two of the cores such as the processor core, the IO core, the memory core, etc. may be interconnected, and the type, the number, the setting position, and the interface protocol used for interconnection of the interconnected cores are not limited in this embodiment of the present application.

The cores such as the processor core, the IO core and the storage core are provided with IO resources which are used for carrying out input and output operations with the peripheral, and the IO resources can be regarded as IO controllers (such as peripheral controllers) and IO interfaces which are used for carrying out input and output operations with the peripheral by the core. The IO resources can support communication between the core particle and the peripheral under different application scenes by supporting different protocols, for example, the IO resources can be IO controllers, IO interfaces and the like supporting protocols such as I2C (Inter-Integrated Circuit, serial dual-line bus), I3C (Improved Inter-Integrated Circuit, modified serial dual-line bus), UART (Universal Asynchronous Receiver Transmitter, universal asynchronous receiver/transmitter), and the like.

In the package of a chip system (for example, an SOC chip), the package pins can lead out internal signals, data and control information of the core particle to the outside of the core particle, and for the purpose of saving the number of the package pins, the number of the package pins in the package has a certain limit, so that when the chip is designed, part of IO resources in the core particle or part of IO resources of the core particle can be selectively led out without passing through the package, so that the number of the package pins is saved. That is, some of the IO resources in the die or some of the IO resources of the die are not connected to the package pins, in which case, for dies where IO resources are not routed through the package (i.e., for dies where IO resources are not connected to the package pins), IO resources of other dies that are routed through the package may be shared to enable communication with the peripheral.

For ease of understanding, fig. 2B illustrates yet another example diagram of interconnection of multiple die within a package, and in conjunction with fig. 2A and 2B, processor core die 210 is provided with IO resources 211, processor core die 220 is provided with IO resources 221, processor core die 230 is provided with IO resources 231, processor core die 240 is provided with IO resources 241, and IO core die 250 is provided with IO resources 251 and 252. The IO resources 231, 241 and 251 and 252 are led out through encapsulation and connected to the encapsulation pins, so that communication with the peripheral can be realized; and IO resources 211 of processor core die 210 and IO resources 221 of processor core die 220 are not pulled out through the package and are not connected to package pins. Based on this, to enable communication of the processor core die 210 and the processor core die 220 with the peripheral devices, the processor core die 210 and the processor core die 220 need to share the IO resources 231 of the processor core die 230, or the IO resources 241 of the processor core die 240, or the IO resources 251 and 252 of the IO core die 250, to enable communication with the peripheral devices by borrowing the IO resources of any one of the processor core die 230, the processor core die 240, and the IO core die 250.

It should be noted that fig. 2B is only an example to illustrate that there is a need for sharing IO resources between the cores, and the types, the numbers, the setting positions of the cores, and the numbers, the setting positions of the IO resources in the cores are not limited in the embodiments of the present application.

It can be seen that, in order to save the number of package pins, the number of package pins inside the package is limited, when a plurality of core grains are integrated inside the same package, there is a requirement for sharing IO resources among the core grains, and some IO resources required to be used by the core grains may be located on other core grains; this results in multiple access requests competing for the same IO resource at the same time, where the access requests may come from multiple functional modules of the same core particle or different core particles, so that access conflict of the IO resource may be caused, even the problem of access processing error of the IO resource may cause difficulty in guaranteeing the sharing reliability of the IO resource. That is, the reliability of sharing the IO resources between the cores is referred to as the sharing reliability of the IO resources, and due to the problems of access conflict of the IO resources, access processing errors of the IO resources, and the like, the sharing reliability of the IO resources may be lower, so that a sharing mechanism of the IO resources needs to be provided to ensure the sharing reliability of the IO resources.

The method for realizing IO resource sharing and guaranteeing the sharing reliability of IO resources comprises the following steps:

running Firmware (Firmware) on the chip by the microprocessor, and inquiring the states of all IO resources in the package by the Firmware through a polling mechanism, so that the IO resources are uniformly distributed and authority managed based on the states of all IO resources; meanwhile, the firmware is responsible for switching the environment configuration of different functional modules using IO resources. When the firmware performs centralized allocation and authority management on the IO resources, only one functional module needs to be ensured to have the authority to use in the same time, namely the same IO resource is used in series among the functional modules.

The above manner is a manner of guaranteeing serial use of the same IO resource by using software (firmware may be in a software form), when there are multiple functional modules accessing the same IO resource, since the IO resource is accessed more frequently and the software execution speed is slower, the on-chip microprocessor needs to use more overhead and time for switching the usage rights of the IO resource and switching the environment configuration of different functional modules using the IO resource, resulting in lower sharing efficiency of the IO resource; meanwhile, as the software execution speed is slower, the more IO resources in the package are, the longer the time interval for the firmware to poll the states of all the IO resources in the package is, which leads to further reduction of the sharing efficiency of the IO resources, and even the situation that the access request of the functional module to the IO resources cannot be responded for a long time may occur.

Another way of implementing the sharing of the IO resources and guaranteeing the sharing reliability of the IO resources is as follows:

the multiple functional modules sharing the IO resources apply for the use permission of the shared IO resources to the on-chip microprocessor through an interrupt mechanism, and firmware operated by the on-chip microprocessor uniformly distributes and manages the shared IO resources in a centralized manner and is responsible for switching environment configuration of the use of the IO resources by different functional modules. When the firmware performs centralized allocation and authority management on shared IO resources, only one functional module needs to be ensured to have the authority to use in the same time, namely the same IO resource is used in series among the functional modules.

Although the above manner does not need firmware to query the status of the IO resources through a polling mechanism, but the function module applies for the usage rights of the IO resources through an interrupt mechanism, the sharing manner of the IO resources is still a manner of guaranteeing serial usage of the same IO resources by adopting software, and when multiple function modules accessing the same IO resources exist, as the access of the IO resources is more frequent, the execution speed of the software is slower, and the interrupt processing procedure is more complicated, so that the on-chip microprocessor still needs to use more overhead and time for switching the usage rights of the IO resources and switching the environment configuration of using the IO resources by different function modules, which results in lower sharing efficiency of the IO resources.

The manner of realizing IO resource sharing and guaranteeing the sharing reliability of IO resources can be seen, and the method belongs to a mechanism for distributing IO resource use permission in a software centralized manner, and has lower sharing efficiency of IO resources due to slower software execution speed, higher software cost and longer response time; in addition, as the number of cores in the package increases, the number of IO resources increases, and the number of functional modules accessing the IO resources increases, the sharing efficiency of the IO resources is further reduced and deteriorated.

Based on the above, the embodiment of the application provides an improved IO resource sharing scheme, and under the condition of guaranteeing the sharing reliability of IO resources, the sharing efficiency of IO resources is improved.

The embodiments of the present application support the allocation of the IO resources of the core to the functional modules inside the core and the sharing to the functional modules of other cores interconnected with the core, that is, for the IO resources shared by the cores, the access request of the IO resources may come from inside the core (for example, from the functional modules inside the core) or from outside the core (for example, from the functional modules of other cores interconnected with the core), where the access request from outside the core may be transmitted between the cores through a logical path between the cores. Meanwhile, for the core grain for sharing the IO resources, the embodiment of the application can set hardware arbitration logic in the core grain, and perform arbitration allocation of the use right for the access request for the IO resources from the plurality of functional modules through the hardware arbitration logic so as to support the access of the plurality of functional modules to the shared IO resources, and further improve the sharing efficiency of the IO resources in a mode of hardware arbitration of the hardware arbitration logic on the basis of guaranteeing the sharing reliability of the IO resources. The functional module for accessing the IO resource in the embodiment of the present application may be located in a core where the IO resource is located, or may be located in another core interconnected with the core where the IO resource is located.

Based on the above-mentioned thought, in the embodiments of the present application, arbitration logic may be set in a core grain of a shared IO resource, and the arbitration logic is connected to a request entry of the IO resource, so that the arbitration logic may be at least used to receive access requests transmitted to the IO resource by a plurality of functional modules, and arbitrate usage rights of the IO resource for the plurality of functional modules; the plurality of functional modules that send the access request to the IO resource may include: the functional module in the core grain where the IO resource is located, and the functional module in any other core grain which is interconnected with the core grain where the IO resource is located.

It should be noted that, the request entry of the IO resource refers to a port where an access request enters the IO resource. The arbitration logic may be regarded as an arbitration circuit in the form of a circuit, which may also be referred to as an arbiter.

For a core setting up shared IO resources, the embodiments of the present application support passing access requests to arbitration logic (e.g., an arbiter) through a control bus within the core to reach a request entry of the IO resources, for access requests within the core (e.g., access requests from functional modules within the core); for access requests external to the die (e.g., from functional modules of other die interconnected with the die), embodiments of the present application support passing access requests to arbitration logic (e.g., an arbiter) to reach the request entry of the IO resource through the control buses within the die where the functional modules reside, the logic paths between the die, and the control buses within the die where the IO resource resides. That is, embodiments of the present application provide a mechanism and path for transmission of access requests inside the core, as well as access requests outside the core to IO resources of the core.

As an optional implementation, fig. 3 exemplarily illustrates an exemplary diagram of sending an access request by a package core granule provided in an embodiment of the present application, as shown in fig. 3, an IO resource 311 of a core granule 310 is led out through a package, and may be used as an IO resource shared between core granules; that is, the IO resources of the die 310 are connected to the package pins, which can be controlled externally and can be shared as IO resources between the die. The request entry of the IO resource 311 of the core 310 is connected with the arbitration logic 312, and the arbitration logic 312 may arbitrate the usage rights of the IO resource 311 for a plurality of functional modules that send access requests to the IO resource 311.

As an alternative implementation, a plurality of IO resources in the core grain can be provided, and for the IO resources which can be shared, the embodiment of the application can connect arbitration logic at a request entry of each IO resource, namely one IO resource can be connected with one arbitration logic, so that the arbitration of the right of use is carried out for the access request sent to each IO resource by the functional module through the arbitration logic correspondingly connected with each IO resource.

As an alternative implementation, the functional module that sends an access request to the IO resource 311 may be located within the core 310, e.g., any functional module within the core 310 may pass the access request to the IO resource 311 to the arbitration logic 312 through a control bus within the core 310. By way of example, functional module 313 as any functional module within the core 310, dashed path 031 with an arrow in FIG. 3 shows the transmission path of an access request issued by functional module 313 to arbitration logic 312, that is, an access request of functional module 313 may reach arbitration logic 312 via a control bus within core 310 to reach the request entry of IO resource 311.

Accordingly, for a core particle sharing an IO resource, a transmission path of an access request of a functional module in the core particle for the IO resource may include: a path from the control bus within the core to the arbitration logic; the function module in the core grain transmits the access request of the IO resource to the arbitration logic through the control bus in the core grain so as to achieve the request entry of the IO resource.

As an alternative implementation, the functional module that sends the access request to the IO resource 311 may be located in another core different from the core 310 in which the IO resource 311 is located, and when the access request comes from another core that is interconnected with the core 310 in which the IO resource 311 is located, the core from which the access request comes may be referred to as a peer core. That is, for a core in which a shared IO resource exists, any other core interconnected with the core that issues an access request for the shared IO resource may be referred to as a peer core.

As shown in connection with fig. 3, the functional module that sends an access request to the IO resource 311 may be located at the opposite core particle 320 that is interconnected with the core particle 310, e.g., any functional module within the opposite core particle 320 may send an access request to the IO resource 311 of the core particle 310. The functional module within the opposite-end core 320 may pass the access request to the control bus within the opposite-end core 320, thereby reaching the control bus within the core 310 through the logical path between the core 310 and the opposite-end core 320, and further reaching the arbitration logic 312, i.e., the request entry to the IO resource 311, through the control bus within the core 310. By way of example, the functional module 321 acts as any functional module within the peer-to-peer core 320, and the dashed path 032 with arrows in FIG. 3 illustrates the transmission path of an access request sent by the functional module 321 to the arbitration logic 312 of the core 310, that is, the access request of the functional module 321 may reach the arbitration logic 312 within the core 310, i.e., the request entry to the IO resource 311 within the core 310, through the control bus within the peer-to-peer core 320, the logical path between the core 310 and the peer-to-peer core 320, and the control bus within the core 310.

Correspondingly, for the core particle sharing the IO resource, the transmission path of the access request of the functional module in the opposite-end core particle for the IO resource at least comprises: a logic path between the opposite core grain and the core grain where the IO resource is located; wherein, the access request of the functional module in the opposite core grain to the IO resource is transmitted from the opposite core grain to the core grain through the logic path. For example, the transmission path for the access request to the IO resource by the functional module within the end-core may include: the method comprises the steps of enabling a functional module of a peer-to-peer core to pass through a control bus in the peer-to-peer core, enabling a path of the control bus in the peer-to-peer core to pass through an inlet of a logic path of the peer-to-peer core, enabling a logic path between the peer-to-peer core and an IO resource to pass through the logic path of the core where the IO resource is located to pass through the control bus in the core, and enabling the control bus in the core to pass through an arbitration logic in the core.

As can be seen, embodiments of the present application provide a core particle, which may include: IO resources, which are connected with the packaging pins; the arbitration logic is at least used for receiving access requests of the IO resources sent by a plurality of functional modules and arbitrating the use rights of the IO resources for the access requests of the functional modules; wherein the plurality of functional modules comprises: a functional module within the core, and a functional module within any pair of end cores interconnected with the core; the transmission path for the functional module in the peer-to-peer core to send an access request to the arbitration logic includes at least: a logic path between the pair of end-pellets and the pellet; wherein access requests of functional modules within the pair of end-pellets are transferred from the pair of end-pellets to the pellets through the logic path.

The core particle provided by the embodiment of the application can support the functional module in the core particle and any pair of functional modules in the end core particle which are interconnected with the core particle, and IO resources of the core particle are shared; for the functional module of the opposite-end core particle, the embodiment of the application supports the realization of transmitting the access request of the functional module of the opposite-end core particle to the IO resource through the logic path between the opposite-end core particle and the core particle where the IO resource is located, so that the functional module of the opposite-end core particle can share the IO resource by the functional modules of a plurality of core particles. Meanwhile, an arbitration logic is arranged at a request inlet of the IO resources of the core grain, and the arbitration logic can arbitrate the use rights of the IO resources for the access requests of the plurality of functional modules when the plurality of functional modules send the access requests of the IO resources; because the arbitration logic is in a hardware form, the embodiment of the application can allocate the use right of the IO resources for a plurality of functional modules sharing the IO resources in a hardware arbitration mode, so that the use right of the IO resources is prevented from being allocated by software, the problem of lower sharing efficiency of the IO resources caused by the participation of the software can be avoided, and the sharing efficiency of the IO resources is improved on the basis that the sharing reliability of the IO resources is ensured by the arbitration logic in the hardware form. Therefore, the embodiment of the application can support the function modules of the plurality of core particles to share the IO resources, and can improve the sharing efficiency of the IO resources under the condition of guaranteeing the sharing reliability of the IO resources.

It should be noted that fig. 3 only shows a main design related to sending an access request by the encapsulated core, other designs not shown in fig. 3 may exist in the core 310, other designs not shown in fig. 3 may exist in the end core 320, and the specific design case inside the core is not limited in the embodiment of the present application. For example, the IO resources may be set inside the opposite-end core particle 320, which in the embodiment of the present application does not set a limit on whether the IO resources of the opposite-end core particle 320 are led out through encapsulation, i.e. does not limit whether the IO resources of the opposite-end core particle 320 are connected to encapsulation pins; that is, in the case where the IO resources of the counter core 320 are not connected to the package pins, the counter core 320 may share the IO resources of the core 310 for peripheral control; in the case that the IO resource of the opposite core particle 320 is itself connected to the package pin, the IO resource of the opposite core particle 320 may be used as an IO resource shared by other core particles, and meanwhile, the embodiment of the present application may also support use of the IO resource of the core particle 310 by the opposite core particle 320 to perform peripheral control.

It should be noted that the control bus in the core may be regarded as a communication channel for transmitting control signals and commands between different functional modules in the core; the logic paths between the die may be used to transmit control signals between the die. For interconnected die, therefore, transmission of control signals between the interconnected die may be accomplished through the respective control buses within the die, as well as the logic paths between the die; thus, for the core particle setting up the shared IO resource, the access request transmitted to the IO resource by the functional module of the opposite end core particle can be transmitted from the opposite end core particle to the core particle where the IO resource is located through the logic path between the opposite end core particle and the core particle where the IO resource is located.

As an alternative implementation, within the package of a chip system (e.g., a SOC chip), the logic paths between the interconnected die may be connected using die connectors (chip links) provided to the die, that is, the die connectors act as a kind of connector that may be used to connect the logic paths between the interconnected die. Further, the interconnected core particles can be used for transmitting control signals through a CFOP (Control Fabric On Package, in-package control network). As an alternative implementation, the core may have multiple core connectors, the core connectors between cores may be connected one-to-one, e.g., one core connector of one core, one core connector of another core, to enable a logical path between connected cores. In an alternative implementation, the IO resources may be mounted under the CFOP and uniformly addressed, so that the functional module of any core may access any IO resource on any core through the address of the IO resource by using the CFOP, for example, the access request sent by the functional module may indicate the address of the IO resource that needs to be used, so as to transfer to the arbitration logic correspondingly connected to the request entry of the IO resource under the address.

In one example, taking the interconnection of 4 processor core dies with 1 IO core die as shown in fig. 2B, the die connectors of processor core die 210, processor core die 220, processor core die 230, and processor core die 240 may be connected with the die connectors of IO core die 250, respectively, thereby implementing a logic path between connecting processor core die 210 and IO core die 250, a logic path between connecting processor core die 220 and IO core die 250, a logic path between connecting processor core die 230 and IO core die 250, and a logic path between connecting processor core die 240 and IO core die 250; the control signal may be transmitted through the CFOP on the logic paths where the processor core 210, the processor core 220, the processor core 230, and the processor core 240 are connected to the IO core 250, respectively.

Based on the arrangement of the core particle connector and the CFOP, as an alternative implementation, aiming at the access request transmitted to the IO resource by the functional module of the opposite-end core particle, the access request can reach the core particle connector of the opposite-end core particle through the control bus in the opposite-end core particle, so that the access request can be transmitted to the core particle where the IO resource is located through the CFOP arranged on the logic path based on the logic path connected with the core particle connector of the opposite-end core particle and the core particle connector of the core particle where the IO resource is located; furthermore, the access request can reach the arbitration logic of the core grain where the IO resource is located through the control bus in the core grain where the IO resource is located, so as to reach the request entry of the IO resource.

For ease of understanding, as an alternative implementation, fig. 4 exemplarily illustrates another exemplary diagram of sending an access request by a packaged core particle provided in an embodiment of the present application, and in conjunction with fig. 3 and fig. 4, an IO resource 311 of a core particle 310 is used as an IO resource shared between core particles, and the core particle 310 and an opposite core particle 320 are respectively provided with a core particle connector, where the core particle connector of the core particle 310 and the core particle connector of the opposite core particle 320 may connect a logic path between the core particle 310 and the opposite core particle 320, so that a path capable of performing information interaction exists between the core particle 310 and the opposite core particle 320. That is, for interconnected cores, the respective core connectors of the cores may connect the logic paths between the interconnected cores.

In one example, the die connectors may be in the form of interfaces as connectors between the die, for example, the die connectors may employ interface protocols such as uci (Universal Chiplet Interconnect Express, universal chip interconnect standard) and the like, serDes (Serializer and Deserializer) techniques, and the like.

On the basis of the use of a die connector to connect the logical paths between interconnected die, control signals between the die may be transmitted through a CFOP, which may be regarded as a bus network inside the package of the chip system for connecting and managing the communication and co-operation between the die, e.g. for transmitting control signals on the logical paths between the die. For example, as shown in connection with fig. 4, a CFOP may be disposed on a logical path between the core particle 310 and the counter core particle 320, such that control signals between the core particle 310 and the counter core particle 320 may be transmitted through the CFOP on the logical path.

As an example, as shown in connection with fig. 3 and 4, the dashed path 031 with arrows shows the transmission path of an access request issued by the functional module 313 to the arbitration logic 312.

As an example, the transmission path shown by the dashed path 0321 with an arrow in fig. 4 may be a refined example of the transmission path shown by the dashed path 032 with an arrow in fig. 3, and as shown in fig. 4, the dashed path 0321 shows the transmission path of the access request sent to the functional module 321 of the end-core 320 to the arbitration logic 312 of the core 310. Wherein, the access request to the functional module 321 of the end core 320 may reach the core particle connector of the end core 320 through the control bus in the end core 320, so that based on the logic path connected by the core particle connector of the end core 320 and the core particle connector of the core particle 310, the access request may be transmitted to the core particle connector of the core particle 310 through the CFOP arranged on the logic path; the access request may then reach the arbitration logic 312 of the core 310, i.e. the request entry to the IO resource 311 within the core 310, via the control bus within the core 310.

Accordingly, for a core particle sharing an IO resource, a transmission path of an access request for the IO resource by a functional module in the core particle at the opposite end may include: a path from a functional module in the opposite end core grain to a control bus in the opposite end core grain, a path from the control bus in the opposite end core grain to a core grain connector of the opposite end core grain, a logic path connected with the core grain connector of the core grain where the IO resource is located, a path from the core grain connector of the core grain where the IO resource is located to the control bus in the core grain, and a path from the control bus in the core grain to arbitration logic in the core grain;

The method comprises the steps that a functional module in a peer-to-peer core particle transmits an access request of IO resources to a core particle connector of the peer-to-peer core particle through a control bus in the peer-to-peer core particle, and transmits the access request transmitted to the core particle connector of the core particle in which the IO resources are located to arbitration logic of the core particle in which the IO resources are located through an encapsulated control network arranged on a logic path based on the core particle connector of the peer-to-peer core particle and the logic path connected with the core particle connector of the core particle in which the IO resources are located.

In one example, taking the interconnection of two processor core kernels as an example, fig. 5 illustrates a further example diagram of sending an access request by a package core kernel provided in an embodiment of the present application, as shown in fig. 5, the processor core kernel 510 and the processor core kernel 520 are connected to each other, and a core kernel connector of the processor core kernel 510 and a core kernel connector of the processor core kernel 520 are connected to a logic path between the processor core kernel 510 and the processor core kernel 520, and a control signal is transmitted through a CFOP on the logic path. In alternative implementations, both processor core die 510 and processor core die 520 may have multiple die connectors.

The devices in processor core die 510 and processor core die 520 may each be connected by an on-chip control bus, which may be one example of an on-chip control bus. As shown in fig. 5, each of the processor core die 510 and the processor core die 520 may be provided with cores (the number may be plural), a core connector (the number may be plural), memory controllers (the number may be plural, for example, memory controllers 1 to N in the processor core die 510 and memory controllers 1 to N in the processor core die 520), IO controllers (the number may be plural), and arbiters provided at request inlets of the IO controllers, and the number of arbiters in the die may correspond to the number of IO controllers.

With the example in which the IO controllers in the processor core die 510 may be shared (the IO controllers are one example of the IO resources), for example, the IO controllers in the processor core die 510 are connected to the package pins, the IO controllers in the processor core die 510 support access by the memory controllers in the processor core die 510 and support access by the memory controllers in the processor core die 520, and the processor core die 520 may be regarded as an opposite processor core die interconnected with the processor core die 510. It should be noted that, the memory controller may be regarded as a functional module in the processor core, and has a requirement of accessing the IO controller to perform peripheral control; embodiments of the present application also support the issue of access requests to the IO controller by other types of functional modules in the processor core die, where only the memory controller issues access requests to the IO controller are illustrated.

Referring to fig. 5, if the memory controller of the processor core 510 sends an access request to the IO controller in the processor core 510, the transmission path of the access request belongs to the internal path of the processor core 510; as shown by the dashed arrow 501 in fig. 5, the memory controller 1 of the processor core 510 issues an access request to the IO controller of the processor core 510 through the on-chip control bus of the processor core 510, and the access request arbitrates the right of use through the arbiter of the processor core 510.

The memory controller of the processor core granule 520 sends an access request to the IO controller in the processor core granule 510, and the transmission path of the access request includes an external path and an internal path of the processor core granule 510; as shown by the arrowed dashed line 502 in fig. 5, the memory controller N of the processor core die 520 issues an access request to the IO controller of the processor core die 510 via the intra-chip control bus of the processor core die 520, the die controller of the processor core die 520, the die connector of the processor core die 510, and the intra-chip control bus of the processor core die 510, and the access request arbitrates the right of use via the arbiter of the processor core die 510.

It should be noted that, in fig. 5, only the IO controller of the processor core die 510 is taken as an example, the processor core die 520 may also be provided with an IO controller, and if the IO controller of the processor core die 520 is connected to the package pins, the IO controller may also be provided as a shared IO controller, and an arbiter may be provided accordingly. The embodiment of the application does not limit the type, the number and the position of the interconnected core grains, the type, the number and the position of IO resources in the core grains, the logic paths among the core grains and the transmission path of the access request, and any functional module (such as a kernel, a memory controller or other functional modules) in any core grain can share any IO resource of any connection encapsulation pin in other core grains through any path in the control network in the encapsulation; in addition, in an alternative implementation, one IO resource may be correspondingly connected to one arbiter for arbitration of the usage rights.

As an alternative implementation, the arbitration logic may be provided with a request register for identifying a functional module that sends an access request, fig. 6 exemplarily illustrates an exemplary diagram of the arbitration logic provided in an embodiment of the present application, and in conjunction with fig. 3, fig. 4, and fig. 6, taking the IO resource 311 of the core 310 as an example of an IO resource shared between cores, the arbitration logic 312 is connected to a request entry of the IO resource 311, and the arbitration logic 312 may set the request register.

The request register may have request bits, one request bit corresponding to each functional module, that is, the request register stores the request bits corresponding to different functional modules; if the value of one request bit is set to a first value (a first value is 1, for example), the function module corresponding to the request bit representing the first value requests the usage rights of the IO resources, and then the arbitration logic may arbitrate the usage rights of the IO resources for the function module.

In an alternative implementation, the function module may send the access request of the IO resource to the arbitration logic by setting the value of the request bit corresponding to the function module in the request register to the first value, where the function module may be a core located at the location of the IO resource, or may be an opposite core located in interconnection with the core located at the location of the IO resource. That is, the function module sends an access request of the IO resource, for setting the value of the corresponding request bit in the request register to the first value.

In an alternative implementation, the functional module may set, in a request register of the arbitration logic, a request bit corresponding to the functional module to a first value through a transmission path for transmitting an access request to the IO resource, so as to implement transmission of the access request to the IO resource to the arbitration logic. The transmission path for transmitting the access request by the functional module located in the core where the IO resource is located, and the transmission path for transmitting the access request by the functional module located in the opposite core may refer to the description of the corresponding parts above, and will not be repeated here.

In a further alternative implementation, after obtaining the usage rights of the IO resources and using the IO resources is finished, the functional module may set the value of the corresponding request bit in the request register to a zero-th value (for example, 0) to implement the request to release the IO resources. Correspondingly, the arbitration logic may be further configured to receive a release request for releasing the IO resource sent by the functional module after the functional module obtains the usage permission of the IO resource and the usage of the IO resource is finished, where the release request is used to set a value of a corresponding request bit in the request register to be a zero value, so as to implement the release request of the IO resource. It should be noted that, the functional module may transmit the release request through a transmission path for transmitting the access request, so as to set the value of the corresponding request bit in the request register to a zero value; that is, the transmission path of the function module transmitting the release request corresponds to the transmission path of the function module transmitting the access request to the arbitration logic.

It can be seen that the request registers are disposed in the arbitration logic, and the values of the request registers are controlled and set by the corresponding functional modules, so that the arbitration logic can confirm the requests of the functional modules by the values of the request registers nearby; that is, when the function module requests to use the IO resource, the function module requesting to use the IO resource may be confirmed by setting a request register corresponding to the function module in the arbitration logic to a first value, so that the arbitration logic may pass through the request register having the first value; when the function module releases the IO resource, the function module releasing the IO resource can be confirmed by clearing the value of the request register corresponding to the function module in the arbitration logic (for example, clearing to be zero value), so that the arbitration logic can pass through the request register with the value of zero value. By the above arrangement, the request register can be brought close to the arbitration logic that needs to use the value of the requester register, thereby optimizing the physical implementation.

In one implementation example, in combination with the example shown in fig. 5, assuming that N memory controllers, e.g., memory controller 1 to memory controller N, are respectively disposed in the processor core die 510 and the processor core die 520, the request register may set N request bits for the N memory controllers of the processor core die 510 and N request bits for the N memory controllers of the processor core die 520; that is, in the embodiment of the present application, a request bit may be set for each functional module that may access the shared IO resource, where a request bit corresponds to one functional module, so as to indicate, by a value of the request bit, whether the corresponding functional module is currently in a state of requesting to use the IO resource or in a state of requesting to release the IO resource; for example, the value of the request bit of the function module is a first value, which indicates that the function module currently requests to use the IO resource, and the value of the request bit of the function module is a zero value, which indicates that the function module currently requests to release the IO resource or does not currently request to use the IO resource.

In a further alternative implementation, the arbitration logic may set a plurality of request registers, and one request register is set for each functional module, so that the request bit for the functional module is set in the request register for the functional module. For example, as shown in connection with fig. 3, 4, and 6, the IO resource 311 of the core 310 is used as an IO resource shared between cores, and then the arbitration logic 312 may set corresponding request registers for each functional module of the core 310, so that the request bits corresponding to the functional modules of the core 310 are set in the corresponding request registers; the arbitration logic 312 may set corresponding request registers for the respective functional modules of the pair-core 320, respectively, such that the request bits corresponding to the functional modules of the pair-core 320 are set in the corresponding request registers.

As an example, taking the example of setting request bits for 2 memory controllers of processor core die 510 and request bits for 2 memory controllers of processor core die 520 as shown in fig. 5, fig. 7A schematically illustrates an example diagram of request registers provided by embodiments of the present application, and with reference to fig. 5 and 7A, the IO controllers in processor core die 510 are shared, the arbitration logic may set request register 701 for memory controller 1 of processor core die 510, request register 702 for memory controller 2 of processor core die 510, request register 703 for memory controller 1 of processor core die 520, and request register 704 for memory controller 2 of processor core die 520.

Wherein the request register has a bit number of a request bit to identify different functional modules, e.g., the request bits corresponding to different functional modules are different. The request register may also set a field name of the request bit, which may be used as an optional reserved field, and the reserved address of the request bit may be used for performing the correspondence. The request register may also set a value field of a request bit, and a request type field of the request bit (e.g., the request type field may indicate a request type of an access request, which may be classified as read data or write data). Alternatively, the default value of the value field of the request bit may be 0x0 (corresponding to a zero-th value, e.g., 0x0 represents a value of 0), the value of the value field of the request bit may be set to a first value when the function module sends an access request, and the value of the value field of the request bit may be set to a zero-th value when the function module sends a release request.

As shown in fig. 7A, from the description of the request bits corresponding to the request registers 701, 702, 703 and 704, when the value of the request bit in a certain request register is written with 1, it indicates that the functional module corresponding to the request bit issues an access request of the IO resource to the arbitration logic, and when the value of the request bit is written with 0, it indicates that the functional module corresponding to the request bit issues a release request of the IO resource to the arbitration logic. A more specific example description of request bits may be found in reference to fig. 7A, and embodiments of the present application are not expanded.

The arbitration logic may perform usage rights arbitration of the IO resources for the functional module that sends the access request, for example, the arbitration logic may perform usage rights arbitration of the IO resources for the functional module with the value of the request bit set to the first value. As an alternative implementation, the arbitration algorithm according to which the arbitration logic performs arbitration may include, but is not limited to, at least one of: the order of arrival of the access requests, the priority of the access requests, the permission level of the function module that sent the access requests, and the like. That is, the arbitration logic may determine the functional module that obtains the usage rights for the IO resources based on the arbitration algorithm of at least one of the above.

As an optional implementation, when the arbitration of the usage right is performed based on the arrival sequence of the access requests, the function module for obtaining the usage right of the IO resource can be determined according to the principle that the access requests are authorized first and then first; that is, according to the order in which the access requests arrive, the function module that obtains the usage rights of the IO resources is determined.

As an alternative implementation, when the arbitration of the usage right is performed based on the priority of the access request, different priorities may be set for different access requests, so that the functional module that obtains the usage right of the IO resource is determined according to the order of the priority of the access request from high to low. Optionally, different priorities are set for the access requests, which may be set based on the type of access request, e.g. different types of access requests have different priorities; the priority of the access request can be fixed, and can be dynamically adjusted according to the actual application condition.

As an alternative implementation, when the arbitration of the usage right is performed based on the permission level of the function module that sends the access request, different permission levels may be set for different function modules, for example, according to the type of the function module, different permission levels are set for different types of function modules, so that the function module that obtains the usage right of the IO resource is determined according to the order of the permission levels of the function modules from high to low.

In a further optional implementation, if at least two arbitration algorithms of the access request arrival sequence, the access request priority, the authority permission degree of the functional module and the like are used, the embodiment of the application may set corresponding weights for each arbitration algorithm (the weights set by different arbitration algorithms may be different); when the arbitration logic performs arbitration of the use right, if at least two arbitration algorithms are used, the arbitration results of the access request in all the arbitration algorithms can be determined, and then the final arbitration results of the access request are determined by combining the arbitration results of the access request in all the arbitration algorithms and the weights corresponding to all the arbitration algorithms; and determining a functional module for obtaining the use right of the IO resource according to the final arbitration result of the access request. For example, the arbitration result may be in the form of a score, such that the arbitration logic may determine the functional module that obtains usage rights for the IO resources in order of the score of the final arbitration result for the access request from high to low.

It should be noted that, the arbitration algorithm used by the arbitration logic may be determined according to specific application requirements, for example, requirements based on a system architecture and performance targets of a chip, and one or more corresponding arbitration algorithms are selected, and the form of the arbitration algorithm selected by the arbitration logic in the embodiment of the present application is not limited.

After the arbitration logic arbitrates, the arbitration logic can grant the use right for the functional module which obtains the use right of the IO resource. The grant may be a transmission path through which the arbitration logic sends the access request through the functional module to send the opposite direction of transmission of the access request, writing grant information to the functional module.

For convenience of explanation, in conjunction with fig. 4, assuming that the function module that obtains the usage right of the IO resource 311 is the function module 313, based on the transmission path shown by the dotted path 031, the arbitration logic 312 may write the authorization information into the function module by sending the opposite transmission direction of the access request to the function module 313 through the transmission path shown by the dotted path 031. For example, arbitration logic 312 may write grant information to functional module 313 via a control bus within die 310.

As shown in fig. 4, assuming that the function module that obtains the usage right of the IO resource 311 is the function module 321 of the peer-to-peer core 320, based on the transmission path shown by the dashed path 0321, the arbitration logic 312 may send the transmission direction opposite to the access request through the transmission path shown by the dashed path 0321 by the function module 321, and write the authorization information into the function module 321. For example, the arbitration logic 312 may transmit grant information to the core particle connector of the core particle 310 via a control bus within the core particle 310, and based on the logical path that the core particle connector of the core particle 310 is connected to the core particle connector of the opposite core particle 320, the grant information may be transmitted to the opposite core particle 320 via a CFOP disposed on the logical path, and the grant information may reach the functional module 321 of the opposite core particle 320 via the control bus within the opposite core particle 320 to be written to the functional module 321.

After the function module obtains the authorization information of the arbitration logic, the function module can transmit peripheral data by using IO resources through a transmission path for sending the access request. For example, the functional module may send peripheral data using the IO resources through a transmission path for sending an access request to send the same transmission direction of the access request. For another example, the functional module may receive the peripheral data using the IO resource by sending a transmission path of the access request to send a transmission direction opposite to the access request. The description of the transmission direction same as that of the transmission request and the transmission direction opposite to that of the transmission request will be referred to the description of the relevant portions, and will not be repeated here.

In a further alternative implementation, the arbitration logic may set an address list for recording the grant addresses of the functional modules; meanwhile, the function module (the function module may be located in a core grain where the shared IO resource is located, or may be located in an opposite core grain) may be provided with an authorization register, and an address of the authorization register of the function module may be regarded as an authorization address of the function module, so that after the arbitration confirms that the function module obtains the usage right of using the IO resource, the arbitration logic may write authorization information into the authorization register of the function module through the address of the authorization register of the function module, so as to write the authorization information into the function module. Based on this, as shown in connection with FIG. 6, the arbitration logic 312 may set up an address list. Meanwhile, the function module in the core may set an authorization register, for example, the function module 313 of the core 310 and the function module 321 of the opposite core 320 shown in fig. 3 may each set an authorization register. The address list set by the arbitration logic can record the addresses of the authorization registers of the functional modules, and the addresses of the authorization registers of the functional modules can be regarded as the authorization addresses for writing authorization information into the functional modules, namely, the authorization registers are used for writing the authorization information; the arbitration logic may implement writing the grant information to the functional module by writing the grant information to a grant register of the functional module.

As an optional implementation, after confirming the function module obtaining the usage right of the IO resource, the arbitration logic may query the address of the authorization register of the function module in the address list based on the identity information of the function module; furthermore, the arbitration logic may send a transmission path of the access request through the functional module according to the address of the queried grant register, so as to send a transmission direction opposite to the access request, and write the grant information into the grant register of the functional module.

As an alternative implementation, the authorization register of the functional module may indicate, by different values, whether authorization information is written to indicate whether the functional module is authorized to obtain the right to use the IO resource. For example, if the value of the authorization register of the function module is a first value (for example, a value of 1), the authorization information is written into the authorization register of the function module, so as to indicate that the function module obtains the authorization of the use right of the IO resource; for another example, if the value of the grant register of the functional module is a zero value (e.g., a value of 0), it indicates that the grant information is not written into the grant register of the functional module, indicating that the functional module does not obtain the grant of the usage right of the IO resource, and waiting for the grant of the arbitration logic.

In a further optional implementation, after the function module obtains the usage rights of the IO resources and the usage of the IO resources ends, the function module may set the value of the authorization register to a zero-th value to release the usage rights of the function module for using the IO resources. That is, at the end of using the IO resource by the functional module, the functional module may set the value of the grant register to the zeroth value by itself to release the usage right of the IO resource. In this implementation, the grant register is set in the functional module, the value of the grant register is set at the first value, and the value of the grant register is controlled and set by the arbitration logic, and the value of the grant register is cleared (for example, the value of the grant register is cleared to be zero value) is controlled and set by the functional model after the use of the IO resource is finished, so that the functional module can confirm the grant condition of the functional module by the value of the grant register nearby.

In a possible alternative implementation, after the function module obtains the use permission of the IO resource and the use of the IO resource is finished, the arbitration logic may obtain a release request for releasing the IO resource sent by the function module; based on the release request, the arbitration logic may send a transmission path of the access request through the functional module to send a transmission direction opposite to the access request, and set a value of an authorization register of the functional module to a zero value to release the usage right of the IO resource used by the functional module. That is, when the function module finishes using the IO resource, the arbitration logic obtains the release request of the IO resource sent by the function module, the arbitration logic may set the value of the grant register of the function module to a zero value to release the grant of the function module for using the IO resource, thereby authorizing other function modules requesting the use right of the IO resource. In an alternative implementation, based on the obtained release request, the arbitration logic may synchronously set the value of the request bit corresponding to the functional module in the request register to a zero-th value.

As an example, taking the example of setting the authorization registers for 2 memory controllers of processor core die 510 and the example of setting the authorization registers for 2 memory controllers of processor core die 520 as shown in fig. 5, fig. 7B schematically illustrates an exemplary diagram of the authorization registers provided in the embodiments of the present application, and as shown in fig. 5 and 7B, memory controller 1 of processor core die 510 may set authorization register 711, memory controller 2 of processor core die 510 may set authorization register 712, memory controller 1 of processor core die 520 may set authorization register 713, and memory controller 2 of processor core die 520 may set authorization register 714;

wherein the authorization register has a bit number of an authorization bit to identify the corresponding functional module. The authorization register may also set the field name of the authorization bit. The grant register may also set a value field of the grant bit, and a grant type field (e.g., the grant type indicated by the grant type field is divided into authorizing the use of IO resources to read and/or write data). Alternatively, the default value of the value field of the grant bit may be 0x0 (corresponding to the zero value, e.g., 0x0 represents a value of 0), where the value field of the grant bit is set to a first value (e.g., a value of 1) when the arbitration logic writes the grant information to the grant register, and where the function module corresponding to the grant register releases the use of the IO resource, the function module or the arbitration logic may set the value field of the grant register to the zero value.

As shown in fig. 7B, from the description of the grant registers 711, 712, 713, and 714, the value of a certain grant register is written with 1, which indicates that the function module corresponding to the grant register is authorized to use the IO resource, and the value of the grant register is written with 0, which indicates that the use right of the function module corresponding to the grant register to use the IO resource is released. A more specific example description of an authorization register may be found in reference to fig. 7B, which is not intended to be exhaustive of embodiments of the present application.

By way of example, taking as an example the setting of the grant registers for the 2 memory controllers of the processor core die 510 and the setting of the grant registers for the 2 memory controllers of the processor core die 520, fig. 7C illustrates an example diagram of an address list provided in an embodiment of the present application, where the address list may set a plurality of grant bits, and the addresses of the grant registers corresponding to the respective grant bits, where one grant bit corresponds to one functional module; for example, as shown in connection with fig. 7B and 7C, the address list may set up: the authorization bit of memory controller 1 of processor core die 510 and the corresponding address are the address of authorization register 711, the authorization bit of memory controller 2 of processor core die 510 and the corresponding address are the address of authorization register 712, the authorization bit of memory controller 1 of processor core die 520 and the corresponding address are the address of authorization register 713, and the authorization bit of memory controller 2 of processor core die 520 and the corresponding address are the address of authorization register 714.

It should be noted that, when the function module uses the IO resource to send and receive the peripheral data, the rate of sending and receiving the peripheral data is lower than the rate of sending and receiving the data by the function module, so that after the IO resource (such as the IO controller) sends out a data processing request to the peripheral, the peripheral needs to wait for the peripheral to return data for a longer time, and during waiting for the peripheral to return data, the function module can maintain the usage right of the IO resource (such as the controller); further, after the IO resource (e.g., the IO controller) acquires the data returned by the peripheral, the data returned by the peripheral may be sent to the functional module. In the process, the functional module sends data to the peripheral by using IO resources through a transmission path for sending the access request so as to send the same transmission direction of the access request; and the functional module receives the data returned by the peripheral through a transmission path for sending the access request so as to send the opposite transmission direction of the access request.

After the functional module obtains the data returned by the peripheral, the IO resources can be continuously used for carrying out the next data transmission with the peripheral, or the IO resources can be used. When the function module finishes using the IO resources, the function module may request to release the IO resources, for example, the function module sets a value of a corresponding request bit in the request register to be a zero value to implement sending a release request for releasing the IO resources to the arbitration logic, and the function module or the arbitration logic clears a value of an authorization register of the function module to implement releasing the usage rights of the function module to the IO resources. After releasing the use right of the IO resource of the functional module, the arbiter can confirm the next functional module obtaining the use right of the IO resource based on an arbitration algorithm and authorize the functional module; for example, the arbiter may arbitrate the usage right of the IO resource for the functional module corresponding to the request bit with a value of 1 based on the arbitration algorithm, thereby identifying the next functional module that obtains the usage right of the IO resource, and setting the value of the grant register of the functional module to 1.

In order to facilitate understanding of the timing mechanism of multiple functional modules competing for IO resources through arbitration logic, taking the timing of 4 functional modules competing for the same IO resource as an example, fig. 8 is an exemplary diagram illustrating the competing timing of IO resources provided in the embodiment of the present application, referring to fig. 8, the access request 811 sent by the functional module 810 reaches the arbiter of the IO resource first, where there is no access request from another functional module (e.g. functional modules 820, 830 and 840), so the functional module 810 will obtain the grant information 812 returned by the arbiter; subsequently, the arbiter receives the access request 821 from the functional module 820, the access request 831 from the functional module 830, and the access request 841 from the functional module 840 at the same time, and the IO resource is currently occupied by the access request 811 of the functional module 810, so that the access requests sent by other subsequent functional modules need to wait for authorization. When the process of transmitting data between the access request 811 and the peripheral device is finished, the arbiter may cause the access request 821 sent by the function module 820 to obtain the grant information 822 according to an arbitration algorithm such as a round robin algorithm, and the like, which in turn causes the access request 831 sent by the function module 830 to obtain the grant information 832 and the access request 841 sent by the function module 840 to obtain the grant information 842.

It should be noted that, fig. 8 illustrates that the usage right arbitration of the IO resources is performed by using a first-in-first-out grant rule of the access request and a Round-robin scheduling (Round-robin) manner for the access request that arrives simultaneously, and the embodiment of the present application is not limited to the arbitration algorithm used by the arbiter, and may be at least one algorithm of multiple algorithms such as first-in first-out, round-robin scheduling, priority, and the like. Round robin scheduling is an arbitration policy that allocates resources based on round robin rotation, to ensure that each requestor has an opportunity to access the resources.

In one example, taking the processor core die as an example, a memory controller on the processor core die needs to access a DIMM on a motherboard through an I3C interface (an example of an IO resource). If the processor core kernels all use the own I3C interfaces, multiple groups of I3C interfaces need to be led out from the package, and DIMMs on the main board need to be connected with multiple I3C interfaces at the same time, which results in quite complex connection relations. By adopting the scheme provided by the embodiment of the application, the I3C interfaces on the core grains of part of the processor core can be led out to the package, so that a plurality of DIMMs on the main board can be connected with the I3C interfaces on the core grains of part of the processor core, and all the core grains of the processor core can access the DIMMs through the IO resource sharing scheme provided by the embodiment of the application, thereby greatly simplifying the package design and the main board wiring design.

According to the scheme provided by the embodiment of the application, the arbitration logic in the form of hardware is used for arbitrating the use right of the functional module accessing the IO resources, so that the problem of lower IO resource sharing efficiency caused by software participation can be avoided when the use right of the IO resources is arbitrated and allocated, and the sharing efficiency of the IO resources is improved on the basis of guaranteeing the sharing reliability of the IO resources. For example, in the initialization stage, the embodiment of the application can initialize the contents of the request register, the authorization register and the address list in a software manner, so as to configure the environments of using IO resources for different functional modules; and then when the function module requests to use the IO resources to perform data interaction with the peripheral equipment, software intervention is not needed, the authorization and release of the use right of the IO resources can be automatically completed through the function module, the arbiter and the corresponding transmission paths directly based on the contents of the configured request register, the authorization register and the address list, the function module using the IO resources uses the IO resources (the contents of the configured request register, the configured authorization register and the address list of the corresponding function module) in the configured environment, and the sharing efficiency of the IO resources is improved.

Based on the core particle for realizing IO resource sharing provided by the embodiment of the application, the embodiment of the application also provides an IO resource sharing method. As an optional implementation, fig. 9 illustrates an optional flowchart of an IO resource sharing method provided by an embodiment of the present application, where the method flowchart may be applied to a core, for example, arbitration logic applied to the core. The portions of the following description that relate to the foregoing are referred to each other. Referring to fig. 9, the method flow may include the following steps.

In step S910, an access request of an IO resource sent by a plurality of functional modules is received.

In step S920, the usage rights of the IO resources are arbitrated for the access requests of the plurality of functional modules.

In an alternative implementation, the embodiment of the application may determine the functional module that obtains the usage rights of the IO resource based on at least one of the following arbitration algorithms: the arrival sequence of the access requests, the priority of the access requests and the permission degree of the function module for sending the access requests;

when the arbitration of the use right is carried out based on the arrival sequence of the access requests, determining a functional module for obtaining the use right of the IO resources according to the arrival sequence of the access requests; when the arbitration of the use right is carried out based on the priority of the access request, determining a functional module for obtaining the use right of the IO resource according to the order from high to low of the priority of the access request; when the arbitration of the use right is carried out based on the permission degree of the function module sending the access request, the function module obtaining the use right of the IO resource is determined according to the order from high to low of the permission degree of the function module.

In a further alternative implementation, if at least two arbitration algorithms are used, determining an arbitration result of the access request in each arbitration algorithm; determining the final arbitration result of the access request by combining the arbitration results of the access request in all arbitration algorithms and the weights corresponding to all arbitration algorithms; and determining a functional module for obtaining the use right of the IO resource according to the final arbitration result of the access request.

In step S930, in order to obtain the function module of the usage right of the IO resource, the function module of the usage right of the IO resource is authorized to perform data interaction with the peripheral device by using the IO resource.

In an alternative implementation, the embodiment of the application may send the transmission path of the access request through the functional module to send the opposite transmission direction of the access request, and write the authorization information into the functional module for obtaining the usage right of the IO resource, so as to implement the function module for obtaining the usage right of the IO resource, and authorize the usage right of the IO resource.

In a further optional implementation, the embodiment of the application may further obtain the usage right of the IO resource at the functional module, and after the usage of the IO resource is finished, obtain a release request for releasing the IO resource sent by the functional module, so that the usage right of the IO resource used by the functional module is relieved based on the release request; or after the function module obtains the use authority of the IO resource and the use of the IO resource is finished, the function module releases the use authority of the IO resource by itself.

Embodiments of the present application also provide a chip system (e.g., a system on a chip) including a plurality of interconnected core particles, wherein some or all of the plurality of core particles are core particles provided by embodiments of the present application.

The embodiment of the application also provides an electronic device, such as a terminal device or a server device, which may include the chip system (e.g., a system on a chip) provided by the embodiment of the application, and/or the core particle provided by the embodiment of the application.

The foregoing describes a number of embodiments provided by embodiments of the present application, and the various alternatives presented by the various embodiments may be combined, cross-referenced, with each other without conflict, extending beyond what is possible, all of which may be considered embodiments disclosed and disclosed by embodiments of the present application.

Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Various changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the invention, and the scope of the invention shall be defined by the appended claims.

Claims

1. A core particle, the core particle comprising:

IO resources, which are connected with the packaging pins;

2. The core particle of claim 1, further comprising: a core particle connector;

the core particle connector of the opposite-end core particle and the core particle connector of the core particle are connected with a logic passage between the opposite-end core particle and the core particle, and an in-package control network for transmitting control signals is arranged on the logic passage;

the access request of the functional module in the opposite-end core particle is transmitted to the core particle by the opposite-end core particle through an in-package control network arranged on a logic path based on the core particle connector of the opposite-end core particle and the logic path connected with the core particle connector of the core particle.

3. The core particle of claim 2, further comprising: a control bus disposed within the core;

wherein the transmission path for the functional module within the peer-to-peer core to send an access request to the arbitration logic further comprises: a path from the functional module within the pair of end-die to the control bus within the pair of end-die, a path from the control bus within the pair of end-die to a die connector of the pair of end-die, a path from a die connector of the die to the control bus within the die, a path from the control bus within the die to arbitration logic within the die;

the access request of the functional module in the opposite-end core grain is transmitted to the core grain connector of the opposite-end core grain by the control bus in the opposite-end core grain, and is transmitted to the core grain connector of the core grain through the control network in the package arranged on the logic path based on the logic path connected with the core grain connector of the opposite-end core grain and the core grain connector of the core grain, and the access request transmitted to the core grain connector of the core grain is transmitted to the arbitration logic through the control bus in the core grain.

4. The core of claim 3, wherein the transmission path for the functional module within the core to send an access request to the arbitration logic comprises: a path from a control bus within the die to the arbitration logic; wherein access requests of functional modules within the core are communicated to the arbitration logic via a control bus within the core.

5. The core of claim 1, wherein the arbitration logic is provided with a request register having request bits, one request bit corresponding to each functional module; and the access request of the IO resource sent by the functional module is at least used for setting the value of the corresponding request bit in the request register as a first value.

6. The core granule of claim 5, wherein the arbitration logic is further configured to, after the functional module obtains the usage rights of the IO resources and finishes using the IO resources, receive a release request sent by the functional module to release the IO resources, where the release request is used to set a value of a corresponding request bit in the request register to a zero value;

The transmission path of the release request transmitted by the functional module corresponds to the transmission path of the access request transmitted by the functional module to the arbitration logic.

7. The core particle of claim 6, wherein the request bit comprises: a bit number of the request bit, a field name of the request bit, a value field of the request bit, and a request type field; the default value of the numerical value field of the request bit is a zero value, and the type of the access request indicated by the request type field is divided into read data and write data.

8. The core particle according to any of the claims 5-7, wherein the number of request registers is plural, and one functional module corresponds to one request register, and the request bit corresponding to the functional module is set in the corresponding request register.

9. The core of claim 1, wherein the arbitration logic to arbitrate usage of the IO resources for access requests by the plurality of functional modules comprises:

determining a functional module for obtaining the use right of the IO resource based on at least one arbitration algorithm: the arrival sequence of the access requests, the priority of the access requests and the permission degree of the function module for sending the access requests;

When the arbitration of the use right is carried out based on the arrival sequence of the access requests, determining a functional module for obtaining the use right of the IO resources according to the arrival sequence of the access requests;

when the arbitration of the use right is carried out based on the priority of the access request, determining a functional module for obtaining the use right of the IO resource according to the order from high to low of the priority of the access request;

when the arbitration of the use right is carried out based on the permission degree of the function module sending the access request, the function module obtaining the use right of the IO resource is determined according to the order from high to low of the permission degree of the function module.

10. The core of claim 9, wherein the arbitration logic is to determine the functional module to obtain usage rights for the IO resources based on at least one of the following arbitration algorithms, comprising:

if at least two arbitration algorithms are used, determining an arbitration result of the access request in each arbitration algorithm; determining the final arbitration result of the access request by combining the arbitration results of the access request in all arbitration algorithms and the weights corresponding to all arbitration algorithms; and determining a functional module for obtaining the use right of the IO resource according to the final arbitration result of the access request.

11. The core of claim 1, wherein the arbitration logic is further to grant the usage rights of the IO resources for a functional module that obtains the usage rights of the IO resources.

12. The core of claim 11, wherein the arbitration logic is to grant the usage rights of the IO resources to a functional module that obtains the usage rights of the IO resources, comprising:

and aiming at the function module which obtains the use right of the IO resource, transmitting a transmission path of the access request through the function module so as to transmit the opposite transmission direction of the access request, and writing the authorization information into the function module.

13. The core particle according to claim 12, wherein the function module that obtains the usage rights of the IO resources uses the IO resources to transmit peripheral data through a transmission path that sends an access request;

the function module for obtaining the use right of the IO resource sends peripheral data by using the IO resource through a transmission path for sending an access request so as to send the same transmission direction of the access request; and the function module for obtaining the use right of the IO resource receives peripheral data by using the IO resource through a transmission path for sending the access request and in a transmission direction opposite to the transmission direction for sending the access request.

14. The core according to any of the claims 12-13, wherein the arbitration logic is provided with an address list, which records addresses of the grant registers of the functional modules; the authorization register of the functional module is used for writing authorization information.

15. The core particle of claim 14, wherein the arbitration logic is configured to, for a functional module that obtains usage rights for the IO resource, send a transmission path of an access request through the functional module to send a transmission direction opposite to the access request, write authorization information to the functional module comprising:

inquiring the address of an authorization register of the function module in the address list according to the identity information of the function module for obtaining the use right of the IO resource;

and according to the address of the inquired authorization register, transmitting a transmission path of the access request through the functional module so as to transmit the opposite transmission direction of the access request, and writing authorization information into the authorization register of the functional module.

16. The core particle according to claim 15, wherein the value of the authorization register of the functional module is a first value, indicating that authorization information is written into the authorization register of the functional module, indicating that the functional module is authorized to obtain the usage rights of the IO resources; and if the value of the authorization register of the functional module is a zero value, indicating that authorization information is not written into the authorization register of the functional module, and indicating that the functional module does not obtain the authorization of the use right of the IO resource.

17. The core particle of claim 16, wherein the functional module sets a value of a corresponding grant register to a zero-th value after obtaining the usage rights of the IO resources and ending using the IO resources;

or,

the arbitration logic obtains the use permission of the IO resources at the functional module, and obtains a release request for releasing the IO resources, which is sent by the functional module, after the use of the IO resources is finished; the arbitration logic sends a transmission path of an access request through the functional module based on the release request to send a transmission direction opposite to the access request, and sets a value of an authorization register of the functional module to be a zero value so as to release the use right of the IO resource by the functional module.

18. The core particle according to any of the claims 15-17, wherein the address list is provided with a plurality of authorization bits, and the address of the authorization register corresponding to each authorization bit, one authorization bit corresponding to each functional module; the authorization register is provided with a bit number of an authorization bit, a field name of the authorization bit, a numerical value field of the authorization bit and an authorization type field; and the default value of the numerical value field of the authorization bit is a zero-th value, and the authorization type indicated by the authorization type field is classified into authorization for reading and/or writing data by using the IO resource.

19. An IO resource sharing method, applied to the core particle of any one of claims 1-18, comprising:

20. The method of claim 19, wherein arbitrating the usage rights of the IO resources for access requests of the plurality of functional modules comprises:

21. The method as recited in claim 19, further comprising:

acquiring a release request for releasing IO resources, which is sent by a functional module, after the functional module acquires the use permission of the IO resources and the use of the IO resources is finished; based on the release request, releasing the use right of the IO resource used by the functional module;

or after the function module obtains the use authority of the IO resource and the use of the IO resource is finished, the function module releases the use authority of the IO resource.

22. A system on a chip comprising a plurality of interconnected core particles, wherein some or all of the plurality of core particles are core particles as claimed in any one of claims 1 to 18.

23. An electronic device comprising the system on chip of claim 22 and/or the core of any of claims 1-18.