UVM automatic verification method for chip to load external memory function

Abstract

The invention discloses a UVM automatic verification method for loading an external memory function on a chip, and belongs to the technical field of integrated circuit design and verification. According to the method, test excitation is divided into configuration information filled by a user and control information automatically generated through a formula to generate a configuration file, the configuration file is read by means of a memory model, data is configured to a specified register after a chip is powered on, and cross-channel data verification is achieved through an analysis module, a driving module and a data checking module. And randomly selecting one node from broadcast nodes for a register configured by the broadcast, and reading back data for comparison. According to the method, the limitation of single-link verification is broken through, a closed loop of configuration generation-simulation execution-cross-channel verification is formed, end-to-end automatic verification is realized, verification efficiency and reliability are improved, manual configuration errors are reduced, abnormity is accurately positioned in real time, and verification completeness and efficiency are balanced.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit design and verification, and particularly relates to a UVM automated verification method for the function of a chip to load an external memory. Background Art

[0002] In the field of chip design, due to the non-volatile characteristics of external memories, they are widely used to store key data such as configuration parameters and system firmware. Their loading process involves multi-module interaction and timing control during chip initialization. Currently, although various functional verification methods have been developed in chip verification technology, there are still obvious limitations in the verification of the external memory loading function: traditional verification means mostly focus on single links such as memory read and write behaviors, controller bus driving, or register configuration, lacking a full-process automated verification framework from memory reading to register configuration. Such fragmented verification methods are difficult to cover the actual scenarios with complex module interactions and precise timing control, and rely on manual participation in generating configuration files and result verification, resulting in low verification efficiency and insufficient standardization.

[0003] When verifying the function of a chip to load an external memory in the prior art, the following technical bottlenecks are mainly faced: First, during the generation of the configuration file, manual calculation and filling of control information are prone to introduce errors, and there is a lack of an automated generation mechanism, resulting in low configuration efficiency and difficult-to-guarantee consistency; Second, the verification process does not form a closed-loop system of "configuration - loading - verification". Data verification mostly relies on the coupling comparison of the paths between the memory and the registers, which is prone to misjudgment due to path interference, and the error location lacks real-time and accuracy; Third, the verification strategies for complex scenarios such as broadcast configuration and indirect access lack generality, and it is difficult to efficiently cover the configuration requirements of multiple nodes and multiple modes, resulting in an imbalance between verification completeness and efficiency. These problems make it difficult to fully expose potential defects in the external memory loading process of the chip before mass production, increasing the hardware debugging cost and market risk. Summary of the Invention

[0004] The purpose of the present invention is to overcome one or more deficiencies of the prior art and provide a UVM automated verification method for the function of a chip to load an external memory.

[0005] The purpose of the present invention is achieved through the following technical solutions:

[0006] A UVM automated verification method for the function of a chip to load an external memory includes:

[0007] Generating a configuration file: dividing the test stimuli into configuration information filled in by a user and control information automatically generated by a formula, where the control information is used to describe the classification, length, start, and end information of the configuration information;

[0008] Simulation loading: The configuration file is read in through the memory model using the $readmemh system function. After the chip under test is powered on, the memory is read through the bus and the data is configured into the specified register.

[0009] Cross-channel data verification: The analysis module parses the configuration file to generate the target register address and the expected data. The driver module simulates the CPU to initiate a register read operation and obtains the actual data. The data check module compares the two and outputs the result.

[0010] The method steps define the core framework of full-process automated verification, breaking through the limitations of single-link verification. Through the closed-loop design of "configuration generation - simulation execution - cross-channel verification", end-to-end automated verification from memory reading to register configuration is achieved, significantly improving verification efficiency and reliability.

[0011] Further, the control information includes at least one of load_end_addr, hss_num, cfg_type, pcie_subsys_end_addr, config_end_addr, hss_custom_start_addr, or hss_broadcast_start_addr.

[0012] In this way, the specific type of control information can be clarified. These parameters are used to define the boundaries of configuration items (such as load_end_addr), module classification (such as cfg_type to distinguish between custom / broadcast modes), and quantity (such as hss_num). By automatically generating instead of manual input, configuration errors are reduced.

[0013] Further, the hss_num is generated through the formula: DEC2HEX(COUNTA(configuration item area) / 22), which is used to represent the number of HSSs configured in the HSS custom items.

