CN117707426A - A chip, IO resource sharing method, system on a chip and electronic equipment - Google Patents

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

A chip, IO resource sharing method, system on a chip and electronic equipment

Technical field

The embodiments of this application relate to the field of chip technology, and specifically relate to a chip, an IO resource sharing method, a system on a chip, and an electronic device.

Background technique

A chiplet is a unit chip that can achieve certain functions. Multiple chiplets can be interconnected to form chip systems such as SOC (System On Chip). The core particle is provided with IO (Input/Output, input and output) resources for input and output operations between the core particle and peripheral devices. For example, the core particle can communicate with external devices (referred to as external devices) such as storage devices, network interfaces, and external sensors through IO resources. Assume) for input and output.

In order to save hardware resources, there is a need for multiple cores to share IO resources. Therefore, when designing chips, how to provide cores that can support shared IO resources to improve IO resources while ensuring the reliability of shared IO resources? The sharing efficiency has become an urgent technical problem that technicians in this field need to solve.

Contents of the invention

In view of this, embodiments of the present application provide a chip, an IO resource sharing method, an on-chip system and an electronic device, which support multiple cores to share IO resources and can improve IO while ensuring the reliability of sharing of IO resources. Resource sharing efficiency.

To achieve the above objectives, embodiments of the present application provide the following technical solutions.

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

IO resources, the IO resources are connected to package pins;

Arbitration logic connected to the request entry of the IO resource. The arbitration logic is at least used to receive access requests for the IO resources sent by multiple functional modules and arbitrate the IO for the access requests of the multiple functional modules. rights to use resources;

Wherein, the plurality of functional modules include: functional modules in the core grain, and functional modules in any pair of end core grains interconnected with the core grain; the functional modules in the opposite end core grain communicate to all The transmission path for the access request sent by the arbitration logic at least includes: a logical path between the opposite end core particle and the core particle; wherein the access request for the functional module in the opposite end core particle passes through the logical path, Passed from the opposite end core particle to the core particle.

In a second aspect, embodiments of the present application provide an IO resource sharing method, applied to the core particle described in the first aspect, and the method includes:

Receive IO resource access requests sent by multiple functional modules;

Arbitrate the use rights of the IO resources for the access requests of the multiple functional modules;

In order to obtain the use right of the IO resource, the functional module is authorized to use the IO resource, so that the functional module that obtains the use right of the IO resource uses the IO resource to interact with peripheral devices.

In a third aspect, embodiments of the present application provide a system-on-a-chip, including a plurality of interconnected cores, and some or all of the plurality of cores are the cores described in the first aspect.

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

Embodiments of the present application provide a core particle. The core particle may include: IO resources, the IO resources are connected to package pins; arbitration logic connected to the request entry of the IO resources, the arbitration logic is at least used to receive Access requests for the IO resources sent by multiple functional modules arbitrate the use rights of the IO resources for the access requests of the multiple functional modules; wherein the multiple functional modules include: functions within the core module, and the functional module in any pair of core particles interconnected with the core particle; the transmission path through which the functional module in the opposite end core particle sends an access request to the arbitration logic at least includes: the opposite end core A logical path between the opposite end core particle and the core particle; wherein the access request to the functional module in the opposite end core particle is passed from the opposite end core particle to the core particle through the logical path.

It can be seen that the core particle provided by the embodiment of the present application can support the functional modules in the core particle and the functional modules in any pair of core particles interconnected with the core particle, and share the IO resources of the core particle; among them, for the opposite end As for the functional module of the core particle, the embodiment of the present application supports the transmission of the access request for the IO resource of the functional module of the opposite end core particle through the logical path between the opposite end core particle and the core particle where the IO resource is located. Therefore, the implementation of this application Examples can realize that IO resources are shared by functional modules of multiple cores. At the same time, the request entry of the core chip's IO resources is equipped with arbitration logic. The arbitration logic can arbitrate the use rights of IO resources for the access requests of multiple functional modules when multiple functional modules send access requests for IO resources; because the arbitration logic is In the form of hardware, the embodiments of this application can allocate the use rights of IO resources to multiple functional modules sharing IO resources through hardware arbitration, avoiding software participation in allocating the use rights of IO resources, and avoiding the problems caused by software participation. This solves the problem of low sharing efficiency of IO resources, thereby improving the sharing efficiency of IO resources on the basis of ensuring the reliability of sharing IO resources with arbitration logic in the form of hardware. Therefore, the embodiments of the present application can support the functional modules of multiple cores to share IO resources, and can improve the sharing efficiency of IO resources while ensuring the reliability of sharing of IO resources.

Description of the drawings

In order to explain the embodiments of the present application or the technical solutions in the prior art more clearly, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are only This is an embodiment of the present application. For those of ordinary skill in the art, other drawings can be obtained based on the provided drawings without exerting creative efforts.

Figure 1 is an example diagram of the interconnection of multiple die within a package.

FIG. 2A is another example diagram of interconnection of multiple die within a package.

FIG. 2B is another example diagram of interconnection of multiple die within a package.

Figure 3 is an example diagram of an access request sent by a core in a package provided by an embodiment of the present application.

FIG. 4 is another example diagram of an access request sent by a core in a package provided by an embodiment of the present application.

FIG. 5 is another example diagram of an access request sent by a core in a package provided by an embodiment of the present application.

Figure 6 is an example diagram of the arbitration logic provided by the embodiment of the present application.

FIG. 7A is an example diagram of a request register provided by an embodiment of the present application.

FIG. 7B is an example diagram of an authorization register provided by an embodiment of the present application.

FIG. 7C is an example diagram of an address list provided by an embodiment of the present application.

Figure 8 is a competition sequence diagram for IO resources provided by the embodiment of the present application.

Figure 9 is a flow chart of an IO resource sharing method provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of this application.

A chip is a small chip die. After multiple chips with different functions or different processes are interconnected, they can be integrated and packaged into a chip system (such as a SOC chip) through advanced packaging (such as 3D packaging), that is, Multiple core particles can be packaged to form a chip system after being interconnected. Some of the interconnected core particles can have different functions or use different processes.

Cores are divided according to their functions and can be divided into many different types of cores such as IO cores, storage cores, and processor cores (such as CPU cores).

Among them, the IO core is a core that realizes the IO function of the chip system and is a core used to manage the input and output of the chip system. For example, IO chips can be connected to network communication, USB (Universal Serial Bus, Universal Serial Bus) communication, PCIE (Peripheral Component Interconnect Express, high-speed serial computer expansion bus standard) communication and other communication methods to realize network communication of the chip system Connection, USB communication connection, PCIE communication connection and other communication connections; various interfaces and control circuits can be set in the IO chip to support different types of communication connections.

The storage core is a core that implements the storage function of the chip system. It is a core used for data storage in the chip system. The storage core provides processing functions such as data reading and writing. Memory chips can support different types of storage devices, such as random access memory, read-only memory, flash memory, solid-state drives, etc.; in one example, DIMM (Dual-Inline-Memory-Modules, dual in-line memory modules) and other memory modules can be placed on the memory core.

A processor core is a core that implements the processor core function of a chip system. It is a core that is used to execute instructions and operations of a computer program. The processor core is, for example, a CPU core. It should be noted that the chip system can have multiple processor cores, and one processor core can be regarded as an independent processing unit, which is provided in one processor core die.

Chips with different functions can be produced using different processes. For example, when IO functions, storage functions and processor core functions are manufactured, the area and power consumption are reduced to different extents with process improvements. IO functions, storage functions, and processor core functions can be set on different cores, and different processes can be used to produce IO cores, storage cores, and processor cores.

Taking the manufacturing of core chips corresponding to IO functions and processor core functions as an example, the area and power consumption corresponding to the production of core chips for IO functions have been reduced with process improvement, which is lower than that of the core chip manufacturing for processor core functions. The corresponding area and power consumption are reduced with process improvement; that is to say, when the IO function chip is manufactured, the area and power consumption are reduced with process improvement to a low extent, while the processor core function chip is. During manufacturing, area and power consumption are reduced to a greater extent with process improvements. Based on this, IO functional chips can be manufactured using a more mature process with lower tape-out costs and lower logic density to obtain IO chips. Since the chip is a small bare chip, the IO chip Dies can also be called IO dies (IO Dies); chips with processor core functions can be manufactured using more advanced processes with higher tape-out costs and higher logic density to obtain processor core dies. A die is a small chip die, and a processor core die can also be called a core die.

After generating and manufacturing IO cores (IO chips), processor core cores (core chips), storage cores and other cores, multiple cores (there can be at least two different types of cores in multiple cores) particles) are integrated into the same package to obtain a chip system (such as a SOC chip), which optimizes the manufacturing cost of the chip system.

