Performance test method and device of DDR controller, equipment and storage medium
By automating the generation of test commands and simulation results, the problems of wasted manpower and errors in DDR controller performance testing are solved, and efficient and accurate performance analysis is achieved.
Patent Information
- Application Number
- CN202511173372.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-20
- Publication Date
- 2026-01-02
AI Technical Summary
In existing technologies, performance testing of DDR controllers requires the manual development of a large number of test vectors, resulting in wasted manpower and tedious performance parameter analysis, and is also prone to human error.
By generating configuration parameter combinations and stimulus files, test commands are automatically generated and simulation results are collected, reducing manual operations and achieving automated performance testing.
It reduces the workload of testers, avoids human error, improves testing efficiency and accuracy, and simplifies the performance analysis process.
Smart Images

Figure CN121254801A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present application relate to the technical field of integrated circuits, and in particular, to a performance testing method, device and equipment of a DDR controller and a storage medium. BACKGROUND
[0002] A DDRC (Dynamic Data Rate Controller) is a key component in a processor or a SoC (System on Chip), which is responsible for managing and coordinating data transmission between the processor and the DDR memory. In the design stage, the performance of the DDR controller needs to be verified to compare the performance gap of different design schemes.
[0003] In the related art, in the process of performance testing of the DDRC, the tester manually develops test cases of performance testing according to different configurations and different stimuli. One test case corresponds to one configuration and one stimulus. The performance parameters of the DDR controller under the configuration are counted in the test result. After the test vectors are simulated and tested, the performance parameters of each test case are analyzed, and the performance difference under different configurations and different stimuli and whether the performance meets the expectation are analyzed.
[0004] However, there are hundreds or thousands of combinations of different configurations and different stimuli of the DDR controller. Developing one test case after another wastes a lot of manpower, and the analysis of the performance parameters needs to be extracted from each test result, which is very tedious and not conducive to analysis and comparison. SUMMARY
[0005] Embodiments of the present application provide a performance testing method, device and equipment of a DDR controller and a storage medium. The technical solution is as follows:
[0006] According to an aspect of an embodiment of the present application, a performance testing method of a DDR controller is provided, which comprises:
[0007] obtaining a first configuration file and N stimulus files, wherein the first configuration file comprises K configuration parameters and candidate values corresponding to the K configuration parameters respectively, N is a positive integer, and K is a positive integer;
[0008] generating M configuration parameter combinations based on the first configuration file through a first script file, one configuration parameter combination being one value combination of the K configuration parameters, and M being a positive integer;
[0009] generate M test command groups based on the M configuration parameter combinations and the N stimulus files, wherein one test command group includes N test commands, and the N test commands correspond to the N stimulus files respectively;
[0010] test the DDR controller based on the M test command groups, and generate M simulation results, wherein the M simulation results are used to reflect the performance of the DDR controller under different configurations.
[0011] According to an aspect of an embodiment of the present application, a device for testing the performance of a DDR controller is provided, and the device comprises:
[0012] a obtaining module, configured to obtain a first configuration file and N stimulus files, wherein the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters respectively, N is a positive integer, and K is a positive integer;
[0013] a first generating module, configured to generate M configuration parameter combinations based on the first configuration file through a first script file, wherein one configuration parameter combination is a value combination of the K configuration parameters, and M is a positive integer;
[0014] a second generating module, configured to generate M test command groups based on the M configuration parameter combinations and the N stimulus files, wherein one test command group includes N test commands, and the N test commands correspond to the N stimulus files respectively;
[0015] a third generating module, configured to test the DDR controller based on the M test command groups, and generate M simulation results, wherein the M simulation results are used to reflect the performance of the DDR controller under different configurations.
[0016] According to an aspect of an embodiment of the present application, a computer device is provided, and the computer device comprises a processor and a memory, wherein the memory stores a computer program, the computer program is loaded and executed by the processor to implement the above-mentioned method for testing the performance of a DDR controller.
[0017] According to an aspect of an embodiment of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program, the computer program is loaded and executed by a processor to implement the above-mentioned method for testing the performance of a DDR controller.
[0018] According to an aspect of an embodiment of the present application, a computer program product is provided, and the computer program product comprises a computer program, the computer program is loaded and executed by a processor to implement the above-mentioned method for testing the performance of a DDR controller.
[0019] The technical scheme provided by the embodiments of the present application can include the following beneficial effects:
[0020] After the test device obtains the first configuration file and the excitation file, the test device can automatically generate a test command based on the first script file and test the DDR controller to collect simulation results, without the need for a test personnel to manually input the test command and the excitation file or manually modify the configuration file code, thereby reducing the workload of the test personnel. Moreover, the workload of manual operation is reduced, and errors caused by manual input can be avoided, thereby ensuring the correctness of the test command. BRIEF DESCRIPTION OF DRAWINGS
[0021] Figure 1 is a schematic diagram of a performance test system of a controller provided by a possible implementation manner of the present application;
[0022] Figure 2 is a flowchart of a performance test method of a DDR controller provided by a possible implementation manner of the present application;
[0023] Figure 3 is a schematic diagram of a performance curve provided by a possible implementation manner of the present application;
[0024] Figure 4 is a schematic diagram of a performance test method of a DDR controller provided by another possible implementation manner of the present application;
[0025] Figure 5 is a block diagram of a performance test device of a DDR controller provided by a possible implementation manner of the present application;
[0026] Figure 6 is a structural schematic diagram of a test device provided by a possible implementation manner of the present application. DETAILED DESCRIPTION
[0027] To make the purpose, technical scheme and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.
[0028] To make the purpose, technical scheme and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.
[0029] Please refer to Figure 1 which shows a schematic diagram of a performance test system of a controller provided by an embodiment of the present application. The performance test system of the controller can include a test device 100.
[0030] The test device 100 is a computer device for testing the controller. The computer device refers to an electronic device with data computing, processing and storage capabilities. In some embodiments, a first script file is run in the test device 200, the first script file is used to generate M configuration parameter combinations based on a first configuration file, one configuration parameter combination is a value combination of K configuration parameters, M is a positive integer; based on the M configuration parameter combinations and N excitation files, M test command groups are generated, wherein one test command group includes N test commands, and the N test commands correspond to the N excitation files respectively; based on the M test command groups, the controller is tested, and M simulation results are generated, the M simulation results are used to reflect the performance of the controller under different configurations.
[0031] In some embodiments, the test device 100 is used for simulation testing of the controller, without the need for testing on a real controller.
[0032] The controller refers to a master device that controls the start, speed regulation, braking and reverse of the motor by changing the wiring of the main circuit or control circuit and changing the resistance value in the circuit according to a predetermined sequence. The controller can be an SDRC (Single Data Rate Controller) or a DDRC.
[0033] The DDRC mainly plays a role of controlling the DDR, and is responsible for converting the commands sent by the MASTER into commands recognized by the DDR. In a more popular way, it plays a role of translation. The core task of the DDRC is to manage and schedule the read and write requests of the processor to the DDR memory, to ensure that the memory access requests sent by the processor can be executed correctly according to the protocol of the DDR memory. Read operation: the DDRC receives the read request of the processor, schedules the related row and column addresses of the DDR memory, reads the data and returns it to the processor. Write operation: the processor sends a write request through the DDRC, and the DDRC writes data into the specified memory address.
[0034] The DDR memory has complex timing requirements, such as activation (ACT), read (READ), write (WRITE) and other operations, which have strict timing restrictions. The DDRC is responsible for controlling the timing of memory operations to ensure that the delay between the issuance, execution and data transmission of different commands meets the timing requirements of the memory. The DDR memory controller needs to process a large number of read and write requests from the processor, and map these logical addresses to the row, column and bank addresses of the physical memory. In order to maximize the utilization of the memory, the DDRC schedules and optimizes these requests to reduce row switching and bank conflicts, and improve the access speed of the memory.
[0035] DDR memory is based on capacitive storage of data, capacitors will lose charge over time, resulting in data loss. Therefore, DDR C must periodically refresh the data in the memory to ensure the correctness of the data. Refresh operation needs to follow certain timing requirements, while trying to avoid affecting normal read and write operations.
[0036] To meet the power consumption requirements of modern devices, DDR C supports a variety of low-power modes, which reduce power consumption by dynamically adjusting the working state of the memory. This is particularly important for mobile devices and embedded systems. In some high-reliability applications (such as servers, data centers), DDR C usually supports ECC (Error-Correcting Code). This mechanism can detect and correct single-bit errors in memory, thereby improving system reliability.
[0037] In modern systems, memory controllers usually support multiple channels and multiple ports to improve memory bandwidth and support multi-task operations. DDR C improves the overall performance of the system by allocating multiple memory channels to handle data read and write requests in parallel. Multi-channel: Multiple memory channels can handle multiple data streams simultaneously, greatly improving memory bandwidth. Multi-port: Multiple peripherals or processor cores can access memory through DDR C simultaneously, improving parallel processing capabilities.
[0038] In multi-core processors or multi-task systems, multiple processor cores or peripherals will simultaneously issue memory access requests. DDR C has an arbitration mechanism to allocate resources fairly and ensure that each request is processed under fair conditions while maximizing bandwidth utilization. With the advancement of DDR technology, DDR C needs to support different generations of DDR standards (such as DDR3, DDR4, DDR5) and LPDDR (Low Power DDR). The timing, command set, and data transfer rate of each generation of DDR memory are different, and DDR C adapts to these standards to ensure that the system can use the latest memory technology.
[0039] In some embodiments, the technical solutions provided by the embodiments of the application can also be applied to controller real machine testing. Exemplarily, it can be applied to in-machine testing of the controller, and can also be applied to out-of-machine testing of the controller.
[0040] DDR is a double data rate synchronous dynamic random access memory, which transmits data on the rising and falling edges of the clock signal to achieve double data transfer rate.
[0041] DDR controller is a key component in processors or system on chips, responsible for managing and coordinating data transmission between processors and DDR memory, acting as a bridge, scheduling commands (such as read, write, refresh, etc.) according to memory access requests, so that processors can access memory data, making full use of the high bandwidth and low latency characteristics of DDR memory.
[0042] By optimizing command scheduling and data transmission, the DDR controller can maximize the bandwidth utilization of the DDR memory and improve the overall performance of the system. Therefore, during the design phase, performance verification needs to be performed on the DDR controller to compare the performance gap of different design schemes; after development, the performance difference under different configurations is compared.
[0043] In the related art, during the performance test of the DDR controller, the tester manually develops a performance test test case according to different configurations and different stimuli. One test case corresponds to one configuration and one stimulus. The performance parameters of the DDR controller under the configuration are counted in the test result. After the test vector is simulated and tested, the performance parameters of each test case are analyzed, and the performance difference under different configurations and different stimuli and whether the performance meets the expectation are analyzed. Since there are hundreds or thousands of combinations of different configurations and different stimuli of the DDR controller, the development of one test case at a time wastes a lot of manpower, and the analysis of performance parameters needs to be extracted from each test result, which is very tedious and not conducive to analysis and comparison.
[0044] There are many configuration combinations of the DDR controller, and different configurations have different performance. In the related art, when performance testing is performed, different test cases are simulated by manually modifying the configuration and stimulus files, and the performance parameters are analyzed from the simulation results.
[0045] Firstly, manually writing different test cases increases the workload of the tester, and the increase in manual workload cannot guarantee the correctness of the modification, and a lot of energy needs to be spent to maintain the correctness of the test case.
[0046] At the same time, the performance parameters are filtered from the simulation results for analysis, and a lot of energy needs to be spent to count the data in each simulation, and it is not intuitive.
[0047] Embodiments of the present application provide a performance test method of a DDR controller. A tester only needs to fill in the related configuration file, and a script file can automatically test the DDR controller based on the related configuration file, or process the simulation results obtained after testing to generate a visual test result chart.
[0048] Please refer to Figure 2 , which shows a flowchart of a performance test method of a DDR controller provided by an embodiment of the present application. The method is performed by a computer device. Illustratively, the computer device can be implemented as the test device 200 in the above embodiments. The method includes at least one of the following steps 210-240.
[0049] In step 210, the test device acquires a first configuration file and N stimulus files, wherein the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters respectively, N is a positive integer, and K is a positive integer.
[0050] In some embodiments, the controller refers to a master device that controls the start, speed, braking and reverse of the motor by changing the wiring of the main circuit or control circuit and changing the resistance value in the circuit in a predetermined order. It is the "decision-making mechanism" that issues commands, i.e., it coordinates and directs the operation of the entire computer system.
[0051] In some embodiments, the controller can be a DDRC (DDR controller) responsible for processing memory access logic, managing data inflow and outflow, processing data caching, row open / close, command scheduling, and other high-level logical operations.
[0052] In some embodiments, the first configuration file includes configuration parameters needed in the performance test process. In some embodiments, the configuration parameters included in the first configuration file are used to generate test commands. The test commands are used to test the DDR controller to obtain performance parameters of the DDR controller under different configurations.
[0053] In some embodiments, the first configuration file includes K configuration parameters, and each configuration parameter corresponds to at least one candidate value. It should be noted that although it is referred to as a candidate value here, it is not a specific numerical value. The attribute of the candidate value is determined based on the configuration parameter. For example, the configuration parameter is a register configuration, and the candidate value can be a register name, a register index, etc. At this time, the attribute of the candidate value is usually a string.
[0054] In some embodiments, the first configuration file is filled out by a test personnel, and the configuration parameters and the candidate values corresponding to the configuration parameters included therein are determined by the test personnel based on a test target. The test target includes a test environment and test commands required in the test of the DDR controller.
[0055] In some embodiments, the stimulus file includes data required in the test process. For example, the stimulus file includes data required for reading and writing by the DDR controller. In some embodiments, the data in the stimulus file is real data obtained by sampling. In some embodiments, the data in the stimulus file is simulation data obtained by simulating real data. The content of the data in the stimulus file does not affect the test process, and therefore the method of obtaining the stimulus file is not limited in the present application.
[0056] In step 220, the test device generates M configuration parameter combinations based on the first configuration file via the first script file, where one configuration parameter combination is one value combination of the K configuration parameters, and M is a positive integer.
[0057] In some embodiments, one configuration parameter combination includes the K configuration parameters. The values of the K configuration parameters are determined based on the respective candidate values corresponding to the K configuration parameters. In some embodiments, at least one value of the configuration parameters in any two configuration parameter combinations is different.
[0058] In some embodiments, the value of M is predefined or preconfigured, and the M configuration parameter combinations are selected from the configuration parameter combinations that can be determined based on the first configuration file. For example, P configuration parameter combinations can be determined based on the first configuration file, where P is an integer greater than or equal to M. For example, the M configuration parameter combinations are randomly sampled from the P configuration parameter combinations. For example, the M configuration parameter combinations are uniformly sampled from the P configuration parameter combinations.
[0059] In some embodiments, the value of M is not predefined or preconfigured. In some embodiments, the value of M is the maximum value of the configuration parameter combinations that can be determined based on the first configuration file. For example, P configuration parameter combinations can be determined based on the first configuration file, and M = P.
[0060] In some embodiments, the M configuration parameter combinations are obtained by arranging and combining the candidate values corresponding to the K configuration parameters. In some embodiments, the candidate values corresponding to the K configuration parameters are arranged and combined via the first script file to obtain the M configuration parameter combinations. For example, the first configuration file includes configuration parameter 1, configuration parameter 2, and configuration parameter 3, where the candidate values corresponding to configuration parameter 1 include a and b, the candidate values corresponding to configuration parameter 2 include a, β, and λ, and the candidate values corresponding to configuration parameter 3 include 11 and 12. Then, 12 configuration parameter combinations can be obtained, i.e., {[a, a, 11], [a, a, 12], [a, β, 11], [a, β, 12], [a, λ, 11], [a, λ, 12], [b, a, 11], [b, a, 12], [b, β, 11], [b, β, 12], [b, λ, 11], [b, λ, 12]}. By arranging and combining, the values of all the configuration parameters configured in the first configuration file are covered, and the automatic test is more comprehensive.
[0061] In step 230, the test device generates M test command groups based on the M configuration parameter combinations and the N stimulus files, where one test command group includes N test commands, and the N test commands correspond to the N stimulus files, respectively.
[0062] In some embodiments, different test commands in a same test command group have a same configuration parameter combination and different stimulus files.
[0063] For example, N=3, and a test command group includes three test commands, each of which corresponds to a stimulus file 1-3. For example, the first configuration file includes configuration parameter 1, configuration parameter 2, and configuration parameter 3, wherein the candidate values of configuration parameter 1 include a and b, the candidate values of configuration parameter 2 include a, β, and λ, and the candidate values of configuration parameter 3 include 11 and 12. M=12, and 12 test command groups can be generated, each of which includes three test commands, and a total of 36 test commands.
[0064] In step 240, the test device tests the DDR controller based on the M test command groups, and generates M groups of simulation results, which are used to reflect the performance of the DDR controller under different configurations.
[0065] In some embodiments, the test device tests the DDR controller based on each test command in the M test command groups respectively, and generates a simulation result corresponding to each test command. For example, the test device tests the DDR controller based on 12 test command groups, and generates 12 groups of simulation results, each of which includes simulation results corresponding to three test commands.
[0066] The technical solution provided by the embodiments of the present application can automatically generate test commands based on the first script file after the test device acquires the first configuration file and the stimulus file, and test the DDR controller and collect simulation results, without the need for a test personnel to manually input test commands and stimulus files, or manually modify configuration file codes, thereby reducing the workload of the test personnel. Moreover, the workload of manual operation is reduced, and errors caused by manual input can be avoided, thereby ensuring the correctness of the test commands.
[0067] In some embodiments, in order to enable the first script file to more easily parse the first configuration file to generate configuration parameter combinations, the embodiments of the present application also provide exemplary descriptions of standardizing the first configuration file.
[0068] In some embodiments, the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters. In some embodiments, the K configuration parameters include at least one of the following: register configuration, macro definition configuration, simulation input option, and simulation command parameter. The register configuration is used to indicate a register to be tested, the macro definition configuration and the simulation input option are used to configure a test environment together, and the simulation command parameter is used to add a function of a simulation tool.
[0069] Exemplarily, regs is used to indicate the register names to be tested, defs is used to configure the test environment, and sim_ops is used to configure the test environment. regs, defs, and sim_opts list different configurations of the registers and the test environment corresponding to the configurations. For a register not listed in the first configuration file, a default value is used. The default value refers to the default configuration of the register, which is configured in advance for each register included in the DDR controller. The run_sim is used to add the functions of the simulation tool. The run_sim is used to provide the options of the simulation tool to be added by the test command. Exemplarily, the simulation tool can be an EDA (Electronic design automation) tool. For example, the simulation tool is used to add waveforms in the test process.
[0070] In some embodiments, the configuration parameters described above and the candidate values corresponding to the configuration parameters respectively can be stored in the first configuration file in the format of a table or in other formats. Exemplarily, the configuration parameters described above and the candidate values corresponding to the configuration parameters respectively can be stored in the first configuration file in the form of a program language. Exemplarily, the format of the first configuration file is as follows:
[0071]
[0072]
[0073] In the above table, regs is the register configuration, defs is the macro definition configuration, sim_opts is the simulation input option, and run_sim is the simulation command parameter.
[0074] Of course, the first configuration file can also store the K configuration parameters and the candidate values corresponding to the K configuration parameters in other formats. The format used in the first configuration file can be different, and the parsing manner of the first script file to the first configuration file can also change accordingly, as long as the first script file can normally parse the first configuration file.
[0075] The above embodiments give a possible standardized manner of the first configuration file, which provides a basis for implementing the automatic test of the DDR controller based on the script file.
[0076] As for the test process of the DDR controller, the embodiments of the present application also give a detailed introduction. In some embodiments, the test process of the DDR controller can include at least one of the following steps a-c.
[0077] Step a, retrieving the address of the corresponding register from the register table based on the register name in the register configuration.
[0078] In some embodiments, the configuration parameters in the first configuration file are configured for all test commands in the whole test process. For example, in the register configuration, the required registers for different test command groups in the whole test process are the same, and are configured in the register configuration. If the address of the register is determined M times in a test process, it is relatively cumbersome. Therefore, step a is only performed once in the test process, and the address of the register obtained is used as a common parameter of the M test command groups.
[0079] For example, the address of the corresponding register is retrieved from the register table based on the register name indicated in the register configuration in the first configuration file. In some embodiments, the register table stores the related information of all registers corresponding to the DDR controller. For example, the related information of the register includes the register name, the address of the register, the configuration parameters of the register, etc.
[0080] Step b, based on the address of the register, the test commands in the M test command groups are imported into the test environment to configure the program file of the register.
[0081] In some embodiments, the above program file is used to configure the register, and the DDR controller can be driven by the program file. In some embodiments, the above program file can be a C file written in C language, or an assembly language file written in assembly language, or a machine language file written in machine language, which is not limited in the present application.
[0082] In some embodiments, the above program file is based on the RTL (Register Transfer Level Code) code of the DDR controller, and the configuration function required by the perf test is reserved in the code of the test environment. In some embodiments, whether the above program file needs to be included in the test environment can be determined by macro definition configuration. RTL code is a hardware abstraction used to describe digital circuits, mainly used to define how data is transmitted between different registers, and how these transmissions depend on clock signals. RTL design emphasizes data path and clock-driven operations, and is an intermediate representation form from algorithm level to gate level design in hardware design.
[0083] Taking the above program file as a C file as an example, the following example can be referred to:
[0084]
[0085] Wherein, ddr_reg_field_value_set refers to the test command to be imported under the address of the corresponding register, and the brackets after it are the relevant configuration parameters.
[0086] Exemplarily, different test command groups implement different configurations by specifying the macro definition in the C file in the test command as different values. For example, in test command group 1, it is intended to configure qcfg_am_mode as 0, and the test command will define DDRC_TB_PERF_QCFG_AM_MODE = 0. For example, in test command group 2, it is intended to configure qcfg_am_mode as 1, and the test command will define DDRC_TB_PERF_QCFG_AM_MODE = 1.
[0087] Step c: executing the program file to generate M test command groups respectively corresponding simulation results.
[0088] In some embodiments, based on the program file, each test command included in the M test command groups is executed, and a simulation result corresponding to each test command is generated, and the simulation results corresponding to each test command are stored in categories. Exemplarily, the simulation results corresponding to each test command in the same test command group are stored in the same storage path.
[0089] The above embodiment gives a specific way of automatically testing the DDR controller by the first script file. No test personnel is needed to manually input test commands and stimulus files for the DDR controller, avoiding errors caused by manual operation.
[0090] For the above embodiment, the present application also gives an exemplary embodiment. The first configuration file is used to generate testcases with different configurations. In this file, register configurations (regs), macro definition configurations (defs), simulation input options (sim_opts), and simulation command parameters (run_sim) are specified. regs, defs, and sim_opts list different register configurations and the verification environment corresponding to the configurations. The registers not listed in this file use default values. run_sim specifies the options that need to be added to the simulation command. The first script file parses the first configuration file to generate testcases, and automatically runs the testcases. The specific implementation steps are as follows:
[0091] S11: Before simulation testing, prepare the stimulus file for testing, determine which performance under different configurations needs to be tested, and fill in the first configuration file.
[0092] S12: The first script file performs permutation and combination on all values defined in regs, defs, and sim_opts in the first configuration file, generates a set of test commands for each combination, and uses different stimulus files for each test command in each set.
[0093] S13: The first script file searches for the register name in the register table according to regs in the first configuration file, and generates a C file for configuring registers in the test environment. If the register name cannot be searched, an error is reported. The values of the registers are transmitted to the C file by the test commands in each set in S12.
[0094] S14: After generating the test commands and the C file, the first script file automatically executes all the test commands, and stores the simulation results of different configurations in different paths.
[0095] Through steps S11-S14, the performance test of the combination of different configurations and different stimuli of the DDR controller can be realized, and the different simulation results can be grouped.
[0096] After obtaining the simulation results, it is a tedious work to extract useful performance parameters from the simulation results and analyze them. Various errors are inevitable in the process of manually completing the work. The technical solution of the embodiment of the application can also automatically analyze the simulation results obtained by the test, and generate visual performance test charts.
[0097] In some embodiments, the method further includes at least one of steps 1-3.
[0098] Step 1: Obtain a second configuration file, which is used to configure the standardized description of the visual performance test chart.
[0099] In some embodiments, the second configuration file includes Q standardized elements, where Q is a positive integer. The standardized elements are used to describe the display effects of each element in the visual performance test chart. For example, the standardized elements can be used to describe the display style, display content, display position, filtering condition, and display quantity of each element in the visual performance test chart.
[0100] In some embodiments, the second configuration file includes a title, an abscissa, an ordinate, a sub-title, an abscissa label, an ordinate label, and a filtering condition. The title is the general title of the visual performance test chart, the abscissa is the performance-related parameter of the abscissa extracted from the simulation results, the ordinate is the performance-related parameter of the ordinate extracted from the simulation results, the sub-title is the title of the sub-chart of the visual performance test chart, and the filtering condition is used to filter the data in the simulation results.
[0101] The format of the second configuration file can refer to the description of the format of the first configuration file, and the present application does not limit this. Illustratively, the second configuration file can be described in the format of a program. Illustratively, the second configuration file is as follows:
[0102]
[0103]
[0104] In some embodiments, the standardized elements included in the second configuration file can be adjusted based on the style of the required visualization chart. Illustratively, if the visualization chart is a pie chart, the content related to the horizontal coordinate and the vertical coordinate can be deleted as appropriate, and the pie part label can be increased instead.
[0105] Step 2: parsing the M groups of simulation results through the second script file to obtain a table file corresponding to the M groups of simulation results, the table file including at least one performance parameter and data corresponding to the performance parameter.
[0106] In some embodiments, the second script file and the first script file are two different script files. In some embodiments, the second script file can automatically start running after the first script file is run, or the running time can be controlled by the tester as needed.
[0107] In some embodiments, the second script file and the first script file can be different functional modules in the same script file, and the two functional modules can be executed in sequence or the execution time can be controlled as needed.
[0108] In some embodiments, the M groups of simulation results are parsed through the second script file to extract the performance parameters respectively included in the M groups of simulation results; a table file is generated based on the performance parameters, the first row of the table file being the name of the performance parameter, and the i-th row of the table file corresponding to the (i-1)-th simulation result, i being an integer greater than 1.
[0109] In some embodiments, the performance parameters include at least one of the following: dq utilization rate, number of read commands, number of write commands, and bandwidth.
[0110] In some embodiments, the table file further includes at least one configuration parameter and / or an excitation file. Illustratively, the at least one configuration parameter is a configuration parameter in the first configuration file. For example, the at least one configuration parameter includes at least one of register configuration, macro definition configuration, and simulation input data.
[0111] In some embodiments, at least one configuration parameter and / or stimulus file is included in the table file, which can be used to specifically compare the influence of a certain configuration parameter on the performance of the DDR controller. For example, it can be used to compare the performance of the DDR controller in the case where a certain configuration parameter is different, but other configuration parameters are the same, and the stimulus file is the same.
[0112] In some embodiments, the M groups of simulation results are parsed to generate an excel table. The first row is respectively the register in KEY2, the macro definition, sim_opts, the test stimulus file, and the names of various performance parameters such as dq utilization, read command number, write command number, and bandwidth. Then, from the log of each test case, the parameters in the first row of the table are extracted and calculated and filled into the subsequent rows. For example, the time of the first read or write and the time of the last read or write are extracted, the number of read commands and the number of write commands in this time period are counted, the time of dq occupied by read and write commands can be calculated, and the performance parameters such as bandwidth under this configuration can be calculated, and filled into the table file.
[0113] The tedious simulation result processing is abstracted into a table file, and the standardized processing based on the table makes it more convenient to realize automation based on a script file.
[0114] Step 3, based on the second configuration file, extracting data from the table file, and drawing a performance chart.
[0115] In some embodiments, the performance chart can be a visual chart of any format. Exemplarily, it can be a bar chart, a pie chart, a curve chart, a line chart, a statistical table, a comparison table, etc. The data extraction methods of performance charts of different formats will also be slightly different. Next, the process of generating a performance chart is introduced by taking the horizontal and vertical coordinates in the performance chart as an example.
[0116] In some embodiments, based on the horizontal and vertical coordinates, the corresponding performance parameters in the table file are determined; based on the filtering condition, the data that meets the filtering condition is selected from the performance parameters; based on the data, the performance chart is drawn, and the combination of the performance chart, the title, the subtitle, the horizontal coordinate label, and the vertical coordinate label obtains a visual performance test chart.
[0117] In some embodiments, the performance parameters corresponding to the horizontal and vertical coordinates and the data corresponding to the performance parameters are extracted from the table file. Based on the filtering condition, the above-mentioned data is filtered to select the data that meets the filtering condition, and then the performance chart is drawn based on the data that meets the filtering condition according to the format of the performance chart.
[0118] In some embodiments, since the measured data can have a large deviation at some time, if each data is used, the data with deviation will present irregularity, in order to avoid affecting the readability of the performance chart, the data also needs to be filtered when drawing the chart, so the filtering condition needs to be set. On the other hand, the measured data usually has a large volume, in order to more simply show the regularity of the data in the chart, the data also needs to be filtered to reduce the amount of data to be drawn in the chart.
[0119] The technical scheme provided by the embodiments of the present application can automatically analyze the simulation results after the DDR controller is measured, generate a visual performance test chart based on the second configuration file, without manual analysis of the simulation results by the tester, and without manual modification of the configuration file code by the tester, thereby reducing the workload of the tester. The visual performance test chart can also help the tester to more conveniently analyze the performance of the DDR controller.
[0120] In addition, the above embodiments also give a possible standardized way of the second configuration file, which provides a basis for automatically drawing the performance chart based on the script file.
[0121] For the above embodiments, the present application also gives an exemplary embodiment. Based on the second configuration file, the second script file automatically processes the simulation results after the simulation test is finished, and generates a visual chart for performance analysis. The second configuration file specifies title, X, Y, X_label, Y_label, sub_title, and condition. The title is the general title of the generated graph, X and Y are the performance-related parameters of the extracted horizontal coordinate and vertical coordinate from the simulation results, X_label and Y_label are the labels of the horizontal coordinate and the vertical coordinate, which can be empty, sub_title is the title of the sub-chart, and condition is the condition for filtering the simulation results. The second script file processes the simulation results to extract all the performance-related parameters to generate an excel table, and then analyzes the description file to extract the required performance parameters to generate a curve chart. The specific implementation steps are as follows:
[0122] S21: Prepare a standard format description file (second configuration file) for generating a visual chart, and fill in the file content according to the performance curve to be generated.
[0123] S22: The second script file first analyzes the simulation results, extracts all the configurations and performance parameters under each configuration, and records them in a table file.
[0124] S23: The second script file reanalyzes the second configuration file prepared in S21, extracts the required data from the table file according to the parameters in the second configuration file, and automatically draws a performance curve. Thus, a large amount of manual operation is saved. The generated performance curve is as shown in Figure 3 .
[0125] Please refer to Figure 4 , and the embodiments of the present application will be described in detail below. The method can include at least one of the following steps 410-460.
[0126] Step 410, the test device first acquires a first configuration file and N excitation files.
[0127] Step 420, M sets of test commands are generated through the first script file, the first configuration file, and the N excitation files.
[0128] Step 430, the DDR controller is tested based on the M sets of test commands, and M sets of simulation results are generated.
[0129] Step 440, a second configuration file is acquired.
[0130] Step 450, the M sets of simulation results are parsed based on the second configuration file, and a table file is generated.
[0131] Step 460, data is extracted from the table file based on the second configuration file, and a performance chart is drawn.
[0132] The detailed content can be referred to the description in the above embodiments, which will not be repeated here.
[0133] Regarding the first script file, the RTL code of the DDR controller needs to be acquired, the C file of the configuration function required for the perf test is reserved in the code of the test environment, and whether to include the file is determined through the macro definition configuration in the simulation test. Then, the performance simulation and analysis of the DDR controller are automatically performed based on the first configuration file and the second configuration file.
[0134] Based on the first configuration file, the listed register configurations, macro definition configurations, and all candidate values of simulation input options in the first configuration file are arranged and combined. A set of SUITE test commands is generated for each combination, and the difference between the commands in each set is the excitation file.
[0135] According to the register configurations listed in the first configuration file, the register address is determined by searching in the register excel table, and a C file is generated for configuring the DDR controller after initialization. If the register configuration cannot be searched, an error will be reported. The value of the register configuration is transmitted to the C file through the above test command.
[0136] After the test command and the C file are generated, the compiling and simulation are automatically performed, and when the simulation ends, an excel table is automatically generated, the first row of which is respectively the register configuration, the macro definition configuration, sim_opts, the excitation file and the dq utilization rate, the read command number, the write command number, the bandwidth and the names of various performance parameters. Then, from the log (i.e., the simulation result corresponding to the test command) of each testcase, the parameters in the first row of the table file are extracted and calculated and filled into the subsequent rows. For example, the first read or write time and the last read or write time are extracted, the read command number and the write command number in the time period are counted, the dq time occupied by the read and write commands is calculated, and then the dq utilization rate under the configuration is calculated, and then the performance parameters such as the bandwidth can be calculated and filled into the table file.
[0137] After the extraction of all testcases is completed, the data in the excel table is filtered based on the second configuration file to extract the required configuration and the performance parameters under the corresponding configuration, and the corresponding performance curve diagram is generated. From the performance curve diagram, the performance difference of the DDR controller under different configuration parameters can be directly observed.
[0138] In summary, the technical scheme of the embodiment of the present application can have the following technical effects:
[0139] Firstly, compared with manually modifying the configuration to develop the testcase, the first configuration file is defined in the present application, and only the configuration used for performance testing needs to be filled in the first configuration file. The first script file will arrange and combine the configurations in the first configuration file to generate all configuration combinations of the testcase. The manual development of the testcase is not required, the manual operation is greatly reduced, the verification efficiency is improved, and the probability of introducing errors by human factors is reduced.
[0140] Secondly, compared with manually extracting the performance parameters in the simulation result for analysis, the second configuration file is defined in the present application, and only the second configuration file needs to be filled in to automatically extract the performance parameters in all simulation results and make a table. Different performance curve diagrams are generated according to the content of the second configuration file. Compared with manually extracting the performance parameters from each test result and analyzing, the manual workload is greatly reduced, and the visual table and curve diagram can more efficiently and accurately analyze the performance of the DDR controller.
[0141] Thirdly, an automatic process is introduced. After filling in the above two configuration files, the whole performance simulation process of the DDR controller can be completed by running a script, and the result of the performance simulation is obtained for analysis. Compared with the previous manual modification of test vectors, manual execution of each test, and manual statistics of the performance parameters of each test result, the workload is greatly reduced, the work efficiency is improved, and the probability of errors caused by human factors is reduced.
[0142] Reference is made to Figure 5 which shows a block diagram of a performance test device of a DDR controller according to an embodiment of the present application. The device has the functions of the above method examples, which can be implemented by hardware or by corresponding software executed by hardware. The device can be the test equipment introduced above or can be arranged in the test equipment. As Figure 5 shown, the device 500 includes an acquisition module 510, a first generation module 520, a second generation module 530, and a third generation module 540.
[0143] The acquisition module 510 is configured to acquire a first configuration file and N stimulus files, where the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters respectively, N is a positive integer, and K is a positive integer.
[0144] The first generation module 520 is configured to generate M configuration parameter combinations based on the first configuration file through a first script file, where a configuration parameter combination is a value combination of the K configuration parameters, and M is a positive integer.
[0145] The second generation module 530 is configured to generate M test command groups based on the M configuration parameter combinations and the N stimulus files, where a test command group includes N test commands, and the N test commands correspond to the N stimulus files respectively.
[0146] The third generation module 540 is configured to test the DDR controller based on the M test command groups, and generate M simulation results, where the M simulation results are used to reflect the performance of the DDR controller under different configurations.
[0147] In some embodiments, the first generation module 520 is configured to arrange and combine the candidate values corresponding to the K configuration parameters through the first script file to obtain the M configuration parameter combinations.
[0148] In some embodiments, the K configuration parameters comprise at least one of: a register configuration, a macro definition configuration, a simulation input option, and a simulation command parameter, the register configuration is used to indicate registers to be tested, the macro definition configuration and the simulation input option are used to configure a test environment, and the simulation command parameter is used to add a function of a simulation tool.
[0149] In some embodiments, the third generating module 540 is configured to retrieve an address of a corresponding register from a register table based on a register name in the register configuration, import a test command in the M test command groups into a program file of the test environment for configuring the register based on the address of the register, and execute the program file to generate simulation results corresponding to the M test command groups respectively.
[0150] In some embodiments, the obtaining module 510 is further configured to obtain a second configuration file used to configure a standardized description of a visual performance test chart, parse the M simulation results through a second script file to obtain a table file corresponding to the M simulation results, the table file comprising at least one performance parameter and data corresponding to the performance parameter, and extract data from the table file based on the second configuration file to draw a performance chart.
[0151] In some embodiments, the second configuration file comprises a title, an abscissa, an ordinate, a sub-title, an abscissa label, an ordinate label, and a filtering condition, the title is a general title of the visual performance test chart, the abscissa is a performance-related parameter of an abscissa extracted from the simulation results, the ordinate is a performance-related parameter of an ordinate extracted from the simulation results, the sub-title is a title of a sub-chart of the visual performance test chart, and the filtering condition is used to filter data in the simulation results.
[0152] In some embodiments, the obtaining module 510 is further configured to determine a corresponding performance parameter in the table file based on the abscissa and the ordinate, select data meeting the filtering condition from the performance parameter based on the filtering condition, and draw the performance chart based on the data, wherein the performance chart, the title, the sub-title, the abscissa label, and the ordinate label are combined to obtain the visual performance test chart.
[0153] In some embodiments, the obtaining module 510 is further configured to parse the M simulation results through the second script file to extract performance parameters respectively included in the M simulation results, and generate the table file based on the performance parameters, wherein a first row in the table file is a name of the performance parameter, an i-th row in the table file corresponds to an (i-1)-th simulation result, and i is an integer greater than 1.
[0154] The technical scheme provided by the embodiments of the present application can automatically generate a test command based on the first script file after the test device acquires the first configuration file and the excitation file, and test the DDR controller and collect simulation results, without the need for a test personnel to manually input the test command and the excitation file, or manually modify the configuration file code, thereby reducing the workload of the test personnel. Moreover, the workload of manual operation is reduced, and errors caused by manual input can be avoided, thereby ensuring the correctness of the test command.
[0155] In addition, after the simulation results of the DDR controller are measured, the simulation results can be automatically analyzed, and a visual performance test chart can be generated based on the second configuration file, without the need for a test personnel to manually analyze the simulation results, thereby reducing the workload of the test personnel. The visual performance test chart can also help the test personnel to more conveniently analyze the performance of the DDR controller.
[0156] It should be noted that the device provided by the above embodiments, when implementing its functions, is only exemplified by the above division of functional modules, and in actual application, the above functions can be completed by different functional modules according to actual needs, that is, the content structure of the device is divided into different functional modules to complete all or part of the functions described above.
[0157] As to the device in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments of the method, and will not be described in detail here.
[0158] Reference is made to Figure 6 which shows a structural schematic diagram of a test device provided by an embodiment of the present application. The test device can be used to implement the performance test method of the DDR controller provided in the above embodiments. The test device 600 is a computer device. Specifically:
[0159] The test device 600 includes a central processing unit (such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a FPGA (Field Programmable Gate Array), etc.) 601, a system memory 604 including a RAM (Random-Access Memory) 602 and a ROM (Read-Only Memory) 603, and a system bus 605 connecting the system memory 604 and the central processing unit 601. The test device 600 also includes a basic input / output system (I / O system) 606 that helps transfer information between various devices within the server, and a mass storage device 607 for storing an operating system 610, a system memory 614, and other program modules 615.
[0160] In some embodiments, the basic input / output system 606 includes a display 608 for displaying information and an input device 609, such as a mouse, keyboard, or the like, for inputting information by a user. The display 608 and the input device 609 are both connected to the central processing unit 601 through an input / output controller 610 connected to the system bus 605. The basic input / output system 606 can also include the input / output controller 610 for receiving and processing input from a number of other devices, such as a keyboard, a mouse, or an electronic stylus, etc. Similarly, the input / output controller 610 also provides output to a display screen, a printer, or other types of output devices.
[0161] The mass storage device 607 is connected to the central processing unit 601 through a mass storage controller (not shown) connected to the system bus 605. The mass storage device 607 and its associated computer readable media provide nonvolatile storage for the test device 600. That is, the mass storage device 607 can include a computer readable medium (not shown) such as a hard disk or a CD-ROM (Compact Disc Read-Only Memory) drive.
[0162] Without loss of generality, the computer readable medium can include computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes RAM, ROM, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid state memory technology, CD-ROM, DVD (Digital Video Disc), or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. It should be understood by those skilled in the art that computer storage media does not limit to the above-mentioned several types. The system memory 604 and the mass storage device 607 mentioned above can be collectively referred to as memory.
[0163] According to the embodiments of the present application, the test device 600 can also be connected to a remote computer on a network through a network such as the Internet. That is, the test device 600 can be connected to a network 612 through a network interface unit 611 connected to the system bus 605, or can be connected to other types of networks or remote computer systems (not shown) using the network interface unit 611.
[0164] The memory further includes a computer program stored in the memory and configured to be executed by one or more processors to implement the performance test method of the DDR controller.
[0165] In the exemplary embodiments, a computer readable storage medium is also provided, and the storage medium stores a computer program which, when executed by a processor of a device under test, implements the performance test method of the DDR controller.
[0166] Optionally, the computer readable storage medium can include a ROM (Read-Only Memory), a RAM (Random-Access Memory), a SSD (Solid State Drives) or an optical disk, etc. Among them, the random access memory can include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).
[0167] In an example embodiment, a computer program product is also provided, which includes computer instructions stored in a computer readable storage medium. The processor of the test device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the test device performs the performance test method of the DDR controller described above.
[0168] It should be understood that "multiple" referred to herein means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents that the associated objects before and after are in an "or" relationship.
[0169] The above only describes example embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.
Claims
1. A performance testing method for a double data rate (DDR) controller, characterized in that, The method includes: Obtain a first configuration file and N incentive files, wherein the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters, where N is a positive integer and K is a positive integer; Using the first script file, M configuration parameter combinations are generated based on the first configuration file. Each configuration parameter combination is a combination of values of the K configuration parameters, where M is a positive integer. Based on the M configuration parameter combinations and the N stimulus files, M test command groups are generated, wherein each test command group includes N test commands, and the N test commands correspond to the N stimulus files respectively; Based on the M test command groups, the DDR controller is tested, and M sets of simulation results are generated. The M sets of simulation results are used to reflect the performance of the DDR controller under different configurations.
2. The method according to claim 1, characterized in that, The step of generating M configuration parameter combinations based on the first configuration file using the first script file includes: By using the first script file, the candidate values corresponding to the K configuration parameters are arranged and combined to obtain the M configuration parameter combinations.
3. The method according to claim 1, characterized in that, The K configuration parameters include at least one of the following: register configuration, macro definition configuration, simulation input options, and simulation command parameters. The register configuration is used to indicate the registers to be tested. The macro definition configuration and the simulation input options are used together to configure the test environment. The simulation command parameters are used to add functionality to the simulation tool.
4. The method according to claim 3, characterized in that, The process of testing the DDR controller based on the M test command groups and generating M sets of simulation results includes: Based on the register name in the register configuration, retrieve the address of the corresponding register from the register table; Based on the address of the register, the test commands in the M test command groups are imported into the program file used to configure the register in the test environment; Execute the program file to generate simulation results corresponding to the M test command groups.
5. The method according to claim 1, characterized in that, The method further includes: Obtain the second configuration file, which is used to configure the standardized description of the visual performance test charts; The second script file is used to parse the M sets of simulation results to obtain a table file corresponding to the M sets of simulation results. The table file includes at least one performance parameter and the data corresponding to the performance parameter. Based on the second configuration file, data is extracted from the table file to create performance charts.
6. The method according to claim 5, characterized in that, The second configuration file includes a title, a horizontal axis, a vertical axis, a subtitle, a horizontal axis label, a vertical axis label, and filter conditions. The title is the main title of the visualization performance test chart. The horizontal axis is the performance-related parameter of the horizontal axis extracted from the simulation results. The vertical axis is the performance-related parameter of the vertical axis extracted from the simulation results. The subtitle is the title of the sub-chart of the visualization performance test chart. The filter conditions are used to filter the data in the simulation results.
7. The method according to claim 6, characterized in that, The step of extracting data from the table file based on the second configuration file and drawing performance charts includes: Based on the horizontal and vertical axes, determine the corresponding performance parameters in the table file; Based on the filtering criteria, select data that meets the filtering criteria from the performance parameters; The performance chart is drawn based on the data, and the performance chart, the title, the subtitle, the horizontal axis label, and the vertical axis label are combined to obtain the visual performance test chart.
8. The method according to claim 5, characterized in that, The step involves parsing the M sets of simulation results using a second script file to obtain a table file corresponding to the M sets of simulation results, including: The second script file is used to parse the M sets of simulation results and extract the performance parameters included in the M sets of simulation results respectively. The table file is generated based on the performance parameters. The first row of the table file is the name of the performance parameters, and the i-th row of the table file corresponds to the (i-1)-th simulation result, where i is an integer greater than 1.
9. A performance testing device for a DDR controller, characterized in that, The device includes: The acquisition module is used to acquire a first configuration file and N incentive files, wherein the first configuration file includes K configuration parameters and candidate values corresponding to the K configuration parameters, where N is a positive integer and K is a positive integer; The first generation module is used to generate M configuration parameter combinations based on the first configuration file using a first script file. Each configuration parameter combination is a combination of values of the K configuration parameters, and M is a positive integer. The second generation module is used to generate M test command groups based on the M configuration parameter combinations and the N stimulus files, wherein each test command group includes N test commands, and the N test commands correspond to the N stimulus files respectively; The third generation module is used to test the DDR controller based on the M test command groups and generate M sets of simulation results. The M sets of simulation results are used to reflect the performance of the DDR controller under different configurations.
10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the performance testing method for the DDR controller as described in any one of claims 1 to 8.
11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the performance testing method for the DDR controller as described in any one of claims 1 to 8.
12. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the performance testing method for the DDR controller as described in any one of claims 1 to 8.