[0014] Taking hss_num as an example, illustrate the generation logic of the control information: The number of configuration items is counted through the COUNTA function in Excel, combined with a fixed coefficient (22) and converted to hexadecimal through DEC2HEX to achieve the dynamic calculation of the number of HSS nodes required by the hardware, avoiding manual counting errors.

[0015] Further, the generation of the configuration file is completed with the help of Excel. The number of configuration items is calculated through the COUNTA function, and the counting result is converted into hexadecimal control information through the DEC2HEX function.

[0016] Emphasize the tooling and automation of configuration file generation. Use Excel formulas (such as COUNTA to count non-empty cells and DEC2HEX to convert number systems) to achieve one-key generation of control information, reducing the manual configuration volume by about 50% and improving the process standardization level.

[0017] Further, in the cross-channel data verification, the hardware write path is that the chip reads data from the memory through the bus and configures the register, and the software read path is that the driver module reads the register data through the APB bus.

[0018] Clarify the cross-channel mechanism of "hardware write - software read": The hardware path completes the configuration through the chip bus, and the software path independently reads the register through the APB bus, forming path isolation to avoid misjudgment caused by the coupling of the memory and register paths and improve reliability.

[0019] Further, when the analysis module parses the configuration file, if it recognizes that eflash_data[87:64] is not 24'hf_ffff, it is determined as direct access, and the register address is obtained through eflash_data[71:64]; if it is 24'hf_ffff, it is determined as indirect access, and the access node is determined through eflash_data[61:56].

