Network-on-chip test file generation method and device, equipment and storage medium

Abstract

The invention provides a network-on-chip test file generation method and device, electronic equipment and a computer readable storage medium. The method comprises the steps of obtaining test scene information of a network-on-chip; the test scene information comprises a plurality of test scenes, and each test scene comprises a group of test parameters; performing text data extraction on the test scene information through a conversion function of the analysis component, and converting the format of the extracted text data into a target format to obtain first data; the target format is matched with a format supported by the analysis component; and generating an on-chip network test file corresponding to each test scene according to the first data and the sequence generation function. According to the embodiment of the invention, the efficiency of generating the test case can be improved, so that the test efficiency and test quality of the network-on-chip are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and computer-readable storage medium for generating an on-chip network test file. Background Art

[0002] A network-on-chip (NOC) is a communication architecture used to interconnect components within a system-on-chip (SoC). Verification is crucial to NOC design. The NOC verification process requires rigorous analysis of the NOC design specifications, planning, use case development, use case writing, and execution.

[0003] Currently, in the verification of on-chip networks, test cases are written manually.

[0004] However, during the entire NOC verification cycle, NOC has many design scenarios and requires a large number of test cases, and manually writing test cases is not efficient. Summary of the Invention

[0005] The embodiments of the present application provide a method, device, electronic device, and computer-readable storage medium for generating a network-on-chip test file to solve problems in related technologies.

[0006] In a first aspect, an embodiment of the present application provides a method for generating an on-chip network test file, the method comprising: Acquire test scenario information of the on-chip network; the test scenario information includes multiple test scenarios, and each test scenario includes a set of test parameters; Extracting text data from each test scenario information through a conversion function of the parsing component, and converting the format of the extracted text data into a target format to obtain first data; the target format matches a format supported by the parsing component; Generate a network-on-chip test file corresponding to each test scenario according to the first data and the sequence generation function.

[0007] In a second aspect, an embodiment of the present application provides an on-chip network test file generation device, which includes: an acquisition unit, a conversion unit and a generation unit.

[0008] An acquisition unit, configured to acquire test scenario information of the network on chip; the test scenario information includes a plurality of test scenarios, each test scenario including a set of test parameters; A conversion unit, configured to extract text data from each test scenario information using a conversion function of the parsing component, and convert the format of the extracted text data into a target format to obtain first data; the target format matches a format supported by the parsing component; The generating unit is configured to generate an on-chip network test file corresponding to each test scenario according to the first data and the sequence generation function.

[0009] In a third aspect, an embodiment of the present application further provides an electronic device, including a processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method of the first aspect.

[0010] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to execute the method of the first aspect.

[0011] In an embodiment of the present application, the test scenario information of the on-chip network can be obtained, and the test scenario information is limited to include multiple test scenarios, and each test scenario includes a set of test parameters. The text data of each test scenario information is extracted through the conversion function of the parsing component, and the extracted text data is converted into the first data that matches the format supported by the parsing component. After the test scenario information is obtained, the obtained test scenario information can be automatically analyzed and data extracted through the parsing component corresponding to the programming language, and the extracted data is converted into a data format that matches the format supported by the parsing component, thereby reducing the risk of recognition errors or unrecognition problems that may be caused by data in different formats, and realizing standardized processing of data. Finally, according to the test parameters and sequence generation functions of each test scenario, the on-chip network test file corresponding to each test scenario is generated, which can reduce the workload of manual coding, reduce the mistakes caused by manual coding errors, and improve the efficiency of generating test cases, thereby improving the testing efficiency and test quality of the on-chip network.

[0012] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0014] Figure 1 This is a flowchart of a method for generating a network-on-chip test file provided by an embodiment of the present application; Figure 2 This is a schematic diagram of an architecture for executing an on-chip network test file provided by an embodiment of the present application; Figure 3 This is a schematic block diagram of a process for generating a network-on-chip test file provided by an embodiment of the present application; Figure 4 This is a block diagram of an on-chip network test file generating device provided in an embodiment of the present application; Figure 5 This is a block diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0016] The terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] In practical applications, although the multiple processor cores within a multi-core processor chip each execute their own code, data sharing and synchronization are required between the processor cores. Therefore, the hardware structure of the multi-core processor must support efficient inter-core communication, and the performance of the on-chip communication structure will directly affect the performance of the processor.

[0018] Therefore, the network-on-chip (NOC) is a key technology in multiprocessor architectures. It serves as the interconnection pathway and communication network within the processors, responsible for message passing and fundamental to processor collaboration. Designed to address communication issues within multicore processors, the NOC is an integrated circuit built on a network-based communication subsystem, a router-based packet-switching network between SoCs. Drawing on the interconnected network architecture of parallel computers, NOC technology integrates a large number of computing resources and an on-chip communication network connecting these resources on a single chip. Each processor core has its own independent router and private cache, connected by an on-chip communication network. Processor cores communicate using message-based mechanisms, replacing the on-chip bus in related technologies with routers and packet switching technologies to accomplish communication tasks. This overcomes the bottlenecks associated with bus interconnections in related technologies.

