A uvm automation verification method of a chip loading external memory function

Abstract

The application discloses a kind of UVM automation verification methods of chip loading external memory function, belong to integrated circuit design and verification technical field.The method will test excitation be divided into the configuration information filled in by user and the control information generated automatically by formula to generate configuration file, with the aid of memory model reading configuration file and after powering on on chip, data is configured to specified register, cross-channel data verification is realized through analysis module, drive module and data check module, and data is read back from a node randomly selected in broadcast node for comparison for the register configured by broadcast.The method breaks through the limitation of single link verification, forms a closed loop of "configuration generation-simulation execution-cross-channel verification", realizes end-to-end automation verification, improves verification efficiency and reliability, reduces manual configuration error, accurately locates anomaly in real time, balances verification completeness and efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of integrated circuit design and verification technology, in particular to a UVM automatic verification method for chip loading external memory function. BACKGROUND

[0002] In the field of chip design, external memory is widely used to store configuration parameters, system firmware and other key data due to its non-volatility, and its loading process involves multi-module interaction and timing control during chip initialization. Currently, although chip verification technology has developed various functional verification methods, the verification of external memory loading function still has obvious limitations: traditional verification methods focus on single aspects such as memory read / write behavior, controller bus driving or register configuration, lacking a full-process automatic verification framework from memory reading to register configuration. Such fragmented verification methods cannot cover complex module interaction and precise timing control scenarios, and rely on manual configuration file generation and result verification, resulting in low verification efficiency and insufficient standardization.

[0003] The existing technology mainly faces the following technical bottlenecks when verifying the chip external memory loading function: first, manual calculation and filling of control information during configuration file generation is prone to errors and lacks automatic generation mechanism, resulting in low configuration efficiency and difficulty in ensuring consistency; second, the verification process does not form a closed-loop system of "configuration-loading-verification", and data verification relies on the coupling comparison of memory and register paths, which is prone to false positives due to path interference, and error localization lacks real-time and accuracy; third, the verification strategy for complex scenarios such as broadcast configuration and indirect access lacks universality, making it difficult to efficiently cover multi-node and multi-mode configuration requirements, resulting in a balance between verification completeness and efficiency. These problems make it difficult to fully expose potential defects in the external memory loading process before mass production, increasing hardware debugging costs and market risks. SUMMARY

[0004] The present application relates to the field of integrated circuit design and verification technology, in particular to a UVM automatic verification method for chip loading external memory function.

[0005] The purpose of the present application is achieved by the following technical solutions:

[0006] A UVM automatic verification method for chip loading external memory function, comprising:

[0007] Generating a configuration file: dividing the test stimulus into configuration information filled by the user and control information automatically generated by the formula, the control information being 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 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 two and outputs the result.

[0010] This method defines 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", it achieves end-to-end automated verification from memory reading to register configuration, significantly improving verification efficiency and reliability.

[0011] Furthermore, 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] This method can clearly define the specific type of control information. 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 and broadcast modes), and quantity (such as hss_num). By automatically generating parameters instead of manual input, configuration errors can be reduced.

[0013] Furthermore, the hss_num is calculated using the formula: DEC2HEX(COUNTA(configuration item area) / 22), and is used to represent the number of HSSs configured in the HSS customization item.

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

[0015] Furthermore, the configuration file is generated with the aid of Excel, the number of configuration items is calculated using the COUNTA function, and the counting result is converted into hexadecimal control information using the DEC2HEX function.

[0016] Emphasize the tooling and automation of configuration file generation, use Excel formulas (such as COUNTA to count the number of non-empty cells, DEC2HEX to convert the base) to realize one-key generation of control information, reduce about 50% of manual configuration, and improve the standardization degree of the process.

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

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

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

