A network-on-chip hardware generation method, device, equipment and medium

Abstract

The application discloses a network-on-chip hardware generation method, device and equipment and a medium, and relates to the technical field of network-on-chip. The method comprises the following steps: acquiring a network configuration comprising an arbitrary directed graph physical topology, a flow set and a virtual network blocking relationship; establishing a candidate route transfer relationship; performing path connectivity verification under a non-blocking condition to determine a benchmark reachable path; based on the virtual network blocking relationship, the candidate route transfer relationship is corrected and modified to determine a reachable path under a resource competition scenario; performing deadlock detection according to the reachable path after the correction and modification; after the legality of the route is confirmed, hardware route selection logic is compiled and generated according to the legal route transfer relationship, and finally, a synthesizable network-on-chip hardware description language code is generated. Through the automatic verification and generation process, the application can generate a network-on-chip hardware without deadlock for an arbitrary topology structure, and the adaptability to complex protocols and heterogeneous environments is enhanced.

Description

Technical Field

[0001] This invention relates to the field of on-chip network technology, and in particular to an on-chip network hardware generation method, apparatus, device and medium. Background Technology

[0002] As the integration density of System-on-Chip (SoC) continues to increase, the number of processing units and modules, such as Central Processing Units (CPU), Graphics Processing Units (GPUs), Neural Processing Units (NPUs), caches, and Direct Memory Access (DMA) controllers, continues to grow. Traditional cross-switch or fixed-topology-based Network-on-Chip (NoC) systems (such as mesh or torus) are proving inadequate when faced with complex physical layouts, diverse bandwidth and latency requirements, and strict protocol order constraints. Interconnect networks in actual chip designs often exhibit irregular, asymmetric, hierarchical, or hybrid topologies.

[0003] Existing on-chip network design methods typically suffer from the following problems: First, routing policies are tightly bound to network topology, making it difficult to quickly and efficiently generate hardware for any given directed graph topology. Second, designers often need to rely on experience to manually determine route connectivity, the number of required virtual channels, and the existence of deadlock risks. This process is not only time-consuming but also error-prone, often revealing fatal problems only in late-stage simulation or even before tape-out, resulting in significant R&D cost losses. Finally, for complex on-chip bus protocols involving multiple channels such as request, response, probe, and release, simply multiplexing physical channels can easily lead to protocol deadlocks or data transmission sequence errors due to protocol-level blocking dependencies. Therefore, existing technologies lack an effective method that can flexibly adapt to arbitrary topologies, automatically perform route verification to avoid deadlock risks, and ultimately generate synthesizable hardware. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for generating on-chip network hardware, which can solve the technical problems of existing on-chip network design methods being unable to adapt to arbitrary topologies and relying on manual route verification, which easily introduces deadlock risks. The technical solution is as follows: On one hand, a method for generating on-chip network hardware is provided, the method comprising: Obtain network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning results, and virtual network blocking relationships; Based on the physical topology and the flow set, establish candidate routing and transfer relationships between each flow in the physical channel; For each flow in the flow set, perform path connectivity verification under non-blocking conditions: starting from the ingress channel accessed by the source terminal of each flow, traverse along the physical topology to the egress channel accessed by its destination terminal according to the candidate route transfer relationship, and determine the set of baseline reachable paths under non-resource blocking conditions. Given the existence of the virtual network blocking relationship, based on the virtual network partitioning results, the virtual network to which each flow belongs is identified, and according to the virtual network blocking relationship, physical channels occupied by other blocked virtual networks are excluded. The candidate route transfer relationship is constrained and corrected, and based on the baseline reachable path set, the reachable path set of each flow in the resource contention scenario is determined. Deadlock detection is performed based on the constrained set of reachable paths. Under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect a deadlock, the legality of the candidate route transition relationship is confirmed; Based on the confirmed valid candidate route transition relationships, compile and generate hardware routing selection logic; Based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results, synthesizable on-chip network hardware description language code is generated. The hardware description language code is used to describe the on-chip network hardware structure containing multiple routers.

[0005] On the other hand, an on-chip network hardware generation apparatus is provided, the apparatus comprising: The configuration acquisition module is used to acquire network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning, and virtual network blocking relationship. The candidate route establishment module is used to establish candidate route transfer relationships between physical channels for each flow based on the physical topology and the flow set; The non-blocking verification module is used to perform path connectivity verification under non-blocking conditions for each flow in the flow set: starting from the ingress channel accessed by the source terminal of each flow, according to the candidate route transfer relationship, traversing along the physical topology to the egress channel accessed by its destination terminal, and determining the set of baseline reachable paths under resource-free blocking conditions. The constraint correction module is used to identify the virtual network to which each flow belongs based on the virtual network partitioning result, under the premise that the virtual network blocking relationship exists, and to exclude physical channels occupied by other blocked virtual networks according to the blocking relationship, to perform constraint correction on the candidate route transfer relationship, and to determine the set of reachable paths for each flow under the resource contention scenario based on the baseline reachable path set. The deadlock detection module is used to perform deadlock detection based on the set of reachable paths after constraint correction. The legality verification module is used to verify the legality of the candidate route transition relationship under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect a deadlock. The hardware generation module is used to compile and generate hardware routing logic based on the confirmed legitimate candidate routing transition relationships, and generate synthesizable on-chip network hardware description language code based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results.

[0006] On the other hand, a computer device is provided, the computer device including a memory and a processor, the memory for storing computer programs, and the processor for executing the computer programs stored in the memory to implement the steps of the on-chip network hardware generation method described above.

[0007] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of the above-described method for generating on-chip network hardware.