For ease of understanding, Figure 1 illustrates an example diagram of the interconnection of multiple core particles in the package. As shown in Figure 1, core particle 101 and core particle 102 are two core particles interconnected in the package. The interconnection can be understood as There is a connection between the core particles and information can be exchanged. That is to say, there can be a connected path between the core particle 101 and the core particle 102, and the core particle 101 and the core particle 102 can exchange information through the connected path. Interaction.

Taking the interconnection between multiple processor cores and IO cores as an example, Figure 2A schematically shows another interconnection example diagram of multiple cores in the package. As shown in Figure 2A, in four processor cores When the chips are interconnected with one IO core chip, the processor core chip 210, the processor core chip 220, the processor core chip 230, and the processor core chip 240 can be connected to the IO core chip 250 respectively.

It should be noted that within the package of a chip system (such as a SOC chip), the interconnected cores can be any type of cores, such as processor cores, IO cores, storage cores, etc. The two can be interconnected with each other. The embodiments of this application do not set limits on the type, quantity, and location of the interconnected core particles, as well as the interface protocol used for interconnecting the core particles.

Processor cores, IO cores, storage cores and other cores are equipped with IO resources for input and output operations with peripherals. IO resources can be regarded as IO controls for input and output operations between cores and peripherals. devices (such as peripheral controllers), IO interfaces, etc. IO resources can support different protocols to support communication between chips and peripherals in different application scenarios. For example, IO resources can support I2C (Inter-Integrated Circuit, serial two-wire bus), I3C (Improved Inter-Integrated Circuit) , improved serial two-wire bus), UART (UniversalAsynchronous Receiver Transmitter, Universal Asynchronous Receiver Transmitter) and other IO controllers and IO interfaces for protocols.

Within the package of a chip system (such as a SOC chip), the package pins can lead the internal signals, data and control information of the chip to the outside of the chip. For the purpose of saving the number of package pins, the package pins inside the package There is a certain limit on the quantity, so when designing a chip, you can choose to not lead out some IO resources in the chip or some of the IO resources in the chip through the package to save the number of package pins. That is to say, some IO resources in the core or part of the IO resources of the core are not connected to the package pins. In this case, for the core whose IO resources are not led out through the package (that is, for the IO resources are not connected to the package pin chip), can share the IO resources derived from other chips through the package to achieve communication with peripherals.

For ease of understanding, FIG. 2B schematically shows another interconnection example diagram of multiple cores in the package. As shown in FIG. 2A and FIG. 2B , the processor core core 210 is provided with an IO resource 211, a processor core The particle 220 is configured with an IO resource 221, the processor core particle 230 is configured with an IO resource 231, the processor core particle 240 is configured with an IO resource 241, and the IO core particle 250 is configured with IO resources 251 and 252. Among them, IO resources 231, IO resources 241, IO resources 251 and 252 are led out through the package and connected to the package pins to achieve communication with peripherals; while the IO resource 211 of the processor core chip 210 and the processor core chip The IO resource 221 of 220 is not brought out through the package and is not connected to the package pins. Based on this, in order to realize communication between the processor core 210 and the processor core 220 and peripherals, the processor core 210 and the processor core 220 need to share the IO resources 231 of the processor core 230, Or, the IO resources 241 of the processor core 240, or the IO resources 251 and 252 of the IO core 250, by borrowing any one of the processor core 230, the processor core 240 and the IO core 250. Core IO resources to achieve communication with peripherals.

It should be noted that Figure 2B is only used as an example to illustrate the need to share IO resources between core particles. The embodiment of the present application requires the type, quantity, and placement location of the core particles, as well as the number of IO resources within the core particles. , there is no limit to setting the location.

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 multiple cores are integrated into the same package, there is a need to share IO resources between the cores, and some cores need The IO resources used may be located on other cores; this results in multiple access requests competing for the same IO resources at the same time. These access requests may come from the same core or multiple functional modules of different cores, which may cause IO resource Problems such as access conflicts and even IO resource access processing errors make it difficult to guarantee the shared reliability of IO resources. In other words, the reliability of shared IO resources between cores is called the shared reliability of IO resources. Due to issues such as access conflicts of IO resources and access processing errors of IO resources, the shared reliability of IO resources may be low. Therefore, it is necessary to provide a sharing mechanism for IO resources to ensure the reliability of sharing IO resources.

A way to realize IO resource sharing and ensure the reliability of IO resource sharing is:

The on-chip microprocessor runs firmware (Firmware), and the firmware queries the status of all IO resources in the package through a polling mechanism, so as to perform centralized allocation and permission management of IO resources based on the status of all IO resources; at the same time, the firmware is responsible for Switch the environment configuration of IO resources used by different functional modules. Among them, when the firmware performs centralized allocation and permission management of IO resources, it must ensure that only one functional module has the permission to use an IO resource at the same time, that is, the same IO resource can be used serially between functional modules.

The above method is a way to use software to ensure the serial use of the same IO resource (the firmware can be in the form of software). When there are multiple functional modules accessing the same IO resource, because the IO resource is accessed more frequently, the software execution The speed is slow, which makes the on-chip microprocessor need to use more overhead and time to switch the usage rights of IO resources and switch the environment configuration of different functional modules to use IO resources, resulting in low sharing efficiency of IO resources; at the same time, Since the software execution speed is slower, the more IO resources in the package, the longer the time interval for the firmware to poll the status of all IO resources in the package, which leads to a further reduction in the sharing efficiency of IO resources, and there may even be functional modules that are unable to access the IO resources. The resource access request does not get a response for a long time.

Another way to realize IO resource sharing and ensure the reliability of IO resource sharing is:

Multiple functional modules sharing IO resources apply to the on-chip microprocessor for usage rights of the shared IO resources through the interrupt mechanism. The firmware running on the on-chip microprocessor centrally allocates and manages permissions for the shared IO resources, and is responsible for switching between different Function modules use the environment configuration of IO resources. Among them, when the firmware performs centralized allocation and permission management of shared IO resources, it needs to ensure that only one functional module has the permission to use an IO resource at the same time, that is, the same IO resource is used serially between functional modules.

Although the above method does not require the firmware to query the status of the IO resources through the polling mechanism, but the functional module applies for the use permission of the IO resources through the interrupt mechanism, the sharing method of IO resources is still a way of using software to protect the same IO resources. When there are multiple functional modules accessing the same IO resource, the on-chip microprocessor still needs to be accessed more frequently, the software execution speed is slower, and the interrupt handler is more cumbersome. More overhead and time are used to switch the usage rights of IO resources and switch the environment configuration of different functional modules to use IO resources, resulting in low sharing efficiency of IO resources.

It can be seen that the above-mentioned method of realizing IO resource sharing and ensuring the reliability of IO resource sharing is a software-centralized mechanism for allocating IO resource usage rights. Due to the slow software execution speed, large software overhead, and response time Longer, this results in lower sharing efficiency of IO resources; and, as the number of chips in the package increases, IO resources increase, and the number of functional modules that access IO resources increases, the sharing efficiency of IO resources will further decrease and deteriorate.

Based on this, embodiments of the present application provide an improved IO resource sharing solution, which improves the sharing efficiency of IO resources while ensuring the reliability of IO resource sharing.

The embodiment of the present application supports allocating the IO resources of the core to the functional modules inside the core, and sharing them with the functional modules of other cores interconnected with the core. That is to say, for the IO resources shared by the core, , the access request for IO resources can come from inside the core particle (for example, from the functional modules inside the core particle), or from outside the core particle (for example, from the functional modules of other core particles interconnected with the core particle), where, Access requests from outside the core particles can be transmitted between core particles through logical paths between core particles. At the same time, for cores that share IO resources, embodiments of the present application can set up hardware arbitration logic in the cores, and use the hardware arbitration logic to arbitrate and allocate usage rights for access requests for IO resources from multiple functional modules, so as to Supports multiple functional modules' access to shared IO resources, thereby improving the sharing efficiency of IO resources through hardware arbitration of usage rights through hardware arbitration logic on the basis of ensuring the reliability of IO resource sharing. Among them, the functional module for accessing IO resources referred to in the embodiments of this application may be located in the core where the IO resource is located, or may be located in other cores interconnected with the core where the IO resource is located.

Based on the above ideas, the embodiments of the present application can set up arbitration logic in the core chip that shares the IO resource, and connect the arbitration logic to the request entry of the IO resource, so that the arbitration logic can be used to at least receive requests from multiple functional modules to the IO resource. access requests, and arbitrate the use rights of IO resources for multiple functional modules; among them, the multiple functional modules that send access requests to IO resources can include: functional modules in the core where the IO resources are located, and functional modules in the core where the IO resources are located. Functional modules in any other interconnected chip.

