Virtual channel distribution method and device of network-on-chip, equipment, medium and product

Abstract

The embodiment of the invention provides a virtual channel distribution method and device for a network-on-chip, equipment, a medium and a product, and the method comprises the steps: obtaining a network connection relation among a plurality of component modules in the network-on-chip, at least one transport stream and channel configuration information corresponding to the transport stream; the transport stream characterizes an access connection from one initiating network interface to one target network interface in the plurality of component modules; the method comprises the steps of determining a plurality of virtual channel types corresponding to a transport stream based on channel configuration information corresponding to the transport stream, performing channel loop inspection on the transport stream under the corresponding plurality of virtual channel types based on a network connection relationship, and performing virtual channel allocation on the transport stream based on an inspection result. And obtaining virtual channel configuration information corresponding to the at least one component module through which the transport stream flows under the corresponding multiple target virtual channel types. In this way, automatic allocation and loop check can be carried out on multiple virtual channels of a single transport stream in the design generation stage of the network-on-chip.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of on-chip network technology, and particularly to a method, apparatus, device, medium, and product for virtual channel allocation in on-chip networks. Background Technology

[0002] Network on Chip (NoC) is widely used in modern digital integrated circuits as an important architecture for achieving efficient interconnection in multi-core systems. NoC enables data exchange between multiple processing units and / or memory controllers by constructing a communication network composed of routers and links. In NoC, Virtual Channel (VC) technology is used to achieve traffic isolation, avoid deadlock, and improve resource utilization.

[0003] In related technologies, virtual channels are typically allocated to transport streams based on preset rules or simple priority strategies. However, with the rapid increase in the complexity of multi-core systems, the number of component modules in on-chip networks can increase by tens of thousands. If virtual channels are allocated solely based on preset rules or simple priority strategies, unreasonable occupation of virtual channel resources can easily occur when facing complex connection relationships and concurrent access, leading to system performance degradation or even deadlock problems. Summary of the Invention

[0004] In view of this, the present disclosure provides at least one method, apparatus, device, medium, and product for virtual channel allocation in a network-on-a-chip.

[0005] The technical solution of this disclosure embodiment is implemented as follows: This disclosure provides a method for allocating virtual channels in an on-chip network, including: Obtain the network connection relationship between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and the channel configuration information corresponding to each transport stream; the transport stream represents the access connection from one of the multiple component modules to one of the multiple component modules to a target network interface; Based on the channel configuration information corresponding to the transport flow, multiple virtual channel types corresponding to a transport flow are determined. Based on the network connection relationship, channel loop checks are performed on the transport flow under the corresponding multiple virtual channel types. Based on the check results, virtual channels are allocated to the transport flow, and the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types is obtained.

[0006] This disclosure provides an on-chip network virtual channel allocation device, comprising: The first acquisition module is used to acquire the network connection relationship between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and the channel configuration information corresponding to each transport stream; the transport stream represents the access connection from one of the multiple component modules to one of the multiple component modules to a target network interface. The inspection and allocation module is used to determine multiple virtual channel types corresponding to a transport flow based on the channel configuration information corresponding to the transport flow, and to perform channel loop checks for the transport flow under the corresponding multiple virtual channel types based on the network connection relationship. Based on the inspection results, virtual channel allocation is performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types.

[0007] This disclosure provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0008] This disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0009] This disclosure provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the above-described method.

[0010] In this embodiment, the network connection relationships between multiple component modules in the on-chip network (BTC) are first obtained, along with at least one transport flow in the BTC and the channel configuration information corresponding to each transport flow. Then, based on the channel configuration information corresponding to the transport flow, multiple virtual channel types corresponding to that transport flow are determined. Based on the network connection relationships, channel loop checks are performed on the transport flow under each virtual channel type. By checking for loops, it is determined whether the current virtual channel type can be used, thus avoiding deadlock. Finally, virtual channels are allocated to the transport flow based on the check results, obtaining the virtual channel configuration information of the component modules through which the transport flow flows under multiple target virtual channel types. This allows for automatic allocation and loop checking of virtual channels during the BTC design and generation phase, allocating multiple types of virtual channels to a single transport flow. This not only improves the efficiency of virtual channel configuration but also identifies potential deadlock risks caused by loops in advance, enabling timely avoidance of deadlock problems during the design phase. This eliminates the need to significantly increase deadlock avoidance logic during runtime, thereby reducing the hardware cost and power consumption of the BTC and improving its overall performance.

[0011] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this disclosure. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0013] Figure 1 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 1 ; Figure 2 A schematic diagram of the topology of an on-chip network provided in an embodiment of this disclosure; Figure 3 A schematic diagram of the composition structure of a computer system provided in this embodiment of the disclosure. Figure 1 ; Figure 4 A schematic diagram of a NoC deadlock scenario provided in an embodiment of this disclosure; Figure 5 A schematic diagram illustrating a method for generating HDL code for instantiating component modules provided in this embodiment of the disclosure; Figure 6 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 2 ; Figure 7 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 3 ; Figure 8 This is a schematic diagram illustrating how configuring different VC types for multiple transport streams to solve the NoC deadlock problem, as provided in an embodiment of this disclosure. Figure 9 A schematic diagram illustrating the implementation flow of a method for checking and avoiding NoC synthesis problems in single-path multi-VC during the design generation phase, as provided in this embodiment of the disclosure; Figure 10 A schematic diagram of the composition structure of a computer system provided in this embodiment of the disclosure. Figure 2 ; Figure 11 A schematic diagram of the composition structure of a virtual channel allocation device for an on-chip network provided in an embodiment of this disclosure; Figure 12 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this disclosure. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this disclosure. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0015] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0016] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this disclosure.

[0018] This disclosure provides a method for allocating virtual channels in a network-on-a-chip. This method can be executed by a computer device, which may include, but is not limited to, at least one of a server, personal computer, smartphone, tablet computer, etc. Figure 1 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 1 ,like Figure 1 As shown, the method includes the following steps S101 to S102: Step S101: Obtain the network connection relationship between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and the channel configuration information corresponding to each transport stream; the transport stream represents the access connection from one of the multiple component modules to one of the multiple component modules to a target network interface.

[0019] Here, the on-chip network can include multiple component modules. Component modules are hardware nodes in the on-chip network used for data transmission, and may include, but are not limited to, network interface units, routers, low-power modules, or connectivity modules.

[0020] The network connectivity relationships between multiple component modules in an on-chip network define the connection topology between these modules, and may include at least one of the following: connectivity between the component modules, upstream and downstream connections, etc. In implementation, this network connectivity relationship can be manually configured by the user or extracted from the on-chip network's topology information; this disclosure does not limit this approach.

[0021] A transport stream refers to an access connection that sends data from one network interface unit (INIU) in an on-chip network (NIC) to another network interface unit (INIU) (target network interface). In an on-chip NIC, the Initiate Network Interface Unit (INIU) and the Target Network Interface Unit (INIU) are component modules connecting processing units (such as central processing units, graphics processing units, etc.) and routers, respectively serving as the initiator and destination of data transmission. The Initiate Network Interface, located between the processing unit and the router, is responsible for packaging the data generated by the processing unit into data packets and sending them to the network. The Target Network Interface, located between the router and the processing unit, is responsible for receiving data packets, disassembling them, and transmitting them to the target processing unit.

[0022] Each transport flow corresponds to a specific data transmission path, and each transport flow can be assigned corresponding channel configuration information. The channel configuration information corresponding to a transport flow can be used to define the number of virtual channel types used by the transport flow and / or multiple virtual channel types used. In a transport flow from an initiating network interface to a target network interface, it can be configured to use more than two virtual channel types, that is, more than two virtual channels can be assigned to each transport flow.

[0023] Each virtual channel type represents a group of virtual channels with the same characteristics. For example, multiple virtual channels with the same initiating network interface can be classified into the same virtual channel type; multiple virtual channels with the same destination network interface can be classified into the same virtual channel type; or multiple virtual channels used to transmit the same type of data packets can be classified into the same virtual channel type. The virtual channel type corresponding to a transport flow can be determined based on the traffic characteristics of that transport flow. For example, multiple transport flows initiated from the same initiating network interface can correspond to the same virtual channel type. Similarly, multiple transport flows destined for the same destination network interface can correspond to the same virtual channel type. Furthermore, multiple transport flows transmitting the same type of data packets can correspond to the same virtual channel type.

[0024] It should be noted that multiple transport flows with the same traffic characteristics can be assigned multiple virtual channel types. Each transport flow can then use multiple virtual channel types, and a virtual channel can be assigned to each transport flow under each of these multiple virtual channel types, resulting in multiple virtual channels corresponding to that transport flow. For example, multiple transport flows initiated by network interface 0 can correspond to virtual channel type 01 and virtual channel type 02, and corresponding virtual channels can be configured for these multiple transport flows under virtual channel type 01 and virtual channel type 02 respectively.

[0025] The configuration information of at least one transport stream in the on-chip network and the channel corresponding to each transport stream can be manually configured by the user or obtained by analyzing the data transmission requirements of the on-chip network. This disclosure does not limit this.

[0026] In some implementations, the network connectivity relationships between multiple component modules in the on-chip network (BTC), at least one transport flow in the BTC, and the channel configuration information corresponding to each transport flow can be extracted from the user-input BTC architecture configuration. For example, in a BTC topology, the initiating network interface 0 may connect to router 0, which in turn connects to router 3, ultimately reaching the target network interface 2. Each such connection path constitutes a transport flow, and each transport flow is configured with corresponding channel configuration information. By extracting information from the user-input BTC architecture configuration and constructing transport flows, all transport flows in the BTC can be constructed, providing foundational data for subsequent channel loop checks and virtual channel allocation.

[0027] Step S102: Based on the channel configuration information corresponding to the transport flow, determine multiple virtual channel types corresponding to a transport flow, and based on the network connection relationship, perform channel loop checks for the transport flow under the corresponding multiple virtual channel types. Based on the check results, allocate virtual channels for the transport flow, and obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types.

[0028] Here, a transport stream can be configured to use two different virtual channel types, each representing a set of independent logical channels. Configuring multiple virtual channel types for a transport stream can effectively break loop dependencies and prevent deadlocks. Depending on the specific needs and performance requirements of the transport stream, different numbers of virtual channel types can be selected, such as one, two, or more.

[0029] In some implementations, multiple virtual channel types corresponding to a transport stream can be obtained by parsing the channel configuration information corresponding to that transport stream. For example, if the channel configuration information includes the number of target virtual channel types corresponding to the transport stream, multiple target virtual channel types equal to that number can be assigned to the transport stream according to a preset virtual channel type allocation method. Alternatively, if the channel configuration information includes multiple target virtual channel types corresponding to the transport stream, these multiple target virtual channel types can be extracted from the channel configuration information.

[0030] To perform a channel loop check for a transport flow under a corresponding virtual channel type, it means checking whether there is a loop between the physical channel through which the transport flow flows and the physical channels through which other transport flows of the corresponding virtual channel type flow.

[0031] Understandably, for at least one transport stream corresponding to the same virtual channel type, if there are loops between the physical channels through which the at least one transport stream flows, it indicates that there may be a risk of deadlock due to ring dependency during the data transmission process of the at least one transport stream using a virtual channel of that virtual channel type. If there are no loops between the physical channels through which each transport stream corresponding to the same virtual channel type flows, it indicates that there will be no ring dependency during the data transmission process of each transport stream using a virtual channel of that virtual channel type, and therefore no risk of deadlock.

[0032] In practice, those skilled in the art can use any suitable method to perform channel loop checks on the transmission stream under the corresponding multiple virtual channel types, and the embodiments of this disclosure are not limited in this regard.

[0033] In some implementations, it is possible to simultaneously check, for each virtual channel type corresponding to the transport stream, whether there is a loop between the physical channel through which the transport stream flows and the physical channel through which other transport streams corresponding to that virtual channel type flow.

[0034] In some implementations, for each virtual channel type corresponding to the transport stream, it can be checked in turn whether there is a loop between the physical channel through which the transport stream flows and the physical channel through which other transport streams corresponding to that virtual channel type flow.

[0035] In some implementations, each virtual channel type corresponding to the transport stream can be traversed sequentially to obtain at least one inspected transport stream under that virtual channel type, and check whether there is a loop between the physical channel through which the transport stream flows and the physical channel through which the at least one inspected transport stream flows.

[0036] In some implementations, if there are no loops between the physical channel through which the transport flow passes and the physical channels through which other transport flows of the same virtual channel type, that is, if the inspection result of the transport flow under the virtual channel type indicates that there are no loops, then the virtual channel type is determined as a target virtual channel type corresponding to the transport flow, and a virtual channel is allocated for the transport flow under the virtual channel type, thereby obtaining the virtual channel configuration information of at least one component module through which the transport flow passes under the virtual channel type.