[0008] The technical solution provided by this invention can bring at least the following beneficial effects: This invention uses arbitrary directed graphs as physical topology input, breaking the strong binding relationship between routing strategies and fixed topologies in traditional methods, and can adapt to irregular and asymmetric complex interconnection structures; through automated verification, compilation and generation processes, it significantly reduces the workload of manual design and lowers the risk of errors introduced by human negligence; by performing strict path connectivity verification, constraint correction considering blocking relationships, and deadlock detection based on directed channel dependency graphs before hardware generation, this invention can discover and avoid potential routing deadlocks and protocol deadlocks in the early stages of design, avoiding expensive debugging and modifications in the later simulation or physical implementation stages, thereby improving the reliability of the design and shortening the development cycle. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is an architecture diagram of an on-chip network hardware generation device according to an embodiment of the present invention; Figure 2This is a flowchart of an on-chip network hardware generation method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a general dateline routing according to an embodiment of the present invention; Figure 4 This is a schematic diagram of layered virtual channel packaging according to an embodiment of the present invention; Figure 5 This is a mapping diagram of protocol channels to NoC virtual networks according to an embodiment of the present invention; Figure 6 This is a schematic diagram of heterogeneous width adaptation and credit flow control according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a heterogeneous SoC interconnect topology according to a specific embodiment of the present invention; Figure 8 This is a hardware architecture diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0012] As mentioned above, this application provides a method for generating on-chip network hardware, which aims to solve the technical problems in the prior art where NoC design is too tightly bound to a specific topology, deadlock risk relies on manual analysis, and cannot be automatically adapted to the integration needs of complex SoCs.

[0013] The specific implementation of the above concept is described below.

[0014] Please refer to Figure 2 The present invention provides a method for generating on-chip network hardware, the method comprising: Step 201: Obtain network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning results, and virtual network blocking relationships; Step 202: Based on the physical topology and the flow set, establish candidate routing and transfer relationships between each flow in the physical channel; For each flow in the flow set, perform path connectivity verification under non-blocking conditions: starting from the ingress channel accessed by the source terminal of each flow, traverse along the physical topology to the egress channel accessed by its destination terminal according to the candidate route transfer relationship, and determine the set of baseline reachable paths under non-resource blocking conditions. Step 203: Under the premise that the virtual network blocking relationship exists, based on the virtual network partitioning result, identify the virtual network to which each flow belongs, and according to the virtual network blocking relationship, exclude physical channels occupied by other blocked virtual networks, constrain and correct the candidate route transfer relationship, and determine the set of reachable paths for each flow under the resource contention scenario based on the baseline reachable path set. Step 204: Perform deadlock detection based on the constrained set of reachable paths; Step 205: Under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect a deadlock, confirm the legality of the candidate route transition relationship; Step 206: Based on the confirmed valid candidate route transition relationships, compile and generate hardware routing selection logic; Step 207: Based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results, generate synthesizable on-chip network hardware description language code. The hardware description language code is used to describe the on-chip network hardware structure containing multiple routers.

[0015] In this embodiment of the invention, before generating synthesizable on-chip network hardware description language code, a series of formal verification steps are used to ensure that the defined routing policy is connected and deadlock-free under given arbitrary topology and constraints, thereby bringing design risks forward and realizing automated generation from high-level configuration to hardware.

[0016] The following description Figure 2 The execution method for each step is shown.

[0017] First, for step 201, obtain the network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning result, and virtual network blocking relationship; The physical topology in this step refers to the network structure diagram consisting of multiple router nodes and a set of unidirectional physical channels connecting them, which is the physical basis of Network on Chip (NoC). In this application's embodiments, the physical topology specifically refers to an arbitrary directed graph topology, capable of flexibly describing the complex interconnect structures commonly found in modern SoCs, including asymmetric, hierarchical, or physically-laid-driven structures.

[0018] Terminal information includes the location of the source / destination node corresponding to each terminal device and the identifier of the ingress / exgress channel it accesses.

[0019] A flow refers to a specific communication request from a source terminal to one or more destination terminals, with independent routing and resource requirements. A flow can be viewed as a logical communication channel, such as a data read request and response from a CPU core to a DDR memory controller. In this embodiment, a flow is defined by a flow model, which includes key attributes such as source terminal, destination terminal, and virtual network affiliation, and serves as the basic unit for route verification and resource allocation. A virtual network (VN) refers to multiple logically isolated sub-networks partitioned from shared physical network resources (such as physical channels). Virtual networks are a key technology for achieving resource isolation and meeting different Quality of Service (QoS) requirements.

[0020] Virtual network partitioning divides the flows in the flow set into multiple mutually exclusive or partially overlapping virtual networks based on protocol channels or communication domains; The blocking relationship between virtual networks is defined as the resource contention constraints that exist between the virtual networks.

[0021] This step receives an arbitrary directed graph of physical topology, capable of describing the irregular connections resulting from the chip's physical layout. Simultaneously, the input stream set defines the actual communication requirements, avoiding wasting hardware resources on non-existent communication paths. Furthermore, the virtual network partitioning and its blocking relationships provide a foundation for correct mapping of upper-layer protocols and avoidance of protocol-level deadlocks. Through this step, the abstract design intent is transformed into the data structures required for subsequent automated processing.

[0022] Step 202: Based on the physical topology and the flow set, establish candidate routing and transfer relationships between each flow in the physical channel; The purpose of this step is to initially filter out all theoretically possible route hops. For example, for a router, a packet belonging to flow F received from input port X might be forwarded to output port Y or Z. This step records these possible combinations (current channel, next channel, flow) to form a broad, unverified superset of routes. This design aims to decouple routing policies from specific verification logic, increasing the method's versatility.

[0023] Furthermore, for each flow in the flow set, a path connectivity verification under non-blocking conditions is performed: starting from the ingress channel accessed by the source terminal of each flow, based on the candidate route transfer relationship, the physical topology is traversed to the egress channel accessed by the destination terminal to determine the baseline reachable path set under non-resource blocking conditions. The purpose of this step is to confirm whether, under ideal conditions (i.e., no other flows competing for resources), each flow can successfully reach its destination from its source. Specifically, this verification process starts with the ingress channel connected to the flow's source terminal and, based on the candidate routing relationships established in the previous step, performs a depth-first or breadth-first traversal along the physical topology until it reaches the egress channel connected to the flow's destination terminal. Through this step, flows that cannot reach their destination due to improper routing strategies or topology connectivity are filtered out, and one or more baseline reachable paths are determined for each reachable flow, forming a baseline reachable path set.

[0024] Furthermore, in a preferred embodiment, the candidate routing transition relationship is represented by a triple (current channel identifier, next channel identifier, flow route identifier). Here, the channel identifier not only points to a physical link but must also be associated with its corresponding virtual channel number, thus uniquely identifying the physical hop of data within a specific virtual network. The flow route identifier uniquely represents a communication flow. This representation encapsulates all the information required for routing decisions, providing a foundation for subsequent formal verification.