It should be noted that the request entry of IO resources refers to the port through which access requests enter the IO resources. Arbitration logic can be regarded as an arbitration circuit in the form of a circuit, and can also be called an arbiter.

For cores that set up shared IO resources, for access requests inside the core (for example, access requests from functional modules inside the core), embodiments of the present application support sending access requests through the control bus within the core. Passed to the arbitration logic (such as the arbiter) to reach the request entry of the IO resource; for access requests outside the core particle (such as access requests from functional modules of other core particles interconnected with the core particle), the embodiment of this application Supports passing access requests to arbitration logic (such as arbiter) through the control bus in the core where the functional module is located, the logical path between cores, and the control bus in the core where the IO resource is located, to reach the IO resource. Request entry. That is to say, the embodiment of the present application provides a transmission mechanism and transmission path for access requests inside the core particle and access requests outside the core particle to reach the IO resources of the core particle.

As an optional implementation, Figure 3 illustrates an example diagram of an access request sent by a core in a package provided by an embodiment of the present application. As shown in Figure 3, the IO resource 311 of the core 310 is extracted through the package and can be used as a core. IO resources shared between chips; that is to say, the IO resources of the chip 310 are connected to the package pins and can be used for peripheral control and can be used as IO resources shared between chips. The request entry of the IO resource 311 of the core particle 310 is connected to an arbitration logic 312. For multiple functional modules that send access requests to the IO resource 311, the arbitration logic 312 can arbitrate the usage rights of the IO resource 311 for the multiple functional modules.

As an optional implementation, there can be multiple IO resources in the core. For IO resources that can be shared, the embodiment of this application can connect arbitration logic to the request entry of each IO resource, that is, one IO resource can be connected to one arbitration Logic, thereby arbitrating the usage rights for the access requests sent by the functional module to each IO resource through the arbitration logic of the corresponding connection of each IO resource.

As an optional implementation, the functional module that sends an access request to the IO resource 311 can be located in the core 310. For example, any functional module in the core 310 can send the access request to the IO resource 311 through the control bus in the core 310. Passed to arbitration logic 312. As an example, the functional module 313 is any functional module in the core 310. The dotted path 031 with an arrow in Figure 3 shows the transmission path of the access request issued by the functional module 313 to the arbitration logic 312. That is to say, the functional module The access request of 313 can reach the arbitration logic 312 through the control bus in the core 310 to reach the request entry of the IO resource 311.

Correspondingly, for a core that shares IO resources, the transmission path for the access request of the IO resource by the functional module in the core may include: the path from the control bus in the core to the arbitration logic; where, the functional module in the core is directed to The access request of IO resources is passed to the arbitration logic through the control bus in the core to reach the request entry of IO resources.

As an optional implementation, the functional module that sends the access request to the IO resource 311 can be located in another core particle different from the core particle 310 where the IO resource 311 is located. When the access request comes from other core particles interconnected with the core particle 310 where the IO resource 311 is located. When , the core particle from which the access request comes can be called the peer core particle. That is to say, for a core particle with shared IO resources, any other core particle interconnected with the core particle that issues an access request for the shared IO resource can be called a peer core particle.

As shown in FIG. 3 , the functional module that sends an access request to the IO resource 311 can be located in the opposite core 320 interconnected with the core 310 . For example, any functional module in the opposite core 320 can target the IO of the core 310 Resource 311 sends an access request. The functional module in the opposite core particle 320 can pass the access request to the control bus in the opposite core particle 320, thereby reaching the control bus in the core particle 310 through the logical path between the core particle 310 and the opposite end core particle 320. , and then the access request reaches the arbitration logic 312 through the control bus in the core 310, that is, reaches the request entry of the IO resource 311. For example, the functional module 321 serves as any functional module in the counterpart core 320. The dotted path 032 with an arrow in Figure 3 shows the transmission path of the access request sent by the functional module 321 to the arbitration logic 312 of the core 310. That is to say, the access request of the functional module 321 can reach the core particle 310 through the control bus in the opposite end core particle 320, the logical path between the core particle 310 and the opposite end core particle 320, and the control bus in the core particle 310. The arbitration logic 312 is the request entry to the IO resource 311 in the core 310 .

Correspondingly, for cores that share IO resources, the transmission path for access requests to IO resources from the functional modules in the counterpart core at least includes: the logical path between the counterpart core and the core where the IO resources are located; where, Access requests for IO resources from the functional modules in the end core are passed from the opposite end core to the core through this logical path. For example, the transmission path of the access request for IO resources from the functional module in the opposite end core particle may include: the path from the functional module of the opposite end core particle to the control bus in the opposite end core particle, the path from the control bus in the opposite end core particle. The path to the entrance of the logical path of the opposite end core, the logical path between the opposite end core and the core where the IO resource is located, the path from the entrance of the logical path of the core where the IO resource is located to the control bus in the core, The path from the control bus within the core to the arbitration logic within the core.

It can be seen that the embodiment of the present application provides a core particle. The core particle may include: IO resources, the IO resources are connected to package pins; arbitration logic connected to the request entry of the IO resources, the arbitration logic is at least used for , receiving access requests for the IO resources sent by multiple functional modules, and arbitrating the use rights of the IO resources for the access requests of the multiple functional modules; wherein the multiple functional modules include: in the core Functional modules, and functional modules in any pair of core particles interconnected with the core particle; the transmission path for the functional module in the opposite end core particle to send an access request to the arbitration logic at least includes: the pair A logical path between the end core particle and the core particle; wherein the access request to the functional module in the end core particle is passed from the opposite end core particle to the core particle through the logical path.

The core particle provided by the embodiment of the present application can support the functional modules in the core particle and the functional modules in any pair of core particles interconnected with the core particle, and share the IO resources of the core particle; among them, for the functions of the opposite end core particle In terms of modules, the embodiments of the present application support the transfer of access requests for IO resources from the functional modules of the opposite end core through the logical path between the opposite end core and the core where the IO resources are located. Therefore, the embodiments of the present application can realize the IO Resources are shared by functional modules of multiple cores. At the same time, the request entry of the core chip's IO resources is equipped with arbitration logic. The arbitration logic can arbitrate the use rights of IO resources for the access requests of multiple functional modules when multiple functional modules send access requests for IO resources; because the arbitration logic is In the form of hardware, the embodiments of this application can allocate the use rights of IO resources to multiple functional modules sharing IO resources through hardware arbitration, avoiding software participation in allocating the use rights of IO resources, and avoiding the problems caused by software participation. This solves the problem of low sharing efficiency of IO resources, thereby improving the sharing efficiency of IO resources on the basis of ensuring the reliability of sharing IO resources with arbitration logic in the form of hardware. Therefore, the embodiments of the present application can support the functional modules of multiple cores to share IO resources, and can improve the sharing efficiency of IO resources while ensuring the reliability of sharing of IO resources.

It should be explained that Figure 3 only shows the main design involved in sending an access request to the core in the package. The core 310 may also have other designs not shown in Figure 3, and the opposite core 320 may also have other designs. As for the other designs shown in Figure 3, the embodiments of this application do not limit the specific design conditions inside the core particles. For example, IO resources can also be set inside the counterpart core 320. The embodiment of the present application does not limit whether the IO resources of the counterpart core 320 are led out through the package, that is, it does not limit whether the IO resources of the counterpart core 320 are connected to the package lead. pin; that is to say, when the IO resources of the opposite die 320 are not connected to the package pins, the opposite die 320 can share the IO resources of the die 310 for peripheral control; when the opposite die 320 When the IO resources themselves are connected to the package pins, the IO resources of the opposite end die 320 can be used as IO resources shared by other die. At the same time, the embodiment of the present application can also support the use of the end die 320 of the die 310. IO resources for peripheral control.

It should be noted that the control bus within the core can be regarded as a communication channel for transmitting control signals and commands between different functional modules within the core; the logical paths between cores can be used to transmit control between cores. Signal. Therefore, for interconnected cores, control signals can be transmitted between interconnected cores through their respective control buses and logical paths between cores; thus, for cores that share IO resources, In other words, the access request transmitted to the IO resource from the functional module of the opposite end core can be passed from the opposite end core to the core where the IO resource is located through the logical path between the opposite end core and the core where the IO resource is located.

As an optional implementation, within the package of a chip system (such as a SOC chip), the logical paths between interconnected chips can be connected using chiplet connectors (Chiplet Links) provided on the chips. That is to say, the chiplets A connector is a type of connector that can be used to connect logical paths between interconnected chips. Furthermore, control signals can be transmitted between interconnected core chips through CFOP (Control Fabric On Package, control network in package). As an optional implementation, a core can have multiple core connectors, and the core connectors between cores can be connected one-to-one. For example, a core connector of one core can be connected to another core connector. A die connector to connect logical paths between die. In an optional implementation, IO resources can be mounted under CFOP and uniformly addressed, so that the functional module of any core can access any IO resource on any core through CFOP through the addressing address of the IO resource, for example, The access request sent by the functional module can indicate the addressing address of the IO resource that needs to be used, thereby passing it to the arbitration logic of the connection corresponding to the request entry of the IO resource under the addressing address.