[0020] Refine the data analysis logic to distinguish between direct / indirect configuration modes through address segment encoding (such as 24'hffff to identify indirect access), and to ensure accurate simulation of the hardware logic by the verification environment.

[0021] Further, the data checking module is based on the UVM verification methodology, and the comparison results of each line of configuration are printed in real time during simulation running.

[0022] Highlight the application value of the UVM methodology, and 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 positioning efficiency is improved by about 40%, which is convenient for rapid debugging.

[0023] Further, for the broadcast configured register, one node is randomly selected from the broadcast node to read back the data for comparison.

[0024] Optimize the verification efficiency of the broadcast scene: by randomly selecting nodes (rather than traversing all nodes) for verification, the simulation time is reduced under the premise of ensuring coverage, which is suitable for HSS and other multi-node broadcast configuration scenes, and balances verification completeness and efficiency.

[0025] Further, the configuration file contains a fixed end marker e0 e6 ea ef for identifying the end of a single HSS configuration in the HSS customization item, and the analysis module skips the end marker line when parsing.

[0026] The definition hardware identification mechanism marks the termination of a single HSS configuration by a fixed end marker (such as e0e6eaef), and the analysis module automatically skips such invalid lines to avoid misinterpretation and ensure the accuracy of data comparison.

[0027] Further, the data checking module compares the results including register address, expected data, actual data and comparison state, for locating abnormal points in the configuration process.

[0028] The output dimension of the verification result is defined, and the configuration exception (such as address error and data writing failure) is accurately located through the structured log (address + data + state), which provides direct basis for hardware debugging and improves problem troubleshooting efficiency.

[0029] The beneficial effects of the present application are:

[0030] (1) Through the UVM verification methodology and cross-channel data checking technology, the register data is compared in real time and the structured log is outputted, so that the error positioning efficiency and the verification reliability are improved;

[0031] (2) The control information in the configuration file is automatically generated by means of the Excel tool, so that the amount of manual configuration is reduced, the manual calculation error is avoided, and the standardization degree of the verification process is improved;

[0032] (3) The hardware write path and the software read path isolation mechanism are adopted, and the random checking strategy of the broadcast node is combined, so that the full-process verification closed loop is covered, and the verification completeness and efficiency are balanced. BRIEF DESCRIPTION OF DRAWINGS

[0033] Figure 1 It is a UVM automatic verification method step flow chart of a chip loading external memory function;

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

[0035] Figure 3 It is an EEPROM storage format schematic diagram;

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

[0037] Figure 5 It is a configuration file format conversion example diagram;

[0038] Figure 6 It is a data extraction and checking process logic diagram;

[0039] Figure 7 This is a logic diagram of the data extraction and verification process. DETAILED DESCRIPTION

[0040] The following will clearly and completely describe the technical solutions of the present invention in conjunction with the embodiments. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work shall fall within the scope of protection of the present invention.

[0041] Example 1

[0042] See Figure 1 , provides a UVM automated verification method for a chip loading external memory function, the method steps comprising:

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

[0044] 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.

[0045] Cross-channel data verification: The analysis module parses the configuration file to generate the target register address and 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 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 calculated using the formula DEC2HEX(COUNTA(configuration item area) / 22) and is used to indicate the number of HSSs configured in the HSS customization item.

[0048] The configuration file is generated with the help of Excel. The COUNTA function is used to calculate the number of configuration items, and the DEC2HEX function is used to convert the count result into hexadecimal control information.

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

[0050] When the analysis module parses the configuration file, if eflash_data[87:64] is not 24'hffff, it is determined to be direct access, and the register address is obtained through eflash_data[71:64]; if it is 24'hffff, it is determined to be indirect access, and the access node is determined through eflash_data[61:56].

[0051] The data checking module is based on the UVM verification methodology, and prints the comparison results of each line of configuration in real time during simulation running.

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

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

[0054] The comparison results of the data checking module include 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 leading UVM automated verification method as the core, and builds a set of end-to-end automated verification system for the external memory loading function of the switch chip. Through the innovative automated configuration file generation mechanism, accurate simulation loading technology and efficient cross-channel data verification strategy, a complete verification closed loop is formed. This design not only greatly improves the verification efficiency, but also fundamentally reduces the verification errors caused by human factors by reducing manual intervention, and builds a solid and reliable technical barrier for the functional verification before chip production.

[0057] Taking a certain type of switch chip as a typical research object, the EEPROM memory mounted externally stores key configuration parameters such as PCIe and Serdes interface. These parameters need to be accurately loaded into the specified register at the moment of chip power-on startup through a precise bus system, thereby laying a solid foundation for the normal initialization and stable operation of each functional module of the chip.

[0058] (I) Systematic design of 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. Referring toFigure 3 The configuration file architecture adopts a hierarchical 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 first few rows of the table, containing important parameters such as load_end_addr, hss_num, and cfg_type. These parameters are used to accurately describe the classification, length, start, and end of configuration information, providing clear guidance for subsequent chip parsing of configuration files. Configuration information follows the control information and contains specific register configuration addresses and data, which are the key to implementing 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 storage content and is scientifically divided into different fields. Taking the basic configuration 0 row as an example, it not only contains control fields such as load_end_addr, hss_num, and cfg_type, but also sets a fixed character c5 as the identifier for configuration validation, and e0e6eaef as the end symbol for a single HSS configuration. This field design strictly follows the technical requirements of the chip hardware interface, ensuring that the generated configuration file can be accurately parsed and executed by the chip.

[0062] (2) Standardized process for user configuration information filling:

[0063] When filling in the configuration information area of the Excel table, the test personnel need to follow a set of scientific and standardized operation procedures. According to different test scenario requirements, the test personnel fill in the necessary register configuration content in the corresponding configuration area. For example, in the PCIe hard-wired configuration part, the address and corresponding data of the target register need to be filled in; in the HSS hard-wired configuration part, detailed configuration parameters related to the high-speed serial interface need to be filled in.

[0064] This filling process allows the test personnel to focus only on the specific configuration function implementation, without the need to manually handle complex control information. This design not only greatly reduces the operation difficulty, but also effectively reduces various errors that may occur during the manual filling process, ensuring the accuracy of the configuration information from the source.

[0065] Reference Figure 4In the HSS custom configuration area, the tester needs to fill in the configuration data of each HSS node line by line according to the established rules, including module node address, register address, and write data, and other key information. After completing the configuration of each HSS node, the table will start the intelligent auxiliary function, automatically insert the fixed end symbol e0e6eaef, clearly identify the end of the node configuration, and effectively avoid confusion and errors that may occur during hardware parsing.

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

[0067] The generation process of control information fully demonstrates the charm of automation technology, and through the powerful function of Excel, it realizes the whole process of automatic generation without human intervention. Taking the generation of the hss_num parameter as an example, there is a subtle logic design behind it: first, use the COUNTA function to accurately count the number of configuration lines of the HSS customization item; then divide the statistical result by a fixed coefficient to complete the standardization of the data; finally, use the DEC2HEX function to convert the result to a hexadecimal value, which accurately represents the number of HSS configurations in the HSS customization item. The automatic generation method ensures the high accuracy of the 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 hard-line configuration item, and its generation process is also full of wisdom: use the COUNTA function to count the number of lines of the HSS hard-line configuration item, and then add a fixed offset to convert it to hexadecimal format. The cfg_type field can automatically generate according to whether there is an HSS broadcast configuration item, if there is a broadcast configuration item, it is a specific identifier, otherwise it is another identifier, so as to accurately distinguish the configuration mode.

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

[0070] After completing the filling of configuration information and the automatic generation of control information, the key link of configuration file format conversion is entered. This process needs to convert the Excel table into a standard configuration file format that can be read by the memory model through a customized script. Referring to Figure 5 , after conversion, each line of data in the file format is marked with an address as the starting point (such as @00, @0b, etc.), followed by hexadecimal data, and each line of data accurately corresponds to a storage unit in the EEPROM, achieving perfect matching of data format and hardware storage.

[0071] The format conversion process is automatically performed by a customized script that iterates through the data in the Excel table line by line, accurately splices the data in each field according to the specified format, and adds the corresponding address label to each line of data. For example, the data in row 0 of the base configuration is accurately converted to a specific format, where "@00" clearly indicates the starting address of the data in the memory, and "c5 e0 e6 ea ef" and other fixed fields and end markers ensure the accuracy and reliability of data parsing.

[0072] Simulation loading process:

[0073] (1) Technical points of memory model establishment:

[0074] Under the advanced technical framework of the UVM verification platform, building an SV simulation model of EEPROM memory is the primary task of the entire simulation loading process. This model achieves efficient reading of the generated configuration file through the system function $readmemh, thereby accurately simulating the behavior of the external memory.

[0075] The address space design of the memory model follows strict standardization principles and forms 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 simulation and accurately access the configuration data, laying a solid foundation for subsequent simulation verification work.

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

[0077] When the simulation process starts, the memory model automatically triggers the configuration file loading mechanism and calls the readmemh system function to read the converted configuration file in an automated manner. The call format of this function is carefully designed as 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 into the corresponding position of the memory model in address order, completing the initialization of the memory model. The entire process does not require any manual intervention, achieving full automation of configuration file loading and significantly improving the efficiency and reliability of the verification process.

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

[0080] When 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 starts the process of automatically reading the configuration data in the external memory through the bus system.

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

[0082] During the configuration process, the timing control of the controller is crucial. It accurately judges the configuration boundary according to key control information such as load_end_addr and config_end_addr. When the configuration operation reaches the end address, the controller will generate the DONE signal in time, which is used to release the reset signal of the subsequent module, ensuring that the subsequent module can start working according to the timing requirements; before the configuration reaches the start address, the controller will patiently wait for the ready signal of other modules to ensure the timing coordination between modules, avoiding timing conflict problems.

[0083] Taking the specific scene of PCIe Subsys configuration as an example, after reading pcie_subsys_end_addr, the controller will immediately confirm the end of this part of the configuration work, and then proceed to the next part of the configuration work according to the established logic. The entire configuration process is closely linked, without any manual intervention, realizing the fully automated process from memory reading to register configuration, fully demonstrating the efficiency and reliability of the 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", which forms a path isolation in the data transmission process, fundamentally avoiding the misjudgment problem caused by the coupling of memory and register paths, and greatly improving the reliability of the verification result.

[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 is independently read by the driver module through the APB bus. The two paths are independent and complementary.

[0088] The overall architecture of the verification framework is composed of three core parts: analysis module, driving module and data checking module. The analysis module is responsible for parsing the configuration file to generate target register address and expected data; the driving module simulates the CPU to initiate register read operation and obtain actual data; the data checking module compares the expected data and the actual data and outputs the results. The three modules work closely together to form a complete and efficient verification system. For details, see Figure 2 .

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

[0090] The analysis module will perform in-depth parsing on the configuration file line by line in the entire verification framework, and intelligently judge the access mode according to the value of the eflash_data[87:64] field. It mainly includes the following two modes:

[0091] 1. Direct access mode: If eflash_data[87:64] is not a specific identification value, the analysis module will determine it as a direct access mode. In this mode, the analysis module obtains the register address through eflash_data[71:64], takes eflash_data[87:72] as the module node address, and identifies eflash_data[63:0] as the write data. Then, the analysis module sends the parsed register address and expected data to the driving module and data checking module respectively, providing accurate "baseline data" for 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 an indirect access mode. At this time, the analysis module determines the access node through eflash_data[61:56]: when the value is 6'h3f, it represents broadcast access to all HSS nodes; when the value is 6'h19, it represents access to the PCIe node. For PCIe node access, the analysis module will further determine the internal submodule node according to eflash_data[55:52], such as 4'd0 representing access to the PCIE_SUB_SYSTERM submodule. In addition, eflash[51:32] is parsed as an offset address, and eflash_data[31:0] is the write data.

[0093] For details, see Figures 6-7, the analysis module has intelligent recognition capability, and will automatically skip the line containing the end symbol e0e6eaef in the analysis process, to avoid interference of invalid data on the analysis result. For the HSS customization item, after analyzing the configuration data of each HSS node, the analysis module will automatically skip the end symbol line and continue to analyze the configuration data of the next node, to ensure the efficiency and accuracy of the analysis work.

[0094] (Three) specific implementation of the driving module simulation operation:

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

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

[0097] (Four) specific process of the data checking module comparison process:

[0098] The data checking module is based on the advanced UVM verification methodology, like an indefatigable "quality inspector", which receives the expected data of the analysis module and the actual data of the driving module in real time during the simulation running, and compares them line by line.

[0099] The comparison process and results include register address, expected data, actual data, and comparison status (such as pass, fail) and other key information. These information will be printed in the simulation log in real time, which facilitates quick positioning of possible abnormal points in the configuration process.

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

[0101] (Five) special scene processing:

[0102] 1. Optimization strategy of broadcast configuration verification: For the broadcast configuration register, an innovative way of randomly selecting nodes is adopted for verification. For example, in the HSS broadcast configuration scenario, the drive module randomly selects a node from the many HSS nodes to read back the data and compares it with the expected data. This strategy, which checks on the premise of ensuring comprehensive coverage, can not only ensure the completeness of the verification, but also effectively reduce the simulation time, achieving a perfect balance between verification quality and efficiency.

[0103] 2. Intelligent mechanism for end-of-file processing: The fixed end-of-file e0e6eaef in the configuration file is used to clearly identify the end of a single HSS configuration. The analysis module has intelligent recognition capability during parsing and will automatically skip when encountering such lines, avoiding misanalysis. For example, in the HSS customization item, an end-of-file line will follow each node configuration, and the analysis module will directly skip it when encountered, continuing to focus on the configuration data parsing of the next node, ensuring the accuracy and continuity of the parsing work.

[0104] 3. Precise logic for indirect access processing: For indirect access mode, especially for configurations involving PCIe submodules, the analysis module will accurately process the address according to the hardware logic. For example, when accessing the PCIE_SUB_SYSTERM submodule, the analysis module will right-shift the offset address of eflash [51:32] before sending it to the drive module, ensuring the correctness of the address and laying a solid foundation for subsequent data configuration operations.

[0105] Implementation example verification process and results:

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

[0107] This embodiment conducts a comprehensive and systematic test case design for the diversified 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 hard-wired configuration parameters can pass through the entire verification process and be accurately loaded into the corresponding registers, ensuring the normal initialization and function implementation of the PCIe interface.

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

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

[0111] 4. Mixed 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 perform comprehensive verification of the configuration results through cross-channel data verification mechanisms. This systematic test case design and execution process ensures the comprehensiveness and scientificity of the verification work.

[0113] II. In-depth analysis of simulation result analysis:

[0114] After running all test cases through the UVM verification platform, the data checking module plays a key role in real-time outputting line-by-line comparison results. In normal test scenarios, the expected data and actual data of all configuration lines are highly consistent, and the comparison status is all passed, indicating that the configuration data has been accurately loaded into the corresponding registers, and the chip's external memory loading function is running normally in this test scenario.

[0115] Taking the HSS custom configuration test case as an example, the simulation log clearly records the comparison results of each line of configuration data, such as "some address: expected some value, actual some value, comparison passed" and other information. These results fully demonstrate 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 incorrect register address in PCIe configuration, the data checking module can capture the abnormality in the first place and output detailed error information, such as "a certain address: expect a certain value, actual a certain value, comparison fails" and the like. These information provides clear debugging direction for engineers, helping them quickly locate the problem source, and thus optimizing the configuration file or related links.

[0117] III. Multi-dimensional analysis of efficiency improvement:

[0118] Compared with the traditional verification method, the UVM automatic verification method adopted in the embodiment achieves significant efficiency improvement in multiple dimensions, mainly reflected in the following aspects:

[0119] 1. Great improvement in configuration file generation efficiency: The automatic generation of control information is realized through Excel tool, which can greatly reduce the manual configuration workload and reduce the manual input compared with the traditional method. At the same time, the automatic generation mechanism fundamentally avoids various errors that may occur in the manual calculation and input process, significantly improving the generation quality and efficiency of the configuration file.

[0120] 2. Significant improvement in error positioning efficiency: The UVM methodology supports real-time printing of line-by-line comparison results, which makes it possible to find errors in real time during simulation. Compared with the traditional script verification method, the real-time feedback mechanism improves the error positioning efficiency, greatly shortens the debugging time, and improves the efficiency of the entire verification process.

[0121] 3. Significant enhancement of test case reusability: In the verification system of the embodiment, different test cases only need to modify the configuration file content according to the requirements, and the verification environment can automatically identify the target register and complete the comparison work. This design does not require re-writing of verification logic, greatly improving the reusability of test cases, making the verification resources more efficiently utilized, and further improving the overall verification efficiency.

[0122] The embodiment presents the UVM automatic verification method of the chip loading external memory function through detailed process demonstration and in-depth technical analysis. The method builds a complete automatic verification closed loop from configuration file generation, simulation loading to cross-channel data verification, and realizes the comprehensive verification of the chip external memory loading function. The core advantages of the method mainly lie in the following aspects:

[0123] 1. Comprehensive of closed loop design: Through the innovative closed loop design of "configuration generation - simulation execution - cross-channel verification", the method realizes end-to-end full process coverage from memory reading to register configuration. This comprehensive verification system ensures that the verification work is thorough and comprehensive, and can effectively find potential functional problems.

[0124] 2. The efficiency of the degree of automation: make full use of Excel tools to realize the automatic generation of control information, realize the full automation of simulation loading and data checking combined with UVM platform, and greatly reduce manual intervention. This highly automated verification process not only greatly improves the verification efficiency, but also fundamentally reduces the verification errors caused by human factors, providing a strong guarantee for the efficient development of chip verification work.

[0125] 3. The scientificity of reliability design: the isolation design of hardware write path and software read path avoids the misjudgment problem caused by path coupling; the real-time comparison and log output function of UVM methodology improves the accuracy and efficiency of error positioning, and guarantees the reliability of the verification result from multiple aspects.

[0126] 4. The flexibility of general design: this method is suitable for different types of chips and diversified configuration scenarios, and users only need to adjust the configuration file content according to actual needs to complete the verification work of different test cases. This good universality and scalability enables it to play an important role in different chip verification projects and has a wide application prospect.

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

[0128] The above is only the preferred embodiment of the present application, it should be understood that the present application is not limited to the form disclosed herein, should not be regarded as excluding other embodiments, and can be used in various other combinations, modifications and environments, and can be modified within the scope of the concept described herein, by the above teaching or related art or knowledge. The modification and change made by the person skilled in the art without departing from the spirit and scope of the present application shall be within the protection scope of the appended claims of the present application.

Claims

1. A UVM automated verification method for a chip loading external memory function, characterized in that: include: Generate configuration files: This is done using Excel. The test stimulus is divided into user-entered configuration information and control information automatically generated by formulas. The COUNTA function is used to calculate the number of configuration items, and the DEC2HEX function is used to convert the count result into hexadecimal control information. The control information is used to describe the configuration information's category, length, start, and end information. 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. Cross-channel data verification: The analysis module parses the configuration file to generate the target register address and expected data. The driver module simulates the CPU to initiate register read operations and obtain actual data. 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 simulation. Among them, the hardware write path is for the chip to read data from the memory through the bus and configure the register. The software read path is for the driver module to read the register data through the APB bus. The data check module compares the two and outputs the results.

2. The method according to claim 1, characterized in that 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, characterized in that The hss_num is calculated using 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, wherein The configuration file is generated 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, characterized in that 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.

6. The method according to claim 1, characterized in that When the analysis module parses the configuration file, if it is recognized that eflash_data[87:64] is not 24'hf_ffff, it is determined to be direct access and the register address is obtained through eflash_data[71:64]. If it is 24'hf_ffff, it is determined to be 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 checking module is based on UVM verification methodology and prints the comparison results of each row configuration in real time during simulation operation.

8. The method according to claim 1, characterized in that For registers configured for broadcast, a node is randomly selected 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 a fixed terminator e0 e6 eaef, which is used to mark the end of a single HSS configuration in the HSS customization item. The analysis module skips the terminator line during parsing.

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

Images