[0025] Based on this triple representation, the path connectivity verification is refined into a recursive decision process.

[0026] Starting with the ingress channel identifier and its initial virtual channel identifier of the target flow to be verified, the following determination is recursively performed until the egress channel and its designated virtual channel of the destination terminal of the target flow are reached: Based on the existence of the candidate route transfer relationship, determine whether the target flow is allowed to jump from the current channel to the next channel; Based on the next channel identifier, verify whether the target physical channel corresponding to the next channel identifier is a legitimate neighbor channel; Based on the virtual channel number associated with the next channel, verify whether the virtual channel number conforms to the preset transfer rules of the virtual network to which the target flow belongs; wherein, each hop is bound to the flow route identifier of the target flow to uniquely associate the routing decision with the flow identity; If at least one complete path is obtained through traversal, and during the traversal process, for the same physical node, the same current virtual channel, and the same flow route identifier, there is only one valid next hop, then the target flow is determined to be connected under non-blocking conditions. All complete paths obtained through traversal are used as the baseline reachable path set.

[0027] The aforementioned Virtual Channel (VC) refers to logically dividing the buffer resources of a single physical channel into multiple independent queues or channels. Each virtual channel has its own independent buffer and flow control state. Virtual channel technology is a core means of solving network layer deadlock problems. For example, by forcibly switching virtual channels when packets cross specific boundaries (such as datalines), resource dependency loops can be broken, thereby ensuring deadlock-free routing.

[0028] Specifically, for a target flow to be verified, the verification process starts from its ingress channel and initial virtual channel, attempting to find a legitimate next channel. Each next channel determination involves multiple verifications: First, it checks if a matching triple (current channel, next channel, flow route identifier) ​​exists to confirm whether the routing policy allows hopping to that next channel; second, it verifies whether the next channel is a legitimate neighbor channel to prevent topology description errors; third, it verifies whether the virtual channel to which the next channel belongs conforms to the preset transfer rules of the virtual network where the target flow resides, for example, prohibiting hopping from the current virtual channel to a next virtual channel that does not conform to the rules. Only when all determinations pass is hopping to that next channel considered legitimate. By recursively executing this process until the destination terminal is reached, a complete reachable path is found. Gathering all found paths constitutes the baseline reachable path set. This process improves the reliability of verification by decomposing the complex path finding into a series of atomic, rigorously verifiable channel transfer determinations.

[0029] Furthermore, in the above recursive verification process, in order to handle the complex situation of shared channels and virtual network congestion, an availability determination of the candidate next channel is added before verifying whether the next virtual channel meets the transfer rules.

[0030] Specifically, the situation becomes complex when a candidate next physical channel is shared by multiple virtual networks. In this case, the decision logic first compares the number of the next virtual channel associated with the candidate next channel with the virtual network identifier of the virtual network to which the target flow belongs. If they match, the next virtual channel is determined to belong to the virtual network to which the target flow belongs; otherwise, it is directly excluded. If the candidate next channel is associated with multiple virtual channel numbers, it is determined to be a shared channel of multiple virtual networks, and further, based on the virtual network blocking relationship, it is determined whether the next virtual channel is available to the target flow in the current blocking state. If the next virtual channel does not match the virtual network to which the target flow belongs, or although it matches, it is unavailable in the current blocking state, the next virtual channel is excluded, and its corresponding candidate next channel does not undergo subsequent route validity verification. For example, if the protocol stipulates that the response flow must wait for the request flow to complete before using a shared channel, then when verifying the path of the response flow, if the request flow is in an active state, the shared channel is unavailable to the response flow and should be excluded. By introducing this availability determination step, the present invention can accurately simulate the behavioral constraints at the protocol level during the path verification stage, thereby eliminating paths that appear reachable when considering only the physical layer but would cause blocking or deadlock at the protocol layer in advance, ensuring the protocol correctness of the final generated route.

[0031] Step 203: Under the premise that the virtual network blocking relationship exists, based on the virtual network partitioning result, identify the virtual network to which each flow belongs, and according to the virtual network blocking relationship, exclude physical channels occupied by other blocked virtual networks, constrain and correct the candidate route transfer relationship, and determine the set of reachable paths for each flow under the resource contention scenario based on the baseline reachable path set. However, real-world on-chip networks experience resource contention. Therefore, given the existence of virtual network congestion relationships, this step further constrains and modifies the candidate route transition relationships. This step simulates resource consumption caused by protocol behavior or quality of service policies. For example, a high-priority video stream (belonging to VN1) might temporarily block a low-priority data backup stream (belonging to VN2). This step identifies the virtual network to which each stream belongs and, based on the virtual network congestion relationships, temporarily marks physical channels that might be occupied by VN1 as unavailable when verifying paths to VN2. Then, under this constraint, the reachability of the path is reassessed. In this way, paths that are infeasible in real-world contention scenarios are eliminated, thereby refining a more realistic and reliable set of reachable paths based on the baseline set of reachable paths.

[0032] Step 204: Perform deadlock detection based on the constrained set of reachable paths; Furthermore, based on the constrained set of reachable paths, a directed channel dependency graph for deadlock detection is constructed. The directed channel dependency graph depicts the routing transition dependencies on physical channels that are still shared by multiple virtual networks under blocking constraints, wherein each transition dependency originates from a valid route jump that any flow in the flow set can still use under blocking conditions. The system checks whether there is a directed loop in the directed channel dependency graph. If there is no directed loop, it is determined that no deadlock has been detected.

[0033] Furthermore, methods for constructing directed channel dependency graphs for deadlock detection include: When multiple virtual networks share the same physical channel, and the physical channel is still allowed to be used by other virtual networks after being blocked in at least one virtual network, the transfer dependencies between the virtual networks on the shared physical channel are recorded and constructed as directed edges. The direction of the directed edges is determined according to the blocking priority or resource request order of each virtual network.

[0034] In one specific implementation, after determining the practically feasible paths, deadlock becomes the next critical issue. This step performs deadlock detection based on the constrained set of reachable paths. Deadlock is essentially a resource loop waiting. This step formally proves the deadlock-free nature of the route by constructing an abstract directed path graph and detecting loops within it. Compared to traditional simulation methods, this static analysis method can identify all potential deadlock risks early in the design process without expending significant simulation time attempting to reproduce specific deadlock scenarios. It transforms deadlock verification from a probabilistic, incomplete dynamic process into a deterministic, complete static check.