In one example, taking the interconnection between four processor core chips and one IO core shown in Figure 2B, the processor core core 210, the processor core core 220, the processor core core 230 and The core connector of the processor core 240 can be connected to the core connector of the IO core 250 respectively, thereby realizing the logical path between the processor core 210 and the IO core 250 and connecting the processor. The logical path between the core die 220 and the IO die 250, the logical path connecting the processor core die 230 and the IO die 250, and the logic connecting the processor core die 240 and the IO die 250 path; and, on the logical paths that the processor core die 210, the processor core die 220, the processor core die 230, and the processor core die 240 are respectively connected to the IO core die 250, control signals can be carried out through CFOP transmission.

Based on the settings of the core chip connector and CFOP, as an optional implementation, for the access request transmitted to the IO resource from the functional module of the opposite end core, the access request can reach the core of the opposite end core through the control bus in the opposite end core. Therefore, based on the logical path connected by the core connector of the opposite core and the core connector of the core where the IO resource is located, the access request can be transmitted to the core where the IO resource is located through the CFOP arranged on the logical path. The access request can then pass through the control bus in the core where the IO resource is located and reach the arbitration logic of the core where the IO resource is located to reach the request entry of the IO resource.

For ease of understanding, as an optional implementation, Figure 4 schematically shows another example diagram of the core in the package sending an access request provided by the embodiment of the present application. As shown in Figure 3 and Figure 4, the IO of the core 310 The resource 311 is an IO resource shared between cores, and the core 310 and the opposite core 320 are respectively provided with core connectors. The core connector of the core 310 and the core connector of the opposite core 320 can A logical path is connected between the core particle 310 and the opposite end core particle 320, so that there is a path capable of information exchange between the core particle 310 and the opposite end core particle 320. That is, for interconnected die, the die's respective die connectors can connect the logical paths between the interconnected die.

In one example, the chip connector serves as a connector between chips and can be in the form of an interface. For example, the chip connector can adopt interface protocols such as UCIE (Universal Chiplet Interconnect Express) and SerDes ( Serializer-Deserializer, serializer and deserializer) and other technologies.

Based on the use of die connectors to connect logical paths between interconnected die, control signals between die can be transmitted through CFOP. CFOP can be regarded as the inside of the package of the chip system for connecting and managing between die. A bus network for communication and collaborative work, such as a bus network used to transmit control signals on logical paths between chips. For example, as shown in FIG. 4 , a CFOP can be arranged on the logical path between the core particle 310 and the opposite end core particle 320 , so that the control signal between the core particle 310 and the opposite end core particle 320 can be transmitted through the CFOP on the logical path. .

As an example, as shown in FIG. 3 and FIG. 4 , the dotted path 031 with an arrow shows the transmission path through which the access request issued by the functional module 313 reaches the arbitration logic 312 .

As an example, the transmission path shown by the dotted path 0321 with an arrow in Figure 4 may be a refined example of the transmission path shown by the dotted path 032 with an arrow in Figure 3. As shown in Figure 4, the dotted path 0321 shows The access request sent by the functional module 321 of the end core particle 320 reaches the transmission path of the arbitration logic 312 of the core particle 310 . Among them, the access request to the functional module 321 of the end core 320 can reach the core connector of the opposite end core 320 through the control bus in the opposite end core 320, thus based on the core connector of the opposite end core 320 As well as the logical path connected to the core particle connector of the core particle 310, the access request can be transmitted to the core particle connector of the core particle 310 through the CFOP arranged on the logical path; and then the access request can pass through the control bus in the core particle 310. The request entry that reaches the arbitration logic 312 of the core particle 310 is the IO resource 311 in the core particle 310 .

Correspondingly, for cores that share IO resources, the transmission path for access requests to IO resources from the functional modules in the opposite core may include: the path from the functional modules in the opposite core to the control bus in the opposite core. , the path from the control bus in the opposite core to the core connector of the opposite core, the logical path connected to the core connector of the opposite core and the core connector of the core where the IO resources are located, and where the IO resources are located The path from the core connector of the core to the control bus in the core, and the path from the control bus in the core to the arbitration logic in the core;

Among them, the access request for IO resources from the functional module in the opposite end core is transmitted from the control bus in the opposite end core to the core connector of the opposite end core, and is based on the core connection of the opposite end core. The logic path connected to the device and the core connector of the core where the IO resource is located is passed to the core connector of the core where the IO resource is located through the in-package control network set on the logic path. The core of the core where the IO resource is located The chip connector passes the access request to the chip connector of the chip where the IO resource is located through the control bus in the chip where the IO resource is located, to the arbitration logic of the chip where the IO resource is located.

In one example, taking the interconnection of two processor core chips as an example, Figure 5 schematically shows yet another example diagram of an access request sent by a packaged core chip provided by an embodiment of the present application, as shown in Figure 5 , the processor core die 510 and the processor core die 520 are interconnected, and the die connector of the processor core die 510 and the die connector of the processor core die 520 connect the processor core die 510 and The logical path between the processor core chips 520 transmits control signals through the CFOP on the logical path. In alternative implementations, both processor core die 510 and processor core die 520 may have multiple die connectors.

Devices in the processor core die 510 and the processor core die 520 may be connected through a core on-chip control bus, which may be an example of an intra-chip control bus. As shown in FIG. 5 , both the processor core die 510 and the processor core die 520 may be provided with cores (the number may be multiple) and core connectors (the number may be multiple) connected through the core on-chip control bus. Multiple), memory controller (the number may be multiple, such as memory controllers 1 to N in the processor core core 510, and memory controllers 1 to N in the processor core core 520), IO controller (the number can be multiple), and the arbiter provided at the request entrance of the IO controller. The number of arbiters in the core chip can correspond to the number of IO controllers.

As an example, the IO controller in the processor core chip 510 can be shared (the IO controller is an example of IO resources). For example, if the IO controller in the processor core chip 510 is connected to the package pin, then the process The IO controller in the processor core die 510 supports access by the memory controller in the processor core die 510 and supports access by the memory controller in the processor core die 520. At this time, the processor core die 520 It can be regarded as the peer processor core chip interconnected with the processor core chip 510 . It should be noted that the memory controller can be regarded as a functional module in the processor core chip and has the need to access the IO controller for peripheral control; the embodiment of this application also supports the processor core chip. Other types of functional modules in the module issue access requests to the IO controller. Here, the memory controller issues an access request to the IO controller as an example.

As shown in Figure 5, the memory controller of the processor core core 510 issues an access request to the IO controller in the processor core core 510, then the transmission path of the access request belongs to the internal path of the processor core core 510; such as As shown in the dotted line 501 with an arrow in Figure 5, the memory controller 1 of the processor core chip 510 sends a signal to the IO controller of the processor core chip 510 through the core on-chip control bus of the processor core chip 510. The access request is arbitrated through the arbiter of the processor core chip 510 for usage rights.

The memory controller of the processor core core 520 issues an access request to the IO controller in the processor core core 510, and the transmission path of the access request includes the external path and the internal path of the processor core core 510; as shown in Figure 5 As shown by the dotted line 502 with an arrow, the memory controller N of the processor core die 520 passes through the core on-chip control bus of the processor core die 520, the die controller of the processor core die 520, and the processor core. The die connector of the core die 510 and the core on-chip control bus of the processor core die 510 issue an access request to the IO controller of the processor core die 510, and the access request passes through the arbiter of the processor core die 510. Arbitrate rights of use.

It should be noted that Figure 5 only takes the example of the IO controller of the processor core 510 being shared. The processor core 520 can also be set with an IO controller, and the IO control of the processor core 520 The controller can also act as a shared IO controller if it is connected to the package pins, and the arbiter is set accordingly. The embodiments of this application do not limit the type, number, and location of interconnected core particles, the type, number, and location of IO resources in the core particles, as well as the logical paths between core particles, and the form of the transmission path of access requests. Any functional module in a chip (such as the core, memory controller or other functional module) can share any IO resource connected to the package pin in other chips through any path in the control network within the package; In addition, in an optional implementation, one IO resource can be connected to an arbiter to arbitrate usage rights.

As an optional implementation, the arbitration logic can be provided with a request register for identifying the functional module that sends the access request. Figure 6 illustrates an example diagram of the arbitration logic provided by the embodiment of the present application, combined with Figures 3 and 4 , and as shown in Figure 6, taking the IO resource 311 of the core 310 as an IO resource shared between cores as an example, the arbitration logic 312 is connected to the request entry of the IO resource 311, and the arbitration logic 312 can set the request register.

