On-chip network access control methods, devices, equipment, media and products

Abstract

This disclosure provides a method, apparatus, device, medium, and product for access verification in on-chip networks (NoCs), relating to integrated circuit design and verification and System-on-Chip (SoC) design technologies, particularly in the areas of NoC security verification, access control, and access control isolation verification. The specific implementation scheme is as follows: a routing access permission file is parsed to obtain access permission paths and self-test instances; the self-test instances are executed to obtain self-test results; the self-test results and the routing access permission file are compared and verified to obtain a verification result; if the verification result fails, the access permission paths in the routing access permission file are modified until the verification result passes; routing tests are performed in a UVM environment based on the modified access permission paths to obtain the access verification result. This technical solution can shorten the access verification cycle of on-chip networks.

Description

Technical Field

[0001] This disclosure relates to the fields of integrated circuit design and verification and system-on-chip (SoC) design technology, and particularly to the fields of network-on-chip (NoC) security verification, access control and permission isolation verification. Background Technology

[0002] With the rapid increase in the integration of System-on-Chips (SoCs), Network-on-Chip (NoC) has become the core backbone connecting hundreds of master and slave devices. To ensure system security, NoCs integrate complex access control logic. Currently, industry verification of NoCs heavily relies on Register Transfer Level (RTL) simulation environments, resulting in long and delayed debugging cycles. Therefore, an effective NoC access control verification method is urgently needed. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, medium, and product for access control authentication in a network-on-a-chip.

[0004] According to one aspect of this disclosure, an access control method for an on-chip network is provided, the method comprising: Parse the routing permission file to obtain the access permission path and self-test instance; Execute the self-test instance to obtain the self-test results; The self-test results and the routing permission file are compared and verified to obtain the verification results; If the verification result fails, the access permission path in the routing permission file is modified until the verification result passes. Based on the modified access permission path, a routing test was performed in the UVM environment to obtain the permission verification results.

[0005] According to another aspect of this disclosure, an on-chip network access verification device is provided, the device comprising: The permission file parsing module is used to parse the routing permission file to obtain the permission access path and self-test instance; The self-test module is used to execute the self-test instance and obtain the self-test results. The self-test verification module is used to compare and verify the permissions of the self-test results and the routing permission file to obtain the verification results. The permission file modification module is used to modify the permission access path in the routing permission file if the verification result fails, until the verification result passes. The route permission verification module is used to perform route testing in the UVM environment based on the modified permission access path and obtain the permission verification result.

[0006] According to another aspect of this disclosure, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the on-chip network access verification method according to any embodiment of this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the on-chip network access verification method described in any embodiment of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the on-chip network access verification method described in any embodiment of this disclosure.

[0009] According to the technology disclosed herein, the authorization verification cycle of on-chip networks can be shortened.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart of an authorization verification method for a network-on-chip according to an embodiment of this disclosure; Figure 2 This is a flowchart of another on-chip network permission verification method provided according to an embodiment of this disclosure; Figure 3 This is a flowchart of another permission verification method for a network-on-chip provided according to an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of an on-chip network access verification device according to an embodiment of this disclosure; Figure 5 This is a block diagram of an electronic device used to implement the on-chip network access verification method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] Furthermore, it should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of routing permission file-related data involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0015] Currently, industry verification of NoC mainly relies on the following existing technical solutions: 1) VIP Auto-Configuration Technology Based on Standard Interface Descriptions: Existing technologies typically use standardized interactive files (such as XML or custom formats) to describe the characteristic information of NoC design instances. By parsing these files, the verification platform can automatically call the preset verification IP (VIP) core and generate basic interface binding files and simple test cases. However, such solutions focus on interface-level connectivity verification and heavily rely on standard process tools. For complex access control matrices, significant manual intervention is still required to define detailed permission rules.

