A chip verification system and method based on RGB image data

Abstract

The present invention provides a chip verification system and method based on RGB image data, comprising: a chip verification system based on RGB image data, characterized in that it comprises: a top-level module, the top-level module comprises: a DUT unit; an instantiated test case, comprising a first test environment and a second test environment; the first test environment is connected to the DUT unit through a first interface, and the DUT unit reads the image data of the first test environment through the first interface; the second test environment is connected to the DUT unit through a second interface, and the second test environment configures the IP of the DUT unit through the second interface; and a monitoring and comparison unit, which is connected to the DUT unit through a third interface and is used for collecting output data of the DUT unit and comparing the output data with an expected value to determine whether the design of the DUT unit is correct.

Description

Technical Field

[0001] The present invention relates to the technical field of chip verification, and in particular to a chip verification system and method for RGB format image data. Background Art

[0002] At present, with the continuous development of high-definition image and video technology, the RGB signal quality of video output devices has become an important indicator for measuring device performance. Traditional verification methods often rely on manual observation of image results and manual testing, which have problems such as low efficiency and poor accuracy. Therefore, an automated and efficient verification model is needed to simulate and verify the RGB signal of video output devices.

[0003] In the process of video output module (VO, Video-out) verification, first configure IP through C or SV, then monitor (monitor) collects the result of design under test (DUT, Design Under Test) is a common method, by obtaining the result of the verification chip under test at a specific time and then outputting it to the comparator (cheker) or scoreboard (Scoreboard) ( Figure 1 In s4), the design under test is compared with the expected (golden) data to determine whether the design under test is correct. The expected (golden) data is generally generated from the reference model. However, this verification and comparison method is generally wasteful of resources and inefficient, especially when adding timing information to the chip post-simulation, its inefficiency becomes more prominent.

[0004] Specifically, the existing VO IP verification platform is generally as follows Figure 1 As shown, where:

[0005] Advanced High-performance Bus (AHB) is used to configure VO IP so that it can process images of a specific resolution;

[0006] Advanced eXtensible Interface (AXI) is used to read image data from storage devices such as Double Data Rate Synchronous Dynamic Random Access Memory (DDR);

[0007] VO result output, including R / G / B, Den, Vsync, Hsync, clk and other signals;