[0019] Specifically, during the development and design of a NoC, verification is crucial for ensuring the design and quality of the NoC. The NoC verification process requires rigorous analysis of the NoC's design specifications, planning, use case planning, use case writing, and use case execution.

[0020] In the related art, test cases for on-chip network verification are usually written manually.

[0021] However, throughout the entire NOC verification cycle, NOC design scenarios are numerous and require a large number of test cases. Especially in multi-core systems such as System on a Chip (SOC), writing test cases is extremely complex, making manual test case writing inefficient.

[0022] Against this background, an embodiment of the present application provides a method for generating a network-on-chip (NOC) test file, which can improve the efficiency of generating test cases, thereby improving the efficiency and quality of NOC testing.

[0023] Figure 1 This is a flow chart of a network-on-chip test file generation process provided by an embodiment of the present application. Figure 1 As shown, the method may include steps 101 to 103.

[0024] Step 101: Acquire test scenario information of the on-chip network.

[0025] In this embodiment, the NOC test scenario information is a structured description of the NOC operating status, communication mode, and abnormal conditions that need to be verified. The purpose is to cover the full range of NOC design requirements, including functionality, performance, and reliability. The test scenario information can include multiple test scenarios, each of which includes a set of test parameters.

[0026] Test scenario information is designed based on the characteristics of the NOC. Because the NOC network is a key component in maintaining consistency within the SoC, it must ensure the consistency of the central processing unit (CPU) cache and access channels for various peripherals. Therefore, the test scenario information must specify test parameters.

[0027] The test parameters may include the test address, the current state of the test core, the final state of the test core, the expected state of other cores in the SoC where the SoC is located, the initial and final states of other cores in the SoC where the SoC is located, the initial and final states of the coherence component, and the scenario name. The parameter values ​​of the test parameters vary for different test scenarios.

[0028] The test scenario information can be obtained according to actual test requirements. The test scenario information can be in the form of an Excel table or a Word text. The embodiment of the present application does not specifically limit the form of the test scenario information.

[0029] Step 102: extract text data from each test scenario information through the conversion function of the parsing component, and convert the format of the extracted text data into a target format to obtain first data; the target format matches the format supported by the parsing component.

[0030] In the embodiment of the present application, the parsing component may be a component corresponding to a compiled language, and the compiled language may be Python, C language, C++, etc. The embodiment of the present application does not impose any specific limitation on this.

[0031] Specifically, the above step 102 may include sub-steps 1021 and 1022.

[0032] Sub-step 1021 : extracting text data from each test scenario information through the conversion function of the parsing component, and converting the extracted text data into structured data.

[0033] For example, if the parsing component is a Python parsing component and the test scenario information is in the form of an Excel table, the structure of the Excel file can be identified through the table processing tool of the Python parsing component, which may include the number of worksheets, the row and column distribution of each worksheet, and the cell content. The table processing tool automatically parses the data types (for example, numbers, text, dates, etc.) in the Excel file, and ignores the format information in the table (such as cell color, border lines, etc.), and only extracts valid text data. The extracted text data can be converted into data in plain text format, such as csv, yaml, ini and other file formats. These formats have simple data formats and high parsing efficiency, and plain text data has strong cross-system compatibility, which is more suitable for batch automated processing of programs (for example, scripts reading configurations, interfaces passing data, etc.).

[0034] Sub-step 1022: Convert the format of the structured data into data in a target format to obtain first data.

[0035] In an embodiment of the present application, after extracting text data from the test scenario information and converting the extracted text data into structured data, the converted structured data can be further processed to obtain first data, and the data format of the first data is a target format that matches the format supported by the parsing component.

[0036] For example, if the extracted text data is converted to CSV data, the CSV data can be converted to a list. CSV data is in plain text format and has no data type, meaning all values ​​are strings, with columns separated by commas (or other delimiters) and rows separated by newlines. A list is a general-purpose ordered, mutable, and sequential data structure in Python that can accommodate any data type. Almost all built-in functions and third-party libraries (such as pandas and numpy) can directly process lists, which can contain elements of different types (such as integers, nested lists, etc.). After converting the CSV data to a list, the data in the file is mapped to a set of elements recognizable by Python (for example, a row of CSV data corresponds to a sublist of a list), allowing direct operations such as traversal through for item in my_list and adding elements through my_list.append(new_item).

[0037] Step 103: Generate an on-chip network test file corresponding to each test scenario according to the first data and the sequence generation function.