[0035] In another preferred embodiment, the deadlock detection step is specified. It first constructs a directed path dependency graph for deadlock detection based on the constraint-corrected set of reachable paths.

[0036] Furthermore, based on the constrained set of reachable paths, a directed channel dependency graph for deadlock detection is constructed. The directed channel dependency graph uses virtual channels as nodes and routing transition dependencies between virtual channels as directed edges. Each routing transition dependency indicates that: in the flow set, there exists at least one flow where, under blocking constraints, when a valid routing path of that flow jumps from the current virtual channel to the next virtual channel, there is a waiting dependency between the current virtual channel and the next virtual channel. The presence of directed loops in the directed channel dependency graph is detected; if no directed loop exists, it is determined that no deadlock has been detected.

[0037] Specifically, the nodes of this directed channel dependency graph are each virtual channel, and the directed edges are used to depict the routing transition dependencies on physical channels that are still shared by multiple virtual networks under congestion constraints. Each transition dependency originates from a legal route hop that any flow in the flow set can still use under congestion conditions. Specifically, if a flow needs to hop from the current virtual channel to the next virtual channel on a legal path, a directed edge is added to the directed channel dependency graph from the current virtual channel to the next virtual channel. This edge represents the data packet waiting for resources in the next virtual channel on the current virtual channel. Once all hops on all legal paths have been converted into directed edges in the graph, the graph fully depicts all possible routing transition dependencies in the entire network.

[0038] Subsequently, the core task of deadlock detection shifts to detecting whether a directed cycle exists in the directed path dependency graph. Taking the directed cycle VC_A→VC_B→VC_C→VC_A as an example, its physical meaning is: there is a possibility that a data packet occupies VC_A waiting for VC_B, another data packet occupies VC_B waiting for VC_C, and a third data packet occupies VC_C waiting for VC_A, forming an unresolvable circular wait. The presence of a directed cycle in the graph is detected using a standard graph theory loop detection algorithm. If no directed cycle exists, it is determined that no deadlock has been detected. This method can theoretically prove that the routing strategy is deadlock-free under given constraints, which is unmatched by traditional dynamic simulation methods.

[0039] In a more specific implementation, the method for constructing the directed channel dependency graph for deadlock detection is further clarified. The generation of directed edges, particularly in scenarios where multiple virtual networks share the same physical channel, follows specific rules: when multiple virtual networks share the same physical channel, and the physical channel is still allowed to be used by other virtual networks even after being blocked in at least one virtual network, the transition dependencies between the virtual networks on the shared physical channel are recorded and constructed as directed edges. For example, flow A jumps from the current virtual channel of input port P_in to the next virtual channel of output port P_out in the first virtual network, while flow B may also jump from the current virtual channel of input port P_in to the next virtual channel of output port P_out in the second virtual network; thus, a dependency relationship is established between the two virtual channels on the shared physical channel. The direction of the directed edges is determined according to the blocking priority or resource request order of each virtual network. For example, if the blocking priority of the first virtual network is specified to be higher than that of the second virtual network, then during resource contention, the second virtual network must wait for the first virtual network, and the dependency relationship points from the virtual channel used by the second virtual network to the virtual channel used by the first virtual network. In this way, the abstract priority and blocking rules are materialized as the directions of edges in the directed channel dependency graph, so that the dependency graph can accurately reflect the complex resource competition logic.

[0040] Step 205: Under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect deadlock, confirm the legality of the route and verify the legality of the candidate route transition relationship. Step 206: Based on the confirmed valid candidate route transition relationships, compile and generate hardware routing selection logic; Furthermore, before compiling and generating the hardware routing logic, the following steps are also included: Based on all source and destination terminal pairs in the physical topology, obtain the shortest path set; Based on the continuous physical channel sequence in the shortest path, a directed channel dependency graph for virtual channel allocation is constructed. The physical channel covering the most unprocessed loops is selected as the dataline edge using a greedy strategy; Calculate the maximum number of times k, which is the shortest path traverses the edge of the dateline, and set the number of virtual channels required for the flow to k+1. On each shortest path, starting from the initial virtual channel, each time a dataline edge is traversed, the current virtual channel number is incremented to the next stage. The hardware routing logic only allows data packets to switch virtual channels in an incremental manner according to the stage sequence.

[0041] Furthermore, the set of shortest paths is divided into multiple virtual channel layers, such that the physical channels contained in all paths within each layer constitute an acyclic directed graph. Each flow is assigned to the smallest numbered layer that satisfies its complete set of path edges, and the hardware only allows the flow to be forwarded along the path within the layer to which it is assigned, prohibiting cross-layer jumps.

[0042] In another preferred embodiment, the present invention also provides a specific deadlock-free route generation algorithm applicable to any irregular topology, namely the general dateline routing method.

[0043] The dateline routing method in this embodiment is a key concept for implementing deadlock-free routing algorithms in arbitrary topologies. It refers to one or more "dividers" artificially created to break circular dependencies after analyzing the dependencies between channels. These dividers typically correspond to one or more physical channels in the network (called dateline edges). The routing algorithm stipulates that when a data packet travels along its path, it must switch to a new, independent resource set (usually a higher-numbered virtual channel) each time it crosses a dateline edge, thereby forcing a unidirectional path forward, fundamentally eliminating the conditions for circular waiting and avoiding deadlock.

[0044] Please see Figure 3 This method does not rely on the regularity of the topology; instead, it proactively constructs deadlock-free paths using a general algorithm. First, it computes the set of shortest paths between all source and destination terminal pairs in the network using Dijkstra's algorithm or a similar algorithm. These shortest paths constitute the foundation for efficient data transmission. Then, based on the consecutive physical channel sequences within this set of shortest paths, an initial directed channel dependency graph is constructed for virtual channel allocation. (See diagram below.) Figure 3 As shown in the upper part, the initial directed channel dependency graph contains directed loops (e.g., A→B→C→D→E→A). These directed loops represent circular waiting relationships between data packets, which are potential deadlock sources and need to be broken.