[0016] 2) Scoreboard Comparison Mechanism Based on Multi-Channel Splitting: In large-scale NoC verification, to address the complexity of data comparison, existing solutions often employ the method of establishing independent sub-channel scoreboards between master and slave nodes, splitting communication into request and response channels for separate processing. While this method improves the micro-accuracy of the comparison, the maintenance cost of the scoreboard is extremely high when dealing with massive node mappings, and it lacks a dynamic synchronization mechanism with the original design specifications.

[0017] 3) Mapping verification for specific business scenarios: For dedicated AI chips such as Compute-in-Memory (CIM), existing technologies tend to map key information of neural network algorithm models (such as ResNet and MobileNet) to the registers and storage models of NoC nodes, verifying the correctness of the calculation by comparing intermediate results of operators. This type of solution has a high degree of business coupling, making it difficult to extend to general NoC security and access verification, and it cannot cover address blind spots that are not related to business.

[0018] 4) Passive definition of functional coverage: In the existing verification process, functional coverage is usually manually defined by engineers based on their understanding of the specifications after the verification environment is set up. This approach results in a significant lag and asynchrony between coverage metrics and the original permission configuration, making it impossible to quantify verification progress in real time and accurately.

[0019] 5) Relying on projects to verify the correctness of scoreboards: In the existing verification process, confirming the correctness of the developed scoreboard often relies on a large number of simulations, which makes it impossible to fully test the scoreboard before the start of the entire project to ensure the reliability of the scoreboard provided to the project.

[0020] The main drawbacks of existing technologies can be summarized as follows: 1) Significant verification blind spots: Existing technologies focus primarily on the correctness of the "forward path," lacking systematic incentive generation methods for address space "holes" and illegal boundaries. 2) Lack of automated closed-loop: Environment generation, incentive generation, and coverage definition are isolated, failing to achieve a "specification-driven verification" closed loop. 3) Delayed debugging cycle: Package correctness verification heavily relies on the RTL simulation environment, lacking a mechanism for logic pre-verification (shift-left development) in the early stages of development. 4) Insufficient security detection capabilities: Difficult to effectively identify deep-seated hardware vulnerabilities such as address aliasing and privilege escalation.

[0021] This disclosure proposes a script-driven, fully automated closed-loop scheme for NoC permission verification to solve the above-mentioned problems.

[0022] Figure 1 This is a flowchart illustrating an on-chip network (CNIC) permission verification method according to an embodiment of this disclosure. This method is applicable to industrial-grade chip verification projects requiring strict permission management, possessing complex interconnect topologies and large-scale address mapping relationships, as well as semiconductor products involving multi-master collaboration and sensitive data protection, including but not limited to artificial intelligence (AI) inference chips, high-performance computing (HPC) processors, and automotive autonomous driving SoCs. This method can be executed by an on-chip CNIC permission verification device, which can be implemented in software and / or hardware and integrated into an electronic device carrying the on-chip CNIC permission verification function, such as a PC. Figure 1 As shown, the on-chip network access control method in this embodiment may include: S101, parse the routing permission file to obtain the permission access path and self-test instance.

[0023] In this embodiment, the routing permission file refers to a file that describes the access addresses and access permissions between the master device and the slave device in the on-chip network using natural language; optionally, the routing permission file can be a CSV format file. The permission access path refers to the communication access path between the master device and the slave device through the on-chip network. The self-test instance is used to verify whether the permission logic design of the routing permission file is accurate.

[0024] Specifically, the automation engine parses the routing permission file to obtain the access permission path and self-test instance.

[0025] S102, execute the self-test instance to obtain the self-test results.

[0026] In this embodiment, the self-test result refers to the result obtained after running the self-test instance, which contains the same content as the routing permission file; optionally, the self-test result can be a log file.

[0027] Specifically, self-test results are obtained by executing self-test instances based on the simulator.

[0028] S103, compare and verify the permissions of the self-test results and the routing permission file to obtain the verification results.

[0029] In this embodiment, the verification result refers to the result of verifying whether the routing permission file is accurate, including whether it passes or fails.

[0030] Specifically, the self-test results are compared and verified with the contents of the routing permission file. If they match, the verification result is considered passed; otherwise, the verification result is considered failed.