[0037] In some implementations, if there is a loop between the physical channel through which the transport flow passes and the physical channel through which any other transport flow of the same virtual channel type passes, that is, if the inspection result corresponding to the transport flow under the virtual channel type indicates the existence of a loop, then the virtual channel allocation for the transport flow under the virtual channel type will not be performed, the loop will be reported, and the virtual channel allocation process of the on-chip network will end.

[0038] In some implementations, if the inspection result corresponding to the transport stream indicates the existence of a loop, a new available virtual channel type is assigned to the transport stream as the new virtual channel type corresponding to the transport stream, and it is checked whether there is a loop between the physical channel through which the transport stream flows and the physical channel through which other transport streams corresponding to the new virtual channel type flow.

[0039] The virtual channel configuration information may include virtual channels allocated to component modules. In implementation, those skilled in the art can allocate appropriate virtual channel configuration information to each component module according to the actual virtual channel architecture adopted. This disclosure does not limit this.

[0040] In some implementations, the on-chip network adopts a unified and immutable virtual channel architecture. This means that virtual channels of the same type are uniform and immutable throughout the entire on-chip network, allowing the allocation of virtual channels of the corresponding type to each component module through which the transmission flow passes. For example, if a transmission flow sequentially passes through initiating network interface 0, router 0, router 3, and destination network interface 2, and this transmission flow corresponds to virtual channel type 1, then virtual channel 1 can be allocated to initiating network interface 0, router 0, router 3, and destination network interface 2. Thus, during data transmission, virtual channel 1 can be used to sequentially access initiating network interface 0, router 0, router 3, and destination network interface 2, thereby realizing the transmission flow.

[0041] In some implementations, the on-chip network adopts a virtual channel architecture based on Next-hop-Output Queueing (NOQ). In the NOQ-based virtual channel architecture, virtual channels are divided into input virtual channels (IVC) and output virtual channels (OVC). Thus, the virtual channel configuration information can include input virtual channels and / or output virtual channels. According to the virtual channel type corresponding to the transport flow, the corresponding input virtual channel and / or output virtual channel can be allocated to each component module through which the transport flow passes. In this way, by identifying the input virtual channel and / or output virtual channel corresponding to each component module under the virtual channel type hop by hop, each component module through which the transport flow passes can be accessed sequentially, thereby realizing the transport flow.

[0042] In this embodiment, the network connection relationships between multiple component modules in the on-chip network (BTC) are first obtained, along with at least one transport flow in the BTC and the channel configuration information corresponding to each transport flow. Then, based on the channel configuration information corresponding to the transport flow, multiple virtual channel types corresponding to that transport flow are determined. Based on the network connection relationships, channel loop checks are performed on the transport flow under each virtual channel type. By checking for loops, it is determined whether the current virtual channel type can be used, thus avoiding deadlock. Finally, virtual channels are allocated to the transport flow based on the check results, obtaining the virtual channel configuration information of the component modules through which the transport flow flows under multiple target virtual channel types. This allows for automatic allocation and loop checking of virtual channels during the BTC design and generation phase, allocating multiple types of virtual channels to a single transport flow. This not only improves the efficiency of virtual channel configuration but also identifies potential deadlock risks caused by loops in advance, enabling timely avoidance of deadlock problems during the design phase. This eliminates the need to significantly increase deadlock avoidance logic during runtime, thereby reducing the hardware cost and power consumption of the BTC and improving its overall performance.

[0043] In some embodiments, the method may further include generating on-chip network hardware code based on the virtual channel configuration information corresponding to each component module through which each transport stream flows. This allows for the early detection and avoidance of deadlock issues during the design phase, ensuring that there is no risk of deadlock between the physical channels through which each transport stream flows in the generated on-chip network hardware code.

[0044] In some embodiments, the channel configuration information includes at least one of the following: number of target types, multiple target virtual channel types; the number of target types represents the number of target virtual channel types corresponding to the transport stream.

[0045] Multiple target virtual channel types refer to different virtual channel types defined for the same transport flow. For example, in a network-on-a-chip, a transport flow may use both request-type virtual channels and response-type virtual channels simultaneously, for sending request packets and receiving response packets, respectively. By assigning multiple target virtual channel types to a transport flow, finer-grained flow control and isolation can be achieved. This partitioning method helps avoid interference and deadlock problems between different packets.

[0046] By configuring the number of target virtual channel types and / or multiple target virtual channel types in the channel configuration information, the virtual channel types required by the transport flow can be precisely defined. This allows for obtaining the virtual channel configuration information of the component modules through which the transport flow passes under multiple target virtual channel types, facilitating the automatic identification and avoidance of potential deadlock risks during the design and development phase. In this way, the system can flexibly configure the number and / or types of virtual channels according to actual needs, effectively improving the NoC's ability to handle deadlock and synthesis problems during the design phase, thereby enhancing the overall performance and stability of the NoC.

[0047] In the above embodiments, the channel configuration information includes the number of target types or multiple target virtual channel types, thereby providing more explicit constraints for allocating different types of virtual channels to the transport flow. This allows the required number or specific types of virtual channels for the transport flow to be defined during the design phase, which helps improve the automation and accuracy of subsequent virtual channel allocation.

[0048] In some embodiments, the channel configuration information includes the number of target types.

[0049] Based on the inspection results, virtual channels are allocated for the transport flow, and the virtual channel configuration information corresponding to at least one component module through which the transport flow passes under the corresponding multiple target virtual channel types is obtained. This may include the following step S111: Step S111: Based on the inspection results corresponding to the transport flow under the corresponding multiple virtual channel types, virtual channel allocation is performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow passes under the corresponding number of target virtual channel types.

[0050] Here, virtual channel types to be checked can be selected sequentially from multiple virtual channel types corresponding to the transport flow. Based on network connectivity, a channel loop check is performed on the transport flow under the virtual channel type to be checked. If the check result for the transport flow under the virtual channel type indicates that no loop exists, then this virtual channel type can be used as a target virtual channel type for the transport flow, and virtual channel allocation can be performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module that the transport flow passes through under the virtual channel type. If the check result for the transport flow under the virtual channel type indicates that a loop exists, then the next virtual channel type to be checked is selected from the multiple virtual channel types corresponding to the transport flow, and a channel loop check is performed on the transport flow under the next virtual channel type to be checked based on network connectivity. This process continues until the number of target virtual channel types corresponding to the transport flow reaches the target number of types, and the virtual channel configuration information corresponding to at least one component module that the transport flow passes through under the corresponding target number of target virtual channel types is obtained.

[0051] In the above embodiments, when the channel configuration information only contains the number of target types, the target number of virtual channel types can be selected from multiple virtual channel types for allocation based on the inspection results, provided that there are no loops. This ensures that each transport stream receives a sufficient number of virtual channel types while avoiding the introduction of loops, thus improving the overall stability and performance of the system.

[0052] In some embodiments, virtual channel allocation for a transport stream is performed based on the inspection results corresponding to the transport stream under the respective multiple virtual channel types, which may include the following steps S121 or S122: Step S121: If the physical channel through which the transmission flow passes indicates that there is no loop under the corresponding virtual channel type, virtual channel allocation is performed for the transmission flow under the virtual channel type, and the virtual channel type is determined as a target virtual channel type corresponding to the transmission flow, until the number of target virtual channel types corresponding to the transmission flow reaches the target number of types.

[0053] Step S122: If the physical channel through which the transmission flow passes is characterized by a loop under the corresponding virtual channel type, determine whether there is an unused virtual channel type among at least one first candidate virtual channel type of the transmission flow, and if there is an unused virtual channel type among at least one first candidate virtual channel type of the transmission flow, update the virtual channel type corresponding to the transmission flow to the unused virtual channel type.

[0054] Here, at least one first candidate virtual channel type of the transport stream can be determined using any suitable virtual channel type classification method (including the first or second classification method hereinafter referred to as the first classification method or the second classification method), and this disclosure embodiment does not limit this. For example, the virtual channel type classification method may include, but is not limited to, classification according to the initiating network interface, classification according to the target network interface, classification according to the type of transmitted data packets, and / or classification according to the priority of the transport stream, etc.

[0055] In some implementations, at least one first candidate virtual channel type for a transport flow may be a set of virtual channel types that can be used to replace the virtual channel types corresponding to that transport flow, selected automatically or manually during the design phase. Unused virtual channel types for a transport flow refer to virtual channel types that have not been used for channel loop checks corresponding to that transport flow.

[0056] In some implementations, multiple transport flows with the same traffic characteristics can be divided into a set of available virtual channel types as candidate virtual channel types (e.g., a first candidate virtual channel type or a second candidate virtual channel type hereinafter). Each transport flow can select a corresponding virtual channel type from this set of candidate virtual channel types. For example, a set of first candidate virtual channels for a transport flow initiated by network interface 0 includes first candidate virtual channel type 01 and first candidate virtual channel type 02. Thus, if the inspection result of the physical channel through which the transport flow flows indicates the existence of a loop, it can be determined whether there is a virtual channel type that the transport flow has not used in first candidate virtual channel type 01 and first candidate virtual channel type 02. If both first candidate virtual channel type 01 and first candidate virtual channel type 02 are virtual channel types that the transport flow has not used, then one of the first candidate virtual channel type 01 and first candidate virtual channel type 02 can be selected as the updated virtual channel type corresponding to the transport flow.

[0057] In some implementations, after confirming that at least one of the first candidate virtual channel types for the transport flow contains an unused virtual channel type, the unused virtual channel type can be configured as a new virtual channel type and applied to the transport flow. The channel connection relationship corresponding to the unused virtual channel type is then reconstructed to verify whether a loop still exists. If no loop exists, it indicates that the operation of configuring the unused virtual channel type as a new virtual channel type and applying it to the transport flow has successfully resolved the deadlock problem; if a loop still exists, other candidate virtual channel types are tried until a suitable configuration is found.

[0058] In the above embodiments, if a potential loop dependency is found between transport flows corresponding to the same virtual channel type under the current configuration, which may lead to deadlock, the configuration can be automatically adjusted to break the loop and avoid deadlock by changing the unused virtual channel type of the transport flow related to the loop dependency. This improves the flexibility and fault tolerance of virtual channel allocation.

[0059] In the above embodiments, when the check results indicate that there are no loops under a certain virtual channel type, it is directly assigned as the target virtual channel type. If a loop exists, it indicates that there is a potential loop dependency between transport flows corresponding to the same virtual channel type under the current configuration, which may lead to deadlock. In this case, unused types can be found from the corresponding first candidate virtual channel types to replace the transport flows related to the loop dependency, and the configuration can be automatically adjusted again to break the loop and avoid deadlock. In this way, the security of virtual channel allocation is guaranteed, the risk of deadlock is reduced, and the flexibility and fault tolerance of virtual channel allocation are improved.

[0060] In some embodiments, at least one first candidate virtual channel type for each transport stream is obtained by dividing each transport stream according to a first partitioning rule; the above method may further include the following steps S131 and S132: Step S131: If there is no unused virtual channel type in at least one first candidate virtual channel type of the transport flow, and the number of target virtual channel types corresponding to the transport flow is less than the number of target types, the transport flow is divided into candidate virtual channel types according to the second division rule to obtain multiple second candidate virtual channel types corresponding to each transport flow.

[0061] Here, the first partitioning rule and the second partitioning rule are two different logical methods used to determine the candidate virtual channel types of a transport flow. For example, the first partitioning rule may include partitioning based on the initiating network interface, and the second partitioning rule may include partitioning based on the destination network interface. Alternatively, the first partitioning rule may include partitioning based on the type of transmitted data packets, and the second partitioning rule may include partitioning based on the priority of the transport flow.

[0062] In implementation, the at least one first candidate virtual channel type and at least one second candidate virtual channel type corresponding to each transport stream can be manually or automatically assigned, and this disclosure does not limit this.

[0063] In some implementations, at least one first candidate virtual channel type corresponding to each transport stream can be automatically generated in advance according to the first partitioning rule, and at least one second candidate virtual channel type corresponding to each transport stream can be automatically generated according to the second partitioning rule.

[0064] Step S132: Based on the multiple second candidate virtual channel types corresponding to each of the transmission flows, redetermine the multiple virtual channel types corresponding to each of the transmission flows, and reallocate virtual channels for each of the transmission flows to obtain the virtual channel configuration information corresponding to at least one component module through which each of the transmission flows flows under the corresponding multiple target virtual channel types.