[0020] Refine the data parsing logic. Distinguish direct / indirect configuration modes through address segment encoding (such as 24'hf_ffff indicating indirect access) to be compatible with the access mechanisms of different registers in the chip (such as broadcast, specified node), ensuring the accurate simulation of the hardware logic by the verification environment.

[0021] Further, the data check module is based on the UVM verification methodology and prints the comparison results of each line of configuration in real time during the simulation run.

[0022] Highlight the application value of the UVM methodology. Use its phase mechanism (such as report_phase) to output the line-by-line comparison results (address, expected data, actual data) in real time. Compared with traditional script verification, the error location efficiency is improved by about 40%, which is convenient for quick debugging.

[0023] Further, for the registers configured by broadcast, randomly select a node from the broadcast nodes to read back the data for comparison.

[0024] Optimize the verification efficiency of the broadcast scenario: Verify by randomly selecting nodes (instead of traversing all nodes), reducing the simulation time consumption on the premise of ensuring coverage, applicable to multi-node broadcast configuration scenarios such as HSS, and balancing verification completeness and efficiency.

[0025] Further, the configuration file contains fixed end markers e0 e6 ea ef, which are used to identify the end of a single HSS configuration in the HSS customization items. When the analysis module parses, it skips the line with these end markers.

[0026] Define that the hardware recognition mechanism marks the termination of a single HSS configuration through fixed end markers (such as e0e6eaef). The analysis module automatically skips such invalid lines to avoid incorrect parsing and ensure the accuracy of data comparison.

[0027] Further, the comparison result of the data check module includes register address, expected data, actual data, and comparison status, which are used to locate abnormal points in the configuration process.

[0028] Clarify the output dimension of the verification result. Through structured logs (address + data + status), accurately locate configuration anomalies (such as incorrect addresses, failed data writes), provide a direct basis for hardware debugging, and improve the efficiency of problem troubleshooting.

[0029] The beneficial effects of the present invention are as follows:

[0030] (1) Through the UVM verification methodology and cross-channel data verification technology, achieve real-time comparison of register data and output structured logs, improving the error location efficiency and verification reliability;

[0031] (2) With the help of Excel tools, automatically generate control information in the configuration file, reducing the amount of manual configuration, avoiding manual calculation errors, and improving the standardization degree of the verification process;

[0032] (3) Adopt the isolation mechanism of the hardware write path and the software read path, combined with the random verification strategy of the broadcast node, to achieve the effect of covering the full-process verification closed-loop and balancing the verification completeness and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a flowchart of the steps of a UVM automated verification method for a chip to load an external memory function;

[0034] Figure 2 It is a system composition architecture diagram;

[0035] Figure 3 It is a schematic diagram of the EEPROM storage format;

[0036] Figure 4 It is an example diagram of filling in an Excel configuration file;

[0037] Figure 5 It is an example diagram of the configuration file format conversion;

[0038] Figure 6 It is a logic diagram of the data extraction and verification process;

[0039] Figure 7 It is a logic diagram of the data extraction and verification process. Specific implementation manners

[0040] Next, the technical solutions of the present invention will be described clearly and completely in conjunction with the embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative efforts fall within the scope of protection of the present invention.

[0041] Embodiment 1

[0042] Refer to Figure 1 , and a UVM automated verification method for the function of a chip to load an external memory is provided. The steps of the method include:

[0043] Generate a configuration file: Divide the test stimuli into configuration information filled in by the user and control information automatically generated by a formula. The control information is used to describe the classification, length, start, and end information of the configuration information;

[0044] Simulation loading: Use the $readmemh system function to read the configuration file through the memory model. After the chip under test is powered on, read the memory through the bus and configure the data into the specified register;

[0045] Cross-channel data verification: The analysis module parses the configuration file to generate the target register address and the expected data. The driving module simulates the CPU to initiate a register read operation and obtains the actual data. The data check module compares the two and outputs the result.

[0046] The control information includes at least one of load_end_addr, hss_num, cfg_type, pcie_subsys_end_addr, config_end_addr, hss_custom_start_addr, or hss_broadcast_start_addr.

[0047] hss_num is generated by the formula DEC2HEX(COUNTA(configuration item area) / 22), and is used to represent the number of HSSs configured in the HSS customization item.

[0048] The generation of the configuration file is completed with the help of Excel. The number of configuration items is calculated by the COUNTA function, and the counting result is converted into hexadecimal control information by the DEC2HEX function.

[0049] In cross-channel data verification, the hardware write path is that the chip reads data from the memory through the bus and configures the register, and the software read path is that the driver module reads the register data through the APB bus.

[0050] When the analysis module parses the configuration file, if it recognizes that eflash_data[87:64] is not 24’hf_ffff, it determines it as a direct access and obtains the register address through eflash_data[71:64]; if it is 24’hf_ffff, it determines it as an indirect access and determines the access node through eflash_data[61:56].

[0051] Based on the UVM verification methodology, the data check module prints the comparison results of each line of configuration in real time during the simulation run.

[0052] For the registers configured for broadcast, a node is randomly selected from the broadcast nodes to read back the data for comparison.

[0053] The configuration file contains fixed end symbols e0 e6 ea ef, which are used to identify the end of a single HSS configuration in the HSS customization item. The analysis module skips this end symbol line during parsing.

[0054] The comparison results of the data check module include the register address, expected data, actual data, and comparison status, which are used to locate the abnormal points in the configuration process.

[0055] Embodiment 2

[0056] This embodiment takes the advanced UVM automated verification method as the core and constructs an end-to-end automated verification system for the external memory loading function of the switch chip. This method forms a complete verification loop through an innovative automated configuration file generation mechanism, precise simulation loading technology, and efficient cross-channel data verification strategy. This design can not only greatly improve the verification efficiency, but also fundamentally reduce the verification errors caused by human factors by reducing manual intervention, and build a solid and reliable technical barrier for the functional verification before chip mass production.

[0057] Taking a certain model of switch chip as a typical research object, the externally mounted EEPROM memory stores key configuration parameters such as PCIe and Serdes interfaces. These parameters need to be accurately loaded into the specified registers through a precise bus system at the moment when the chip is powered on and started, so as to lay a solid foundation for the normal initialization and stable operation of each functional module of the chip.

[0058] (1) Systematic design of the configuration file structure:

[0059] The scientificity and rationality of the structure design of the configuration file directly affect the quality and efficiency of the subsequent verification work. Refer toFigure 3 , the configuration file architecture adopts a hierarchical and modular design concept, clearly dividing the overall structure into two core parts: control information and configuration information.

[0060] The control information configuration file is located in the key positions of the first few rows of the table and contains important parameters such as load_end_addr, hss_num, and cfg_type. These parameters are used to accurately describe the key attributes of the configuration information, such as classification, length, start, and end, providing clear guidance for the subsequent chip to parse the configuration file. The configuration information follows the control information and contains the core contents such as the specific register configuration addresses and data, which is the key to realizing the chip function configuration.

[0061] In the specific implementation carrier of the Excel table, each row of data is carefully designed to represent 11 bytes of stored content and is scientifically divided into different fields. Taking the base configuration row 0 as an example, it not only contains control fields such as load_end_addr, hss_num, and cfg_type, but also sets the fixed character c5 as the identifier for the configuration to take effect, and e0e6eaef as the end symbol for a single HSS configuration. This field design strictly follows the technical requirements of the chip hardware interface to ensure that the generated configuration file can be accurately parsed and executed by the chip.

[0062] (2) The standardized process for filling in user configuration information:

[0063] When testers fill in the content in the configuration information area of the Excel table for the configuration file, they need to follow a scientific and standardized operation process. According to the requirements of different test scenarios, testers fill in the necessary register configuration content in the corresponding configuration area. For example, in the PCIe hardwired configuration part, the address of the target register and the corresponding data need to be filled in; in the HSS hardwired configuration part, the various configuration parameters related to the high-speed serial interface need to be filled in detail.

[0064] In this filling process, testers only need to focus on the realization of the specific configuration function and do not need to manually handle complex control information. This design not only greatly reduces the operation difficulty but also effectively reduces various mistakes that may occur during the manual form-filling process, ensuring the accuracy of the configuration information from the source.

[0065] Refer to Figure 4, in the HSS custom configuration area, testers need to fill in the configuration data of each HSS node line by line according to the established rules, including key information such as module node address, register address, and write data. After completing the configuration of each HSS node, the form will activate the intelligent assistance function and automatically insert the fixed end symbol e0e6eaef to clearly mark the end of the node configuration, effectively avoiding confusion and errors that may occur during hardware parsing.

[0066] (III) Intelligent mechanism for automatic generation of control information:

[0067] The generation process of control information fully demonstrates the charm of automation technology. It realizes the full-process automatic generation through the powerful function of Excel built-in, completely without manual intervention. Taking the generation of the hss_num parameter as an example, there is a delicate logical design behind it: first, the COUNTA function accurately counts the number of configuration lines of the HSS customization items; then the statistical result is divided by a fixed coefficient to complete the standardization of the data; finally, the DEC2HEX function is used to convert the result into a hexadecimal value, which accurately represents the number of HSS configured in the HSS customization items. The automatic generation method ensures the high accuracy of control information and completely eliminates the low-level errors that may be caused by manual counting.

[0068] Similarly, the load_end_addr parameter is used to accurately identify the end address of the HSS hardwired configuration item, and its generation process is also full of wisdom: the COUNTA function is used to count the number of lines of the HSS hardwired configuration item, and then it is converted into hexadecimal format after adding a fixed offset. The cfg_type field can be automatically judged and generated according to the existence of the HSS broadcast configuration item. If there is a broadcast configuration item, it is a specific identifier, otherwise it is another identifier, so as to achieve accurate differentiation of the configuration mode.

[0069] (IV) Standardization process of configuration file format conversion:

[0070] After completing the filling of configuration information and the automatic generation of control information, it enters the key link of configuration file format conversion. This process requires a custom script to convert the Excel table into a standard configuration file format that can be read by the memory model. Refer to Figure 5 , each line of data in the converted file format starts with an address mark (such as @00, @0b, etc.), followed by hexadecimal data, and each line of data accurately corresponds to a storage unit in the EEPROM, achieving a perfect match between the data format and hardware storage.

[0071] The format conversion process is fully automated by a custom script. This script traverses the data in the Excel table line by line, precisely concatenates the data in each field according to the specified format, and adds corresponding address markers to each line of data. For example, the data in row 0 of the basic configuration is accurately converted into a specific format, where "@00" clearly indicates the starting address of this row of data in the memory, and fixed fields such as "c5 e0 e6 ea ef" and the end symbol ensure the accuracy and reliability of data parsing.

[0072] Emulation loading process:

[0073] (1) Technical key points for establishing the memory model:

[0074] Under the advanced technical framework of the UVM verification platform, constructing an SV emulation model of the EEPROM memory is the primary task of the entire emulation loading process. This model efficiently reads the generated configuration file through the system function $readmemh, thus accurately simulating the behavior of the external memory.

[0075] The address space design of the memory model follows strict standardization principles, forming a one-to-one mapping relationship with the physical address of the actual EEPROM. This address mapping data transmission ensures that the chip can access the real memory during the emulation process, accurately access the configuration data, and lay a solid foundation for subsequent emulation verification work.

[0076] (2) Automatic implementation of loading the configuration file:

[0077] When the emulation process starts, the memory model automatically triggers the configuration file loading mechanism and calls the readmemh system function to automatically read the converted configuration file. The call format of this function is carefully designed, in the form of readmemh ("config_file.mem", memory_model), where "config_file.mem" clearly specifies the storage path of the configuration file, and memory_model represents the memory model instance.

[0078] During this loading process, the function accurately loads the data in the configuration file to the corresponding positions in the memory model according to the address order, completing the initialization of the memory model. The entire process requires no manual intervention, realizing the full automation of loading the configuration file, and greatly improving the efficiency and reliability of the verification process.

[0079] (3) Timing control of the chip power-on and configuration process:

[0080] After the chip under test completes the power-on operation, the Clock Reset Management Module (CRG) releases the reset signal of the memory controller according to the established timing logic. After receiving the reset release signal, the controller will start the process of automatically reading the configuration data in the external memory through the bus system.

[0081] During the data reading process, the controller will accurately parse the control field segment in the configuration data and configure the data into the specified register in different ways such as direct access, indirect access, or broadcast mode according to the parsing result. This process can select the optimal data transmission path according to different configuration requirements.

[0082] During the configuration process, the controller's control of timing is crucial. It will accurately judge the configuration boundary based on key control information such as load_end_addr and config_end_addr. When the configuration operation reaches the end address, the controller will generate a DONE signal in a timely manner. This signal is used to release the reset signal of the subsequent module to ensure that the subsequent module can start working according to the timing requirements; before configuring to the start address, the controller will patiently wait for the ready signal of other modules to ensure the timing coordination among modules and avoid timing conflict problems.

[0083] Taking the specific scenario of PCIe Subsys configuration as an example, after the controller reads pcie_subsys_end_addr, it will immediately confirm the end of this part of the configuration work, and then turn to the next part of the configuration work according to the established logic. The entire configuration process is closely linked and does not require any manual intervention, realizing the fully automated process from memory reading to register configuration, fully demonstrating the efficiency and reliability of this verification method.

[0084] Cross-channel data verification:

[0085] (1) The core concept of the verification framework design:

[0086] The cross-channel data verification mechanism adopts the innovative design concept of "hardware write - software read". This design forms path isolation during the data transmission process, fundamentally avoiding misjudgment problems caused by the coupling of the memory and register paths, and greatly improving the reliability of the verification results.

[0087] Among them, the hardware write path simulates the real process of the chip reading data from the memory through the bus and configuring the register, while the software read path independently reads the register data by the driver module through the APB bus. The two paths are independent and complementary to each other.

[0088] The overall architecture of the verification framework consists of three core parts: an analysis module, a driver module, and a data check module. The analysis module is responsible for parsing the configuration file to generate the target register address and the expected data; the driver module simulates the CPU to initiate a register read operation and obtain the actual data; the data check module compares the expected data with the actual data and outputs the result. The three work closely together to form a complete and efficient verification system. Refer to Figure 2 .

[0089] (2) In-depth explanation of the parsing logic of the analysis module:

[0090] The analysis module will deeply parse the configuration file line by line in the entire verification framework and intelligently determine the access mode based on the value of the eflash_data[87:64] field. There are mainly the following two modes:

[0091] 1. Direct access mode: If eflash_data [87:64] is a non-specific identification value, the analysis module will determine it as the direct access mode. In this mode, the analysis module obtains the register address through eflash_data [71:64], uses eflash_data [87:72] as the module node address, and identifies eflash_data [63:0] as the write data. Subsequently, the analysis module will send the parsed register address and expected data to the driver module and the data check module respectively, providing accurate "reference data" for the subsequent verification work.

[0092] 2. Indirect access mode: If eflash_data [87:64] is a specific identification value, the analysis module will determine it as the indirect access mode. At this time, the analysis module determines the access node through eflash_data [61:56]: when this value is 6’h3f, it represents a broadcast access to all HSS nodes; when this value is 6’h19, it represents an access to the PCIe node. For the access to the PCIe node, the analysis module will further determine the internal sub-module node according to eflash_data [55:52]. For example, 4’d0 represents an access to the PCIE_SUB_SYSTERM sub-module. In addition, eflash [51:32] is parsed as the offset address, and eflash_data [31:0] is the write data.

[0093] Refer to Figure 6 - Figure 7, the analysis module has intelligent recognition capabilities and will automatically skip lines containing the end symbol e0e6eaef during the parsing process to avoid interference from invalid data on the parsing results. For HSS customization items, once the analysis module encounters an end symbol line after parsing the configuration data of each HSS node, it will automatically skip it and continue to focus on parsing the configuration data of the next node to ensure the efficiency and accuracy of the parsing work.

[0094] (3) Specific implementation of the driving module's simulation operation:

[0095] After receiving the target register address sent by the analysis module, the driving module will accurately simulate the entire process of the CPU initiating a register read operation through the APB bus. This read operation process includes multiple precise links: first, send the address information to let the bus clarify the target position of data reading; then send the control signal to command the bus to work according to the established rules; finally, send the read request to officially start the data reading process. After completing the above operations, the driving module will patiently wait for the bus response until it successfully obtains the actual data.

[0096] For registers with broadcast configuration, the driving module adopts an intelligent and efficient operation strategy: it will not blindly traverse all nodes, but randomly select a node from the broadcast nodes to initiate a read operation. This strategy can conduct a sample survey, and on the premise of ensuring the verification coverage rate, it greatly reduces the simulation time consumption and effectively improves the efficiency of the entire verification process. For example, when parsing the HSS broadcast configuration, the driving module will randomly select a node from many HSS nodes to accurately read its register data, which not only ensures the comprehensiveness of verification but also takes into account efficiency.

[0097] (4) Specific process of the data check module's comparison process:

[0098] The data check module is built based on the advanced UVM verification methodology and is like an indefatigable "quality inspector". During the simulation operation, it receives the expected data from the analysis module and the actual data from the driving module in real time and compares the two line by line.

[0099] The comparison process and results include key information such as register address, expected data, actual data, and comparison status (such as pass, fail), etc. These information will be printed and output in the simulation log in real time to facilitate quickly locating possible abnormal points in the configuration process.

[0100] When the comparison results are inconsistent, the data check module will immediately record the abnormal register addresses and data values, providing a direct and accurate basis for hardware debugging. For example, if the expected data is a certain specific value while the actually read data does not match it, the data check module will clearly output the abnormal address, expected data, actual data, and the status information of comparison failure, helping engineers quickly locate the problem and significantly shortening the debugging time.

[0101] (V) Special scenario handling:

[0102] 1. Optimization strategy for broadcast configuration verification: For the registers of broadcast configuration, an innovative method of randomly selecting nodes is adopted for verification. For example, in the HSS broadcast configuration scenario, the driver module will randomly select a node from numerous HSS nodes to read back the data and compare it with the expected data. This strategy conducts spot checks while ensuring comprehensive coverage, which can not only ensure the completeness of verification but also effectively reduce the simulation time, achieving a perfect balance between verification quality and efficiency.

[0103] 2. Intelligent mechanism for end symbol handling: The fixed end symbol e0e6eaef in the configuration file is used to clearly identify the end of a single HSS configuration. The analysis module has the intelligent recognition ability during the parsing process and will automatically skip when encountering such lines to avoid misparsing. For example, in the HSS customization items, each node configuration is followed by an end symbol line, and the analysis module will directly skip it and continue to focus on parsing the configuration data of the next node, ensuring the accuracy and coherence of the parsing work.

[0104] 3. Precise logic for indirect access handling: For the indirect access mode, especially for the configuration involving the PCIe sub-module, the analysis module will accurately process the address according to the hardware logic. For example, when accessing the PCIE_SUB_SYSTERM sub-module, the analysis module will right-shift the offset address of eflash [51:32] and then send it to the driver module. This process ensures the correctness of the address and lays a solid foundation for subsequent data configuration operations.

[0105] Verification process and results of the embodiment:

[0106] I) System planning for test case design and execution:

[0107] In this embodiment, comprehensive system test cases are designed for the diverse configuration scenarios of the switch chip, mainly including the following key scenarios:

[0108] 1. PCIe Interface Configuration Test: This test case focuses on verifying whether the PCIe hardwired configuration parameters can be accurately loaded into the corresponding registers through the entire verification process, ensuring the normal initialization and functionality of the PCIe interface.

[0109] 2. HSS Custom Configuration Test: This test case aims to verify whether the customized configurations of multiple HSS nodes can be correctly parsed, loaded, and verified, ensuring that each HSS node can achieve specific functions according to the design requirements.

[0110] 3. HSS Broadcast Configuration Test: This test case focuses on verifying whether the configuration data can be accurately applied to the target nodes in the broadcast mode, ensuring that all target nodes can correctly receive and apply the configuration data in the broadcast configuration scenario.

[0111] 4. Hybrid Configuration Scenario Test: This is a comprehensive test case that includes multiple configuration types such as PCIe, HSS custom, and broadcast configuration, used to verify the stability and reliability of the entire verification process in complex configuration scenarios.

[0112] Each test case follows a standardized execution process: First, generate the corresponding configuration file according to the test requirements, then load the configuration file into the simulation environment for execution, and finally comprehensively verify the configuration results through the cross-channel data verification mechanism. This systematic test case design and execution process ensure the comprehensiveness and scientific nature of the verification work.