[0031] S104. If the verification result fails, modify the access permission path in the routing permission file until the verification result passes.

[0032] Specifically, if the verification result fails, the access permission path in the routing permission file is modified through the interactive interface, and a self-test instance is regenerated and executed until the verification result passes.

[0033] S105. Based on the modified access permission path, perform routing tests in the UVM environment to obtain the permission verification results.

[0034] In this embodiment, the UVM environment refers to a complete, automated, standardized, and reusable test platform for chip verification. The permission verification result refers to the verification result of the master device's access rights to the slave device via the on-chip network, including whether access is allowed / denied.

[0035] Specifically, test cases are generated based on the modified access permission path, and routing tests are performed in the UVM environment to obtain the permission verification results.

[0036] The technical solution provided in this disclosure parses the routing permission file to obtain the permission access path and self-test instance; executes the self-test instance to obtain the self-test result; compares and verifies the permissions between the self-test result and the routing permission file to obtain the verification result; if the verification result fails, the permission access path in the routing permission file is modified until the verification result passes; and a routing test is performed in the UVM environment based on the modified permission access path to obtain the permission verification result. This technical solution generates a lightweight self-test instance simultaneously while parsing the permission routing file to support second-level syntax checking and permission logic pre-checking, ensuring "zero defects" in environment configuration before integration into a large UVM platform. It overcomes the shortcomings of existing technologies that heavily rely on large RTL simulation environments, have long and lagging debugging cycles, significantly shorten the environment iteration cycle, and achieve a leftward shift in the development cycle.

[0037] It should be noted that, compared to traditional methods where effective simulation can only be performed after the RTL (Register Transfer Level) code is complete, and where errors in the environment itself are often only exposed in the later stages of simulation, leading to costly retesting, this disclosure, by generating self-test examples accompanying the permission routing file, allows verification personnel to pre-verify the verification logic and package before the RTL is ready. This achieves early problem closure, avoids inefficient troubleshooting during the simulation phase of complex systems, and significantly reduces the complexity of later debugging.

[0038] It should also be noted that, compared to existing technologies that typically rely on manually writing test cases and maintaining permission matrices, the environment setup cycle for complex SoCs with hundreds of nodes is usually measured in weeks. This disclosure achieves second-level generation from specifications to the verification environment through a script-driven mechanism based on a "single source of truth," namely, permission routing files. In actual industrial projects, the verification environment setup and maintenance cycle has been shortened by more than 80%, greatly accelerating the overall chip R&D iteration progress and enabling products to be brought to market faster.

[0039] Figure 2 This is a flowchart of another on-chip network access control method provided according to an embodiment of this disclosure. Based on the above embodiments, this embodiment further optimizes the step of "performing routing tests in the UVM environment according to the modified access control path to obtain the access control result," providing an optional implementation scheme. For example... Figure 2 As shown, the method includes: S201, parse the routing permission file to obtain the access permission path and self-test instance.

[0040] In this embodiment, the access permission path includes a routing link consisting of the master address and slave address of the on-chip network; wherein, the master address and slave address are both routing addresses of the on-chip network, the master address connects to the master device, and the slave address connects to the slave device. It should be noted that the access permission path includes authorized paths and unauthorized paths, wherein an authorized path is a routing path in which the master device has access rights to the slave device; an unauthorized path is a routing path in which the master device does not have access rights to the slave device.

[0041] S202, execute the self-test instance to obtain the self-test results.

[0042] S203, compare and verify the permissions of the self-test results and the routing permission file to obtain the verification results.

[0043] S204 If the verification result fails, modify the access permission path in the routing permission file until the verification result passes.

[0044] S205, retrieve the modified access path from the address.

[0045] In this embodiment, the address refers to the routing address in the on-chip network that connects to the slave device.

[0046] S206, based on the complement algorithm, determines holed addresses and unauthorized controlled addresses according to the address mapping between the slave address and the on-chip network.