[0065] Here, step S132 corresponds to the aforementioned step S102, and the implementation of step S102 can be referred to in practice.

[0066] In the above embodiments, candidate virtual channel types are generated through different partitioning rules to more flexibly address the risk of deadlock under different circumstances. This provides more options for transport flows that cannot find a suitable virtual channel type, further enhancing the possibility of automatically achieving reasonable virtual channel allocation in complex scenarios, so that all transport flows can be successfully allocated to suitable virtual channels. At the same time, by trying different configurations multiple times, it is easier to find the optimal or feasible solution, thereby improving the overall design quality of the on-chip network.

[0067] In some embodiments, the channel configuration information includes multiple target virtual channel types. Based on the inspection results, virtual channel allocation for the transport stream may include the following step S141: Step S141: For each target virtual channel type corresponding to the transport flow, if the inspection result of the physical channel through which the transport flow flows under the target virtual channel type indicates that there is no loop, then the transport flow is assigned a virtual channel under the target virtual channel type.

[0068] In the above embodiments, when multiple target virtual channel types have been specified in the channel configuration information, allocation can be performed simply by checking whether loops exist under these specified types. This simplifies the virtual channel allocation process and speeds up the processing.

[0069] In some embodiments, performing a channel loop check on the transport stream under a corresponding virtual channel type may include the following steps S151 and S152: Step S151: Determine the physical channel through which the transmission flow passes based on the network connection relationship. The physical channel includes multiple physical channel segments.

[0070] A physical channel refers to the actual communication link or path used by a transmission stream in an on-chip network. A physical channel consists of multiple physical channel segments, each representing an independent link, such as a link between routers, or a link between a low-power module and a connectivity module. For example, in... Figure 2The on-chip network topology 600 shown includes initiating network interfaces INIU0, INIU1, INIU2, and INIU3; connection modules LINK0, LINK1, LINK2, LINK3, and LINK4; routers Router0, Router1, Router2, and Router3; low-power modules Low-Power1 and Low-Power2; and target network interfaces TNIU0, TNIU1, TNIU2, and TNIU3. The transmission flow from the initiating network interface INIU0 to the target network interface TNIU2 may pass through multiple component modules such as Router0, Router3, Low-Power module Low-Power1, and connection module LINK4. The connection link between two adjacent component modules is a physical channel segment, and these multiple physical channel segments together constitute the physical path of the transmission flow from the initiating network interface INIU0 to the target network interface TNIU2.

[0071] Understandably, since the network connection relationship defines the connection topology between the various component modules in the on-chip network, the physical channels through which each transmission stream in the on-chip network flows and the various physical channel segments through which each transmission stream passes can be determined based on the network connection relationship.

[0072] Step S152: Perform loop checks on each physical channel segment in stages to obtain the check results of the physical channels through which the transmission flow passes under the virtual channel type.

[0073] Loop checking can be used to check whether there is a loop dependency between the physical channel through which a transport stream flows and the physical channels through which other transport streams of the same virtual channel type flow. By checking in segments, the loop checking mechanism can determine whether each segment of the physical channel will lead to the formation of a loop.

[0074] In the above embodiments, by dividing the physical channel through which the transport stream flows into multiple physical channel segments and performing loop checks on each segment separately, potential loop problems can be detected more accurately and promptly, and potential deadlock risks can be identified without waiting for the entire physical channel to be checked. Therefore, dividing the physical channel into multiple segments for segmented checks not only improves detection efficiency but also reduces unnecessary consumption of computing resources.

[0075] In some embodiments, performing loop checks on each physical channel segment in stages may include the following steps S161 and S162: Step S161: Add each physical channel segment to the channel connection relationship of the virtual channel type corresponding to the transport flow in sequence; the channel connection relationship is established based on at least one physical channel through which the transport flow has been detected, corresponding to the virtual channel type.

[0076] The channel connection relationship of a virtual channel type can include at least one physical channel through which an inspected transport flow corresponding to that virtual channel type flows. An inspected transport flow corresponding to a virtual channel type refers to a transport flow that has been inspected and confirmed to have no loops in the physical channel under that virtual channel type.

[0077] The implementation form of channel connection relationships can be determined according to the actual situation and is not limited here. For example, the channel connection relationship of a virtual channel type can be a list of physical channel segments, which includes all physical channel segments through which all detected transport flows corresponding to that virtual channel type pass. Alternatively, the channel connection relationship of a virtual channel type can be a channel connection topology diagram established based on the physical channels through which all detected transport flows corresponding to that virtual channel type pass.

[0078] The physical channel segments that the transport stream passes through can be added to the channel connection relationship of the virtual channel type corresponding to the transport stream in any suitable order. For example, the physical channel segments can be added to the channel connection relationship of the virtual channel type corresponding to the transport stream in the order in which the transport stream flows. Alternatively, the physical channel segments can be added to the channel connection relationship of the virtual channel type corresponding to the transport stream in a random order.

[0079] It should be noted that the channel connection relationship obtained before the first transport flow corresponding to the virtual channel type undergoes channel loop checking is empty. That is, at this time, the virtual channel type does not have any inspected transport flows. In this case, the first transport flow can be identified as an inspected transport flow corresponding to the virtual channel type. When the virtual channel type has at least one corresponding inspected transport flow, the channel connection relationship obtained before the next transport flow corresponding to the virtual channel type undergoes channel loop checking can be established based on the physical channels through which all inspected transport flows currently corresponding to the virtual channel type flow, excluding the physical channels through which uninspected transport flows under the virtual channel type flow. Here, an uninspected transport flow corresponding to the virtual channel type refers to a transport flow whose physical channel, after inspection, indicates the presence of a loop under the virtual channel type.

[0080] Step S162: If, after adding all physical channel segments through which the transmission flow passes, there is no loop in the channel connection relationship corresponding to the virtual channel type, then the physical channel through which the transmission flow passes is determined to have no loop under the virtual channel type's inspection result, and the transmission flow is regarded as an inspected transmission flow corresponding to that virtual channel type.

[0081] Here, the channel connection relationship corresponding to the virtual channel type can be used as a channel constraint. Each physical channel segment that the current transmission flow passes through can be added to the channel connection relationship in sequence, and after adding each physical channel segment, the channel connection relationship can be checked to see if there is a loop.

[0082] In some implementations, the channel connection relationships of virtual channel types are established based on a channel connection topology map built from all physical channels traversed by the detected transport flows corresponding to that virtual channel type. Physical channel segments of the physical channels traversed by the current transport flow can be gradually added to the constructed channel connection topology map, and the map is checked to determine if loops exist. If no loops exist in the channel connection topology map after all physical channel segments traversed by the transport flow have been added, it indicates that configuring virtual channels for the transport flow based on the current virtual channel type will not cause a deadlock. In this case, virtual channel allocation can be performed for the transport flow under the current virtual channel type. If an addition operation causes a loop to appear, it indicates that configuring virtual channels for the current transport flow based on the current virtual channel type may lead to a deadlock. In this case, subsequent virtual channel allocation operations can be stopped, or an available virtual channel type can be reassigned to the current transport flow, and the check process can be executed again.

[0083] In the above embodiments, the channel connection relationships used in the segmented loop checking of each physical channel segment are constructed based on the previously checked transport flows corresponding to the virtual channel type. That is, the physical channels through which transport flows previously confirmed to be loop-free under that virtual channel type are preferentially used as the reference basis for the physical channels through which the current transport flow flows. This allows for the gradual addition of physical channel segments to construct new channel connection relationships, ensuring that each newly added physical channel segment does not disrupt the original loop-free state, thereby improving the accuracy and efficiency of loop detection. When no loop is found, other transport flows can continue to be processed, thus improving the efficiency of the overall design process.

[0084] In some embodiments, performing loop checks on each physical channel segment in stages may include the following steps S171 and S172: Step S171: Add each physical channel segment to the channel connection relationship of the virtual channel type corresponding to the transport stream in sequence; the channel connection relationship is established based on at least one physical channel through which the transport stream has been detected, corresponding to the virtual channel type.

[0085] Here, step 171 corresponds to the aforementioned step S161, and the implementation of the aforementioned step S161 can be referred to.

[0086] Step S172: If a loop exists in the channel connection relationship corresponding to the virtual channel type after adding any physical channel segment through which the transmission flow passes, then it is determined that the physical channel through which the transmission flow passes under the virtual channel type indicates the existence of a loop.

[0087] Here, if a loop exists in the channel connection relationship corresponding to the virtual channel type after adding any physical channel segment through which the transmission flow passes, it indicates that there is a loop dependency between the physical channel through which the transmission flow passes and at least one physical channel through which the transmission flow has been checked corresponding to the virtual channel type. Thus, it can be determined that the inspection result of the physical channel through which the transmission flow passes indicates the existence of a loop.

[0088] In the above embodiments, if a loop is found after adding any physical channel segment, further processing of the transport stream can be stopped immediately, thereby saving computing resources and quickly identifying configurations that may lead to deadlock.

[0089] In some embodiments, the above method may further include the following step S181: Step S181: When multiple transport streams correspond to the same virtual channel type, loop checks are performed on each physical channel segment through which the transport stream flows for each of the multiple transport streams in turn, so as to obtain the check results of the physical channels through which the multiple transport streams flow under the virtual channel type.

[0090] Here, channel loop checks can be performed on each transport flow corresponding to the same virtual channel type in any suitable order, and this embodiment of the disclosure is not limited in this regard. For example, the order in which channel loop checks are performed on each transport flow can be determined based on factors such as the priority of the transport flow, traffic characteristics, routing path length, and / or the load balancing strategy of the on-chip network.

[0091] In some implementations, the order in which loop checks are performed on each transport stream can be determined based on its priority. Loop checks are performed sequentially on transport streams corresponding to the same virtual channel type, from highest to lowest priority. Here, the transport stream priority refers to the priority at which the transport stream transmits data; for example, in situations where network resources are insufficient, the data transmission requests of higher-priority transport streams are processed first. The transport stream priority can be pre-set by those skilled in the art based on the actual application scenario, or it can be dynamically determined through mechanisms such as load balancing.

[0092] In some implementations, channel loop checks can be performed sequentially on each transport stream corresponding to the same virtual channel type in a random order.

[0093] In the above embodiments, loop checks are performed on each of the multiple transport streams belonging to the same virtual channel type. This allows for a more comprehensive assessment of the overall security of the virtual channel type's configuration, thereby avoiding the impact of problems with some transport streams on the stability of the entire system.

[0094] In some embodiments, the virtual channel configuration information corresponding to the component module includes an input virtual channel and / or an output virtual channel. Assigning virtual channels to the transport stream to obtain the virtual channel configuration information corresponding to at least one component module through which the transport stream flows under a specific target virtual channel type may include the following step S191: Step S191: Based on the type identifier of the target virtual channel type, assign input virtual channels and / or output virtual channels to each component module through which the transport stream flows.

[0095] Here, the input virtual channel refers to the identifier of the virtual channel in the on-chip network used to receive message packets from upstream modules. The output virtual channel refers to the number of the virtual channel in the on-chip network used to send message packets to downstream modules. The identifier of the input virtual channel is used to identify the input queue used by the current component module when processing message packets, and the output virtual channel determines which output port queue the message packet will be routed to after leaving the current component module. This enables isolation and scheduling between different transport streams.

[0096] Setting up input and output virtual channels can effectively avoid deadlock problems because it allows different transport streams to use different virtual channel paths within the same physical channel, thereby breaking loop dependencies.

[0097] By defining the input and output virtual channels of component modules, fine-grained control of the transport stream can be achieved, improving the communication efficiency and reliability of on-chip networks.

[0098] The virtual channel type identifier is a unique code used to distinguish different types of transport flows. Based on the type identifier of the target virtual channel type corresponding to the transport flow, appropriate input and output virtual channels can be dynamically allocated to each transport flow to ensure the correct transmission of the transport flow in the network.

[0099] In some implementations, the type identifier of a virtual channel type can be a serial number or number of the virtual channel type.

[0100] In some implementations, the allocation of input and output virtual channels can be calculated by combining the path characteristics of the transport flow, the port number of the component module, and the alignment value of the maximum number of ports. For example, in a NOQ-based virtual channel architecture, if a component module is the first hop of the path, the input virtual channel value of that component module is equal to the type number of the transport flow multiplied by the alignment value of the maximum number of ports; if a component module is not the first hop, the input virtual channel value of that component module is equal to the output virtual channel value of the previous hop component module. It should be noted that in the NOQ architecture, the input and output virtual channels of connection modules and low-power modules are equal and do not need to be distinguished. Therefore, in some implementations, if the on-chip network adopts a NOQ architecture, input and / or output virtual channels can be allocated only to component modules that include route calculations (such as the initiating network interface, router, or target network interface) through which the transport flow passes, based on the type identifier of the virtual channel type corresponding to the transport flow. In the following text, the first-hop module, non-first-hop module, last-hop module, and non-last-hop module all refer to the component modules in the NOQ architecture that include route calculation.