[0038] Based on the above embodiment, for example, after obtaining the first data for each test scenario, the first data can be analyzed and processed using a sequence generation function to obtain a test command sequence corresponding to each test scenario. In this embodiment of the present application, a sequence can also be understood as an on-chip network test file. A sequence is a series of operational instructions arranged in a chronological or logical order, used to guide the standard verification component (e.g., VIP component) used in chip verification to generate stimulus.

[0039] Specifically, the above step 103 may include: sub-step 1031 and sub-step 1032.

[0040] Sub-step 1031: extracting test parameters of each test scenario from the first data.

[0041] Based on the above embodiment, for example, the first data is in the form of a list, and the first data can be analyzed, each test scenario can be traversed, and the test parameters of each test scenario can be extracted. The test parameters extracted for each test scenario include the above test address, the current state of the test core, the end state of the test core, the expected state of other cores in the system-on-chip where the on-chip network is located, the initial state and end state of other cores in the system-on-chip where the on-chip network is located, the initial state and end state of the consistency component, and the scenario name, etc.

[0042] For example, the extracted results may include: Scenario SC001: Source address = Core0, Destination address = Core3, Packet size = 64 bytes, Injection rate = 50%. Scenario SC002: Source address = Core1, Destination address = Core4, Fault injection point = Link2, Routing algorithm = Adaptive.

[0043] Sub-step 1032: Generate an on-chip network test file corresponding to each test scenario based on the test parameters and sequence generation function of each test scenario.

[0044] In this embodiment of the present application, a sequence generation function in a sequence generator (chi-sequence-gen) can be used to convert the test parameters of each test scenario into an executable test command sequence, thereby generating a network-on-chip test file corresponding to each test scenario. The sequence generation function is used to generate a test command sequence that complies with the network-on-chip protocol based on the test parameters. The sequence generation function takes the extracted test parameters as input and outputs a test command sequence that complies with the communication protocol (e.g., Read / Write transactions of the AMBA-CHI protocol).

[0045] For example, in the process of generating a specific on-chip network test file, a test sequence may include transaction type (e.g., Read, Write, Invalidate, etc.), address information (e.g., source address, destination address), data content (transmitted data value), control information (e.g., priority, QOS level, etc.), and timing constraints (e.g., time interval between transactions, etc.). Among them, the QOS level is a grading standard for measuring and guaranteeing the performance of services such as data transmission and resource allocation in network, communication or computing systems. Its core purpose is to provide differentiated service guarantees based on the needs of different services or data.

[0046] The test sequence can be parsed first, specifically extracting core information such as transaction type, address, and data, parsing timing constraints (e.g., number of delay cycles, timeout settings, etc.), and processing conditional branches and loop structures. Then, based on the requirements of the test platform and verification tool, an appropriate file format (e.g., text, binary, or script) is selected. In this embodiment of the present application, if the parsing component is a Python parsing component, the file format can be a Python script. Finally, based on the selected file format, the parsed sequence is converted to the corresponding format. A test file typically contains header information, a transaction sequence body, and trailer information. The header information may include a description of the test scenario, parameter configuration (e.g., injection rate, packet size, etc.), expected results (e.g., pass or fail conditions), version information, and a timestamp. The transaction sequence body may include a sequentially arranged list of transactions, detailed fields for each transaction (e.g., type, address, data, etc.), and dependencies and timing constraints between transactions. The trailer information may include an end marker, additional verification instructions, or comments.

[0047] The embodiment of the present application can obtain the test scenario information of the on-chip network, and limit the test scenario information to include multiple test scenarios, each test scenario including a set of test parameters. The text data of each test scenario information is extracted through the conversion function of the parsing component, and the extracted text data is converted into the first data that matches the format supported by the parsing component. After obtaining the test scenario information, the obtained test scenario information can be automatically analyzed and data extracted through the parsing component corresponding to the programming language, and the extracted data is converted into a data format that matches the format supported by the parsing component, thereby reducing the risk of recognition errors or unrecognition problems that may be caused by data in different formats, and realizing standardized processing of data. Finally, according to the test parameters and sequence generation function of each test scenario, the on-chip network test file corresponding to each test scenario is generated, which can reduce the workload of manual coding, reduce the mistakes caused by manual coding errors, improve the efficiency of generating test cases, and thus improve the testing efficiency and test quality of the on-chip network.

[0048] In some embodiments, the above method may further include: steps 201 to 203.

[0049] Step 201: Verify the first data according to the on-chip network communication protocol using the verification function of the scenario judgment component to obtain a verification result.