[0047] In this embodiment, an unauthorized controlled address refers to a routing address in the network-on-a-chip that requires specific access permissions and will be blocked if access is not authorized; a hole address refers to an illegal routing address in the network-on-a-chip.

[0048] Specifically, based on the complement algorithm, the hole addresses and unlicensed controlled addresses of the on-chip network can be obtained by mapping the addresses from the address to the on-chip network address.

[0049] S207. Illegal paths are determined based on the main address, void address, and unauthorized controlled address in the modified access path.

[0050] In this embodiment, the primary address refers to the routing address in the on-chip network that connects to the primary device. An invalid path refers to an invalid routing path in the on-chip network.

[0051] Specifically, an illegal path can be constructed by using the main address in the modified access path as the starting address and ending with empty addresses and unauthorized controlled addresses, respectively.

[0052] S208 generates test cases for the modified access path and the illegal path respectively.

[0053] Specifically, test cases are generated for the modified authorized access paths and the illegal paths, respectively. It should be noted that there are multiple authorized access paths and multiple illegal paths.

[0054] S209, execute test cases in the UVM environment to perform routing tests and obtain permission verification results.

[0055] Specifically, the simulator is invoked in the UVM environment to execute test cases for routing testing and obtain permission verification results.

[0056] The technical solution provided in this disclosure obtains the slave address in the modified access path, then determines the void address and unauthorized controlled address based on the complement algorithm and the address mapping between the slave address and the on-chip network. Next, based on the master address, void address, and unauthorized controlled address in the modified access path, illegal paths are determined. Test cases are generated for both the modified access path and the illegal paths. Finally, the test cases are executed in the UVM environment to perform routing tests and obtain the access verification results. Unlike existing technologies that only verify "known forward paths," this disclosure automatically generates void addresses and unauthorized controlled addresses to obtain illegal paths through the complement algorithm. This generates test cases that cover the entire address space, achieving 100% negative test coverage. This ensures that the test cases (i.e., incentives) not only cover legitimate access but also more accurately reach illegal boundaries, effectively identifying deep security risks such as address aliases and privilege escalation, and eliminating verification blind spots.

[0057] It should be noted that this disclosure provides a full address space complement computation incentive generation technology, achieving 100% negative test coverage for NoC permissions. By accurately identifying key risks such as privilege escalation, it ensures that the product has extremely high anti-attack capabilities and access compliance at the underlying hardware level.

[0058] Figure 3 This is a flowchart of another on-chip network access control method provided according to an embodiment of this disclosure; this embodiment, based on the above embodiments, adds an optimized scheme for on-chip network access control verification using a simulation scheduling manager and a functional coverage model. Figure 3 As shown, the method includes: S301 parses the routing permission file to obtain the permission access path, self-test instance, and simulation scheduler.

[0059] In this embodiment, the simulation scheduler is used to schedule the simulator during testing in the UVM environment to avoid repeated testing of test cases.

[0060] Specifically, the automation engine parses the routing permission file and automatically generates permission access paths, self-test instances, and a simulation scheduler.

[0061] S302, execute the self-test instance to obtain the self-test results.

[0062] S303 compares and verifies the permissions of the self-test results and the routing permission file to obtain the verification results.

[0063] S304 If the verification result fails, modify the access permission path in the routing permission file until the verification result passes.

[0064] S305, retrieve the modified access path from the address.

[0065] S306, based on the complement algorithm, determines holed addresses and unauthorized controlled addresses according to the address mapping between the slave address and the on-chip network.

[0066] S307, based on the main address, void address and unauthorized controlled address in the modified access path, determine the illegal path.

[0067] S308 generates test cases for the modified access path and the illegal path respectively.

[0068] S309, the simulator corresponding to the test case is determined through the simulation scheduler manager.

[0069] Specifically, the test cases corresponding to each access path with different permissions are numbered, for example, by mapping them to consecutive integer numbers to obtain test case numbers. Then, based on the test case numbers, the simulator corresponding to the test case is determined by the simulation scheduler.

[0070] It should be noted that resource allocation across simulations is achieved based on decentralization, lock-free operation, and atomic operations based on the file system, using a simulation scheduler. Each simulator corresponds to one process.