Among them, the request register can have a request bit, and one request bit corresponds to a functional module. That is to say, the request register stores request bits corresponding to different functional modules; among them, if the value of a request bit is set to the first value (the first A value such as 1) indicates that the functional module corresponding to the request bit of the first value requests the right to use IO resources, and then the arbitration logic can arbitrate the right to use IO resources for the functional module.

In an optional implementation, the functional module sends an IO resource access request to the arbitration logic by setting the value of the request bit corresponding to the functional module in the request register to the first value. The functional module referred to here can It is located in the core where the IO resource is located, or it can be located in the opposite core that is interconnected with the core where the IO resource is located. That is to say, the IO resource access request sent by the functional module is used to set the value of the corresponding request bit in the request register to the first value.

In an optional implementation, the functional module can send the transmission path of the access request to the IO resource, and set the request bit corresponding to the functional module to the first value in the request register of the arbitration logic to realize the transmission of the IO resource to the arbitration logic. Access request. The transmission path for the functional module located in the core where the IO resource is located to send the access request, and the transmission path for the functional module located at the opposite end core to send the access request, can refer to the description of the corresponding parts above, and will not be repeated here.

In a further optional implementation, after the function module obtains the permission to use the IO resource and ends using the IO resource, the function module can set the value of the corresponding request bit in the request register to the zeroth value (the zeroth value such as 0) , to implement the request to release IO resources. Correspondingly, the arbitration logic can also be used to receive a release request to release the IO resource sent by the functional module after the functional module obtains the permission to use the IO resource and ends using the IO resource. This release request is used to transfer the corresponding IO resource in the request register. The value of the request bit is set to the zeroth value to request the release of IO resources. It should be noted that the functional module can transmit the release request by sending the transmission path of the access request to set the value of the corresponding request bit in the request register to the zeroth value; that is, the functional module transmits the transmission path of the release request, Corresponds to the transmission path through which the functional module sends access requests to the arbitration logic.

It can be seen that the request register is set in the arbitration logic, and the value of the request register is controlled and set by the corresponding functional module, so that the arbitration logic can confirm the request of each functional module through the value of each request register nearby; that is, the function When the module requests the use of IO resources, it can set the request register corresponding to the functional module in the arbitration logic to the first value, so that the arbitration logic can confirm the functional module requesting the use of IO resources through the request register with the first value; When releasing IO resources, the functional module can clear the value of the request register corresponding to the functional module in the arbitration logic (for example, clear it to the zeroth value), so that the arbitration logic can confirm the release through the request register whose value is the zeroth value. Function module of IO resources. Through the above settings, the request register can be placed close to the arbitration logic that needs to use the value of the requester register, thereby optimizing the physical implementation.

In an implementation example, combined with the example shown in FIG. 5 , it is assumed that N memory controllers are respectively provided in the processor core core 510 and the processor core core 520 , for example, memory controller 1 to memory controller N, Then the request register can set N request bits for the N memory controllers of the processor core core 510 and set N request bits for the N memory controllers of the processor core core 520; that is to say, the embodiment of the present application A request bit can be set for each functional module that may access shared IO resources. One request bit corresponds to a functional module, and the value of the request bit indicates whether the corresponding functional module is currently requesting the use of IO resources or requesting the release of IO. The status of the resource; for example, if the value of the request bit of the function module is the first value, it means that the function module is currently requesting to use IO resources; if the value of the request bit of the function module is the zeroth value, it means that the function module is currently requesting to release IO resources or There is currently no request to use IO resources.

In a further optional implementation, the arbitration logic can set multiple request registers, and one request register is set corresponding to one functional module, so that the request bit corresponding to the functional module is set in the request register corresponding to the functional module. For example, as shown in Figure 3, Figure 4, and Figure 6, the IO resource 311 of the core 310 is used as an IO resource shared between cores, then the arbitration logic 312 can set corresponding requests for each functional module of the core 310. register, so that the request bits corresponding to the functional modules of the core chip 310 are set in the corresponding request registers; the arbitration logic 312 can set corresponding request registers for each functional module of the counterpart core core 320, so that the functions of the counterpart core core 320 The corresponding request bit of the module is set in the corresponding request register.

As an example, as shown in FIG. 5 , request bits are set for the two memory controllers of the processor core die 510 and the request bits are set for the two memory controllers of the processor core die 520 . FIG. 7A illustrates shows an example diagram of the request register provided by the embodiment of the present application. As shown in FIG. 5 and FIG. 7A , the IO controller in the processor core core 510 is shared, and the arbitration logic can be Memory controller 1 sets the request register 701, sets the request register 702 for the memory controller 2 of the processor core die 510, sets the request register 703 for the memory controller 1 of the processor core die 520, and sets the request register 703 for the processor core die 520. The memory controller 2 sets the request register 704.

The request register has the bit number of the request bit to identify different functional modules. For example, the request bits corresponding to different functional modules are different. The request register can also set the field name of the request bit. As an optional implementation, the field name can also be used as an optional reserved field, corresponding to the reserved address of the request bit. The request register can also set the numerical field of the request bit, and the request type field of the request bit (for example, the request type field can indicate the request type of the access request, and the request type can be divided into reading data or writing data). Optionally, the default value of the numeric field of the request bit can be 0x0 (corresponding to the zeroth value, for example, 0x0 represents the value 0). When the function module sends an access request, the value of the numeric field of the request bit can be set to the first value. , and when the function module sends a release request, the value of the numerical field of the request bit can be set to the zeroth value.

As shown in Figure 7A, judging from the description of the request bits corresponding to the request register 701, the request register 702, the request register 703 and the request register 704, if the value of the request bit in a certain request register is written as 1, it means that the request bit corresponds to The functional module sends an IO resource access request to the arbitration logic, and the value of the request bit is written as 0, which means that the functional module corresponding to the request bit sends an IO resource release request to the arbitration logic. For a more specific example description of the request bit, reference can be made to FIG. 7A , and the embodiment of this application will not be further elaborated.

The arbitration logic can arbitrate the usage rights of IO resources for the functional module that sends the access request. For example, the arbitration logic can arbitrate the usage rights of IO resources for the functional module whose request bit value is set to the first value. As an optional implementation, the arbitration algorithm based on which the arbitration logic performs arbitration may include but is not limited to at least one of the following: the arrival order of access requests, the priority of access requests, the permission level of the functional module that sends the access request, etc. That is to say, the arbitration logic can determine the functional module that obtains the right to use the IO resource based on at least one of the above arbitration algorithms.

As an optional implementation, when arbitrating usage rights based on the arrival order of access requests, you can follow the principle of first-come, first-served access requests to determine the functional module that obtains the right to use IO resources; that is, according to the arrival order of access requests In sequence, determine the functional module that obtains the right to use IO resources.

As an optional implementation, when arbitrating usage rights based on the priority of access requests, you can set different priorities for different access requests, so as to determine the use of IO resources in order from high to low priority of access requests. Right function module. Optionally, set different priorities for access requests, which can be set based on the type of access request. For example, different types of access requests have different priorities; the priority of access requests can be fixed or set according to actual application conditions. Make dynamic adjustments.

As an optional implementation, when arbitrating usage rights based on the permission permission level of the functional module that sends the access request, different permission permission levels can be set for different functional modules. For example, according to the type of functional module, set different permission permission levels for different types of functional modules. Different permission permission levels, thereby determining the functional modules that obtain the right to use IO resources in order from high to low permission permission levels of the functional modules.

In a further optional implementation, if at least two arbitration algorithms are used, such as the arrival order of access requests, the priority of access requests, and the permission permission level of functional modules, the embodiments of this application can be used for each arbitration algorithm. Set corresponding weights respectively (the weights set by different arbitration algorithms can be different); thus, when the arbitration logic arbitrates usage rights, if at least two arbitration algorithms are used, the arbitration results of the access requests in each arbitration algorithm can be determined, and then Combine the arbitration results of the access requests in various arbitration algorithms and the corresponding weights of each arbitration algorithm to determine the final arbitration results of the access requests; determine the functional modules that obtain the right to use IO resources based on the final arbitration results of the access requests. For example, the arbitration result can be in the form of a score, so that the arbitration logic can determine the functional module that obtains the right to use the IO resource in order of the score of the final arbitration result of the access request from high to low.

It should be noted that the arbitration algorithm used by the arbitration logic can be determined according to specific application requirements, such as chip-based system architecture and performance goals, and one or more corresponding arbitration algorithms can be selected. In the embodiment of this application, the arbitration logic There are no restrictions on the form of arbitration algorithm chosen.