[0113] II) In-depth Interpretation of Simulation Results Analysis:

[0114] After comprehensively running each test case through the UVM verification platform, the data check module plays a key role in real-time outputting the line-by-line comparison results. In a normal test scenario, the expected data and the actual data of all configuration lines can be highly consistent, and the comparison status shows as passed, indicating that the configuration data has been accurately loaded into the corresponding registers, and the external memory loading function of the chip operates normally in this test scenario.

[0115] Taking the HSS custom configuration test case as an example, the comparison results of each line of configuration data are clearly recorded in the simulation log, such as "at a certain address: expected a certain value, actual a certain value, comparison passed" and other information, which fully indicates that the configuration data of the HSS node has been correctly loaded into the register, verifying the reliability of this function.

[0116] For abnormal test scenarios, such as misfilling the register address in the PCIe configuration, the data check module will capture the abnormality immediately and output detailed error information, such as "At a certain address: expected a certain value, but actually got a certain value, comparison failed", etc. These messages provide engineers with clear debugging directions, helping them quickly locate the root cause of the problem, and then optimize the configuration file or related links accordingly.

[0117] III) Multi-dimensional analysis of the improved verification efficiency:

[0118] Compared with traditional verification methods, the UVM automated verification method adopted in this embodiment has achieved significant efficiency improvement in multiple dimensions, mainly reflected in the following aspects:

[0119] 1. Substantial improvement in the efficiency of generating configuration files: By using the Excel tool to automatically generate control information, this innovative mechanism can greatly reduce the manual configuration workload and reduce the manual input compared with traditional methods. At the same time, the automated generation mechanism fundamentally avoids various errors that may occur during the manual calculation and input processes, significantly improving the generation quality and efficiency of configuration files.

[0120] 2. Significantly improved error location efficiency: The UVM methodology supports real-time printing of line-by-line comparison results, which enables errors to be detected in a timely manner during the simulation process. Compared with traditional script verification methods, the real-time feedback mechanism improves the error location efficiency, greatly shortening the debugging time and enhancing the efficiency of the entire verification process.

[0121] 3. Significantly enhanced reusability of test cases: In the verification system of this embodiment, different test cases only need to modify the content of the configuration file according to requirements, and the verification environment can automatically identify the target registers and complete the comparison work. This design eliminates the need to rewrite the verification logic, greatly improving the reusability of test cases, enabling more efficient utilization of verification resources, and further enhancing the overall verification efficiency.

[0122] This embodiment comprehensively presents the UVM automated verification method for the function of the chip loading external memory through detailed process demonstrations and in-depth technical analyses. This method constructs a complete automated verification closed-loop from configuration file generation, simulation loading to cross-channel data verification, achieving a comprehensive verification of the chip's external memory loading function. The core advantages of this method are mainly reflected in the following aspects:

[0123] 1. Comprehensiveness of the closed-loop design: Through the innovative closed-loop design of "configuration generation - simulation execution - cross-channel verification", this method achieves end-to-end full-process coverage from memory reading to register configuration. Such a comprehensive verification system ensures the comprehensiveness of the verification work without dead ends and can effectively detect potential functional problems.

[0124] 2. High efficiency of automation: Make full use of Excel tools to automatically generate control information, and combine with the UVM platform to achieve full automation of simulation loading and data verification, greatly reducing manual intervention. This highly automated verification process not only significantly improves verification efficiency, but also fundamentally reduces verification errors caused by human factors, providing strong guarantee for the efficient development of chip verification work.

[0125] 3. Scientific reliability design: The isolation design between the hardware write path and the software read path avoids misjudgment problems caused by path coupling; the real-time comparison and log output functions of the UVM methodology improve the accuracy and efficiency of error location, ensuring the reliability of verification results from multiple levels.

[0126] 4. Flexible general design: This method is applicable to different types of chips and diverse configuration scenarios. Users only need to adjust the content of the configuration file according to actual needs to complete the verification of different test cases. This good generality and scalability enable it to play an important role in different chip verification projects and have broad application prospects.

[0127] Through the verification method of this embodiment, the external memory loading function of the switch chip has been fully and comprehensively verified, ensuring the correctness and stability of the configuration process before mass production of the chip, and providing a solid technical guarantee for the reliability and market competitiveness of the chip. At the same time, the design concepts and technical ideas contained in this method are also applicable to the verification of the external memory loading function of other types of chips, and can provide useful reference for the technological progress of the entire chip verification field.