[0101] In the above embodiments, by assigning specific input virtual channels and / or output virtual channels to each component module, the path of data flow and resource consumption can be precisely controlled, thereby improving system performance and reliability.

[0102] In some embodiments, when the virtual channel configuration information corresponding to a component module includes an input virtual channel, the allocation of input virtual channels and / or output virtual channels to each component module through which the transport stream flows, based on the type identifier of the target virtual channel type corresponding to the transport stream, may include one of the following: If the component module is the first-hop module in the transmission path corresponding to the transmission flow, the input virtual channel of the component module is determined based on the type identifier of the target virtual channel type corresponding to the transmission flow and the maximum number of ports; the maximum number of ports is the largest of the number of input ports and the number of output ports of each component module in the on-chip network; If the component module is a non-first-hop module in the transmission path corresponding to the transmission stream, the output virtual channel of the previous hop module of the component module is determined as the input virtual channel of the component module.

[0103] The first-hop module is the first component module accessed in the access path of a transport flow. The definition of the first-hop module is based on routing algorithms. For example, in a transport flow from the initiating network interface INIU0 to the destination network interface TNIU1, the initiating network interface INIU0 is the first-hop module. The virtual channel allocation of the first-hop module is special because it is the starting point of the entire transport flow, and its virtual channel allocation determines the virtual channel mapping relationship of each component module in the subsequent path.

[0104] The maximum number of ports refers to the maximum number of input ports and output ports of all component modules in the entire on-chip network system.

[0105] In some implementations, determining the input virtual channel of a component module based on the type identifier of the target virtual channel type corresponding to the transport stream and the maximum number of ports may include: determining the input virtual channel of the component module as the product of the type identifier of the current target virtual channel type and the alignment value of the maximum number of ports; the alignment value of the maximum number of ports is a power of 2 for the port width, where the port width is the data width corresponding to the maximum number of ports. The maximum number of ports can be used to calculate the alignment value of the virtual channel to ensure the continuity and scalability of the virtual channel numbering. For example, if the maximum number of ports for a component module in the on-chip network is 6, then the minimum width of the input virtual channel is 3 bits, and the corresponding alignment value is 8. Setting the maximum number of ports to 6 and setting the minimum width of the input virtual channel to 3 bits and the alignment value to 8 ensures that each virtual channel number is unique and supports more transport stream configurations.

[0106] By calculating the input virtual channel of the first-hop module based on the alignment value of the target virtual channel type number and the maximum number of ports, an efficient virtual channel allocation strategy can be achieved. This method not only simplifies virtual channel management but also improves the overall performance and stability of the on-chip network system.

[0107] In some implementations, there is a logical correspondence between input virtual channels and output virtual channels. When a component module receives a data packet, it sends the data packet to the next output virtual channel according to the current input virtual channel, thereby realizing the sequential transmission and path control of data packets.

[0108] A non-first-hop module refers to any component module other than the first-hop module in the access path of a transport stream. The virtual channel allocation of a non-first-hop module depends on the output virtual channel of the previous hop module; therefore, the input virtual channel of a non-first-hop module is directly inherited from the output virtual channel of the previous hop module. This design of non-first-hop modules reduces the complexity of virtual channels and maintains the continuity of data packets during transmission.

[0109] The identifier of an output virtual channel is typically determined by the type identifier of the target virtual channel corresponding to the current transport stream, the alignment value of the maximum number of ports, and the output port number of the next-hop module. The purpose of the output virtual channel is to ensure that data packets arrive at the target module in the correct order and along the correct path, while avoiding loops and deadlocks.

[0110] By setting the input virtual channel of a non-first-hop module as the output virtual channel of the previous-hop module, a chain-like transfer of virtual channels can be achieved. This method not only simplifies the virtual channel allocation process but also improves the flexibility and scalability of the on-chip network system.

[0111] In the above embodiments, by distinguishing the input virtual channel allocation methods of the first-hop and non-first-hop modules, resources can be utilized more rationally, ensuring the continuity and consistency of the data stream during transmission.

[0112] In some embodiments, when the virtual channel configuration information corresponding to a component module includes an output virtual channel, the allocation of input virtual channels and / or output virtual channels to each component module through which the transport stream flows, based on the type identifier of the target virtual channel type corresponding to the transport stream, may include one of the following: If the component module is the last hop module in the transmission path corresponding to the transmission flow, the output virtual channel of the component module is determined based on the type identifier of the target virtual channel type corresponding to the transmission flow and the maximum number of ports; the maximum number of ports is the largest of the number of input ports and the number of output ports of each component module in the on-chip network. If the component module is a non-last hop module in the transmission path corresponding to the transmission flow, the intermediate parameters are determined based on the type identifier and maximum number of ports of the target virtual channel type corresponding to the transmission flow. The sum of the intermediate parameters and the output port number of the next hop module of the component module is determined as the output virtual channel of the component module.

[0113] The last-hop module refers to the last component module accessed in the access path of a transport stream. For example, in a transport stream that originates from network interface INIU0 and is directed to network interface TNIU1, the target network interface TNIU1 is the last-hop module.

[0114] By determining the output virtual channel of the last-hop module based on the maximum number of ports and the type identifier of the virtual channel, the uniqueness and predictability of the virtual channel allocation for each transport stream can be ensured. This method can avoid virtual channel conflicts between different transport streams, thereby improving the communication efficiency and stability of the on-chip network system.

[0115] Non-last-hop modules refer to other component modules besides the last-hop module in the access path of the transport stream.

[0116] The intermediate parameter is a value calculated based on the type identifier of the target virtual channel type and the maximum number of ports of the current component module. This value is used to help determine the output virtual channel number of the current component module.

[0117] In some implementations, the intermediate parameter can be equal to the type identifier of the target virtual channel type multiplied by the alignment value of the maximum number of ports. The intermediate parameter is added to the output port number of the next-hop module, and the result is used as the output virtual channel number of the current component module. This design tightly associates the output virtual channel of each non-last-hop module with the output port of the next-hop module, allowing the output port used by the next module to be indicated through the output virtual channel of each non-last-hop module, thereby progressively forming the access path of the transport flow.

[0118] By introducing intermediate parameters and combining them with the output port number of the next-hop module, output virtual channels are allocated to non-last-hop modules. This ensures the continuity of the transmission path while avoiding the reuse of virtual channel identifiers. By introducing intermediate parameters and combining them with the output port number of the next-hop module to allocate output virtual channels to non-last-hop modules, deadlock can be effectively prevented, and the reliability and performance of the entire on-chip network system can be improved.

[0119] In the above embodiments, by reasonably calculating the output virtual channel value, it is possible to ensure that data packets are correctly transmitted between various component modules, while reducing conflicts and resource contention, thereby improving the overall operating efficiency and stability of the system.

[0120] In some embodiments, the above method may further include the following steps S1101 and S1102: Step S1101: Obtain the target synthesis constraints corresponding to the on-chip network.

[0121] Target synthesis constraints refer to a set of technical parameters used to limit the number and / or types of virtual channels during the on-chip network design process. Target synthesis constraints can be set by the on-chip network designer based on the actual requirements of the chip, such as performance, power consumption, and area, and can be used to reduce the risk of synthesis failure during the on-chip network physical implementation stage.

[0122] Target synthesis constraints may include, but are not limited to, the maximum total number of virtual channels and the maximum number of virtual channel types supported by each component module in the on-chip network, the maximum total number of virtual channels and the maximum number of virtual channel types supported by all component modules in the on-chip network, and / or the resource usage of specific types of virtual channels in the on-chip network. The purpose of target synthesis constraints is to ensure that the generated on-chip network architecture can meet synthesis conditions such as timing, frequency, and / or area during the physical implementation phase (such as logic synthesis and place and route), thereby avoiding implementation failures or performance degradation caused by excessive use of system resources.

[0123] In implementation, the target synthesis constraints can be any suitable constraints pre-set by those skilled in the art based on the actual situation, and are not limited here. For example, target synthesis constraints can be defined based on different types of virtual channel architectures (such as a unified immutable virtual channel architecture or a NOQ architecture) and may vary depending on different transport flow paths.

[0124] Target synthesis constraints are typically passed into the design tool by the designer through user-input configuration files, graphical interface settings, or script commands. For example, in a complex on-chip network topology containing numerous input interface units and transmission node interface units, the designer might set specific values ​​as synthesis constraints, such as each router supporting a maximum of 8 input virtual channels and each link module supporting a maximum of 4 output virtual channels. Properly setting target synthesis constraints is crucial for improving the efficiency and reliability of on-chip network design.

[0125] Step S1102: During the process of allocating virtual channels for the transmission flow under the corresponding target virtual channel type, for each component module through which the transmission flow passes, check whether the total number of virtual channels and / or the total number of virtual channel types corresponding to at least one component module in the on-chip network after allocating virtual channels for the component module under the target virtual channel type meets the target comprehensive constraints.

[0126] During the process of allocating virtual channels for each transport stream, it is possible to dynamically check whether the current virtual channel configuration meets the pre-set target comprehensive constraints.

[0127] In some implementations, after selecting a target virtual channel type for each transport flow, all component modules in the on-chip network (such as input interface units, transport node interface units, routers, link modules, and / or low-power modules) can be traversed, and the total number of virtual channels and / or the total number of virtual channel types currently used by all component modules can be counted. If the total number of virtual channels and / or the total number of types counted do not exceed the maximum value allowed in the target synthesis constraints, it indicates that the target synthesis constraints are met; otherwise, it indicates that the target synthesis constraints are not met.

[0128] In some implementations, after selecting a target virtual channel type for each transport flow, each component module in the on-chip network (such as input interface units, transport node interface units, routers, link modules, and / or low-power modules) can be traversed, and a virtual channel can be allocated to the component module under the target virtual channel type. The total number of virtual channels and / or the total number of virtual channel types currently used by the component module are then counted. If the total number of virtual channels and / or the total number of types does not exceed the maximum allowed value in the target synthesis constraints, it indicates that the target synthesis constraints are met; otherwise, it indicates that the target synthesis constraints are not met. After selecting a target virtual channel type for a path in the transport flow, all component modules traversed by the transport flow can be traversed, and the number of virtual channels and / or the number of virtual channel types currently used by each component module can be counted. If the number of virtual channels or the number of virtual channel types currently used by any component module exceeds the maximum allowed value in the target synthesis constraints, it indicates that the target synthesis constraints are not met, and this virtual channel allocation will be considered invalid.

[0129] By combining virtual channel allocation with a real-time comprehensive constraint detection mechanism, resource conflicts or over-limit issues can be effectively prevented during the design phase. This not only improves the degree of design automation but also significantly reduces potential error feedback during subsequent logic synthesis and physical design phases, thereby improving overall design efficiency.

[0130] In some embodiments, when the total number of virtual channels and / or the total number of virtual channel types currently used by a component module approaches the corresponding upper limit in the target synthesis constraints, the user can be automatically prompted to adjust the relevant configuration or try using other virtual channel types to optimize the overall allocation scheme. This helps to make the most of limited hardware resources while ensuring design quality, thereby achieving a more efficient design process.

[0131] In some implementations, if the total number and / or total number of virtual channels exceeds the maximum allowed value in the target aggregation constraints, the current virtual channel allocation will be considered invalid. That is, the currently selected target virtual channel type is invalid, and it is necessary to reselect another available virtual channel type as the new target virtual channel type for the transport flow to satisfy the constraints. Here, any suitable method can be used to reselect another available virtual channel type as the new target virtual channel type for the transport flow; this disclosure is not limited in this regard.

[0132] In the above embodiments, by introducing target synthesis constraints during the virtual channel allocation process to limit the total number and / or the total number of virtual channel types in the on-chip network, potential resource conflicts can be identified and resolved in advance during the design phase, thereby preventing insufficient hardware resources due to over-allocation. This constraint mechanism reduces the failure rate of subsequent logic synthesis stages, enhances the overall robustness of the design process, thereby reducing design iteration costs and improving the overall efficiency and stability of on-chip network design.

[0133] In some embodiments, the above method may further include the following steps S1201 and S1202: Step S1201: If, after a component module performs virtual channel allocation under the target virtual channel type, the total number of virtual channels and / or the total number of virtual channel types corresponding to each component module in the on-chip network do not meet the target synthesis constraint, then each virtual channel allocated for the transmission flow under the target virtual channel type will be removed from at least one virtual channel corresponding to each component module through which the transmission flow passes, and at least one virtual channel after reset will be obtained for each component module.