After arbitration by the arbitration logic, the arbitration logic can authorize the use rights for the functional modules that have obtained the right to use the IO resources. The authorization method can be a transmission path in which the arbitration logic sends the access request through the functional module, in the opposite transmission direction of the access request, and writes the authorization information into the functional module.

For ease of explanation, as shown in Figure 4, assuming that the functional module that obtains the right to use the IO resource 311 is the functional module 313, based on the transmission path shown by the dotted line path 031, the arbitration logic 312 can pass the transmission path shown by the dotted line path 031. , writing the authorization information into the functional module in the opposite transmission direction to the access request sent by the functional module 313. For example, the arbitration logic 312 can write authorization information into the functional module 313 through the control bus within the core 310 .

As shown in FIG. 4 , assuming that the functional module that obtains the right to use the IO resource 311 is the functional module 321 of the opposite end core 320 , based on the transmission path shown by the dotted path 0321 , the arbitration logic 312 can pass the transmission path shown by the dotted path 0321 . The transmission path is the transmission direction opposite to the access request sent by the functional module 321, and the authorization information is written into the functional module 321. For example, the arbitration logic 312 can transmit the authorization information to the core connector of the core 310 through the control bus in the core 310, based on the connection between the core connector of the core 310 and the core connector of the opposite core 320. Through the connected logical path, the authorization information can be transmitted to the opposite end core 320 through the CFOP arranged on the logical path, and then the authorization information reaches the functional module 321 of the opposite end core 320 through the control bus in the opposite end core 320, so as to Write function module 321.

After the functional module obtains the authorization information of the arbitration logic, the functional module can use IO resources to transmit peripheral data by sending the transmission path of the access request. For example, the function module can use the IO resource to send peripheral data by sending the access request in the same transmission direction as the transmission path. For another example, the functional module can use the transmission path of the access request to receive the peripheral data using the IO resource in the opposite transmission direction of the access request. For information about the transmission direction that is the same as sending the access request and the transmission direction that is opposite to sending the access request, please refer to the description in the relevant parts above and will not be repeated here.

In a further optional implementation, the arbitration logic can set an address list for recording the authorized address of the functional module; at the same time, the functional module (the functional module may be located on the core where the shared IO resources are located, or may be located on the opposite core). The authorization register can be set in the module), and the address of the authorization register of the functional module can be regarded as the authorization address of the functional module. Therefore, after the arbitration logic confirms that the functional module has obtained the right to use IO resources, it can pass the authorization register of the functional module. Address, write authorization information to the authorization register of the functional module to write authorization information to the functional module. Based on this, as shown in FIG. 6 , the arbitration logic 312 may set an address list. At the same time, the functional modules in the core particle can set authorization registers. For example, the functional module 313 of the core particle 310 shown in FIG. 3 and the functional module 321 of the opposite core particle 320 can both set authorization registers. Among them, the address list set by the arbitration logic can record the address of the authorization register of each functional module. The address of the authorization register of the functional module can be regarded as the authorization address for writing authorization information to the functional module, that is, the authorization register is used to write authorization information. ; The arbitration logic can write authorization information to the authorization register of the functional module to write authorization information to the functional module.

As an optional implementation, after the arbitration logic confirms the functional module that has obtained the right to use the IO resource, it can query the address of the authorization register of the functional module in the address list based on the identity information of the functional module; furthermore, the arbitration logic can query the authorization according to the The address of the register, the transmission path for sending the access request through the function module, and the opposite transmission direction for sending the access request, write the authorization information into the authorization register of the function module.

As an optional implementation, the authorization register of the functional module can use different values to indicate whether authorization information is written to indicate whether the functional module is authorized to use the IO resource. For example, if the value of the authorization register of the functional module is the first value (such as the value 1), it means that the authorization information is written into the authorization register of the functional module, indicating that the functional module is authorized to obtain the right to use IO resources; for another example, the authorization of the functional module If the value of the register is the zeroth value (for example, value 0), it means that the authorization information has not been written into the authorization register of the functional module, indicating that the functional module has not been authorized to use the IO resource and needs to wait for authorization from the arbitration logic.

In a further optional implementation, after the functional module obtains the right to use the IO resource and ends using the IO resource, the functional module can set the value of the authorization register to the zeroth value to release the functional module's right to use the IO resource. That is to say, after the function module finishes using the IO resources, the function module can set the value of the authorization register to the zeroth value by itself to release the right to use the IO resources. In this implementation, the authorization register is set in the functional module. The value of the authorization register is set to the first value and is controlled and set by the arbitration logic. The value of the authorization register is cleared (for example, the value of the authorization register is cleared to the zeroth value). The functional model is controlled and set by itself after using the IO resources, which allows the functional module to confirm the authorization status of the functional module through the value of the authorization register.

In a possible alternative implementation, after the functional module obtains the permission to use the IO resource and ends using the IO resource, the arbitration logic can obtain a release request sent by the functional module to release the IO resource; based on the release request, the arbitration logic can pass the function The module sends the transmission path of the access request to the opposite transmission direction of the access request, and sets the value of the authorization register of the functional module to the zeroth value to release the functional module's right to use IO resources. That is to say, when the functional module ends using IO resources and the arbitration logic obtains the release request of the IO resources sent by the functional module, the arbitration logic can set the value of the authorization register of the functional module to the zeroth value to release the use of IO for the functional module. Authorization of resources to authorize other functional modules that request the right to use IO resources. In an optional implementation, based on the obtained release request, the arbitration logic can synchronously set the value of the request bit corresponding to the function module in the request register to the zeroth value.

As an example, as shown in FIG. 5 , authorization registers are set for the two memory controllers of the processor core core 510 and authorization registers are set for the two memory controllers of the processor core core 520 . FIG. 7B illustrates shows an example diagram of the authorization register provided by the embodiment of the present application. As shown in FIG. 5 and FIG. 7B , the memory controller 1 of the processor core chip 510 can set the authorization register 711 and the memory of the processor core chip 510 . The controller 2 sets the authorization register 712, the memory controller 1 of the processor core die 520 can set the authorization register 713, and the memory controller 2 of the processor core die 520 sets the authorization register 714;

Among them, the authorization register has the bit number of the authorization bit to identify the corresponding functional module. The authorization register can also set the field name of the authorization bit. The authorization register can also set the numerical field of the authorization bit, and the authorization type field (for example, the authorization type indicated by the authorization type field is divided into authorization to use IO resources to read data and/or write data). Optionally, the default value of the numeric field of the authorization bit can be 0x0 (corresponding to the zeroth value, for example, 0x0 represents the value 0). When the arbitration logic writes authorization information to the authorization register, the numeric field of the authorization bit is set to the first value. (such as value 1), and when the functional module corresponding to the authorization register releases the right to use the IO resource, the functional module or arbitration logic can set the numerical field of the authorization register to the zeroth value.

As shown in Figure 7B, judging from the description of the authorization registers corresponding to the authorization register 711, the authorization register 712, the authorization register 713 and the authorization register 714, if the value of a certain authorization register is written as 1, it means that the functional module corresponding to the authorization register is The use of IO resources is authorized, and the value of the authorization register is written as 0, which means that the right to use the IO resources of the functional module corresponding to the authorization register is released. For a more specific example description of the authorization register, reference can be made to FIG. 7B , and the embodiment of this application will not be further elaborated.

As an example, take the authorization registers being set for the two memory controllers of the processor core die 510 and the authorization registers being set for the two memory controllers of the processor core die 520 as an example. FIG. 7C exemplarily shows the application. The example diagram of the address list provided by the embodiment. The address list can be set with multiple authorization bits, and the address of the authorization register corresponding to each authorization bit. Among them, one authorization bit corresponds to one functional module; for example, as shown in Figure 7B and Figure 7C , the address list can be set: the authorization bit and the corresponding address of the memory controller 1 of the processor core die 510 are the address of the authorization register 711, and the authorization bit and the corresponding address of the memory controller 2 of the processor core die 510 are The address of the authorization register 712, the authorization bit of the memory controller 1 of the processor core die 520, and the corresponding address are the addresses of the authorization register 713, and the authorization bit and the corresponding address of the memory controller 2 of the processor core die 520 are The address of authorization register 714.

It should be noted that when the functional module uses IO resources to send and receive peripheral data, the rate at which the peripheral sends and receives data is lower than the rate at which the functional module sends and receives data. Therefore, after the IO resource (such as IO controller) sends a data processing request to the peripheral, , it takes a long time to wait for the peripheral to return data. During the period of waiting for the peripheral to return data, the functional module can maintain the right to use the IO resource (such as the controller); furthermore, when the IO resource (such as the IO controller) obtains After receiving the data returned by the peripheral device, the data returned by the peripheral device can be sent to the function module. In the above process, the function module uses the IO resource to send data to the peripheral by sending the access request in the same transmission direction as the access request; and, the function module sends the access request in the opposite direction by sending the access request in the transmission path. The transmission direction, receives the data returned by the peripheral device.