[0050] For example, communication protocols may include the NOC protocol and the AMBA-CHI protocol. The NOC protocol defines the communication rules, state transition logic, and data exchange methods for various components within the chip (such as cores, caches, and coherence nodes). The AMBA-CHI protocol is a high-performance cache coherent interconnect protocol, part of the AMBA protocol family. Designed specifically for multiprocessor systems, it aims to address cache coherence issues in multi-core environments and provide efficient memory access mechanisms.

[0051] The scenario assessment component integrates communication protocol-related content. It uses Chi-transaction-compare (CHI) to verify the first data using a verification function to obtain a verification result. Chi-transaction-compare is a key technology used in chip verification to detect whether AMBA-CHI protocol transactions meet expectations. By comparing actual CHI transactions with expected transactions, it ensures the correctness of system behavior.

[0052] In the embodiment of the present application, when verifying the first data, the first data can be verified by comparing each test parameter in the first data to obtain a verification result.

[0053] Specifically, the verification function of the scene judgment component can be used to verify whether the scene name in the test parameters of each test scene in the first data is consistent with the scene name of the scene to be tested. If the scene name in the first data is consistent with the scene name of the scene to be tested, it is determined that the scene name verification has passed; if they are inconsistent, it is determined that the scene name verification has failed.

[0054] Furthermore, the verification function of the scenario judgment component can be used to analyze the test parameters of each test scenario in the first data to see whether the test address corresponding to the current test scenario exceeds the address boundary. If the test address does not exceed the address boundary, the test address verification passes; if the test address exceeds the address boundary, the test address verification fails.

[0055] Furthermore, the verification function of the scenario judgment component can be used to verify whether the transition of the state of the test core from the current state to the target state in the test parameters of each test scenario in the first data complies with the rules of the on-chip network communication protocol. If it does, the state verification of the test core passes; if it does not, the state verification of the test core fails.

[0056] Exemplarily, the current state of the test core, the expected state change target of the test core at the test address, and the conversion rules for the state of the test core in the on-chip network communication protocol can be obtained to verify whether the conversion of the state of the test core from the current state to the target state in the test parameters of each test scenario in the first data complies with the rules of the on-chip network communication protocol.

[0057] For example, the current state of the test core is I, and the target state of the test core at the test address is expected to be UC. Taking the AMBA-CHI protocol as an example, if the transition rules for the test core states in the NOC protocol are: "I": ["S", "E", "M", "UC"], the I state can transition to the S state, E state, M state, and UC state; "S": ["I", "E", "M"], the S state can transition to the I state, E state, and M state; "E": ["I", "M"], the E state can transition to the I state and M state; "M": ["I", "S"], the M state can transition to the I state and S state; "UC": ["I"], the UC state can transition to the I state. The transition rules for the test core states in the NOC protocol show that the I state can transition to the UC state, so the test core's transition from the current state I to the target state UC complies with the NOC protocol rules.

[0058] Furthermore, the verification function of the scenario judgment component can be used to verify whether the transition of the state of other cores in the on-chip system where the on-chip network is located from the current state to the target state complies with the rules of the on-chip network communication protocol. If it does, the state verification of other cores in the on-chip system where the on-chip network is located passes; if it does not, the state verification of other cores in the on-chip system where the on-chip network is located fails.

[0059] For example, the state verification method for other cores in the SoC can refer to the verification method for the test core described above. For example, each core's state transition is verified to comply with the rules of the aforementioned communication protocols (e.g., MESI, MESIF, etc.). In the MESI protocol, transitions from the Invalid (I) state to the Shared (S), Exclusive (E), or Modified (M) state are possible, but the Shared (S) state cannot transition directly to the Modified (M) state; it must first transition through the Exclusive (E) state. The verification logic determines the current state and target state; then checks whether the transition exists in the protocol's list of permitted transitions. If not, the transition is deemed illegal, indicating a verification failure.

[0060] For example, in a specific verification process, a four-core SoC (cores 0-3) uses the MESI cache coherence protocol and a Mesh NoC topology. The current states are as follows: Core 0: Cache line address 0x1000 is in the S (Shared) state; Core 1: The same cache line is in the S (Shared) state; Cores 2 and 3: The address is not cached (states are I). The test target (target state): Core 0 changes the cache line state from S to M (Modified). The verification process may include: state transition validity check: Current state: S (Shared); Target state: M (Modified). Protocol rules: In the MESI protocol, an S→M transition requires first obtaining the E state before performing a write operation. Verification conclusion: Verification failed. Directly transitioning from S to M is illegal and must first transition to E.

[0061] Verification of the impact of multi-core consistency: Core 0 target state: M (modified). Other cores' current states: Core 1 is S, cores 2 / 3 are I. Protocol rule: When a core is in M ​​state, no other cores can have valid replicas (they must all be in I state). Verification conclusion: Before core 0 transitions to M, core 1's state must be changed from S to I (by sending an Invalidate transaction).