[0134] When a virtual channel is allocated to a component module under a specific target virtual channel type, if the total number and / or total number of virtual channels of all component modules in the on-chip network exceed the comprehensive constraints set during the on-chip network design (such as the maximum number of supported VCs and the maximum number of supported VC types), then all virtual channels allocated to each component module through which the current transport flow passes under the target virtual channel type can be removed from the virtual channel configuration information of the corresponding component module. This resets the virtual channel configuration information of each component module to its state before the current virtual channel allocation, ensuring that subsequent reselection of appropriate virtual channel configurations can continue. The virtual channel currently allocated to the transport flow is the virtual channel value allocated to the transport flow under the target virtual channel type.

[0135] By rationally allocating virtual channel configurations for multiple transport streams, the problem of system overload or violation of design constraints due to virtual channel configuration of a single transport stream can be avoided. This configuration method can ensure the stability and scalability of the system and help improve the robustness and flexibility of on-chip networks during the design phase.

[0136] Step S1202: Select one of the virtual channel types that is available to the transport stream and is different from the target virtual channel type from the virtual channel types to which at least one virtual channel belongs to the component module, as the updated target virtual channel type corresponding to the transport stream.

[0137] Here, new candidate virtual channel types can be found among other virtual channel types already used by the current component module to replace the original target virtual channel type for the current transport flow. The newly selected virtual channel type must meet at least two conditions: first, the virtual channel type has not been used by the current transport flow; second, the virtual channel type will not cause deadlock or other comprehensive constraint conflicts. This replacement mechanism allows the system to dynamically adjust the virtual channel configuration of the transport flow while maintaining design constraints, in order to achieve the design goal of deadlock-free operation.

[0138] Understandably, since the newly selected virtual channel type is chosen from the virtual channel types belonging to at least one virtual channel of the component module through which the current transport flow passes, the reusability of virtual channel types in the on-chip network can be improved. This, in turn, reduces the total number and / or total number of virtual channels of all component modules in the on-chip network after virtual channel allocation, increasing the likelihood of meeting the target synthesis constraints. This enables rapid iteration and optimization during the design phase, maximizing the performance of the on-chip network with limited resources, and improving the efficiency and quality of the entire system's automated design.

[0139] The following describes the application of the embodiments of this disclosure in a real-world scenario, which can be used to allocate multiple virtual channels for the transmission path of a single transmission stream in an on-chip network.

[0140] The structure of a computer system can be as follows: Figure 3 As shown, the computing system 200 includes an on-chip network 210 for connecting a memory controller 251, an interconnect link 260, and multiple clients. The memory controller 251 is an interface for connecting to memory 252. Figure 3 An example of a client is shown, including a CPU complex 241, a graphics processing unit (GPU) 242, and a hub 243 for exchanging information with a multimedia engine 244. In some implementations, the number of clients can be multiple or zero. The types of clients can also be other, such as displays, one or more initiating / targeting network interfaces, network interface cards (NICs), etc. Interconnect links 260 are used for interconnection between chips (e.g., NvLink, Peripheral Component Interconnect Express (PCIE), and Compute Express Link (CXL)).

[0141] The on-chip network 210 is a high-performance interconnect structure within the chip for multi-processor unit systems. The NoC architecture uses system-level networking technology to transmit traffic within the chip. Compared to bus architectures, NoC provides a high-bandwidth, low-latency, and scalable switching network. The on-chip network 210 uses a routing network 220, including a first router 221, a second router 222, a third router 223, a fourth router 224, and a fifth router 225, for efficient traffic routing. In some implementations, the routing network may organize the routers into a butterfly, ring, mesh, or torus topology. Routers are components within the NoC responsible for routing, arbitration, flow control, quality of service assurance, and virtual channel isolation. A virtual channel (VC) virtualizes the same physical channel into multiple channels for time-division multiplexing, with a certain degree of isolation between each virtual channel (VC). The on-chip network 210 uses a first initiating network interface 211, a second initiating network interface 212, and a third initiating network interface 213 to exchange information with multiple clients. The initiating network interfaces can convert client output protocols (e.g., AXI) into NoC intra-transmission protocols, perform local address to global address conversion, and allocate request VC channels, among other functions. The on-chip network 210 uses a first target network interface 231 and a second target network interface 232 to exchange information with multiple memory controllers 251 and interconnect links 260. The target network interfaces can convert NoC intra-transmission protocols into memory controller or interconnect link input protocols (e.g., AXI), perform global address to local address conversion, temporarily store NoC data packet control information, and return response VCs, among other functions. The connection channels between the initiating network interface, target network interface, and router within the on-chip network 210 can contain zero or more first connection modules 271, second connection modules 272, first low-power modules 273, and second low-power modules 274. The connectivity module is a component within the NoC responsible for link channel bit width conversion, pipeline timing, rate adapter, and FIFO (First-In, First-Out) buffer functions. The low-power module is a component within the NoC responsible for cross-clock domain synchronization, power control, and pipeline pause functions.

[0142] Deadlock problems can occur in NoC interconnect systems when a message packet cannot reach its destination because it is waiting for another message packet to release NoC resources, including buffers and / or channels. Buffer congestion caused by deadlock can spread rapidly within the NoC until it permeates the entire NoC system. Deadlock problems in NoCs are often caused by circular constraints in network channels. Figure 4 This is a schematic diagram of a NoC deadlock scenario provided in an embodiment of this disclosure, as shown below. Figure 4 As shown, NoC includes component module A, component module B, component module C, and component module D. There are four data packets (e.g., a, b, c, d) that need to be transmitted, resulting in four transmission streams: A->C, B->D, C->A, and D->B. Each component module uses an output port to transmit messages to its target module. Figure 4 In the example, each channel can only be occupied by one data packet at a time, and each channel waits for the next channel to pass a message packet, eventually leading to a circular constraint between channels and ultimately causing a deadlock problem in NoC. This deadlock problem can be solved using VC. VC virtualizes the same physical channel into multiple channels for time-division multiplexing. There is a certain degree of isolation between the transmissions of each VC, so the circular path constraint can be broken, and the risk of deadlock is reduced by reusing channels.

[0143] Digital integrated circuits, especially computationally intensive digital integrated circuits, include Field-Programmable Gate Arrays (FPGAs) and other programmable logic circuits, as well as computer-aided design (CADI) digital integrated circuits such as Application-Specific Integrated Circuits (ASICs). In the hardware design or verification of digital integrated circuits, the widely used programming language is register-transfer-level (RTL) hardware description languages. For example, hardware description languages ​​can include, but are not limited to, Verilog, Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL), ABEL, CUPL, AHDL, MACHX, PALASM, SystemVerilog, and combinations of these languages. Hardware description language (HDL) code can be translated into gate-level netlists using various synthesis programs, and then physical design tools can process these netlists into actual hardware implementations.

[0144] Figure 5 This is a schematic diagram illustrating a method for generating HDL code for instantiating component modules, as provided in an embodiment of this disclosure. Figure 5As shown, the module configuration 301, the module's mixed Python and HDL code 302, and the module's unique identifier command 303 are input into the Python+HDL generator 304, and an instantiated module HDL code file 305 is output. The mixed Python+HDL code can be replaced by mixed code of C / C++ and HDL, or mixed code of Java and HDL.

[0145] Use such as Figure 5 The method shown can generate HDL code for component module instantiation in a NoC (NoC), and this HDL code can be used to generate RTL code for the same NoC's component module instantiation. However, the VC configuration for the NoC's component module instantiation needs to be manually defined in the module configuration. As the scale of multi-core chip NoCs gradually increases, manually allocating the VC configuration for each component module becomes increasingly impractical. Furthermore, related technologies cannot automatically identify and avoid deadlocks. In large-scale NoC systems, considering limitations such as design cost, power consumption, and performance, it is impossible to significantly increase deadlock avoidance logic during runtime. In such NoC systems, deadlock checking and avoidance during the design generation phase gradually become a critical architectural requirement. However, existing technologies cannot automatically identify and avoid deadlocks, and manually avoiding deadlocks is also becoming increasingly impractical.

[0146] Furthermore, to improve the communication efficiency of component modules in NoC, some transport flows in some NoCs require the introduction of single-path multiple VCs, thereby increasing the types of interleaved output VCs and achieving higher bandwidth efficiency. However, component modules with single-path multiple VCs may have more VCs, which may not meet frequency constraints after synthesis. If frequency issues are discovered through synthesis after generating RTL code, the feedback time will be relatively long.

[0147] Based on this, embodiments of this disclosure provide a method and system for virtual channel allocation in a network-on-chip (NOC). It defines a set of methods for automated loop checking and deadlock avoidance, VC allocation, and synthesis problem checking and avoidance for a NoC with single-path multi-VC architecture. This method can automatically allocate virtual channels for components in the NoC and avoid deadlock, improving the allocation efficiency of single-path multi-VC configurations instantiated within the NoC. Simultaneously, it checks and avoids deadlock problems in the NoC during the design generation phase and can check and reduce synthesis problems during the design generation phase, thereby significantly improving the design efficiency of a single-path multi-VC NoC.

[0148] Figure 6 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 2 ,like Figure 6 As shown, the method includes the following steps S401 to S415: Step S401: Receive the user's NoC specifications and architecture configuration.

[0149] The specifications and architecture configuration of the receiving user's NoC include, but are not limited to, at least one transport stream and multiple target VC types corresponding to the transport stream, NoC topology definition, and maximum available VC types. In the receiving configuration, each transport stream is configured with multiple target VC types, that is, one transport stream corresponds to multiple target VC types.

[0150] Step S402: Based on the NoC topology definition, construct the module connection diagram.

[0151] In a NoC topology definition, upstream and downstream modules of a router can be defined, for example. By adding each component module from the NoC topology definition and the connections between them to a directed graph, a module connection graph for that NoC is obtained.

[0152] The NoC topology definition or module connection diagram can correspond to the network connection relationship in the aforementioned embodiments.

[0153] Step S403: Select the next transport stream from at least one transport stream in NoC.

[0154] The order in which the transport streams are selected can be arbitrary.

[0155] Step S404: Based on the routing algorithm and module connection diagram, obtain all physical channel segments corresponding to the single path of the transmission flow, as well as all component modules through which the transmission flow passes.

[0156] Based on the currently selected transport stream and the module connection diagram above, all component modules and physical channel segments through which the transport stream flows can be obtained, i.e., the transport path corresponding to the transport stream.

[0157] Routing algorithms can be, for example, deterministic routing, where the path from an originating network interface to a destination network interface is deterministic, ensuring that each data packet follows only one path.

[0158] Step S405: Based on the NoC specification and architecture configuration, select the next target VC type from the multiple target VC types corresponding to the transport stream.

[0159] The order in which you select target VC types can be any order.

[0160] Step S406: Select the next physical channel segment from the physical channel segments corresponding to the transport stream, and add the selected physical channel segment to the channel constraint graph corresponding to the target VC type.

[0161] The order in which physical channel segments are selected can be based on the data packet transmission direction corresponding to the transport stream, that is, the order from the initiating network interface to the destination network interface. For example, request packets can be selected from INIU to TNIU, and response packets can be selected from TNIU to INIU.

[0162] The selected physical channel segment is added to the channel constraint graph corresponding to that VC type to obtain the updated channel constraint graph. One VC type corresponds to one channel constraint graph. For example, VC type 0 corresponds to one channel constraint graph, and VC type 1 corresponds to one channel constraint graph.

[0163] It is understandable that the dependencies between channel constraint graphs corresponding to different VC types will not lead to deadlock problems. On the contrary, a loop with a deadlock problem can be broken by two VC types, thereby achieving the effect of unblocking the loop and avoiding deadlock.

[0164] The channel constraint graph can correspond to the channel connection topology graph in the aforementioned embodiments.

[0165] Step S407: Check for loops in the channel constraint graph corresponding to the current target VC type.

[0166] In this context, a loop refers to a physical channel that can be found in the channel constraint graph through a path where both ends are the same channel. This loop check can detect deadlock issues caused by NoC configuration during the design phase.

[0167] Step S408: Has a loop been detected? If yes, proceed to step S409; if no, proceed to step S410.

[0168] Step S409: Determine that there is a deadlock problem in the NoC configuration and report the detected loop to the user.

[0169] This step indicates that the user-defined NoC configuration is not ideal. Finally, any loops caused by the configuration will be reported to the user, and the method will then terminate.

[0170] Users may subsequently modify the multiple target VC types corresponding to the transport stream in the NoC configuration and then repeat this method to detect and avoid deadlocks.