After the function module obtains the data returned by the peripheral device, it can continue to use the IO resources for the next data transmission with the peripheral device, or it can end using the IO resources. When the functional module finishes using the IO resources, the functional module can request to release the IO resources. For example, the functional module sets the value of the corresponding request bit in the request register to the zeroth value to send a release request to the arbitration logic to release the IO resources. , and the functional module or arbitration logic releases the functional module's right to use IO resources by clearing the value of the authorization register of the functional module. After releasing the right to use the IO resources of the functional module, the arbiter can confirm the next functional module that obtains the right to use the IO resources based on the arbitration algorithm, and authorize the functional module; for example, the arbiter can use the arbitration algorithm to Arbitrate the right to use IO resources for the functional module corresponding to the request bit of 1, thereby confirming the next functional module that obtains the right to use IO resources, and set the value of the authorization register of the functional module to 1.

In order to facilitate understanding of the timing mechanism in which multiple functional modules compete for IO resources through arbitration logic, taking the timing of four functional modules competing for the same IO resource as an example, Figure 8 exemplarily shows the competition timing of IO resources provided by the embodiment of the present application. Referring to Figure 8, the access request 811 sent by the functional module 810 reaches the arbiter of the IO resource first. At this time, there are no access requests from other functional modules (such as functional modules 820, 830 and 840), so the functional module 810 The authorization information 812 returned by the arbiter will be obtained; subsequently, the arbiter simultaneously received the access request 821 sent by the functional module 820, the access request 831 sent by the functional module 830, and the access request 841 sent by the functional module 840. Since the IO resource is currently It is occupied by the access request 811 of the functional module 810, so subsequent access requests sent by other functional modules need to wait for authorization. When the process of transmitting data between the access request 811 and the peripheral device ends, the arbiter can use an arbitration algorithm such as a round-robin scheduling algorithm to cause the access request 821 sent by the functional module 820 to obtain the authorization information 822, and so on, so that the access request 821 sent by the functional module 830 in turn obtains the authorization information 822. The access request 831 obtains authorization information 832, and the access request 841 sent by the functional module 840 obtains authorization information 842.

It should be noted that the example in Figure 8 is based on the principle of first-come, first-served access requests and round-robin scheduling of access requests arriving at the same time to arbitrate the use rights of IO resources. This application implements The example does not limit the arbitration algorithm used by the arbiter, which can be at least one of multiple algorithms such as first-in-first-out, round-robin scheduling, and priority. Among them, round-robin scheduling is an arbitration strategy based on round-robin allocation of resources to ensure that each requestor has the opportunity to access resources.

In one example, taking a processor core chip as an example, the memory controller on the processor core chip needs to access the DIMM on the motherboard through the I3C interface (an example of IO resources). If the processor core chips use their own I3C interface, multiple sets of I3C interfaces need to be introduced on the package, and the DIMM on the motherboard also needs to be connected to multiple I3C interfaces at the same time, which will lead to a very complicated connection relationship. Using the solution provided by the embodiment of this application, the I3C interface on some processor core chips can be led out to the package, so that multiple DIMMs on the motherboard can connect to the I3C interfaces on some processor core chips, and can be connected through this The IO resource sharing solution provided by the application embodiment enables all processor core chips to access DIMMs, thereby greatly simplifying packaging design and motherboard wiring design.

The solution provided by the embodiment of this application uses arbitration logic in the form of hardware to arbitrate the usage rights of functional modules that access IO resources. It can avoid software participation and reduce IO resource sharing caused by software participation when arbitrating and allocating the usage rights of IO resources. It solves the problem of low efficiency, thereby improving the sharing efficiency of IO resources on the basis of ensuring the reliability of IO resource sharing. For example, the embodiment of the present application can initialize the contents of the request register, authorization register and address list in software during the initialization phase, thereby configuring the environment for different functional modules to use IO resources; and then subsequently use the IO resources when the functional module requests the use of external resources. When performing data interaction, the authorization and release of usage rights of IO resources can be automatically completed directly based on the contents of the configured request register, authorization register and address list through functional modules, arbiters and corresponding transmission paths without software intervention. And the functional modules that use IO resources use IO resources in a configured environment (corresponding to the configured contents of the request register, authorization register and address list of the functional module), improving the sharing efficiency of IO resources.

Based on the core chip for realizing IO resource sharing provided by the embodiment of the present application, the embodiment of the present application also provides an IO resource sharing method. As an optional implementation, FIG. 9 exemplarily shows an optional flow chart of the IO resource sharing method provided by the embodiment of the present application. The method flow can be applied to the core particle, for example, applied to the arbitration logic of the core particle. The parts described below that are related to the previous part may be cross-referenced. Referring to Figure 9, the method flow may include the following steps.

In step S910, IO resource access requests sent by multiple functional modules are received.

Wherein, the plurality of functional modules include: functional modules in the core grain, and functional modules in any pair of end core grains interconnected with the core grain; the functional modules in the opposite end core grain communicate to all The transmission path for the access request sent by the arbitration logic at least includes: a logical path between the opposite end core particle and the core particle; wherein the access request for the functional module in the opposite end core particle passes through the logical path, Passed from the opposite end core particle to the core particle.

In step S920, the right to use the IO resource is arbitrated for the access requests of the multiple functional modules.

In an optional implementation, the embodiment of the present application can determine the functional module that obtains the right to use the IO resource based on at least one of the following arbitration algorithms: the arrival order of the access request, the priority of the access request, and the functional module that sends the access request. The degree of permission granted;

Among them, when the use rights are arbitrated based on the arrival order of the access requests, the functional module that obtains the use rights of the IO resource is determined according to the order in which the access requests arrive; when the use rights are arbitrated based on the priority of the access requests, the use rights are determined according to the order in which the access requests arrive. The priority of the access request is in order from high to low to determine the functional module that obtains the right to use the IO resource; when the use right is arbitrated based on the permission level of the functional module that sends the access request, the use right is arbitrated according to the permission level of the functional module. In order from high to low, determine the functional module that obtains the right to use the IO resource.

In a further optional implementation, if at least two arbitration algorithms are used, the arbitration results of the access requests in each arbitration algorithm are determined; combined with the arbitration results of the access requests in each arbitration algorithm and the corresponding weights of each arbitration algorithm, Determine the final arbitration result of the access request; determine the functional module that obtains the right to use the IO resource according to the final arbitration result of the access request.

In step S930, in order to obtain the right to use the IO resource, the functional module is authorized to use the IO resource, so that the functional module that obtains the right to use the IO resource uses the IO resource to interact with peripheral devices.

In an optional implementation, the embodiment of the present application can send the transmission path of the access request through the functional module to send the access request in the opposite transmission direction, and write the authorization information into the functional module that obtains the right to use the IO resource, so as to obtain the IO resource. The functional module of resource usage rights authorizes the usage rights of the IO resources.

In a further optional implementation, the embodiment of the present application can also obtain the release request to release the IO resource sent by the functional module after the functional module obtains the usage rights of the IO resource and ends using the IO resource, so as to release the release request based on the release request. The functional module has the right to use the IO resources; or, after the functional module obtains the right to use the IO resources and ends using the IO resources, the functional module releases the right to use the IO resources on its own.

Embodiments of the present application also provide a chip system (for example, a system on a chip), which includes a plurality of interconnected core particles, and some or all of the core particles among the plurality of core particles are core particles provided by embodiments of the present application.

Embodiments of the present application also provide an electronic device, such as a terminal device or a server device. The electronic device may include a chip system (such as a system-on-chip) provided by embodiments of the present application, and/or a chip provided by embodiments of the present application.

The above describes multiple embodiment solutions provided by the embodiments of the present application. The optional methods introduced in each embodiment solution can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible embodiment solutions. These can be considered as embodiments disclosed and disclosed in the embodiments of this application.

Although the embodiments of the present application are disclosed as above, the present application is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the protection scope of the present application shall be subject to the scope defined by the claims.

Claims (23)