[0062] Furthermore, the verification function of the component can be judged by the scenario to verify whether the transition from the initial state to the final state of the consistency component complies with the rules of the on-chip network communication protocol. If it does, the state verification of the consistency component passes; if it does not, the state verification of the consistency component fails.

[0063] For example, the consistency component status verification method can refer to the verification method for the test core described above and will not be repeated here. The consistency component refers to the hardware module or logical structure used to record, manage, and maintain cache status and shared information in a system that supports cache coherence. In a multi-core system, each core has its own cache. If multiple cores access the same memory area simultaneously, cache data inconsistency may occur. The consistency component can solve this problem.

[0064] For example, in an AMBA-CHI-based consistency system, the collaboration process between consistency components may include: core A initiates a request (such as ReadUnique), the snoop filter (Snoop Filter) or directory (Directory) checks which cores currently cache the data at the address; sends a snoop request to these cores, asking them to invalidate or provide data; other cores respond, return data or confirm invalidation; the Home Node collects responses, returns the data to the initiating core, and updates the status of the consistency component; the consistency component records the new cache status (for example, only core A owns the data).

[0065] When the verification results for each test parameter are all passed, it is determined that the first data verification is passed; when there is at least one test parameter in the verification results for each test parameter that fails, it is determined that the first data verification has failed.

[0066] Step 202: When the verification result indicates that the first data verification fails, an error reminder message is output.

[0067] Step 203: When the verification result of the first data indicates that the first data verification has passed, extract the test parameters of each test scenario from the first data.

[0068] For example, when the verification result indicates that the first data verification has failed, the system generates a signal or message to notify the user that an illegal or unreasonable test scenario exists in the current test data, i.e., an error reminder message. The error reminder message may include the specific reason for the failure of the first data verification, such as an illegal state transition, an incorrectly cleared core, or a mismatch in the consistency component state. The tester can correct the test scenario information based on the error reminder message.

[0069] When the verification result of the first data indicates that the first data verification has passed, test parameters for each test scenario are extracted from the first data, including but not limited to the scenario name, test address, current state of the test core, end state of the test core, expected states of other cores in the SoC where the SoC is located, initial and end states of other cores in the SoC where the SoC is located, and initial and end states of the consistency component. These parameters can serve as the basis for subsequent generation of test stimuli to construct specific test files or transaction sequences.

[0070] This embodiment uses the verification function of the scenario judgment component to verify the first data according to the on-chip network communication protocol to obtain a verification result. When the verification result indicates that the first data verification fails, an error reminder message is output, which can detect errors in the early stage of generating the test file and avoid bringing illegal test scenarios into the subsequent simulation or verification process, thereby saving time and resources; when the verification result of the first data indicates that the first data verification passes, the test parameters of each test scenario are extracted from the first data, which can complete a pre-screening before the test case is executed, ensuring that only legal and reasonable test scenarios can enter the subsequent process, thereby improving test efficiency and accuracy.

[0071] In some embodiments, the above method further includes: steps 301 to 304.

[0072] Step 301: Perform driver conversion on the test file of the on-chip network through the driver, and send it to the reference model and the design under test.

[0073] For example, Figure 2This is a schematic diagram of the architecture for executing the on-chip network test file provided in the embodiment of the present application. Figure 2 As shown, in the test file generation stage, taking Python as an example, the Python parsing component can analyze and convert the test scenario list obtained after the design scenario analysis to obtain a sequence.

[0074] like Figure 2 As shown, during the test file execution phase, the verification platform can be built based on the Universal Verification Methodology (UVM). UVM is a comprehensive class library built in the System Verilog language that implements a coverage-driven verification methodology based on random constraints. UVM aims to unify and standardize industry verification specifications. When the verification platform executes the test file, it can drive the sequence input driver (DRV) and drive it to the input port of the design under test (DUT) through an interface. The driver is a functional module in the verification platform that converts the test file (usually an abstract test scenario description or transaction description) into a specific signal or transaction format that can be understood by the hardware. For example, it packages data into Flits (flow control units), adds routing information, and sets control signals.

[0075] The input monitor (In-mon) can collect input data sent to the DUT and send it to the reference model (Refrence-model). Input monitors are typically used to collect input data sent by the test stimulus to the design under test (DUT). This data is usually driven by a driver to the input port of the DUT. The input monitor can listen to and record these input transactions for subsequent analysis, debugging, or correlation with output data. For example, when collecting functional coverage, it is used to record the characteristics of input transactions; in transaction-level comparisons, it is used to correlate with data collected by the output monitor (Out-mon); and it is used for debugging to check whether the DUT correctly receives the input data.

[0076] Step 302: Obtain the output result of the design to be tested through the output monitor.