[0071] S310 uses a simulator to execute test cases in the UVM environment to perform routing tests and obtain permission verification results.

[0072] Specifically, each simulator executes corresponding test cases in the UVM environment to perform routing tests and obtain permission verification results.

[0073] The technical solution provided in this disclosure parses the routing permission file to obtain the access permission path, self-test instance, and simulation scheduler. Then, the self-test instance is executed to obtain the self-test result, and the self-test result is compared and verified against the routing permission file. If the verification result fails, the access permission path in the routing permission file is modified until the verification result passes. Next, the slave address in the modified access permission path is obtained, and based on the complement algorithm and the address mapping between the slave address and the on-chip network, the hole address and unauthorized controlled address are determined. Then, based on the master address, hole address, and unauthorized controlled address in the modified access permission path, illegal paths are determined. Finally, test cases are generated for the modified access permission path and illegal paths respectively, and the simulator corresponding to the test case is determined by the simulation scheduler. The test cases are executed in the UVM environment based on the simulator to perform routing tests and obtain the permission verification result. This technical solution, by assigning a corresponding simulator to each test case through the simulation scheduler, enables multiple simulators (i.e., simulation processes) to achieve globally unique allocation without any communication protocols or lock services, achieving rapid coverage convergence and avoiding the synchronous work of a large number of test cases.

[0074] It should be noted that, compared to traditional IC verification regression testing, the allocation of test cases between multiple simulations relies on two methods: one is independent and random selection for each simulation, leading to a large amount of duplicate coverage, slow and unpredictable coverage convergence; the other is unified allocation through a centralized scheduling service (such as a database or task queue), but this may introduce additional infrastructure dependencies and single point of failure risks. This disclosure, through a simulation scheduling manager, can achieve centralization without additional infrastructure dependencies and without the risk of file deadlock, thus facilitating coverage convergence in the shortest possible time.

[0075] Based on the above embodiments, as an optional method of this disclosure, while parsing the routing permission file to obtain the permission access path and self-test instance, it also includes: parsing the routing permission file to obtain the functional coverage model; After executing test cases in the UVM environment to perform routing tests and obtaining the permission verification results, the process also includes updating the functional coverage model based on the permission verification results.

[0076] The functional coverage model can be used to characterize whether the function / specification corresponding to each test case has been tested. It is automatically generated based on the permission matrix in the permission routing file to establish a 1:1 mapping between specifications and metrics.

[0077] Specifically, the routing permission file is parsed using an automation engine to obtain the access permission paths, self-test instances, and a functional coverage model. Then, test cases are executed in the UVM environment to perform routing tests. After obtaining the permission verification results, the functional coverage model is updated based on these results, determining whether the corresponding functional points in the functional coverage model have been tested.

[0078] Understandably, by generating a functional coverage model simultaneously when parsing the permission routing file, the definition of verification metrics is brought forward to the environment building stage, ensuring that the coverage model is strictly synchronized with the design specifications.

[0079] It should be noted that, compared to existing technologies where verification progress often relies on engineers' manual records and subjective judgments, lacking objective metrics to prove whether "all permissions have been tested," this disclosure directly transforms design specifications into measurable physical metrics by synchronously generating a 1:1 mapping between specifications and metrics for functional coverage models. Management and architects can obtain the verification achievement rate of each permission in real time and objectively through coverage reports, avoiding the risk of missed tests due to human negligence.

[0080] The present invention also provides an on-chip system verification package for a network-on-chip, wherein the on-chip system verification package is obtained by encapsulating the on-chip network permission verification method provided in any embodiment of the present disclosure.

[0081] Specifically, the on-chip network permission verification method provided in any embodiment of this disclosure is automatically packaged to obtain an on-chip system verification package; wherein, the on-chip system verification includes hardware topology and permission attributes.

[0082] Understandably, by encapsulating the system-on-chip verification package, the redundant work of hard-coding a large number of comparison paths for different topologies, which is required by existing technologies, is avoided, greatly improving the reusability and scalability of the verification environment.