[0171] Step S410: Have all physical channel segments corresponding to the transport stream been selected? If yes, proceed to step S411, indicating that the addition of all physical channel segments through which the current transport flow passes will not cause a deadlock. Therefore, it is possible to start allocating NoC component virtual channels to each component module through which the current transport flow passes under the current target VC type. If no, proceed to step S406 to continue checking other physical channel segments corresponding to the current transport flow.

[0172] Step S411: Based on the above module connection diagram, assign virtual channels corresponding to the target VC type to each component module through which the current transmission stream flows.

[0173] Step S412: Have all target VC types corresponding to this transport stream been selected? If yes, proceed to step S413; if no, proceed to step S405 and continue to select the next target VC type.

[0174] Step S413: Have all transport streams been selected? If yes, proceed to step S414; if no, proceed to step S403 and continue to select the next transmission stream.

[0175] Step S414: Determine that the single-path multi-VC configuration allocation for all NoC components is complete, and that there are no deadlock issues in the above NoC configuration.

[0176] This step indicates that under this NoC configuration, the single-path multi-VC configuration of all NoC component modules has been assigned, and the current NoC is a deadlock-free NoC.

[0177] Step S415: Based on the virtual channel configuration information corresponding to each group of modules in NoC, and combined with Python+HDL hybrid code, generate NoC RTL code with virtual channels and no deadlock.

[0178] The process of generating RTL can be implemented in any suitable manner, and the embodiments disclosed herein are not limited thereto.

[0179] The virtual channel allocation method for on-chip networks (NCNs) provided in the above-described embodiments of this disclosure for checking and avoiding deadlock issues in NoCs during the design and generation phase defines the specifications and architecture configuration based on the NoC, manually defines the multiple VC types corresponding to the transport flow, automatically constructs the channel constraint graphs corresponding to each VC type to check for and avoid deadlock, and automatically allocates multiple virtual channels for a single path in NoC components. Therefore, it improves the efficiency of single-path multiple VC configuration allocation for instantiation of components within the NoC, while simultaneously checking and avoiding deadlock issues in NoCs with multiple single-path multiple VCs during the design and generation phase.

[0180] Figure 7 A schematic diagram of the implementation process of a virtual channel allocation method for an on-chip network provided in this embodiment of the present disclosure. Figure 3 ,like Figure 7 As shown, the method includes the following steps S501 to S519: Step S501: Receive the user's NoC specifications and architecture configuration.

[0181] The specifications and architecture configuration of the receiving user's NoC include, but are not limited to, at least one transport stream and the number of target types corresponding to the transport stream, the NoC topology definition, and the maximum number of available VC types. One transport stream corresponds to at least one VC type. The number of target types corresponding to the transport stream refers to the configured number of target VC types corresponding to the transport stream. Based on this number of target types, deadlock-free VC configurations can be automatically allocated through subsequent steps.

[0182] Step S502: Based on the NoC topology definition, construct the module connection diagram.

[0183] Step S503: Select the next transport stream from at least one transport stream in NoC.

[0184] Step S504: Based on the routing algorithm and module connection diagram, obtain all physical channel segments corresponding to the single path of the transmission flow, as well as all component modules through which the transmission flow passes.

[0185] Step S505, initialize i=0.

[0186] `i` is an internal counter corresponding to the current transport stream, used to represent the index of the currently selected VC type among at least one candidate VC type corresponding to the current transport stream. For example, the value of `i` can range from 0 to the number of candidate VC types corresponding to the current transport stream. For each transport stream, a channel loop check can be performed on each VC type corresponding to the internal counter.

[0187] Step S506: Select the next physical channel segment from each physical channel segment corresponding to the transport stream, and add the selected physical channel segment to the channel constraint graph corresponding to VC[i].

[0188] Wherein, VC[i] refers to the i-th candidate VC type in a set of candidate VC types corresponding to the current transport stream.

[0189] The order in which physical channel segments are selected can be based on the data packet transmission direction corresponding to the transmission flow, that is, the order from the initiating network interface to the ending target network interface.

[0190] Step S507: Check for loops in the channel constraint graph corresponding to VC[i].

[0191] Step S508: Has a loop been detected? If yes, proceed to step S509; if no, proceed to step S513.

[0192] Step S509: Reset the channel constraint graph corresponding to VC[i] to the state before adding any physical channel segment through which the current transport flow passes.

[0193] Step S510, i = i++.

[0194] Here, an internal counter can be added to select the next candidate VC type.

[0195] Step S511: Does VC[i] exist? If yes, proceed to step S506 and re-traverse each physical channel segment corresponding to the transmission stream; if no, proceed to step S512.

[0196] If the next available VC type corresponding to the internal counter exists, the check can continue; otherwise, it indicates that the deadlock problem cannot be avoided.

[0197] Step S512: Determine that there is an unavoidable deadlock problem in the NoC configuration, and report the detected loop to the user.

[0198] This step indicates that the user-defined NoC configuration is not ideal. Finally, any loops caused by the configuration will be reported to the user, and the method will then terminate.

[0199] Users may subsequently modify the number of target types corresponding to the transport stream in the NoC configuration and then repeat this method to detect and avoid deadlocks.

[0200] Step S513: Have all physical channel segments corresponding to the transport stream been selected under VC[i]? If yes, proceed to step S514; otherwise, proceed to step S506.

[0201] Step S514: Based on the above module connection diagram, assign virtual channels corresponding to VC[i] to each component module through which the current transmission flow passes, and determine VC[i] as a target VC type corresponding to the current transmission flow.

[0202] Step S515: Does the number of target VC types corresponding to the current transport stream reach the corresponding number of target types? If yes, proceed to step S517; otherwise, proceed to step S516.

[0203] Step S516, i = i++.

[0204] You can select the next candidate VC type by adding an internal counter.

[0205] Step S517: Have all transport streams been selected? If yes, proceed to step S518; if no, proceed to step S503.

[0206] Step S518: Determine that the single-path multi-VC configuration allocation of all NoC components is completed, and that there are no deadlock issues in the above NoC configuration.

[0207] This step indicates that under this NoC configuration, the single-path multi-VC configuration of all NoC component modules has been assigned, and the current NoC is a deadlock-free NoC.

[0208] Step S519: Based on the virtual channel configuration information corresponding to each group of modules in the NoC, and combined with Python+HDL hybrid code, generate RTL code for the NoC with virtual channels and no deadlock.

[0209] The virtual channel allocation method for on-chip networks (NCNs) provided in the above-described embodiments of this disclosure for checking and avoiding deadlock issues in NoCs during the design and generation phase automatically allocates NoC single-path multi-VC configurations, defines the specifications and architecture configuration based on the NoC, manually defines the number of target VC types corresponding to the transport stream, automatically tests available VC types, automatically constructs channel constraint graphs corresponding to each VC type to check for deadlocks, selects VC types to automatically avoid deadlocks when they occur, and allocates multiple other VCs on a single path for NoC components by automatically selecting VCs, ultimately generating deadlock-free NoC RTL code with multiple virtual channels along a single path. Therefore, it simplifies the definition of NoC single-path multi-VC configurations, improves the efficiency of single-path multi-VC configuration allocation for instantiated components within the NoC through automatic allocation, and checks and avoids NoC deadlock issues with single-path multi-VCs during the design and generation phase.

[0210] Figure 8 This is a schematic diagram illustrating how configuring different VC types for multiple transport streams to resolve the NoC deadlock problem, as provided in an embodiment of this disclosure. Figure 8 As shown, NoC includes a first component module A, a second component module B, a third component module C, and a fourth component module D. There are four data packets (e.g., a, b, c, d) that need to be transmitted, resulting in four transport streams: A->C, B->D, C->A, and D->B. Transport streams A->C and B->D are configured with VC type 0, while transport streams C->A and D->B are configured with VC type 1. Figure 7 In the example, no loops are formed between transport streams corresponding to the same VC type. Therefore, there is no deadlock problem under this NoC configuration, that is, Figure 4 The deadlock scenario shown was resolved by increasing the number of VC types.

[0211] See also Figure 2Topology 600 describes the request network, while the response network is a mirror image; alternatively, it can be a custom topology. The NoC topology 600 uses a NOQ-based VC architecture. In the NOQ VC architecture, VCs are divided into IVCs and OVCs, where IVC represents the input VC and OVC represents the output VC. A hop refers to a path passing through a component module, such as INIU, TNIU, or ROUTER. Regarding the calculation of IVC during message packet transmission, if the component module is the first-hop module of the current path, the IVC input for this hop is equal to the VC type index multiplied by the alignment value of the component module's maximum port count; if the component module is not the first-hop module of the current path, the IVC input for this hop is equal to the OVC output by the previous hop module. The minimum bit width corresponding to the maximum port count of a component module is called the VC port width. For example, if the maximum port count in NoC is 6, then the VC port width is 3 bits. The alignment value of the maximum port count of a component module is equal to 2 raised to the power of the VC port width. For example, if the VC port width is 3 bits, the alignment value of the maximum port count of the component module is 8. Regarding the calculation of OVC during packet transmission, if the component module is the last hop module of the current path, the OVC output of this hop is equal to the VC type sequence number multiplied by the alignment value of the component module's maximum port number; if the component module is not the last hop module of the current path, the OVC output of this hop is equal to the VC type sequence number multiplied by the alignment value of the component module's maximum port number, plus the output port number of the downstream module. For example, in the NoC topology 600, there is a path from INIU0 to TNIU2: INIU0 OUT0 -> Router0 IN1 OUT1 -> Router3 IN1 OUT0 -> Low Power1 -> LINK4 -> TNIU2 IN0, where OUT0 and OUT1 are output port numbers, and IN0 and IN1 are input port numbers. Based on the topology, the maximum number of ports for the component module is 2. Assuming that INIU0 has a VC type number of 1 that accesses TNIU2, then the corresponding INIU0 IVC is 2 and OVC is 3; Router0 IVC is 3 and OVC is 2; Router0 IVC is 2 and OVC is 2; Low Power1 IVC is 2 and OVC is 2; LINK4IVC is 2 and OVC is 2; TNIU2 IVC is 2 and OVC is 2.

[0212] Figure 9 A schematic diagram illustrating the implementation flow of a method for checking and avoiding NoC synthesis problems in single-path multi-VC during the design generation phase, as provided in this disclosure embodiment, is shown below. Figure 9 As shown, the process includes the following steps S601 to S614.

[0213] Step S601: Receive the NoC module connection diagram, current transport stream, current VC type, current channel constraint diagram, all component modules through which the current transport stream flows, and target comprehensive constraints.

[0214] The current VC type refers to the target VC type currently selected for the current transport flow, and the current channel constraint graph corresponds to this current VC type.

[0215] Based on the channel constraint graph, when the loop check of all physical channel segments under the current VC type represents a five-loop (i.e., passes the deadlock check), the subsequent allocation and check steps begin based on all component modules corresponding to the single path of the current transport flow.

[0216] In some implementations, the comprehensive constraints include, but are not limited to, the maximum number of VC values ​​for each component module, and / or the total number of maximum VC values ​​for all component modules in the on-chip network.

[0217] In one implementation, the VC architecture employs a unified, immutable VC, where the maximum number of VCs per component refers to the maximum number of VC values ​​used by the component. For example, in a NoC using a unified, immutable VC architecture, a router with four input ports can support a maximum of 16 VC values ​​at a 2.0 GHz operating frequency. In another implementation, the VC architecture employs a NOQ VC architecture, where the maximum number of VCs per component includes the maximum number of IVCs and / or the maximum number of OVCs used by the component.

[0218] Step S602: Select the next component module.

[0219] Here, the next component module can be selected sequentially from all the component modules through which the current transport stream flows. The order in which component modules are selected is based on the direction of data packet transmission. For example, request packets start from INIU and end from TNIU, and response packets start from TNIU and end from INIU.

[0220] Step S603: Assign a VC to the current component module and add the assigned VC to the VC list of the component module.

[0221] In one embodiment, the VC architecture adopts a unified and immutable VC architecture, where one VC type corresponds to one VC value, and the value of the VC type can be directly added to the VC list as the assigned VC.

[0222] In one embodiment, the VC architecture adopts a NOQ-based VC architecture, where one VC type corresponds to at least one VC value, and VC values ​​can be divided into IVC and OVC.

[0223] Step S604: Does the total number of VC values ​​of the current component module meet the maximum number of VC values ​​in the target synthesis constraints? If yes, proceed to step S613 to start detecting other transport streams; if no, proceed to step S605, detect the synthesis problem, and proceed to VC reallocation to avoid the synthesis problem.

[0224] Step S605: Remove the currently assigned VC value from the VC list of the current component module.