[0045] To break these loops, this method introduces the concept of a dateline. It iteratively selects the physical channels that can "cut off" the most currently unprocessed loops using a greedy strategy and marks them as dateline edges. For example... Figure 3 As shown, the algorithm identifies the physical channel that covers the most loops (e.g., the loop A→B→C→D→E→A) and marks it as a dateline edge (indicated by a thick line or special marker in the diagram). This dateline edge cuts off the original loop, making the dependency graph acyclic. This process continues until all loops in the dependency graph have been cut off by at least one dateline edge.

[0046] Next, the algorithm counts the maximum number of times any path traverses the dateline edge among all shortest paths, denoted as k. For example... Figure 3 As shown in the lower part, a shortest path from the source terminal to the destination terminal traverses two dataline edges in sequence, so k=2. Based on this, the number of virtual channels required for this flow is set to k+1=3, corresponding to the three stages VC0, VC1, and VC2. This number is the theoretical minimum to guarantee no deadlock.

[0047] Finally, a rule is enforced in the hardware routing logic: the virtual channel number used by a data packet must increment each time it traverses a dataline edge along the path. For example, starting from the initial virtual channel VC0, after traversing the first dataline, it must switch to the next virtual channel VC1, then to the next one VC2, and so on, and switching is only allowed in this incrementing order (VC0→VC1→VC2), hopping or decrementing is prohibited. Because the virtual channel number can only increment in one direction, loops are avoided in the dependency graph, maintaining the performance advantage of shortest path routing while ensuring no deadlock for any topology.

[0048] As a variation or supplement to the aforementioned dateline method, another implementation proposes a layered virtual channel packaging method, such as... Figure 4 As shown. This method also aims to automatically assign virtual channels for arbitrary topologies to achieve deadlock-free operation. First, the method takes the set of shortest paths for all source and destination terminal pairs as input, such as... Figure 4 As shown at the top (paths P1 to P6). Next, the shortest path set is preprocessed: duplicate edge sequences are removed, and paths that belong to strict subsets of other paths are pruned, retaining the critical path edge set (e.g., removing redundant paths P3 and P5 in the figure).

[0049] Then, the method attempts to divide the preprocessed, simplified shortest path set into multiple virtual channel layers. The core constraint here is that within the same virtual channel layer, the set of physical channels contained in all paths must form an acyclic directed graph (DAG). For example... Figure 4 As shown, layer VC0 contains paths A→B→C and D→E. The edges of these two paths, when merged, do not form any directed cycles, thus satisfying the acyclic condition. Similarly, paths C→A and B→D→E in layer VC1, and paths E→B and A→D in layer VC2, do not form directed cycles within their respective layers. This means that any flows allocated to the same virtual channel layer will never form a cycle in their resource dependencies.

[0050] The algorithm searches to find the minimum number of layers that satisfy the above acyclic constraints (e.g., ...). Figure 4 The virtual channel is assigned to three layers (VC0, VC1, and VC2) and each flow is assigned to the lowest-numbered virtual channel layer that can accommodate its complete path edge set. For example, if the complete path A→B→C of flow F1 can be accommodated by the lowest-numbered VC0 layer, then F1 is assigned to the VC0 layer and transmitted using virtual channel number 0 within that layer.

[0051] In the final hardware, routing logic is strictly limited: each flow can only be forwarded within its assigned virtual channel layer, using the virtual channel number corresponding to that layer; cross-layer hopping is prohibited in the hardware. For example, a flow assigned to the VC0 layer must always use virtual channel number 0 along its entire path from the source terminal to the destination terminal, and must not switch to the virtual channel numbers of the VC1 or VC2 layers. By decomposing the complex global deadlock problem into a local problem of maintaining an acyclic directed graph within each layer, this method provides a deadlock-free solution that differs from the dateline concept but achieves the same effect.

[0052] Step 207: Based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results, generate synthesizable on-chip network hardware description language code. The hardware description language code is used to describe the on-chip network hardware structure containing multiple routers.

[0053] The Hardware Description Language (HDL) in this embodiment refers to a dedicated computer language, such as Verilog HDL or VHDL, used to describe the structure, design, and behavior of digital circuits. The method proposed in this application produces HDL code that can be directly read and processed by Electronic Design Automation (EDA) tools (such as synthesizers). This code can be automatically converted into the actual gate-level circuit netlist that constitutes the on-chip network hardware.

[0054] Specifically, for confirmed valid routes, this method compiles and generates hardware routing logic. This step is the endpoint of design automation, transforming abstract, validated routing relationships—for example, the virtual channel VC2 where flow F, when at input port X of router R, should be forwarded to output port Y—into concrete hardware circuit logic implemented by logic gates. Then, based on this hardware routing logic, routing decision circuits for each router are generated; physical channel connections between routers are instantiated based on the physical topology; port connections between each terminal and its corresponding router are instantiated based on terminal information; and resource parameters (such as buffer depth, channel number, etc.) for each virtual channel are configured based on the virtual network partitioning results. Combining all the above instantiation results, the final output is synthesizable on-chip network hardware description language code.

[0055] In one specific implementation, the present invention addresses the problem of how to securely run standard on-chip bus protocols (such as AXI and TileLink) on general-purpose NoCs. Figure 5 As shown, this method maps each protocol channel of a multi-channel protocol (e.g., AXI has 5 channels: write address AW, write data W, write response B, read address AR, and read response R) to an independent virtual network. For example, AW is mapped to VN0, W to VN1, B to VN2, AR to VN3, and R to VN4. The protocol channels are mapped into streams according to transmission direction, address, and identifier, injected at the NoC ingress point, and extracted at the egress point.

[0056] Next, based on the inherent sequence dependencies in the protocol specification, congestion constraints between virtual networks are established. The AXI protocol specifies that sequence dependencies include: The write address (AW) must be received before the write data (W) can be sent; that is, write data VN1 blocks write address VN0. The read address (AR) must be received before the read data (R) can be returned; that is, the read response VN4 blocks the read address VN3. The write response (B) can only be released after the write address (AW) has been transferred, that is, VN2 blocks VN0.

[0057] Meanwhile, the response stream can only release its corresponding request stream resources after the transmission is complete, and the request stream remains blocked until the corresponding response stream completes its transmission, thus forming a complete bidirectional sequential dependency constraint. For example, the virtual network resources occupied by the read address AR are only released after the read response R returns to the requesting end; before the read response R is completed, the virtual network channel corresponding to the read address AR remains blocked, and new read requests are not allowed to occupy the channel.