[0077] For example, Figure 2As shown in the figure, during the test file execution phase, the output monitor (Out-mon) can collect the response signals output by the DUT and send them to the scoreboard. The output monitor is typically used to collect DUT output data. This data is the response or output generated by the DUT after receiving input stimulus and undergoing internal logic processing. The output monitor can monitor these output signals and encapsulate them into transactions for subsequent processing. For example, it can compare them with the output of the reference model to verify the correct functionality of the DUT; collect output transactions for functional coverage analysis; and generate response signals to be fed back to the verification platform (such as the scoreboard) for comparison.

[0078] Step 303: Run the converted NoC test file through the reference model to obtain a reference result.

[0079] For example, the reference model can simulate the behavior of the NOC based on its internal logic (such as routing algorithms, arbitration mechanisms, and caching mechanisms). This simulation runs test scenarios and generates expected output results, or reference results. These include the expected content of received packets, the order in which packets are received, and the forwarding paths they take. This reference result represents the ideal NOC behavior output and is used for comparison with the actual output of the design under test.

[0080] Step 304: Compare the output result with the reference result to obtain the test result of the on-chip network test file.

[0081] For example, the scoreboard can compare the output results of the design under test with the reference results output by the reference model. Specifically, the scoreboard can compare each data point in the measured results (i.e., the output results of the design under test) with the reference results output by the reference model according to predefined rules and strategies. This comparison not only checks the consistency of data values, but also covers aspects such as data format, sequence, and transaction timing. During the comparison process, the scoreboard records every discrepancy in detail and identifies any potential errors. Finally, based on the scoreboard's comparison results, a comprehensive assessment is made of the verification status of the NoC test file. If the measured results and the reference results are highly consistent in all key aspects, with no significant differences or errors, the NoC test file can be considered to have passed verification and its functionality and performance generally meet design requirements. Conversely, if significant differences or a large number of errors are recorded, this indicates that the NoC test file may contain design flaws or logical errors, requiring in-depth investigation and modification before retesting.

[0082] In a specific embodiment, reference Figure 3 , Figure 3 This is a flow chart illustrating a process for generating a network-on-chip test file, as provided in an embodiment of the present application. Testers can analyze the current design's design scenario file, i.e., a test scenario list, based on the design specifications. Table 1 is an example of a test scenario list. Table 1 specifies the test name, address, initialization status of several cores and coherence nodes, and the end status of the current test.

[0083]

[0084] Table 1 The Python parsing component can parse the entire table and convert it into structured data in plain text format (such as data in csv, yaml, ini, etc.) through convert-list, and then convert the above plain text structured data into a list through return-list. The format of the list is: List_scenerio=['name':smoke_read_00,'addr':80000000,'core0_init':I,'core1_init':I,'core2_init':I,'core3_init':I, 'core0_final':I,'core1_final':I,'core2_final':I,'core3_ final':I,'HN_INIT':I,'HN_final':I].

[0085] The scene judgment component verifies the above list through Chi-transaction-compare according to the on-chip network communication protocol to obtain the verification result.

[0086] When the verification result indicates that the above list verification fails, the error handling and output module (error-hand-output) can output error reminder information.

[0087] When the verification result indicates that the above list has passed verification, the Python component can analyze the list and, combined with the NOC protocol content, analyze that the current scenario intends to test the address 0x80000000 and that it is expected that core 0 will eventually transition from the I state to the UC state, while the states of the other cores and the consistency node remain unchanged. This means that this core will have exclusive access to this data. The scenario conversion component can be used to extract the test parameters for each test scenario from the list. The sequence generation function in the sequence generator (chi-sequence-gen) can then convert the extracted test parameters for each test scenario into an executable test command sequence (sequence), generating the corresponding on-chip network test file for each test scenario and outputting the generated on-chip network test file.

[0088] In summary, in the embodiment of the present application, the test scenario information of the on-chip network can be obtained, and the test scenario information is limited to include multiple test scenarios, and each test scenario includes a set of test parameters. The text data of each test scenario information is extracted through the conversion function of the parsing component, and the extracted text data is converted into the first data that matches the format supported by the parsing component. After the test scenario information is obtained, the obtained test scenario information can be automatically analyzed and data extracted through the parsing component corresponding to the programming language, and the extracted data is converted into a data format that matches the format supported by the parsing component, thereby reducing the risk of recognition errors or unrecognition problems that may be caused by data in different formats, and realizing standardized processing of data. Finally, according to the test parameters and sequence generation functions of each test scenario, the on-chip network test file corresponding to each test scenario is generated, which can reduce the workload of manual coding, reduce errors caused by manual coding errors, and improve the efficiency of generating test cases, thereby improving the testing efficiency and test quality of the on-chip network.