[0225] Step S606: Reset the above channel constraint diagram to the state before adding any physical channel segment corresponding to the current transport flow.

[0226] Since the transport flow applies the current VC configuration, the maximum number of VC values ​​that do not meet the target synthesis constraints after introducing the currently allocated VCs needs to be adjusted. Therefore, the loop needs to be re-detected. Thus, all newly added physical channel segments in the above transport flow must be removed from the channel constraint graph corresponding to the current VC type.

[0227] Step S607: Among the VCs allocated to the component modules through which the current transport stream flows, are there any VC types available for the current transport stream other than the current VC type? If yes, proceed to step S609 to begin allocating and checking based on the existing VC types in the current component module; if no, proceed to step S608 to detect a comprehensive problem that cannot be avoided.

[0228] Step S608: Determine that there are unavoidable comprehensive problems with the NoC configuration, and report the list of VCs currently used by the component to the user.

[0229] This step indicates that the user-defined NoC configuration is inappropriate. The resulting synthesis problem will be reported to the user, and the method will then end. Subsequently, the user may manually modify the specific single-path multi-VC configuration or target synthesis constraints in the NoC configuration, and then repeat this method to detect synthesis problems.

[0230] Step S609: Select the next available VC type for the current transport stream from the list of used VCs of the current component module.

[0231] The order in which the next available VC type is selected can be arbitrary. Selecting the next available VC type for the current transport stream from the list of used VCs in the component module can reduce the complexity of VC allocation in the current component module.

[0232] Step S610: Is the currently selected VC type duplicated with the VC already used in the current transport stream? If yes, proceed to step S609 to select other available VC types; otherwise, proceed to step S611 to check for deadlock. Because the transport stream supports multiple VCs on a single path, the newly added VC cannot be the same as an already allocated transport stream VC.

[0233] Step S611: In the channel constraint diagram of the currently selected VC type, add each physical channel segment through which the current transmission flow passes, and check for loops.

[0234] Here, you can select each physical channel segment through which the current transmission stream flows in sequence, add it to the channel constraint graph of the currently selected VC type, and check if loops exist.

[0235] Step S612: Check if a loop is found; If yes, proceed to step S605, reset the channel constraint diagram, and reselect other used VCs; if no, proceed to step S613.

[0236] Step S613: All component modules that the current transmission stream passes through have been selected; If yes, proceed to step S614; otherwise, proceed to step S602 and select the next component module.

[0237] Step S614: Determine that all virtual channels of all component modules through which the current transport stream flows have been allocated.

[0238] This step indicates that under this NoC configuration, the single-path multi-VC configuration of all NoC component modules has been assigned, and the current NoC configuration meets the input synthesis constraints.

[0239] The above-described embodiments of this disclosure provide a method for checking and avoiding synthesis problems in a NoC with single-path multiple VCs during the design generation phase. This method defines the NoC-based specifications and architecture configuration, including synthesis constraints. It implements automatic allocation of component modules with single-path multiple VCs, automatic checking for synthesis problems, and, when synthesis problems are detected, automatically selecting VCs already used by the component to automatically avoid the problems. Therefore, it can improve the efficiency of single-path multiple VC allocation for instantiation of components within a NoC, while simultaneously checking for synthesis problems in a NoC with single-path multiple VCs during the design generation phase, automatically avoiding synthesis problems, and further checking and avoiding deadlock problems introduced by VC reallocation.

[0240] Figure 10 A schematic diagram of the composition structure of a computer system provided in this embodiment of the disclosure. Figure 2 ,like Figure 10As shown, the computer system 1000 includes a server 1010, which includes an input / output unit 1011, a memory 1012, and a processor 1020. The server 1020 is capable of executing one or more units. In this invention, the term "computer-readable medium" refers to any medium involved in providing instructions to the processor 1020, such as, but not limited to, optical discs, magnetic disks, read-only memory, random access memory, solid-state devices and drives, or any other tangible medium suitable for storing electrical signals, or a computer-readable signal medium, which may include transient media such as carrier waves. The input / output unit 1011 processes input from a user interface interface 1001 and an operation interface interface 1002, which may utilize input devices such as, but not limited to, a keyboard, mouse, touch device, or voice commands.

[0241] Server 1010 may be connected to an external storage device 1003, which may contain removable storage, such as, but not limited to, a portable hard drive, optical media (CD or DVD), disk media, or any other medium from which a computer can read executable instructions. Server 1010 may be connected to an output device 1004, such as a display that outputs data and other information to a user, and requests additional information from the user. The connection between server 1010 and user interface 1001, operating interface 1002, external storage 1003, and output device 1004 may be via wireless protocols, such as, but not limited to, the 802.11 standard, Bluetooth, or mobile phone protocols, or via physical transmission protocols, such as cables or fiber optics. Output device 1004 may also further serve as an input device for user interaction.

[0242] Processor 1020 may execute one or more modules.

[0243] The NoC single-path multi-VC configuration interface module 1021 can be configured to: receive the user's NoC specifications and architecture configuration, including but not limited to the single-path multi-VC configuration supported by each transport flow (corresponding to the channel configuration information in the aforementioned embodiments), the transport flow between INIU and TNIU, the NoC topology definition, and comprehensive constraints. In one embodiment, the single-path multi-VC configuration includes multiple target VC types corresponding to each transport flow. Based on the above NoC configuration, a list of NoC transport flows is extracted, and a NoC module connection graph is constructed. Transport flows are selected cyclically to obtain the list of NoC component modules and the list of NoC channels under their corresponding paths. In one embodiment, the routing algorithm used for path selection is a deterministic routing algorithm, and the path corresponding to the transport flow in the NoC is a single path.

[0244] The NoC single-path multi-VC deadlock detection and avoidance module 1022 can be configured to: cyclically select VC types based on the aforementioned single-path multi-VC configuration. In one embodiment, cyclically selecting VC types can be done by selecting from multiple target VC types corresponding to each transport flow in any order. In one embodiment, cyclically selecting target VC types can be done by setting an internal counter that increments from 0 to the maximum number of available VCs based on the number of target types corresponding to each transport flow, automatically selecting the VC types corresponding to the internal counter; cyclically selecting physical channel segments based on each physical channel segment through which the current transport flow passes, constructing a channel constraint graph corresponding to the currently selected target VC type; and checking for loop deadlock problems in NoC based on this channel constraint graph. In one embodiment, the multi-VC configuration corresponding to the transport flow is manually defined by the user; after a deadlock is detected, the deadlock problem and the detected loop are reported to the user. In one embodiment, the multi-VC configuration corresponding to the transport stream is automatically selected for testing. Upon detecting a deadlock, the channel constraint graph of the currently selected target VC type is reset to its state before any physical channel segment in the current transport stream is added. An internal counter is incremented, remaining available VC types are selected, and deadlock is rechecked. If no remaining available VC types exist, deadlock under this NoC configuration is unavoidable, and the detected loop is reported to the user. If no deadlock is found after traversing all transport streams, the NoC configuration of the multi-VC corresponding to the current transport stream is deadlock-free.

[0245] The NoC single-path multi-VC synthesis check and avoidance module 1023 can be configured to: cyclically select module components based on all component modules traversed by the current transport flow; allocate the VCs of the module components to the VC list of the module components under the current VC type; and check whether the number of VCs of the component modules meets the target synthesis constraints. The target synthesis constraints include, but are not limited to, the maximum number of VCs used by the component. After detecting a synthesis problem, the channel constraint graph of the current VC type is reset to the state before adding all physical channel segments of the aforementioned transport flow VCs. Among the VC types already used by the component modules, cyclically select VC types that do not overlap with the VC types already allocated to the current transport flow. If such a VC type does not exist, the synthesis problem under this NoC configuration is unavoidable, and the list of VCs currently used by the component is reported to the user. If such a VC type exists, the deadlock problem of reallocating VCs is further checked based on the channel constraint graph of that VC type. If no synthesis problem is found after traversing all transport flows, the current single-path multi-VC NoC configuration is without synthesis problems.

[0246] The NoC single-path multi-VC RTL generation module 1024 can be configured to: generate RTL code for a single-path multi-virtual-channel NoC without deadlock or synthesis problems, based on the VCs allocated by all component modules configured by the NoC component virtual channel allocation module 1023, combined with Python+HDL hybrid code.

[0247] The embodiments disclosed herein have at least the following advantages: On the one hand, to address the problem of low efficiency in manually allocating single-path multi-VC configurations of NoC components in related technologies, this disclosure presents a method for automatically allocating single-path multi-virtual channels for NoC components. It defines the method steps for automatically allocating multiple virtual channels for NoC components based on the specifications and architecture configuration of NoC, thereby improving the efficiency of single-path multi-VC configuration allocation for instantiation of each component within NoC.

[0248] On the other hand, to address the problem of existing technologies failing to automatically identify and mitigate deadlock risks in NoCs with multiple VCs on a single path, a method is disclosed to check and avoid deadlock issues in NoCs with multiple VCs on a single path during the design generation phase. The method defines steps based on the NoC's specifications and architecture configuration, automatically constructing channel constraint graphs corresponding to VC types to check and avoid deadlocks, and automatically allocating virtual channels for NoC components. Therefore, it improves the efficiency of VC configuration allocation for instantiation of components within the NoC, while simultaneously checking and avoiding deadlock issues in NoCs with multiple VCs on a single path during the design generation phase.

[0249] On the other hand, to address the existing technology's inability to automatically identify and avoid synthesis problems involving multiple VC NoCs on a single path, a method is disclosed for checking and avoiding synthesis problems involving multiple VC NoCs on a single path during the design generation phase. This method defines VC allocation, checks for compliance with synthesis constraints, and, when synthesis problems occur, reallocation of VCs based on the types of VCs already used by the component modules to automatically avoid synthesis problems. Furthermore, it automatically checks and avoids deadlock problems introduced by VC reallocation based on the channel constraint graph.

[0250] In summary, the embodiments of this disclosure provide a system and method for allocating single-path multiple virtual channels and avoiding deadlock in a network-on-a-chip (NoC), improving the efficiency of single-path multiple VC allocation for instantiated components within a NoC, checking and avoiding deadlock issues in NoCs with single-path multiple VCs during the design and generation phase, and checking and avoiding comprehensive issues in NoCs with single-path multiple VCs during the design and generation phase.

[0251] Based on the foregoing embodiments, this disclosure provides a virtual channel allocation device for a network-on-a-chip (NIC). The NIC includes various modules and units included in each module, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0252] Figure 11 This is a schematic diagram of the composition structure of a virtual channel allocation device for an on-chip network provided in an embodiment of this disclosure, as shown below. Figure 11 As shown, the on-chip network virtual channel allocation device 700 includes: a first acquisition module 710 and an inspection and allocation module 720, wherein: The first acquisition module 710 is used to acquire the network connection relationship between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and the channel configuration information corresponding to each transport stream; the transport stream represents the access connection from one of the multiple component modules to one of the multiple component modules to a target network interface. The inspection and allocation module 720 is used to determine multiple virtual channel types corresponding to a transport flow based on the channel configuration information corresponding to the transport flow, and to perform channel loop checks for the transport flow under the corresponding multiple virtual channel types based on the network connection relationship. Based on the inspection results, virtual channel allocation is performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types.

[0253] In some embodiments, the channel configuration information includes at least one of the following: number of target types, multiple target virtual channel types; the number of target types represents the number of target virtual channel types corresponding to the transport stream.

[0254] In some embodiments, the channel configuration information includes the number of target types; the inspection and allocation module is further configured to: allocate virtual channels for the transport flow based on the inspection results corresponding to the transport flow under the corresponding number of virtual channel types, so as to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding number of target virtual channel types.

[0255] In some embodiments, the checking and allocation module is also used for one of the following: If the physical channel through which the transmission flow passes indicates that there is no loop under the corresponding virtual channel type, virtual channel allocation is performed for the transmission flow under that virtual channel type, and that virtual channel type is determined as a target virtual channel type corresponding to the transmission flow, until the number of target virtual channel types corresponding to the transmission flow reaches the target number of types. If the physical channel through which the transport flow passes is characterized by a loop under the corresponding virtual channel type, determine whether there is an unused virtual channel type among at least one first candidate virtual channel type of the transport flow, and if there is an unused virtual channel type among at least one first candidate virtual channel type of the transport flow, update the virtual channel type corresponding to the transport flow to the unused virtual channel type.