[0058] When these blocking relationships are input into the aforementioned constraint correction and verification process, the system can automatically ensure that the generated routes do not violate these protocol orders, thereby avoiding protocol-level deadlocks caused by out-of-order delivery or resource contention. This allows NoC to function as a protocol-independent transport layer, enhancing its applicability and reusability in complex SoCs.

[0059] Furthermore, to address the heterogeneous integration challenges prevalent in modern SoCs, this invention also provides a method for automatically handling data bit-width mismatch issues. For example... Figure 6 As shown, the configuration information of the physical topology includes not only the connection relationships, but also the data bit width of each router, terminal, and physical channel.

[0060] When the method detects an integer multiple of the bit width difference between two adjacent modules (e.g., a 64-bit CPU and a 32-bit DSP), it automatically inserts a flow control unit splitting module or merging module between them.

[0061] The flow control unit (flit) in this embodiment is the smallest unit for flow control in the network. A data packet can be divided into multiple flits for transmission. In this embodiment, when modules with different data bit widths are interconnected, the flit is the basic granularity for segmentation, merging, and credit flow control calculation, ensuring the continuity and correctness of data transmission between heterogeneous width interfaces.

[0062] like Figure 6 As shown in Scenario 1 above, wide-to-narrow transmission from 64-bit to 32-bit requires inserting a 64-bit to 32-bit flow control unit splitting module. This splits a complete 64-bit flow control unit, including header, payload, and trailer, into two 32-bit flow control units for transmission. Conversely, as... Figure 6As shown in Scenario 2 below, for narrow-to-wide transmission from 32-bit to 64-bit, a 32-bit to 64-bit flow control unit merging module needs to be inserted to merge multiple 32-bit flow control units into a single 64-bit flow control unit.

[0063] This insertion is fully automatic and collaboratively adjusted, specifically including three synchronized adjustments: First, the start of packet (SOP) and end of packet (EOP) flags of the flow control unit are expanded or compressed accordingly. For example... Figure 6 As shown, in the wide-to-narrow splitting scenario, the 1-bit header flag of a 64-bit flow control unit needs to be expanded into the header flags carried by two separate 32-bit flow control units after splitting; similarly, the tail flag needs to be expanded into the last narrow flow control unit. In the narrow-to-wide merging scenario, the header and tail flags of multiple 32-bit flow control units need to be compressed and merged into a single 1-bit header and tail flag of a 64-bit flow control unit to ensure that the receiving end can correctly reassemble the data packets.

[0064] Secondly, the depth of the virtual channel buffer is calculated proportionally to the bit width. For example... Figure 6 As shown in the buffer capacity conversion label, when transferring from a 64-bit channel to a 32-bit channel, the depth of the virtual channel buffer on the 32-bit side needs to be increased proportionally (for example, if the depth on the 64-bit side is 4, the depth on the 32-bit side is converted to 4×2=8) to ensure equivalent buffer capacity; conversely, when transferring from 32-bit to 64-bit, the depth on the 64-bit side is decreased proportionally (for example, if the depth on the 32-bit side is 8, the depth on the 64-bit side is converted to 8÷2=4).

[0065] Furthermore, the credit value in the credit return mechanism is also proportionally calculated based on the number of transmission units. For example... Figure 6 As shown in the credit conversion diagram, taking the 64-bit to 32-bit split as an example, the 32-bit side only returns one credit to the upstream 64-bit side after consuming two flow control units. This is because a 64-bit flow control unit is split into two 32-bit flow control units for transmission. Downstream processing of two 32-bit flow control units is equivalent to processing a complete 64-bit flow control unit, hence only returning one credit.

[0066] Through the above three synchronous adjustments, the present invention ensures the integrity and correctness of the end-to-end credit flow control protocol, making the interconnection between heterogeneous modules transparent and reliable, and eliminating the need for designers to manually handle the complex timing and flow control issues caused by bit width conversion.

[0067] Please see Figure 1 This application also provides an on-chip network hardware generation apparatus, comprising: The configuration acquisition module 11 is used to acquire network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning result, and virtual network blocking relationship; The candidate route establishment module 12 is used to establish candidate route transfer relationships between physical channels for each flow based on the physical topology and the flow set; The non-blocking verification module 13 is used to perform path connectivity verification under non-blocking conditions for each flow in the flow set: starting from the ingress channel accessed by the source terminal of each flow, according to the candidate route transfer relationship, traversing along the physical topology to the egress channel accessed by its destination terminal, and determining the set of baseline reachable paths under non-resource blocking conditions. The constraint correction module 14 is used to identify the virtual network to which each flow belongs based on the virtual network partitioning result, under the premise that the virtual network blocking relationship exists, and to exclude physical channels occupied by other blocked virtual networks according to the virtual network blocking relationship, to perform constraint correction on the candidate route transfer relationship, and to determine the set of reachable paths for each flow under the resource contention scenario based on the baseline reachable path set. Deadlock detection module 15 is used to perform deadlock detection based on the set of reachable paths after constraint correction; The legality confirmation module 16 is used to confirm the legality of the candidate route transition relationship under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect a deadlock. The hardware generation module 17 is used to compile and generate hardware routing selection logic based on the confirmed legal candidate routing transition relationship, and generate synthesizable on-chip network hardware description language code based on the hardware routing selection logic, the physical topology, the terminal information, and the virtual network partitioning result.

[0068] It should be noted that the on-chip network hardware generation device provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the on-chip network hardware generation device and the on-chip network hardware generation method embodiment provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiment, which will not be repeated here.

[0069] To more specifically illustrate the synergistic effect of the various technical features in this invention and their comprehensive technical benefits, the following will combine... Figure 7The following example illustrates a specific heterogeneous SoC (System-on-a-Chip) interconnect topology. This embodiment simulates a core computing chip in a typical autonomous driving or advanced driver assistance systems (ADAS) application scenario. Figure 7 As shown, the SoC includes a high-performance CPU cluster 701 (e.g., ARM Cortex-A series, using the AXI4 bus protocol, with a data width of 64 bits), an NPU (Neural Processing Unit) 702 for performing neural network calculations (using a custom bus, with a data width of 128 bits), a DSP 703 for signal processing (with a data width of 32 bits), and a DDR controller 704 connected to external memory. These core processing units and memory interfaces are interconnected through an on-chip network NoC 710. The topology of the NoC 710 is irregular, consisting of four routers R1 (711), R2 (712), R3 (713), and R4 (714), whose connection relationship is customized according to the chip's physical layout and performance requirements, rather than a standard Mesh or Torus structure.