1. A core particle, characterized in that, the core particle includes: IO resources, the IO resources are connected to package pins; Arbitration logic connected to the request entry of the IO resource. The arbitration logic is at least used to receive access requests for the IO resources sent by multiple functional modules and arbitrate the IO for the access requests of the multiple functional modules. rights to use resources; Wherein, the plurality of functional modules include: functional modules in the core grain, and functional modules in any pair of end core grains interconnected with the core grain; the functional modules in the opposite end core grain communicate to all The transmission path for the access request sent by the arbitration logic at least includes: a logical path between the opposite end core particle and the core particle; wherein the access request for the functional module in the opposite end core particle passes through the logical path, Passed from the opposite end core particle to the core particle. 2. The core particle according to claim 1, wherein the core particle further includes: a core particle connector; Wherein, the core particle connector of the opposite end core particle and the core particle connector of the core particle connect the logical path between the opposite end core particle and the core particle, and the logical path is provided with a useful Control network within the package that transmits control signals; The access request to the functional module in the end core is based on the core connector of the end core and the logical path connected by the core connector of the core through the package provided on the logical path. The internal control network is transmitted from the opposite core particle to the core particle. 3. The core particle according to claim 2, wherein the core particle further includes: a control bus disposed inside the core particle; Wherein, the transmission path for the functional module in the opposite end core to send the access request to the arbitration logic also includes: the path from the functional module in the opposite end core to the control bus in the opposite end core, The path from the control bus in the opposite end core to the core connector of the opposite end core, the path from the core connector of the core to the control bus in the core, the core The path from the control bus within the chip to the arbitration logic within the chip; The access request to the functional module in the opposite end core is transmitted from the control bus in the opposite end core to the core connector of the opposite end core, and is based on the core of the opposite end core. The connector and the logic path connected by the core element connector of the core element are passed to the core element connector of the core element through the in-package control network provided on the logic path. The core element connection of the core element is The controller passes the access request passed to the core connector of the core to the arbitration logic through the control bus within the core. 4. The core particle according to claim 3, characterized in that the transmission path for the functional module in the core particle to send an access request to the arbitration logic includes: a control bus in the core particle to the arbitration logic. path; wherein, the access request of the functional module in the core particle is passed to the arbitration logic through the control bus in the core particle. 5. The core particle according to claim 1, characterized in that the arbitration logic is provided with a request register, the request register has a request bit, and one request bit corresponds to a functional module; the IO sent by the functional module The resource access request is at least used to set the value of the corresponding request bit in the request register to the first value. 6. The core according to claim 5, characterized in that the arbitration logic is further configured to receive the A release request sent by the functional module to release the IO resource, the release request being used to set the value of the corresponding request bit in the request register to the zeroth value; Wherein, the transmission path through which the functional module transmits the release request corresponds to the transmission path through which the functional module sends an access request to the arbitration logic. 7. The core according to claim 6, wherein the request bit includes: 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; wherein, the request bit The default value of the bit value field is the zeroth value, and the type of access request indicated by the request type field is divided into read data and write data. 8. The core according to any one of claims 5-7, characterized in that the number of the request registers is multiple, and one functional module corresponds to one request register, and the request bit corresponding to the functional module is set in the corresponding in the request register. 9. The core according to claim 1, wherein the arbitration logic is used to arbitrate the use rights of the IO resources for the access requests of the multiple functional modules including: Determine the functional module that obtains the right to use the IO resource based on at least one of the following arbitration algorithms: the arrival order of access requests, the priority of access requests, and the permission level of the functional module that sends the access request; Wherein, when the usage rights are arbitrated based on the arrival sequence of access requests, the functional module that obtains the usage rights of the IO resource is determined according to the arrival sequence of the access requests; When arbitrating usage rights based on the priority of the access request, determine the functional module that obtains the right to use the IO resource in order from high to low priority of the access request; When the use rights are arbitrated based on the permission permission level of the functional module that sends the access request, the functional module that obtains the right to use the IO resource is determined in order of the permission permission level of the functional module from high to low. 10. The core particle according to claim 9, characterized in that the arbitration logic is used to determine the functional module to obtain the right to use the IO resource based on at least one of the following arbitration algorithms: If at least two arbitration algorithms are used, determine the arbitration results of the access request in each arbitration algorithm; determine the final arbitration result of the access request based on the arbitration results of the access request in each arbitration algorithm and the corresponding weight of each arbitration algorithm; According to the final arbitration result of the access request, the functional module that obtains the right to use the IO resource is determined. 11. The core according to claim 1, wherein the arbitration logic is further configured to authorize the right to use the IO resource for a functional module that obtains the right to use the IO resource. 12. The core according to claim 11, wherein the arbitration logic is used to, in order to obtain the functional module of the right to use the IO resource, authorizing the right to use the IO resource includes: For the functional module that obtains the right to use the IO resource, the authorization information is written into the functional module in the opposite transmission direction of the access request through the transmission path of the functional module. 13. The core according to claim 12, characterized in that the functional module that obtains the right to use the IO resource uses the IO resource to transmit peripheral data by sending a transmission path of the access request; Wherein, the functional module that obtains the right to use the IO resource uses the transmission path of the access request to send the access request in the same transmission direction, and uses the IO resource to send peripheral data; and, the obtainment of the The functional module with the right to use IO resources uses the transmission path of the access request to send the access request in the opposite transmission direction, and uses the IO resources to receive peripheral data. 14. The core according to any one of claims 12-13, characterized in that the arbitration logic is provided with an address list, and the address list records the address of the authorization register of the functional module; wherein, the authorization of the functional module The register is used to write authorization information. 15. The core according to claim 14, wherein the arbitration logic is used to send an access request through a transmission path of the functional module for the functional module that obtains the right to use the IO resource. In the opposite direction of transmission, writing authorization information to functional modules includes: Query the address of the authorization register of the functional module in the address list according to the identity information of the functional module that has obtained the right to use the IO resource; According to the address of the queried authorization register, the transmission path of the access request is sent through the functional module to the opposite transmission direction of the access request, and the authorization information is written into the authorization register of the functional module. 16. The core according to claim 15, wherein if the value of the authorization register of the functional module is the first value, it means that authorization information is written into the authorization register of the functional module, indicating that the functional module obtains the IO resource. authorization of the use right; if the value of the authorization register of the functional module is the zeroth value, it means that the authorization information has not been written into the authorization register of the functional module, indicating that the functional module has not been authorized to use the IO resource. 17. The core according to claim 16, characterized in that, after the functional module obtains the usage rights of the IO resources and ends using the IO resources, it sets the value of the corresponding authorization register to the zeroth value; or, The arbitration logic obtains a release request sent by the functional module to release the IO resource after the functional module obtains the usage rights of the IO resource and ends using the IO resource; the arbitration logic is based on the Release the request, send the access request through the transmission path of the functional module in the opposite transmission direction of the access request, and set the value of the authorization register of the functional module to the zeroth value to release the functional module from using the IO Rights to use resources. 18. The core according to any one of claims 15-17, characterized in that the address list is provided with multiple authorization bits, and the address of the authorization register corresponding to each authorization bit, and one authorization bit corresponds to one functional module. ; The authorization register is set with the bit number of the authorization bit, the field name of the authorization bit, the numerical field of the authorization bit, and the authorization type field; wherein, the default value of the numerical field of the authorization bit is the zeroth value, and the authorization bit The authorization type indicated by the type field is divided into authorization to use the IO resource to read data and/or write data. 19. An IO resource sharing method, characterized in that it is applied to the core particle according to any one of claims 1-18, and the method includes: Receive IO resource access requests sent by multiple functional modules; Arbitrate the use rights of the IO resources for the access requests of the multiple functional modules; In order to obtain the use right of the IO resource, the functional module is authorized to use the IO resource, so that the functional module that obtains the use right of the IO resource uses the IO resource to interact with peripheral devices. 20. The method according to claim 19, wherein the arbitrating the usage rights of the IO resources for the access requests of the multiple functional modules includes: Determine the functional module that obtains the right to use the IO resource based on at least one of the following arbitration algorithms: the arrival order of access requests, the priority of access requests, and the permission level of the functional module that sends the access request; Wherein, when the usage rights are arbitrated based on the arrival sequence of access requests, the functional module that obtains the usage rights of the IO resource is determined according to the arrival sequence of the access requests; When arbitrating usage rights based on the priority of the access request, determine the functional module that obtains the right to use the IO resource in order from high to low priority of the access request; When the use rights are arbitrated based on the permission permission level of the functional module that sends the access request, the functional module that obtains the right to use the IO resource is determined in order of the permission permission level of the functional module from high to low. 21. The method of claim 19, further comprising: After the functional module obtains the usage rights of the IO resources and ends using the IO resources, obtain a release request sent by the functional module to release the IO resources; based on the release request, release the functional module's right to use the IO resources; Or, after the function module obtains the right to use the IO resource and ends using the IO resource, the functional module releases the right to use the IO resource. 22. A system on a chip, characterized in that it includes a plurality of interconnected core particles, and some or all of the plurality of core particles are the core particles according to any one of claims 1-18. 23. An electronic device, characterized by comprising the system-on-chip according to claim 22, and/or the core particle according to any one of claims 1-18.