[0256] In some embodiments, at least one first candidate virtual channel type for each transport flow is obtained by dividing each transport flow according to a first partitioning rule; the checking and allocation module is further configured to: when there is no unused virtual channel type among the at least one first candidate virtual channel type of the transport flow, and the number of target virtual channel types corresponding to the transport flow is less than the number of target types, divide each transport flow into candidate virtual channel types according to a second partitioning rule to obtain multiple second candidate virtual channel types corresponding to each transport flow; based on the multiple second candidate virtual channel types corresponding to each transport flow, redetermine the multiple virtual channel types corresponding to each transport flow, and reallocate virtual channels for each transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which each transport flow flows under the corresponding multiple target virtual channel types.

[0257] In some embodiments, the channel configuration information includes multiple target virtual channel types; the checking and allocation module is further configured to: for each target virtual channel type corresponding to the transmission flow, if the check result of the physical channel through which the transmission flow flows under the target virtual channel type indicates that there is no loop, then perform virtual channel allocation for the transmission flow under the target virtual channel type.

[0258] In some embodiments, the inspection and allocation module is further configured to: determine the physical channel through which the transmission flow passes based on the network connection relationship, wherein the physical channel includes multiple physical channel segments; and perform loop checks on each physical channel segment in segments to obtain the inspection results of the physical channel through which the transmission flow passes under the virtual channel type.

[0259] In some embodiments, the inspection and allocation module is further configured to: sequentially add each physical channel segment to the channel connection relationship of the virtual channel type corresponding to the transport flow; the channel connection relationship is established based on at least one physical channel through which the inspected transport flow flows corresponding to the virtual channel type; if there is no loop in the channel connection relationship corresponding to the virtual channel type after adding all the physical channel segments through which the transport flow flows, then the inspection result of the physical channel through which the transport flow flows under the virtual channel type indicates that there is no loop, and the transport flow is regarded as an inspected transport flow corresponding to the virtual channel type.

[0260] In some embodiments, the inspection and allocation module is further configured to: sequentially add each physical channel segment to the channel connection relationship of the virtual channel type corresponding to the transport flow; the channel connection relationship is established based on at least one physical channel through which the transport flow has been inspected corresponding to the virtual channel type; if a loop exists in the channel connection relationship corresponding to the virtual channel type after adding any physical channel segment through which the transport flow flows, then the inspection result of the physical channel through which the transport flow flows under the virtual channel type indicates the existence of a loop.

[0261] In some embodiments, the inspection and allocation module is further configured to: when multiple transport flows correspond to the same virtual channel type, sequentially perform loop checks on each physical channel segment through which the transport flow passes for each of the multiple transport flows, so as to obtain the inspection results of the physical channels through which the multiple transport flows pass under the virtual channel type.

[0262] In some embodiments, the virtual channel configuration information corresponding to the component module includes an input virtual channel and / or an output virtual channel; the checking and allocation module is further configured to: allocate an input virtual channel and / or an output virtual channel to each component module through which the transport stream flows, based on the type identifier of the target virtual channel type.

[0263] In some embodiments, the checking and allocation module is further configured to: obtain the target synthesis constraints corresponding to the on-chip network; and, during the process of allocating virtual channels for the transport flow under the corresponding target virtual channel type, sequentially check for each component module through which the transport flow passes whether the total number of virtual channels and / or the total number of virtual channel types corresponding to at least one component module in the on-chip network after allocating virtual channels for the component module under the target virtual channel type satisfies the target synthesis constraints.

[0264] In some embodiments, the checking and allocation module is further configured to: if, after allocating virtual channels for a component module under a target virtual channel type, the total number of virtual channels and / or the total number of virtual channel types corresponding to the component module do not meet the target synthesis constraint, then remove each virtual channel allocated for the transmission flow under the target virtual channel type from at least one virtual channel corresponding to each component module through which the transmission flow passes, and obtain at least one virtual channel after reset for each component module; and select, from the virtual channel types to which the at least one virtual channel corresponding to the component module belongs, one that is available to the transmission flow and is different from the target virtual channel type as the updated target virtual channel type corresponding to the transmission flow.

[0265] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this disclosure can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0266] It should be noted that, in the embodiments of this disclosure, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this disclosure, or the parts that contribute to related technologies, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this disclosure are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0267] This disclosure provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0268] This disclosure provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0269] This disclosure provides a computer program including computer-readable code. When the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0270] This disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0271] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referenced interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0272] It should be noted that, Figure 12 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this disclosure, such as... Figure 12 As shown, the hardware entity of the computer device 800 includes: a processor 801, a communication interface 802, and a memory 803, wherein: Processor 801 typically controls the overall operation of computer device 800.

[0273] The communication interface 802 enables computer devices to communicate with other terminals or servers over a network.

[0274] The memory 803 is configured to store instructions and applications executable by the processor 801, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 801 and various modules in the computer device 800. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 801, the communication interface 802, and the memory 803 can be performed via bus 804.

[0275] It should be understood that the phrase "an embodiment" or "one embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this disclosure. Therefore, "in one embodiment" or "one embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this disclosure, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure. The sequence numbers of the above embodiments of this disclosure are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0276] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0277] In the several embodiments provided in this disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0278] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the embodiments of this disclosure may all be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the integrated unit may be implemented in hardware or in a combination of hardware and software functional units.

[0279] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0280] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0281] The above are merely embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for allocating virtual channels in an on-chip network, characterized in that, The method includes: The network connection relationships between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and channel configuration information corresponding to each transport stream are obtained; the transport stream represents an access connection from one of the multiple component modules to one of the multiple component modules to a target network interface. Based on the channel configuration information corresponding to the transport flow, multiple virtual channel types corresponding to a transport flow are determined. Based on the network connection relationship, channel loop checks are performed on the transport flow under the corresponding multiple virtual channel types. Based on the check results, virtual channels are allocated to the transport flow, and the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types is obtained.

2. The virtual channel allocation method for on-chip networks according to claim 1, characterized in that, The channel configuration information includes at least one of the following: number of target types, multiple target virtual channel types; the number of target types represents the number of target virtual channel types corresponding to the transport stream.

3. The virtual channel allocation method for on-chip networks according to claim 2, characterized in that, The channel configuration information includes the number of target types; Based on the inspection results, virtual channels are allocated for the transport flow, obtaining virtual channel configuration information for at least one component module through which the transport flow passes under the corresponding multiple target virtual channel types, including: Based on the inspection results corresponding to the transport flow under the corresponding multiple virtual channel types, virtual channel allocation is performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding number of target virtual channel types.

4. The virtual channel allocation method for on-chip networks according to claim 3, characterized in that, The virtual channel allocation for the transport stream based on the inspection results corresponding to the various virtual channel types under the respective virtual channel types includes one of the following: If the physical channel through which the transport flow passes indicates that there is no loop under the corresponding virtual channel type, virtual channel allocation is performed for the transport flow under the virtual channel type, and the virtual channel type is determined as a target virtual channel type corresponding to the transport flow, until the number of target virtual channel types corresponding to the transport flow reaches the target number. If the physical channel through which the transport flow passes indicates the presence of a loop under the corresponding virtual channel type, determine whether there is an unused virtual channel type among at least one first candidate virtual channel type of the transport flow, and if there is an unused virtual channel type among at least one first candidate virtual channel type of the transport flow, update the virtual channel type corresponding to the transport flow to the unused virtual channel type.

5. The virtual channel allocation method for on-chip networks according to claim 4, characterized in that, At least one first candidate virtual channel type for each of the transport streams is obtained by dividing each of the transport streams according to a first partitioning rule; The method further includes: If there is no unused virtual channel type in at least one first candidate virtual channel type of the transport flow, and the number of target virtual channel types corresponding to the transport flow is less than the number of target types, the transport flow is divided into candidate virtual channel types according to the second division rule to obtain multiple second candidate virtual channel types corresponding to each transport flow. Based on the multiple second candidate virtual channel types corresponding to each of the transport streams, the multiple virtual channel types corresponding to each of the transport streams are re-determined, and virtual channels are re-allocated for each of the transport streams, so as to obtain the virtual channel configuration information corresponding to at least one component module through which each of the transport streams flows under the corresponding multiple target virtual channel types.

6. The virtual channel allocation method for on-chip networks according to claim 2, characterized in that, The channel configuration information includes multiple target virtual channel types; The process of allocating virtual channels for the transport stream based on the inspection results includes: For each target virtual channel type corresponding to the transport flow, if the physical channel through which the transport flow passes indicates that there is no loop under the target virtual channel type, then a virtual channel is allocated for the transport flow under the target virtual channel type.

7. The virtual channel allocation method for on-chip networks according to claim 1, characterized in that, Performing a channel loop check on the transport flow under a corresponding virtual channel type includes: Based on the network connectivity, the physical channel through which the transmission stream flows is determined, and the physical channel includes multiple physical channel segments; Loop checks are performed on each physical channel segment to obtain the check results of the physical channels through which the transmission flow passes under the virtual channel type.

8. The virtual channel allocation method for on-chip networks according to claim 7, characterized in that, The segmented loop check for each physical channel segment includes: Each physical channel segment is sequentially added to the channel connection relationship of the virtual channel type corresponding to the transport stream; the channel connection relationship is established based on at least one physical channel through which the transport stream has been detected, corresponding to the virtual channel type; If, after adding all physical channel segments through which the transmission flow passes, there is no loop in the channel connection relationship corresponding to the virtual channel type, then it is determined that the physical channel through which the transmission flow passes does not have a loop in the inspection result of the virtual channel type, and the transmission flow is regarded as an inspected transmission flow corresponding to the virtual channel type.

9. The virtual channel allocation method for on-chip networks according to claim 7, characterized in that, The segmented loop check for each physical channel segment includes: Each physical channel segment is sequentially added to the channel connection relationship of the virtual channel type corresponding to the transport stream; the channel connection relationship is established based on at least one physical channel through which the transport stream has been detected, corresponding to the virtual channel type; If a loop exists in the channel connection relationship corresponding to the virtual channel type after adding any physical channel segment through which the transmission flow passes, then the inspection result of the physical channel through which the transmission flow passes under the virtual channel type indicates that a loop exists.

10. The virtual channel allocation method for on-chip networks according to claim 7, characterized in that, The method further includes: When multiple transport streams correspond to the same virtual channel type, loop checks are performed sequentially on each physical channel segment through which the transport stream flows, to obtain the check results of the physical channels through which the multiple transport streams flow under the virtual channel type.

11. The method for virtual channel allocation in an on-chip network according to any one of claims 1 to 10, characterized in that, The virtual channel configuration information corresponding to the component module includes input virtual channels and / or output virtual channels; Virtual channel allocation is performed for the transport stream to obtain virtual channel configuration information for at least one component module through which the transport stream flows, under a corresponding target virtual channel type, including: Based on the type identifier of the target virtual channel type, input virtual channels and / or output virtual channels are assigned to each of the component modules through which the transport stream flows.

12. The virtual channel allocation method for an on-chip network according to any one of claims 1 to 10, characterized in that, Also includes: Obtain the target synthesis constraints corresponding to the on-chip network; During the process of allocating virtual channels for the transport flow under the corresponding target virtual channel type, for each component module through which the transport flow passes, it is checked whether the total number of virtual channels and / or the total number of virtual channel types corresponding to at least one component module in the on-chip network after the virtual channel allocation for the component module under the target virtual channel type meets the target comprehensive constraint.

13. The virtual channel allocation method for on-chip networks according to claim 12, characterized in that, Also includes: If, after a component module performs virtual channel allocation under the target virtual channel type, the total number of virtual channels and / or the total number of virtual channel types corresponding to the component module do not meet the target comprehensive constraint, then each virtual channel allocated to the transmission flow under the target virtual channel type will be removed from at least one virtual channel corresponding to each component module through which the transmission flow passes, to obtain at least one virtual channel after reset for each component module. From the virtual channel types belonging to at least one virtual channel corresponding to the component module, select one that is available to the transport stream and is different from the target virtual channel type as the updated target virtual channel type corresponding to the transport stream.

14. A virtual channel allocation device for an on-chip network, characterized in that, include: The first acquisition module is used to acquire the network connection relationship between multiple component modules in the on-chip network, at least one transport stream in the on-chip network, and channel configuration information corresponding to each transport stream; the transport stream represents an access connection from one of the multiple component modules to one of the multiple component modules to a target network interface. The inspection and allocation module is used to determine multiple virtual channel types corresponding to a transport flow based on the channel configuration information corresponding to the transport flow, and to perform channel loop checks for the transport flow under the corresponding multiple virtual channel types based on the network connection relationship. Based on the inspection results, virtual channel allocation is performed for the transport flow to obtain the virtual channel configuration information corresponding to at least one component module through which the transport flow flows under the corresponding multiple target virtual channel types.

15. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 13.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

17. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 13.

Images