[0070] In this embodiment, the designer uses the method described in this invention to automatically generate the hardware for this NoC 710. First, the designer inputs the network configuration into the generation tool. The physical topology is... Figure 7 The connection relationships are shown. The stream set may include: high-bandwidth read / write streams between CPU cluster 701 and DDR controller 704, large-block data transfer streams between NPU 702 and DDR controller 704, and low-speed streams of CPU cluster 701 sending control commands to DSP 703. Regarding virtual network partitioning, to ensure the correctness of the AXI4 protocol, the AXI4 bus of CPU cluster 701 is mapped to multiple virtual networks, and their blocking relationships are defined according to protocol rules (as described above).

[0071] Next, the method of this invention begins to execute. It first applies a general dateline route generation algorithm. Through analysis... Figure 7 Given the topology and defined flows, this method constructs a channel dependency graph and detects potential loops, such as the dependency R1(711)->R2(712)->R1(711). To break this loop, the algorithm might select a physical channel between router R2(712) and router R1(711) as a dataline edge 730. Then, by calculating the maximum number of times k traverses this dataline edge by all shortest paths, the required number of virtual channels is determined to be k+1.

[0072] Simultaneously, the method addresses the heterogeneous width adaptation issue. A bit width mismatch exists on the communication path between CPU cluster 701 (64-bit) and DSP 703 (32-bit) via router R1 (711). The method of this invention automatically detects this and automatically inserts a width adapter 720 between router R1 (711) and router R3 (713), or at the input port of router R3 (713). This width adapter 720 is responsible for splitting the 64-bit flit from R1 into two 32-bit flits before sending them to R3, while correctly handling credit flow control calculations.

[0073] During the path verification phase, the method comprehensively considers dateline rules, virtual network congestion relationships (derived from AXI4 protocol mapping), and physical connectivity. For example, when verifying the path from CPU cluster 701 to DDR controller 704, it must not only ensure physical reachability but also that virtual channel switching on the path conforms to dateline rules (i.e., the VC number must increase when traversing dateline edge 730) and does not violate the internal order dependencies of the AXI4 protocol. Only routes that pass all these rigorous checks are deemed legitimate.

[0074] Finally, after all verifications are successful, the hardware generation module solidifies all this logic into hardware. It generates Verilog or VHDL code describing routers R1 through R4, width adapter 720, and the physical channels between them. Each router's routing table or routing calculation logic contains verified, deadlock-free routing decisions. For example, the logic for router R2 (712) might include rules such as: if a packet's destination requires traversing dataline edge 730, it must be assigned to a virtual channel with a higher VC number than the current one. The final generated HDL code is a complete NoC design that can be directly used in subsequent chip implementation processes, supporting… Figure 7 The irregular topology shown ensures the correct operation of the AXI4 protocol, automatically resolves the width mismatch problem, and avoids network deadlock through the dateline mechanism.

[0075] This highly integrated embodiment demonstrates that the present invention unifies multiple complex design problems (irregular topology routing, deadlock avoidance, protocol adaptation, and heterogeneous integration) that previously required manual handling by designers and were prone to errors into an automated process. Various technical features work synergistically; for example, the dateline method provides a deadlock-free foundation for arbitrary topologies, protocol mapping solves deadlock problems in upper-layer protocols, and width adaptation solves physical integration issues. This synergy significantly improves the overall performance and reliability of the design, enabling automation and reliability verification of complex SoC interconnect designs. An embodiment of this application also provides a computer device; please refer to [reference needed]. Figure 8 The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the on-chip network hardware generation method provided in the above-described method embodiments.

[0076] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement an on-chip network hardware generation method provided in the above-described method embodiments.

[0077] Embodiments of this application also provide a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform any of the on-chip network hardware generation methods described in the above embodiments.

[0078] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0079] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0080] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, 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 said element.

[0081] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating on-chip network hardware, characterized in that, The method includes: Obtain network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning results, and virtual network blocking relationships; Based on the physical topology and the flow set, establish candidate routing and transfer relationships between each flow in the physical channel; For each flow in the flow set, perform path connectivity verification under non-blocking conditions: starting from the ingress channel accessed by the source terminal of each flow, traverse along the physical topology to the egress channel accessed by its destination terminal according to the candidate route transfer relationship, and determine the set of baseline reachable paths under non-resource blocking conditions. Given the existence of the virtual network blocking relationship, based on the virtual network partitioning results, the virtual network to which each flow belongs is identified, and according to the virtual network blocking relationship, physical channels occupied by other blocked virtual networks are excluded. The candidate route transfer relationship is constrained and corrected, and based on the baseline reachable path set, the reachable path set of each flow in the resource contention scenario is determined. Deadlock detection is performed based on the constrained set of reachable paths. Under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and deadlock detection does not detect deadlock, the legality of the candidate route transition relationship is confirmed; Based on the confirmed valid candidate route transition relationships, compile and generate hardware routing selection logic; Based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results, synthesizable on-chip network hardware description language code is generated. The hardware description language code is used to describe the on-chip network hardware structure containing multiple routers.

2. The method according to claim 1, characterized in that, The candidate route transfer relationship is represented by a triple, which includes the current channel identifier, the next channel identifier, and the flow route identifier; wherein, each channel identifier is associated with its virtual channel number to uniquely determine the physical channel hop within a specific virtual network; The path connectivity verification specifically includes: Starting with the ingress channel identifier and its initial virtual channel identifier of the target flow to be verified, the following determination is recursively performed until the egress channel and its designated virtual channel of the destination terminal of the target flow are reached: Based on the existence of the candidate route transfer relationship, determine whether the target flow is allowed to jump from the current channel to the next channel; Based on the next channel identifier, verify whether the target physical channel corresponding to the next channel identifier is a legitimate neighbor channel; Based on the virtual channel number associated with the next channel, verify whether the virtual channel number conforms to the preset transfer rules of the virtual network to which the target flow belongs; wherein, each hop is bound to the flow route identifier of the target flow to uniquely associate the routing decision with the flow identity; If at least one complete path is obtained through traversal, and during the traversal process, for the same physical node, the same current virtual channel, and the same flow route identifier, there is only one valid next hop, then the target flow is determined to be connected under non-blocking conditions. All complete paths obtained through traversal are used as the baseline reachable path set.