[0089] The embodiment of the present application also provides a device for generating a network-on-chip test file. Figure 4 This is a block diagram of a device for generating network-on-chip test files provided by an embodiment of the present application. Figure 4 As shown, the apparatus 400 may include: an acquisition unit 401 , a conversion unit 402 and a generation unit 403 .

[0090] The acquisition unit 401 is configured to acquire test scenario information of the network on chip; the test scenario information includes multiple test scenarios, and each test scenario includes a set of test parameters.

[0091] The conversion unit 402 is used to extract text data from each test scenario information through the conversion function of the parsing component, and convert the format of the extracted text data into a target format to obtain first data; the target format matches the format supported by the parsing component.

[0092] The generating unit 403 is configured to generate an on-chip network test file corresponding to each test scenario according to the first data and the sequence generation function.

[0093] Optionally, the generating unit 403 is specifically configured to extract test parameters of each test scenario from the first data; and generate an on-chip network test file corresponding to each test scenario according to the test parameters of each test scenario and a sequence generation function.

[0094] Alternatively, as Figure 4 As shown, the device 400 may further include: a verification unit 404 and an output unit 405.

[0095] The verification unit 404 is configured to verify the first data according to the on-chip network communication protocol using the verification function of the scenario judgment component to obtain a verification result.

[0096] The output unit 405 is configured to output error reminder information when the verification result indicates that the first data verification fails.

[0097] The generating unit 403 is specifically configured to extract the test parameters of each test scenario from the first data when the verification result of the first data indicates that the first data verification has passed.

[0098] Optionally, the verification unit 404 is specifically used to verify, through the verification function of the scenario judgment component, whether the transition of the state of the test core in the test parameters of each test scenario in the first data from the current state to the target state complies with the rules of the on-chip network communication protocol, whether the transition of the state of other cores in the on-chip system where the on-chip network is located from the current state to the target state complies with the rules of the on-chip network communication protocol, and whether the transition of the initial state to the end state of the consistency component complies with the rules of the on-chip network communication protocol; if so, it is determined that the first data verification is passed; if not, it is determined that the first data verification has failed.

[0099] Optionally, the conversion unit 402 is specifically configured to extract text data from each test scenario information through a conversion function of the parsing component, and convert the extracted text data into structured data; and convert the format of the structured data into data in a target format to obtain first data.

[0100] Alternatively, as Figure 4 As shown, the device 400 may further include: a testing unit 406.

[0101] The test unit 406 is used to drive the conversion of the on-chip network test file through the driver and send it to the reference model and the design under test; obtain the output result of the design under test through the output monitor; run the converted on-chip network test file through the reference model to obtain a reference result; and compare the output result with the reference result to obtain the test result of the on-chip network test file.

[0102] Optionally, the test parameters may include: test address, current state of the test core, end state of the test core, expected state of other cores in the SoC where the SoC is located, initial state and end state of the consistency component, and scenario name.

[0103] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0104] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0105] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0106] An embodiment of the present application also provides an on-chip network test file generation device, including a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by one or more processors to include the methods described in one or more of the above embodiments.

[0107] The present application also provides an electronic device. Figure 5 , Figure 5 1 is a block diagram of an electronic device 500 according to an exemplary embodiment. For example, the electronic device 500 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0108] Reference Figure 5 The electronic device 500 may include one or more of the following components: a processing component 502 , a memory 504 , a power component 506 , a multimedia component 508 , an audio component 510 , an input / output (I / O) interface 512 , a sensor component 514 , and a communication component 516 .

[0109] The processing component 502 generally controls the overall operation of the electronic device 500, such as operations associated with display, phone calls, data communications, camera operation, and recording operations. The processing component 502 may include one or more processors 520 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 502 may include one or more modules to facilitate interaction between the processing component 502 and other components. For example, the processing component 502 may include a multimedia module to facilitate interaction between the multimedia component 508 and the processing component 502.

[0110] The memory 504 is used to store various types of data to support operations on the electronic device 500. Examples of such data include instructions for any application or method operating on the electronic device 500, contact data, phone book data, messages, pictures, multimedia, etc. The memory 504 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0111] The power supply assembly 506 provides power to the various components of the electronic device 500. The power supply assembly 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 500.

[0112] The multimedia component 508 includes a screen that provides an output interface between the electronic device 500 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the demarcation of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. In some embodiments, the multimedia component 508 includes a front-facing camera and / or a rear-facing camera. When the electronic device 500 is in an operating mode, such as a capture mode or a multimedia mode, the front-facing camera and / or the rear-facing camera can receive external multimedia data. Each front-facing camera and the rear-facing camera can have a fixed optical lens system or have a variable focal length and optical zoom capability.