[0008] Among them, AHB ( Figure 1The S2 bus is mainly used to configure the registers of the VO module so that it can run according to the predetermined design plan, such as configuring the storage location of the read image data, the output image resolution and other parameters; while the AXI ( Figure 1 The s1 bus is used to read image data from storage devices such as DDR (data is pre-stored in the storage device), where the command to read image data is issued by the VO module. Through the VO module, images pre-stored in devices such as DDR (the image data is generally compressed YUV420, YUV444, etc.) can be read in by VO through the AXI bus. According to the configuration preset by the customer, the VO module can convert color coding (YUV) data into RGB pixel data signals, and can also realize operations such as mixing multiple layers, and then display the image data on the LCD (Liquid Crystal Display) screen.

[0009] In the chip verification environment, it is impossible to connect a real LCD display to observe whether the image is correct, so the general method is to capture the output data of the VO module through a monitor and compare it with the data of the scoreboard / comparator to determine whether it is correct. In the verification environment based on the Universal Verification Methodology (UVM), the collected data is usually collected through a monitor (monitor) ( Figure 1 The monitor is a passive component that is instantiated in the entire environment variable (env), constantly observing and recording bus activities in the simulation, extracting useful signals, and ultimately transmitting them to the scoreboard or comparator. This method makes the environment variables bloated. If a chip has many modules and the verification environment is complex, the verification environment is not reusable.

[0010] Therefore, it is necessary to provide an image data processing method and an image data processing system to effectively solve the above problems. Summary of the invention

[0011] The present invention provides an image data processing method and an image data processing system, and specifically provides a chip verification system and method based on RGB image data.

[0012] An embodiment of the present invention provides a chip verification system based on RGB image data, including: a top-level module, wherein the top-level module includes:

[0013] DUT unit;

[0014] Instantiating a test case, including a first test environment and a second test environment; the first test environment is connected to the DUT unit through a first interface, and the DUT unit reads image data of the first test environment through the first interface; the second test environment is connected to the DUT unit through a second interface, and the second test environment configures the IP of the DUT unit through the second interface; and

[0015] The monitoring and comparing unit is connected to the DUT unit through a third interface, and is used to collect output data of the DUT unit and compare the output data with an expected value to determine whether the design of the DUT unit is correct.

[0016] Preferably, collecting the output data of the DUT unit and comparing the output data with an expected value to determine whether the design of the DUT unit is correct includes:

[0017] Identify the start time of each frame of data in the output data;

[0018] Collecting and storing frame data at the start time;

[0019] obtaining the expected value;

[0020] Determining whether the frame data matches the expected value;

[0021] If yes, output success information;

[0022] If not, output an error message and terminate the test process.

[0023] Preferably, the output data includes a vertical synchronization signal; and the identifying the start time of each frame of data in the output data includes:

[0024] Determining whether the value of the vertical synchronization signal changes from a first value to a second value;

[0025] The start time is defined as the time when the value of the vertical synchronization signal changes from the first value to the second value.

[0026] Preferably, the output data further includes a reset signal and an RGB pixel data signal; and the collecting and storing frame data at the start time includes:

[0027] Determine whether the reset signal is a reset value; if so, configure the value of the frame counter to 0;

[0028] Each time the start of the frame data is detected, the value of the frame counter increases by 1, and its function is to determine which frame of data collected by other units is collected;

[0029] Determine whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value;

[0030] If yes, the RGB pixel data signal is collected.

[0031] Preferably, obtaining the expected value includes:

[0032] Determine whether the expected value is configured with an acquisition address;

[0033] If yes, obtaining the expected value based on the acquisition address;

[0034] If not, the expected value is configured as a default value.

[0035] Preferably, the monitoring and comparing unit is also used to store the output data of the DUT unit; the monitoring and comparing unit generates a corresponding output file at the start time of each frame of data, and automatically closes the file at the end of the frame.

[0036] The present application also provides a chip verification method based on RGB image data, which is applied to a chip verification system based on RGB image data, wherein the collecting of output data of the DUT unit and comparing the output data with an expected value to determine whether the design of the DUT unit is correct include:

[0037] Identify the start time of each frame of data in the output data;

[0038] Collecting and storing frame data at the start time;

[0039] obtaining the expected value;

[0040] Determining whether the frame data matches the expected value;

[0041] If yes, output success information;

[0042] If not, output an error message and terminate the test process.

[0043] Preferably, the output data includes a vertical synchronization signal; and the identifying the start time of each frame of data in the output data includes:

[0044] Determining whether the value of the vertical synchronization signal changes from a first value to a second value;

[0045] The start time is defined as the time when the value of the vertical synchronization signal changes from the first value to the second value.

[0046] Preferably, the output data further includes a reset signal and an RGB pixel data signal; and the collecting and storing frame data at the start time includes:

[0047] Determine whether the reset signal is a reset value; if so, configure the value of the frame counter to 0;

[0048] Each time the start of the frame data is detected, the value of the frame counter increases by 1;

[0049] Determine whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value;

[0050] If yes, the RGB pixel data signal is collected.

[0051] Preferably, obtaining the expected value includes:

[0052] Determine whether the expected value is configured with an acquisition address;

[0053] If yes, obtaining the expected value based on the acquisition address;

[0054] If not, the expected value is configured as a default value.

[0055] Preferably, the collecting of the output data of the DUT unit and comparing the output data with the expected value to determine whether the design of the DUT unit is correct also includes: storing the output data, generating a corresponding output file at the start time of each frame of data, and automatically closing the file at the end of the frame.

[0056] Compared with the prior art, the technical solution of the embodiment of the present invention has the following beneficial effects:

[0057] The chip verification system and method based on RGB image data provided by the embodiment of the present invention is a new image data processing method and image data processing system, which will not make the verification environment more complicated. The monitoring and comparison unit is instantiated in the top-level module instead of in the test environment, making it easy to separate from the entire verification environment and easy to control. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are some embodiments of the present invention, not all embodiments. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor.

[0059] Figure 1 It is a structural block diagram of a traditional image data processing system;

[0060] Figure 2 A structural block diagram of a chip verification system based on RGB image data provided by one embodiment of the present invention;

[0061] Figure 3 A flowchart of an image data processing method provided by one embodiment of the present invention. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] The technical solution of the present invention is described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0064] Based on the problems existing in the prior art, an embodiment of the present invention provides an image data processing method and system.

[0065] Figure 2 A structural block diagram of a chip verification system based on RGB image data provided by an embodiment of the present invention is shown in FIG. Figure 2 As shown, the chip verification system includes a top-level module (TB_top) 10 , and the top-level module 10 includes a DUT unit (video-out) 12 , an instantiated test case (test) 11 , and a monitoring and checking unit (monitor and checker) 13 .

[0066] Among them, the DUT unit 12 is the test design (DUT, Design Under Test), which is the IP module to be tested, usually composed of a series of RTL files. The top-level module 10 includes an instantiated test case 11. The instantiated test case 11 includes a test environment (env) 110. The instantiated test case 11 is used to instantiate the test environment 110. The test environment 110 is used to mount various test sequences (test sequences) used for testing.

[0067] In this embodiment, the test environment 110 may include a first test environment 111, a second test environment 112, and a test environment configuration file (env_config) 113. The first test environment 111 is connected to the DUT unit 12 via a first interface 141, and the DUT unit 12 reads the image data of the first test environment 111 via the first interface 141. The second test environment 112 is connected to the DUT unit 12 via a second interface 142, and the second test environment 112 configures the IP of the DUT unit 12 via the second interface 142.

[0068] Exemplarily, the first test environment 111 may be an axi test environment (axi_env), and correspondingly, the first interface 141 may be an axi interface (AXI-Interface). The first test environment 111 may include a first agent, and the first agent may include a first memory (MEM, Memory). The first memory may be a storage device such as DDR, which may be used to store image data. The image data may be color-coded data, such as compressed YUV420, YUV444, etc. The DUT unit 12 reads the YUV data pre-stored in the first memory through the first interface 141. Afterwards, the DUT unit 12 may process the YUV data, for example, convert the YUV data into RGB pixel data signals, and may also implement operations such as mixing multiple layers.

[0069] Exemplarily, the second test environment 112 may be an ahb test environment (ahb_env), and correspondingly, the second interface 142 may be an ahb interface (AHB-Interface). The second test environment 112 may include a second agent, and the second agent may include a driver. The driver may configure the IP of the DUT unit 12 through the second interface 142 so that it can process images of a specific resolution.

[0070] The monitoring and comparing unit 13 is connected to the DUT unit 12 via the third interface 143. The monitoring and comparing unit 13 is used to collect output data of the DUT unit 12 and compare the output data with an expected value to determine whether the design of the DUT unit 12 is correct.

[0071] Exemplarily, the monitoring and comparison unit 13 is a parameterized module that supports the processing and storage of input video signals and pixel data. Parameters may include PIX_SIZE and F_NUM. Among them, PIX_SIZE controls the bit width of each color channel (i.e., the bit width of each RGB color component, which is convenient for controlling various RGB pixel format inputs, such as supporting the acquisition of different data formats such as RGB888, RGB565); F_NUM is the maximum supported number of frames and the number of frame data that can be processed and stored. The monitoring and comparison unit 13 is mainly synchronized by input signals, and frame data acquisition and storage comparison. The third interface 143 can be the data output interface (VO-Interface) of the DUT unit 12. The DUT unit 12 can output RGB pixel data signals (pixel_out_r, pixel_out_g, pixel_out_b), display valid signals (den_out), vertical synchronization signals (vsync_out), horizontal synchronization signals (hsync_out), clock signals (clk) and other signals to the monitoring and comparison unit 13 through the third interface 143.

[0072] The monitoring and comparing unit 13 of the chip verification system for image data provided in the present application will not make the verification environment more complicated. The monitoring and comparing unit 13 is instantiated in the top-level module 10 instead of in the test environment, making it easy to separate from the entire verification environment and easy to control.

[0073] In some embodiments, Figure 3 As shown, the monitoring and comparing unit 13 collects the output data of the DUT unit 12 and compares the output data with the expected value to determine whether the design of the DUT unit 12 is correct, including the following steps:

[0074] Step S11, identifying the start time of each frame of data in the output data.

[0075] Step S12, collecting frame data at the start time and storing it.

[0076] Step S13, obtaining the expected value.

[0077] Step S14, determining whether the frame data matches the expected value.

[0078] If yes, then execute step S151 to output a success message; if no, then execute step S152 to output an error message and terminate the test process.

[0079] In some embodiments, the output data includes a vertical synchronization signal vsync_out. Step S11 identifies the start time of each frame of data in the output data, including: determining whether the value of the vertical synchronization signal vsync_out changes from a first value to a second value; and taking the moment when the value of the vertical synchronization signal vsync_out changes from the first value to the second value as the start time. In this embodiment, the first value of the vertical synchronization signal vsync_out is 0, and the second value is 1, that is, whenever the value of the vertical synchronization signal vsync_out jumps from 0 to 1, it is the start time of the frame data. In other embodiments, the start time of the frame data may also be when the value of the vertical synchronization signal vsync_out jumps from 1 to 0.

[0080] Specifically, the monitoring and comparison unit 13 receives the video signal (i.e., the video-out output signal to be tested), clock signal clk, reset signal rstn, display valid signal den_out, horizontal synchronization signal hsync_out, vertical synchronization signal vsync_out, and RGB pixel data signals pixel_out_r, pixel_out_g, pixel_out_b. By detecting the edge change of the vertical synchronization signal vsync_out, the module identifies the beginning of each frame of data, and then controls the subsequent frame data acquisition and storage. The exemplary code is as follows, and the sample code is only used as one implementation method, not as a limitation:

[0081] / / Trigger this logic block on the rising edge of the clock signal (clk) or the falling edge of the reset signal (rstn)

[0082] always @(posedge clk or negedge rstn) begin

[0083] / / If the reset signal (rstn) is low (i.e. in reset state)

[0084] if (~rstn) begin

[0085] / / Reset the frame counter (cnt_frame) to 0

[0086] cnt_frame <= 0;

[0087] / / Reset the vertical sync signal output (vsync_out_d) to 0

[0088] vsync_out_d <= 0;

[0089] end

[0090] / / If it is not reset

[0091] else begin

[0092] / / Set the vertical synchronization signal output (vsync_out_d) to the current vertical synchronization signal (vsync_out) value

[0093] vsync_out_d <= vsync_out;

[0094] end

[0095] end

[0096] / / Define a continuous assignment statement to detect the frame start signal. When vsync_out_d is 0 and vsync_out is 1, it indicates the start of a frame.

[0097] assign frame_start = ~vsync_out_d & vsync_out.

[0098] In some embodiments, the output data also includes a reset signal rstn and RGB pixel data signals pixel_out_r, pixel_out_g, and pixel_out_b. Step S12, collecting frame data at the start time and storing it includes: determining whether the reset signal rstn is a reset value; if so, configuring the value of the frame counter to 0; increasing the value of the frame counter by 1 each time the start of the frame data is detected; determining whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value; if so, collecting the RGB pixel data signals pixel_out_r, pixel_out_g, and pixel_out_b.

[0099] Specifically, at the beginning of each frame, the module resets the frame counter cnt_frame. The exemplary code is as follows. The exemplary code is only used as one implementation method and is not intended to limit the implementation method.

[0100] / / Frame counting logic

[0101] always @(posedge clk) begin

[0102] if (~rstn) begin

[0103] cnt_frame <= 0;

[0104] end

[0105] / / If the reset signal is high and the frame start signal is detected, cnt_frame increments and updates each time a new frame arrives

[0106] else begin

[0107] if (frame_start) begin

[0108] cnt_frame <= cnt_frame + 1;

[0109] end

[0110] end

[0111] end

[0112] When the valid data signal den_out is high, the RGB pixel data signal is captured and stored in an RGB pixel data signal controlled by PIX_SIZE through logic. Through the generation (genrata) loop, the module supports the collection of RGB pixel data signals of different frames, and pushes the data to the comparison task (vo_rgb_data) during the collection to compare with the expected data (golden data).

[0113] / / Use the generate statement to create processing logic for each frame. This sample code is only one implementation method and is not a limitation:

[0114] generate

[0115] / / Loop F_NUM times, generate a processing block for each frame, F_NUM is the incoming parameter

[0116] for(genvar i = 1; i < F_NUM; i++) begin

[0117] always @(posedge clk) begin

[0118] / / If the current frame counter value is equal to the current frame index (i+1), and the den_out signal is true

[0119] if (cnt_frame == i && den_out) begin

[0120] / / Combine the red, green, and blue pixel output signals into RGB values

[0121] rgb = {pixel_out_r, pixel_out_g, pixel_out_b};

[0122] / / Call function to check or process RGB pixel data signal

[0123] check_vo_rgb_data(rgb,,j++, i); / / i is the current frame, j is a pixel data of the current frame

[0124] end

[0125] end

[0126] end

[0127] endgenerate

[0128] In some specific implementations, step S13 of obtaining the expected value includes: determining whether the expected value is configured with an acquisition address; if so, obtaining the expected value based on the acquisition address; if not, configuring the expected value as a default value.

[0129] Specifically, the monitoring and comparison unit 13 provides a data comparison function. Data is passed through command line parameters and stored in a file under a specified path to improve flexibility. An exemplary pseudo code is as follows, which is only used as one implementation method and not a limitation thereof:

[0130] / / Prepare expected data (golden data)

[0131] initial begin

[0132] / / File handle

[0133] integer fh;

[0134] / / Flag variable to indicate whether to perform a check, default is 1 (check)

[0135] int do_check = 1;

[0136] / / Set the value of do_check through the command line parameters. If not set, keep the default value 1

[0137] if (!$value$plusargs("do_check=%0d", do_check)) begin

[0138] do_check = 1;

[0139] end

[0140] / / The number of repeated checks is determined by the value of do_check

[0141] repeat_num = do_check;

[0142] / / Loop through each repetition check

[0143] for (int idx = 0; idx < repeat_num; idx++) begin

[0144] / / Set the expected data file name through the command line parameter, if not set, use the default value

[0145] if(!$value$plusargs("disp_golden_data=%0s", disp_golden_data)) begin

[0146] disp_golden_data = "disp_ly1_RGB888_YUV420_128X128";

[0147] end

[0148] / / Construct the path of the expected data file

[0149] monitor_out_exp = $sformatf("%0s / %0s / monitor_0%0d.out",monitor_out_exp_dir, disp_golden_data, idx);

[0150] / / Open the expected data file for reading

[0151] fh = $fopen(monitor_out_exp, "r");

[0152] / / Check if the file was opened successfully

[0153] if (!fh) begin

[0154] / / If the file fails to open, print an error message and terminate the simulation

[0155] `uvm_fatal("TRACE", $sformatf("can not open %0s",monitor_out_exp));

[0156] end else begin

[0157] / / Declare variables for storing file data

[0158] bit [31:0] file_data;

[0159] / / Declare a flag variable to indicate whether the data is read successfully

[0160] bit valid = 0;

[0161] / / Loop through each line of data in the file

[0162] while (!$feof(fh)) begin

[0163] / / Read a line of data from the file and check whether it is read successfully

[0164] valid = $fscanf(fh, "%24h\n", file_data);

[0165] / / Add the read data to the expected data queue

[0166] exp_data_q.push_back(file_data);

[0167] end

[0168] / / Check if the expected data queue is empty. If it is empty, print an error message and terminate the simulation.

[0169] if (exp_data_q.size() == 0)

[0170] `uvm_fatal("TRACE", $sformatf("%0s Golden data shouldnot be zero = %0d", monitor_out_exp, exp_data_q.size()));

[0171] end

[0172] end

[0173] end

[0174] In some specific implementations, in step S14, in which the frame data and the expected value match, the monitoring and comparison unit 13 uses the exp_data_q queue to store the expected data (i.e., the expected value). The file where the expected data (golden data) is stored is read ($fopen) and the expected value of each frame is stored in the queue. When new frame data is collected, the module will compare the current frame data with the expected value in the queue. If there is no match, an error message is triggered and the test process is terminated. If there is an error, the test process stops immediately to reduce the simulation time. When the match is successful, a success message is output.

[0175] The pseudo code for this step is as follows:

[0176] / / Define a task to check whether the RGB pixel data signal of the video output (VO) matches the expected data

[0177] task check_vo_rgb_data(bit [23:0] rgb, int j, int frame_cnt);

[0178] / / If data checking is enabled (do_check is true)

[0179] if(do_check) begin

[0180] / / Compare the actual RGB pixel data signal with the corresponding data in the expected data queue

[0181] if (exp_data_q[j] != rgb)

[0182] / / If the data does not match, print an error message and terminate the simulation

[0183] / / Error information includes frame number, data index, expected value and actual value

[0184] `uvm_fatal("TRACE", $sformatf("monitor_0%0d.out Data[%0d] check fails !!! exp = %0h, act = %0h", frame_cnt, j, exp_data_q[j],rgb));

[0185] else

[0186] / / If the data matches, print the pass information

[0187] / / The information includes the frame number, data index, expected value and actual value (the two are equal at this time)

[0188] `uvm_info("TRACE", $sformatf("monitor_0%0d.out Data[%0d]check pass ... exp = %0h, act = %0h", frame_cnt, j, exp_data_q[j], rgb), UVM_LOW);

[0189] end

[0190] endtask: check_vo_rgb_data

[0191] In some embodiments, the monitoring and comparison unit 13 is also used to store the output data of the DUT unit. Specifically, the monitoring and comparison unit 13 supports generating corresponding output files (monitor_00.out, monitor_01.out, etc.) at the beginning of each frame, and automatically closes the file at the end of the frame. The RGB pixel data signal of each frame will be written to the corresponding file in real time, and the formatted output of the data is realized by the $fwrite function.

[0192] The exemplary pseudo code is as follows:

[0193] / / Define the file handle array, the size is determined by F_NUM

[0194] file f_handle[0: F_NUM-1];

[0195] / / Define a state variable to keep track of the current frame

[0196] int current_frame = 0;

[0197] / / Perform the following operations when the clock rises

[0198] always @(posedge clk) begin

[0199] / / If a new frame starts and the frame number is within the valid range, open the corresponding file

[0200] if (frame_start && (cnt_frame >= 0) && (cnt_frame < F_NUM)) begin

[0201] current_frame <= current_frame + 1;

[0202] string filename;

[0203] $sformat(filename, "monitor_0%0d.out", current_frame - 1);

[0204] f_handle[current_frame - 1] = $fopen(filename);

[0205] end

[0206] / / If the data is valid (den_out is high) and the current frame number is in the valid range, write the data to the file

[0207] if (den_out && (current_frame > 0) && (current_frame <= F_NUM))begin

[0208] $fwrite(f_handle[current_frame - 1], "%06h\n", {pixel_out_r,pixel_out_g, pixel_out_b});

[0209] end

[0210] / / At the beginning of a new frame (except the first frame), close the file of the previous frame

[0211] / / Note: Here we assume that cnt_frame is increasing and synchronized with frame_start

[0212] / / If cnt_frame is not increasing continuously, or the logic is different, you need to adjust it accordingly

[0213] if (frame_start && (cnt_frame > 0) && (cnt_frame <= F_NUM)) begin

[0214] $fclose(f_handle[current_frame - 1]);

[0215] end

[0216] end

[0217] The chip verification system based on RGB image data provided by this application can capture multiple frames of data at the same time and control the number of captured frames through parameterization. The design ensures the correctness of the video output by comparing the actual data of the current frame with the expected data, and saves the generated data in the simulation directory for easy debugging.

[0218] Furthermore, the chip verification system of image data can automatically complete the entire process from data capture, storage, verification to output, greatly improving data processing efficiency. The automatic generation and closing of files reduces resource usage, and the results of the design to be tested are compared with the expected data in real time, which improves the comparison efficiency. There is no need to wait for the design results to be fully generated before comparison, which improves verification efficiency.

[0219] Furthermore, the monitoring and comparing unit 13 in the chip verification system based on RGB image data allows dynamic loading of expected data files and verification in each simulation test, thereby enhancing the flexibility and reliability of the test.

[0220] Furthermore, the present application also provides a chip verification method based on RGB image data, which is applied to the chip verification system of the above-mentioned image data, collecting the output data of the DUT unit and comparing the output data with the expected value to determine whether the design of the DUT unit is correct, including: identifying the start time of each frame of data in the output data; collecting and storing the frame data at the start time; obtaining the expected value; determining whether the frame data matches the expected value; if so, outputting a success message; if not, outputting an error message and terminating the test process.

[0221] In some embodiments, the output data includes a vertical synchronization signal; identifying the start time of each frame of data in the output data includes: determining whether the value of the vertical synchronization signal changes from a first value to a second value; and taking the moment when the value of the vertical synchronization signal changes from a first value to a second value as the start time.

[0222] In some embodiments, the output data also includes a reset signal and an RGB pixel data signal; collecting frame data at the start time and storing it, including: determining whether the reset signal is a reset value; if so, configuring the value of the frame counter to 0; increasing the value of the frame counter by 1 each time the start of frame data is detected; determining whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value; if so, collecting the RGB pixel data signal.

[0223] In some implementations, obtaining the expected value includes: determining whether the expected value is configured with an acquisition address; if so, obtaining the expected value based on the acquisition address; if not, configuring the expected value as a default value.

[0224] In some implementations, the chip verification method of image data further includes storing output data of the DUT unit.

[0225] The various steps of the chip verification method for image data provided in the present application can be referred to in the relevant description of the image data processing system, and will not be repeated here.

[0226] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A chip verification system based on RGB image data, characterized in that: include: A top-level module, the top-level module comprising: DUT unit; Instantiating a test case, including a first test environment and a second test environment; the first test environment is connected to the DUT unit through a first interface, and the DUT unit reads image data of the first test environment through the first interface; the second test environment is connected to the DUT unit through a second interface, and the second test environment configures the IP of the DUT unit through the second interface; and The monitoring and comparison unit is a parameterized module, supports the processing and storage of input video signals and pixel data, is connected to the DUT unit through a third interface, and is used to collect output data of the DUT unit and compare the output data with an expected value to determine whether the design of the DUT unit is correct, including: Identify the start time of each frame of data in the output data; Collecting and storing frame data at the start time; obtaining the expected value; Determining whether the frame data matches the expected value; If yes, output success information; If not, output an error message and terminate the test process; The output data includes a reset signal and an RGB pixel data signal; the collecting and storing of frame data at the start time includes: judging whether the reset signal is a reset value; if so, configuring the value of the frame counter to 0; increasing the value of the frame counter by 1 each time the start of the frame data is detected; judging whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value; if so, collecting the RGB pixel data signal; and storing the collected RGB pixel data signal in an RGB pixel data signal controlled by PIX_SIZE through logic, supporting the collection of RGB pixel data signals of different frames by generating a loop, and pushing the data to the monitoring and comparison unit while collecting, and comparing the data with the expected value; In the step of determining whether the frame data matches the expected value, the monitoring and comparison unit uses a queue to store the expected value, reads the file where the expected value is stored, and stores the expected value of each frame in the queue. When new frame data is collected, the monitoring and comparison unit compares the current frame data with the expected value in the queue. If there is no match, an error message is triggered and the test process is terminated. If the match is successful, a success message is output.

2. The chip verification system according to claim 1, characterized in that: The output data includes a vertical synchronization signal; the identifying the start time of each frame of data in the output data includes: Determining whether the value of the vertical synchronization signal changes from a first value to a second value; The start time is defined as the time when the value of the vertical synchronization signal changes from the first value to the second value.

3. The chip verification system according to claim 1, characterized in that: The obtaining of the expected value comprises: Determine whether the expected value is configured with an acquisition address; If yes, obtaining the expected value based on the acquisition address; If not, the expected value is configured as a default value.

4. The chip verification system according to claim 1, characterized in that: The monitoring and comparing unit is also used to store the output data; the monitoring and comparing unit generates a corresponding output file at the start time of each frame of data, and automatically closes the file when the frame ends.

5. A chip verification method based on RGB image data, characterized in that: Setting a top-level unit, wherein the top-level unit includes a DUT unit, an instantiated test case, and a monitoring and comparison unit; The instantiated test case includes a first test environment and a second test environment; the first test environment is connected to the DUT unit through a first interface, and the DUT unit reads the image data of the first test environment through the first interface; the second test environment is connected to the DUT unit through a second interface, and the second test environment configures the IP of the DUT unit through the second interface; The monitoring and comparison unit is a parameterized module that supports the processing and storage of input video signals and pixel data; the monitoring and comparison unit is connected to the DUT unit through a third interface to collect output data of the DUT unit, and the output data is compared with an expected value to determine whether the design of the DUT unit is correct, including: Identify the start time of each frame of data in the output data; Collecting and storing frame data at the start time; obtaining the expected value; Determining whether the frame data matches the expected value; If yes, output success information; If not, output an error message and terminate the test process; The output data includes a reset signal and an RGB pixel data signal; the collecting and storing of frame data at the start time includes: judging whether the reset signal is a reset value; if so, configuring the value of the frame counter to 0; increasing the value of the frame counter by 1 each time the start of the frame data is detected; judging whether the current value of the frame counter is equal to the frame index value and whether the valid data signal is a valid value; if so, collecting the RGB pixel data signal; and storing the collected RGB pixel data signal in an RGB pixel data signal controlled by PIX_SIZE through logic, supporting the collection of RGB pixel data signals of different frames by generating a loop, and pushing the data to the monitoring and comparison unit while collecting, and comparing the data with the expected value; In the step of determining whether the frame data matches the expected value, the monitoring and comparison unit uses a queue to store the expected value, reads the file where the expected value is stored, and stores the expected value of each frame in the queue. When new frame data is collected, the monitoring and comparison unit compares the current frame data with the expected value in the queue. If there is no match, an error message is triggered and the test process is terminated. If the match is successful, a success message is output.

6. The chip verification method according to claim 5, characterized in that: The output data includes a vertical synchronization signal; the identifying the start time of each frame of data in the output data includes: Determining whether the value of the vertical synchronization signal changes from a first value to a second value; The start time is defined as the time when the value of the vertical synchronization signal changes from the first value to the second value.

7. The chip verification method according to claim 5, characterized in that: The obtaining of the expected value comprises: Determine whether the expected value is configured with an acquisition address; If yes, obtaining the expected value based on the acquisition address; If not, the expected value is configured as a default value.

8. The chip verification method according to claim 5, characterized in that: The collecting of the output data of the DUT unit and comparing the output data with the expected value to determine whether the design of the DUT unit is correct also includes: storing the output data, generating a corresponding output file at the start time of each frame of data, and automatically closing the file at the end of the frame.

Images