[0083] It should be noted that when the chip topology or address mapping changes, traditional solutions require rewriting a large number of hard-coded scoring board comparison paths and VIP configurations. In contrast, this disclosure encapsulates the on-chip network's permission verification, employing a metadata-driven dynamic monitoring architecture. When the product (carrying the on-chip system verification package) undergoes redesign or topology fine-tuning, only the permission routing table needs to be updated and the on-chip system verification package (script) re-run to complete the environment update. This ensures the verification platform's high reusability across a series of products, exhibiting strong scalability and low maintenance costs.

[0084] Figure 4 This is a schematic diagram of an on-chip network access control device according to an embodiment of this disclosure. This embodiment is applicable to industrial-grade chip verification projects requiring strict access control, possessing complex interconnect topologies and large-scale address mapping relationships, as well as semiconductor products involving multi-master collaboration and sensitive data protection, including but not limited to artificial intelligence (AI) inference chips, high-performance computing (HPC) processors, and automotive autonomous driving SoCs. This device can be implemented in software and / or hardware and can be integrated into electronic devices carrying on-chip network access control functions, such as PCs. Figure 4 As shown, the on-chip network access control device 400 includes: The permission file parsing module 401 is used to parse the routing permission file to obtain the permission access path and self-test instance; Self-test module 402 is used to execute self-test instances and obtain self-test results; The self-test verification module 403 is used to compare and verify the self-test results with the routing permission file to obtain the verification results. The permission file modification module 404 is used to modify the permission access path in the routing permission file if the verification result fails, until the verification result passes. The routing permission verification module 405 is used to perform routing tests in the UVM environment based on the modified permission access path and obtain the permission verification results.

[0085] The technical solution provided in this disclosure parses the routing permission file to obtain the permission access path and self-test instance; executes the self-test instance to obtain the self-test result; compares and verifies the permissions between the self-test result and the routing permission file to obtain the verification result; if the verification result fails, the permission access path in the routing permission file is modified until the verification result passes; and a routing test is performed in the UVM environment based on the modified permission access path to obtain the permission verification result. This technical solution generates a lightweight self-test instance simultaneously while parsing the permission routing file to support second-level syntax checking and permission logic pre-checking, ensuring "zero defects" in environment configuration before integration into a large UVM platform. It overcomes the shortcomings of existing technologies that heavily rely on large RTL simulation environments, have long and lagging debugging cycles, significantly shorten the environment iteration cycle, and achieve a leftward shift in the development cycle.

[0086] Furthermore, the routing authorization verification module 405 is used for: Retrieve the modified access permission path from the address; Based on the complement algorithm, holed addresses and unauthorized controlled addresses are determined according to the address mapping between the address and the on-chip network. Illegal paths are identified based on the main address, void address, and unauthorized controlled address in the modified access permission path; Generate test cases for the modified access paths and illegal paths respectively; Execute test cases in the UVM environment to perform routing tests and obtain permission verification results.

[0087] Furthermore, the master address refers to the routing address in the on-chip network that is connected to the master device; the slave address refers to the routing address in the on-chip network that is connected to the slave device; the unauthorized controlled address refers to the routing address in the on-chip network that requires specific access permissions and will be blocked if unauthorized access is not granted; and the void address refers to the illegal routing address in the on-chip network.

[0088] Furthermore, the permission file parsing module 401 is also used for: In addition to parsing the routing permission file to obtain the access permission path and self-test instance, it also includes: parsing the routing permission file to obtain the simulation scheduler; The routing permission verification module 405 is also used for: Execute test cases in the UVM environment to perform routing tests and obtain permission verification results, including: The simulator corresponding to the test case is determined by the simulation scheduler; The test cases were executed in the UVM environment using a simulator to perform routing tests and obtain permission verification results.