3. The method according to claim 2, characterized in that, Before verifying whether the target virtual channel number conforms to the preset transfer rules of the virtual network to which the target flow belongs, the following availability determination is also performed on the next virtual channel associated with each candidate next channel for each hop: The number of the next virtual channel is compared with the virtual network identifier of the virtual network to which the target flow belongs; If the comparison matches, it is determined that the next virtual channel belongs to the virtual network to which the target flow belongs; If the candidate next channel is associated with multiple virtual channel numbers, then the candidate next channel is determined to be a shared channel of multiple virtual networks, and further, based on the blocking relationship of the virtual networks, it is determined whether the next virtual channel is available to the target flow under the current blocking state; If the next virtual channel does not match the virtual network to which the target flow belongs, or if it matches but is unavailable under the current blocking state, the next virtual channel will be excluded, and its corresponding candidate next channel will not undergo subsequent route validity verification.

4. The method according to claim 1, characterized in that, The deadlock detection based on the constrained set of reachable paths includes: Based on the set of reachable paths after constraint correction, a directed channel dependency graph for deadlock detection is constructed; the directed channel dependency graph uses virtual channels as nodes and the routing transition dependencies between virtual channels as directed edges. Each routing dependency indicates that: in the flow set, there is at least one flow, under blocking constraints, when a valid routing path of the flow jumps from the current virtual channel to the next virtual channel, there is a waiting dependency between the current virtual channel and the next virtual channel; The system checks whether there is a directed loop in the directed channel dependency graph. If there is no directed loop, it is determined that no deadlock has been detected.

5. The method according to claim 4, characterized in that, The method for constructing the directed channel dependency graph for deadlock detection includes: When multiple virtual networks share the same physical channel, and the physical channel is blocked in at least one virtual network but is still allowed to be used by other virtual networks, the transfer dependency relationship between the virtual channels of each virtual network on the shared physical channel is recorded and constructed as a directed edge; the direction of the directed edge is determined according to the blocking priority or resource request order of each virtual network.

6. The method according to claim 1, characterized in that, After confirming the legality of the candidate route transition relationship, the process further includes the following steps before compiling and generating the hardware routing selection logic: Based on all source and destination terminal pairs in the physical topology, obtain the shortest path set; Based on the continuous physical channel sequence in the shortest path set, a directed channel dependency graph for virtual channel allocation is constructed. The physical channel covering the most unprocessed loops is selected as the dataline edge using a greedy strategy; Calculate the maximum number of times k, which is the shortest path traverses the edge of the dateline, and set the number of virtual channels required for the flow to k+1. On each shortest path, starting from the initial virtual channel, each time a dataline edge is traversed, the current virtual channel number is incremented to the next stage. The hardware routing logic only allows data packets to switch virtual channels in an incremental manner according to the stage sequence.

7. The method according to claim 6, characterized in that, Also includes: The set of shortest paths is divided into multiple virtual channel layers, such that the physical channels contained in all paths within each layer form an acyclic directed graph. Each flow is assigned to the smallest numbered layer that satisfies its complete set of path edges, and the hardware only allows the flow to be forwarded along the path within the layer to which it is assigned, prohibiting cross-layer jumps.

8. The method according to claim 1, characterized in that, The virtual network blocking relationship is generated by the protocol specification mapping of the multi-channel on-chip bus protocol. The mapping method includes: mapping each protocol channel as an independent virtual network according to the multiple protocol channels and their functions defined in the protocol specification. Based on the sequential dependencies of request, response, probe, and release in the protocol specification, blocking constraints are established between virtual networks, wherein the response stream of any protocol channel is released after waiting for its corresponding request stream to complete transmission, and the request stream remains blocked until its corresponding response stream is completed.

9. The method according to claim 1, characterized in that, The physical topology also includes the data bit width configuration of each router, terminal, and physical channel; The method further includes: When there is an integer multiple difference in the data bit width between adjacent routers, terminals, or physical channels, the traffic control unit segmentation module or traffic control unit merging module is automatically inserted and adjusted synchronously. The expansion or compression of the header and tail flags of the flow control unit packet; The depth of the virtual channel buffer is calculated proportionally to the bit width. In the credit return mechanism, the credit value is proportionally calculated based on the number of transmission units to maintain the integrity of the credit flow control protocol.

10. An on-chip network hardware generation device, characterized in that, include: The configuration acquisition module is used to acquire network configuration, which includes: physical topology, flow set, terminal information, virtual network partitioning results, and virtual network blocking relationships. The candidate route establishment module is used to establish candidate route transfer relationships between physical channels for each flow based on the physical topology and the flow set; The non-blocking verification module is used to perform path connectivity verification under non-blocking conditions for each flow in the flow set: starting from the ingress channel accessed by the source terminal of each flow, according to the candidate route transfer relationship, traversing along the physical topology to the egress channel accessed by its destination terminal, and determining the set of baseline reachable paths under resource-free blocking conditions. The constraint correction module is used to identify the virtual network to which each flow belongs based on the virtual network partitioning result, under the premise that the virtual network blocking relationship exists, and to exclude physical channels occupied by other blocked virtual networks according to the virtual network blocking relationship, to perform constraint correction on the candidate route transfer relationship, and to determine the set of reachable paths for each flow under the resource contention scenario based on the baseline reachable path set. The deadlock detection module is used to perform deadlock detection based on the set of reachable paths after constraint correction. The legality verification module is used to verify the legality of the candidate route transition relationship under the conditions that the baseline reachable path exists, the constraint-corrected reachable path exists, and the deadlock detection does not detect a deadlock. The hardware generation module is used to compile and generate hardware routing logic based on the confirmed legitimate candidate routing transition relationships, and generate synthesizable on-chip network hardware description language code based on the hardware routing logic, the physical topology, the terminal information, and the virtual network partitioning results.

11. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to implement the steps of the method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-9.

Images