[0113] The audio component 510 is used to output and / or input audio signals. For example, the audio component 510 includes a microphone (MIC) that receives external audio signals when the electronic device 500 is in an operating mode, such as a call mode, a recording mode, or a voice recognition mode. The received audio signals may be further stored in the memory 504 or transmitted via the communication component 516. In some embodiments, the audio component 510 also includes a speaker for outputting audio signals.

[0114] I / O interface 512 provides an interface between processing component 502 and peripheral interface modules, such as a keyboard, click wheel, buttons, etc. These buttons may include but are not limited to: a home button, volume buttons, a start button, and a lock button.

[0115] The sensor assembly 514 includes one or more sensors for providing various aspects of status assessment for the electronic device 500. For example, the sensor assembly 514 can detect the open / closed state of the electronic device 500, the relative positioning of components, such as the display and keypad of the electronic device 500. The sensor assembly 514 can also detect changes in the position of the electronic device 500 or a component of the electronic device 500, the presence or absence of user contact with the electronic device 500, the orientation or acceleration / deceleration of the electronic device 500, and temperature changes of the electronic device 500. The sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 514 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 514 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0116] The communication component 516 is used to facilitate wired or wireless communication between the electronic device 500 and other devices. The electronic device 500 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 516 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 516 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0117] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of the present application.

[0118] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, which can be executed by the processor 520 of the electronic device 500 to perform the above method. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0119] An embodiment of the present application further provides a computer program product, including a computer program, which implements the method described in the above embodiment when executed by a processor.

[0120] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0121] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for generating a network-on-chip test file, characterized in that: The method comprises: Acquire test scenario information of the on-chip network; the test scenario information includes multiple test scenarios, each of the test scenarios includes a set of test parameters; Extracting text data from each of the test scenario information using a conversion function of the parsing component, and converting the format of the extracted text data into a target format to obtain first data; the target format matches a format supported by the parsing component; The on-chip network test file corresponding to each of the test scenarios is generated according to the first data and the sequence generation function.

2. The method according to claim 1, characterized in that Generating the network-on-chip test file corresponding to each test scenario according to the first data and the sequence generation function includes: Extracting test parameters of each test scenario from the first data; The on-chip network test file corresponding to each test scenario is generated according to the test parameters of each test scenario and the sequence generation function.

3. The method according to claim 2, characterized in that The method further comprises: Verifying the first data according to the on-chip network communication protocol using a verification function of the scene judgment component to obtain a verification result; When the verification result indicates that the first data verification fails, outputting an error reminder message; Extracting the test parameters of each test scenario from the first data includes: When the verification result of the first data indicates that the first data verification has passed, the test parameters of each of the test scenarios are extracted from the first data.

4. The method according to claim 3, characterized in that The verification function of the scene judgment component verifies the first data according to the on-chip network communication protocol to obtain a verification result, including: Verify, by means of a verification function of a scenario judgment component, whether a transition from a current state to a target state of a test core in the test parameters of each of the test scenarios in the first data complies with the rules of the on-chip network communication protocol, whether a transition from a current state to a target state of other cores in the on-chip system where the on-chip network is located complies with the rules of the on-chip network communication protocol, and whether a transition from an initial state to an end state of a consistency component complies with the rules of the on-chip network communication protocol; If yes, it is determined that the first data verification has passed; If not, it is determined that the first data verification has failed.

5. The method according to claim 1, wherein The extracting text data from each of the test scenario information by the conversion function of the parsing component and converting the format of the extracted text data into a target format to obtain first data includes: Extracting text data from each of the test scenario information using a conversion function of the parsing component, and converting the extracted text data into structured data; The format of the structured data is converted into data in a target format to obtain the first data.

6. The method according to claim 1, characterized in that The method further comprises: Performing driver conversion on the test file of the network on chip through a driver, and sending the result to the reference model and the design under test; Obtaining the output result of the design under test through an output monitor; Running the converted test file of the on-chip network through the reference model to obtain a reference result; The output result is compared with the reference result to obtain a test result of the on-chip network test file.

7. The method according to claim 1, characterized in that The test parameters include: test address, current state of the test core, end state of the test core, expected state of other cores in the system on chip where the on-chip network is located, initial state and end state of the consistency component, and scenario name.

8. A device for generating a network-on-chip test file, characterized in that: The device comprises: An acquiring unit, configured to acquire test scenario information of the network on chip; the test scenario information includes a plurality of test scenarios, each of the test scenarios including a set of test parameters; a conversion unit, configured to extract text data from each of the test scenario information using a conversion function of the parsing component, and convert the format of the extracted text data into a target format to obtain first data; wherein the target format matches a format supported by the parsing component; A generating unit is configured to generate the on-chip network test file corresponding to each of the test scenarios according to the first data and a sequence generation function.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method according to any one of claims 1 to 7.

Images