[0089] Furthermore, the permission file parsing module 401 is also used for: In addition to parsing the routing permission file to obtain the access permission path and self-test instance, it also includes: The routing permission file is parsed to obtain the functional coverage model; The routing permission verification module 405 is also used for: After executing test cases in the UVM environment to perform routing tests and obtaining the permission verification results, the following steps are also included: The functional coverage model is updated based on the permission verification results.

[0090] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0091] Figure 5 This is a block diagram of an electronic device used to implement the on-chip network access verification method of the embodiments of this disclosure. Figure 5 This is a block diagram of an electronic device used to implement the on-chip network access verification method of the embodiments of this disclosure. Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0092] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0093] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0094] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the on-chip network access control method. For example, in some embodiments, the on-chip network access control method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the on-chip network access control method described above may be performed. Alternatively, in other embodiments, computing unit 501 may be configured to perform on-chip network access control methods by any other suitable means (e.g., by means of firmware).

[0095] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0096] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0097] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0098] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0099] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0100] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0101] Artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies mainly include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0102] Cloud computing refers to a technology system that enables access to a shared pool of physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, applications, and storage devices, and can be deployed and managed on demand and in a self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.

[0103] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for authentication of an on-chip network, comprising: Parse the routing permission file to obtain the access permission path and self-test instance; Execute the self-test instance to obtain the self-test results; The self-test results and the routing permission file are compared and verified to obtain the verification results; If the verification result fails, the access permission path in the routing permission file is modified until the verification result passes. Based on the modified access permission path, a routing test was performed in the UVM environment to obtain the permission verification results.

2. The method according to claim 1, wherein, Based on the modified access permission path, a routing test was performed in the UVM environment to obtain the permission verification results, including: Obtain the address from the modified access permission path; Based on the complement algorithm, the holed address and the unauthorized controlled address are determined according to the address mapping between the slave address and the on-chip network; The illegal path is determined based on the main address, the void address, and the unauthorized controlled address in the modified access path; Generate test cases for the modified access path and the illegal path respectively; The test cases are executed in the UVM environment to perform routing tests and obtain permission verification results.

3. The method according to claim 2, wherein, The primary address refers to the routing address in the network-on-a-chip (NAT) that connects to the primary device; the secondary address refers to the routing address in the NAT that connects to the secondary device; the unauthorized controlled address refers to the routing address in the NAT that requires specific access permissions and will be blocked if unauthorized access is not granted; and the void address refers to an illegal routing address in the NAT.

4. The method according to claim 2, wherein, In addition to parsing the routing permission file to obtain the access permission path and self-test instance, the process also includes: The routing permission file is parsed to obtain the simulation scheduling manager; The test cases are executed in the UVM environment to perform routing tests and obtain permission verification results, including: The simulator corresponding to the test case is determined by the simulation scheduler; The test cases are executed in the UVM environment using the simulator to perform routing tests and obtain permission verification results.

5. The method according to claim 2, wherein, In addition to parsing the routing permission file to obtain the access permission path and self-test instance, the process also includes: The routing permission file is parsed to obtain the functional coverage model; After executing the test case in the UVM environment to perform routing tests and obtaining the permission verification results, the process also includes: The function coverage model is updated based on the permission verification results.

6. An on-chip network system verification package, wherein, The on-chip system verification package is obtained by encapsulating the on-chip network permission verification method as described in any one of claims 1-5.

7. An on-chip network access control device, comprising: The permission file parsing module is used to parse the routing permission file to obtain the permission access path and self-test instance; The self-test module is used to execute the self-test instance and obtain the self-test results. The self-test verification module is used to compare and verify the permissions of the self-test results and the routing permission file to obtain the verification results. The permission file modification module is used to modify the permission access path in the routing permission file if the verification result fails, until the verification result passes. The routing permission verification module is used to perform routing tests in the UVM environment based on the modified permission access path and obtain the permission verification results.

8. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the on-chip network access verification method according to any one of claims 1-5.

9. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to execute the network-on-chip authentication method according to any one of claims 1-5.

10. A computer program product comprising a computer program that, when executed by a processor, implements the access control method for a network on-chip according to any one of claims 1-5.

Images