[0128] The above are only the preferred embodiments of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein, should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications and environments, and can be changed within the scope of the concept described herein through the above teachings or the technology or knowledge in related fields. And the changes and modifications made by those skilled in the art without departing from the spirit and scope of the present invention shall fall within the protection scope of the appended claims of the present invention.

Claims

1. A UVM automated verification method for a chip to load an external memory function, characterized in that, Including: Generating a configuration file: Divide the test stimuli into configuration information filled in by the user and control information automatically generated by formulas. The control information is used to describe the classification, length, start and end information of the configuration information; Simulation loading: Use the $readmemh system function to read the configuration file through the memory model. After the chip under test is powered on, read the memory through the bus and configure the data into the specified register; Cross-channel data verification: The analysis module parses the configuration file to generate the target register address and expected data. The driving module simulates the CPU to initiate a register read operation and obtains the actual data. The data check module compares the two and outputs the result.

2. The method according to claim 1, wherein The control information includes at least one of load_end_addr, hss_num, cfg_type, pcie_subsys_end_addr, config_end_addr, hss_custom_start_addr or hss_broadcast_start_addr.

3. The method according to claim 2, wherein The hss_num is generated by the formula: DEC2HEX(COUNTA(configuration item area) / 22), and is used to represent the number of HSSs configured in the HSS customization item.

4. The method according to claim 1, characterized in that, The generation of the configuration file is completed with the help of Excel. The number of configuration items is calculated by the COUNTA function, and the counting result is converted into hexadecimal control information by the DEC2HEX function.

5. The method according to claim 1, wherein In the cross-channel data verification, the hardware write path is that the chip reads data from the memory through the bus and configures the register, and the software read path is that the driving module reads the register data through the APB bus.

6. The method according to claim 1, wherein When the analysis module parses the configuration file, if it recognizes that eflash_data[87:64] is not 24’hf_ffff, it is determined as direct access, and the register address is obtained through eflash_data[71:64]; if it is 24’hf_ffff, it is determined as indirect access, and the access node is determined through eflash_data[61:56].

7. The method according to claim 1, characterized in that, The data check module is based on the UVM verification methodology and prints the comparison results of each line of configuration in real time during the simulation run.

8. The method according to claim 1, wherein For the registers configured for broadcast, randomly select a node from the broadcast nodes to read back the data for comparison.

9. The method according to claim 1, characterized in that, The configuration file contains fixed end characters e0 e6 eaef, which are used to identify the end of a single HSS configuration in the HSS customization item. The analysis module skips this end character line during parsing.

10. The method according to claim 1, characterized in that The comparison result of the data check module includes the register address, expected data, actual data and comparison status, which are used to locate the abnormal points in the configuration process.

Images