A universal accurate performance verification system and method
By connecting the signal interface of the DUT to be tested with the general verification component UVC and integrating it into the test platform verification environment, the problems of low reusability of verification components and difficult to simulate the impact of system delays in the prior art are solved, and more efficient Verification and more complete functional design.
Patent Information
- Application Number
- CN202411052610.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-02
- Publication Date
- 2025-02-18
- Estimated Expiration
- 2044-08-02
AI Technical Summary
Existing chip function verification methods are difficult to effectively simulate real application scenarios, especially in terms of the impact of system delays on memory read and write access on functions, and the reusability of verification components is low, resulting in difficulty in positioning and debugging of verification environment problems.
A general precise performance verification system and method is proposed, which integrates the test platform verification environment by classifying the signal interface of the DUT to be tested by function type and connecting it with the general verification component UVC. At the same time, performance monitoring of system delay and memory read and write access is added, improving the completeness of functional design.
It improves the reusability of verification components, facilitates the instantiation of verification components and problem positioning and debugging of verification environments, can more accurately simulate real application scenarios, and improves the completeness of functional design.
Smart Images

Figure CN118569163B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of chip verification technology, and in particular to a universal accurate performance verification system and method. Background Art
[0002] Chip functional verification usually involves placing the Design Under Test (DUT) into the testbench and verifying it through test cases. Currently, the mainstream verification language is SystemVerilog, and the verification methodology is the Universal Verification Methodology (UVM). A testbench usually consists of verification components such as the verification environment Env, agent Agent, driver Driver, monitor Monitor, sequence sequence, etc. The instantiation reuse of verification components in general testbench is low, which is not conducive to locating and debugging verification environment problems.
[0003] At the same time, when verifying the function of the existing DUT, people often only focus on whether its basic functions are covered, but ignore the impact of the system latency of memory read and write access on the function, which cannot simulate the application in the real application scenario. For example, for an audio data system, the delay in the system transmission process will affect the continuity of data transmission, thereby affecting performance and even functionality.
[0004] The above technical problems have not been properly solved yet, and the present invention is intended to solve these technical problems. Summary of the invention
[0005] In order to at least solve the technical problems existing in the above-mentioned background technology, the present invention provides a universal accurate performance verification system and method.
[0006] A first aspect of the present invention provides a general accurate performance verification method, comprising the following steps:
[0007] Classify the signal interfaces of the DUT in the test platform according to different functional types;
[0008] Connecting each of the signal interfaces belonging to different functional categories with the corresponding universal verification component UVC;
[0009] Integrate all common verification components UVC into the test platform verification environment TB_Env.
[0010] Optionally, the signal interface of the design under test DUT is divided into a clock reset interface, a register configuration bus interface, a memory read-write access bus interface, and a data bus interface according to function.
[0011] Optionally, the universal verification component UVC includes a clock reset UVC, a register configuration UVC, a ring buffer UVC, and a data bus UVC.
[0012] Optionally, the test platform verification environment TB_Env also includes three verification components: a register model, a reference model and a scoreboard;
[0013] Among them, the register model is used to organize and configure the registers in the design under test (DUT); the reference model also generates data flow; the scoreboard is used to check whether the data flow output by the data bus interface is consistent with the data flow output by the reference model.
[0014] Optionally, the signal interface of the design under test DUT and the corresponding universal verification component UVC are connected by means of virtual interface binding Bind.
[0015] Optionally, the DUT includes a delay monitoring status register, which is used to count the total delay of the memory read and write access system of the channel of the DUT.
[0016] Optionally, the test platform also includes a bandwidth monitoring module, and the memory read and write access bus interface of the DUT under test is connected to the bandwidth monitoring module. The bandwidth monitoring module performs performance monitoring on the memory read and write access bus interface of the DUT under test, records the monitoring results into a record file, and forms a performance bandwidth report after script processing and calculation.
[0017] The second aspect of the present invention provides a general accurate performance verification system, including a design under test DUT and a test platform verification environment TB_Env; wherein,
[0018] The design DUT to be tested is a multi-channel data DMA design, and its design interface is divided into a clock reset interface, a register configuration bus interface, a memory read-write access bus interface, and a data bus interface according to the functional type;
[0019] The test platform verification environment TB_Env is used to perform functional verification on the design under test DUT, which includes clock reset UVC, register configuration UVC, ring buffer UVC, data bus UVC, as well as register model, reference model and scoreboard verification components.
[0020] Compared with the prior art, the present invention has the following advantages:
[0021] 1) The present invention modularly instantiates the universal verification component UVC of the test platform verification environment TB_Env, thereby improving the reusability of the verification component in the test platform and facilitating the instantiation of the verification component and the problem location and debugging of the verification environment;
[0022] 2) The present invention also adds system delay and performance monitoring of memory read and write access, which improves the functional design completeness of the DUT under test and can be closer to the actual application scenario. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.
[0024] Figure 1 It is a structural schematic diagram of a universal accurate performance verification system disclosed in an embodiment of the present invention.
[0025] Figure 2 It is a schematic diagram of system latency monitoring of memory read and write access of the design under test (DUT).
[0026] Figure 3 This is a block diagram of the bandwidth monitoring of the DUT memory read and write access bus interface. DETAILED DESCRIPTION
[0027] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions 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.
[0028] The words "first, second, third, etc." or module A, module B, module C and the like in the specification and claims are used only to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that the specific order or sequence can be interchanged where permitted so that the embodiments of the invention described herein can be implemented in an order other than that illustrated or described herein.
[0029] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.
[0030] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.
[0031] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present invention. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.
[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. In the event of any inconsistency, the meanings described in this specification or derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.
[0033] The embodiment of the present invention discloses a general accurate performance verification method, comprising the following steps:
[0034] Classify the signal interfaces of the DUT in the testbench according to different functional types;
[0035] Connecting each of the signal interfaces belonging to different functional categories with the corresponding universal verification component UVC;
[0036] Integrate all common verification components UVC into the test platform verification environment TB_Env.
[0037] The present invention connects interfaces of different functions of the design DUT to be tested to different universal verification components (UVC), and then integrates all UVCs into a test platform verification environment TB_Env, which improves the reusability of the verification components and facilitates the instantiation of the verification components and the problem location and debugging of the verification environment.
[0038] Optionally, the signal interface of the design under test DUT is divided into a clock reset interface, a register configuration bus interface, a memory read-write access bus interface, and a data bus interface according to function.
[0039] Optionally, the universal verification component UVC includes a clock reset UVC, a register configuration UVC, a ring buffer UVC, and a data bus UVC.
[0040] Among them, the universal verification component UVC actually also includes the memory read and write access bus interface, that is, Figure 1 The interface between the ring buffer UVC and the design under test DUT.
[0041] Optionally, the test platform verification environment TB_Env includes three verification components: a register model, a reference model and a scoreboard;
[0042] Among them, the register model is used to organize and configure the registers in the design under test (DUT); the reference model also generates data streams (such as audio data streams); the scoreboard is used to check whether the data stream output by the data bus interface is consistent with the data stream output by the reference model.
[0043] The test platform verification environment TB_Env of the present invention instantiates all universal verification components UVC, and also instantiates two verification components, the test platform verification environment configuration TB_Cfg and the test platform verification environment sequencer TB_Sequencer. Among them, the test platform verification environment configuration TB_Cfg verification component instantiates the environment configuration Cfg verification component of each universal verification component UVC; the test platform verification environment sequencer TB_Sequencer verification component instantiates the environment sequencer Sequencer verification component of the register configuration UVC.
[0044] Next, the signal interface of the design DUT to be tested and the universal verification components UVC and their connection methods are explained:
[0045] 1) The clock reset UVC is connected to the clock reset interface of the design under test (DUT), including multiple clocks and resets. The frequency of each clock is defined in the environment configuration Cfg verification component of the clock reset UVC, and the frequency variation range can be configured to achieve randomization of the clock frequency.
[0046] 2) The register configuration UVC is connected to the register configuration bus interface of the design under test DUT to configure the register of the design under test DUT. The register configuration UVC includes a master agent and a slave agent, and which agent to use is selected by configuring CFG is_active. In the present invention, the register configuration UVC is used to configure the register of the design under test DUT, so the master agent Master Agent verification component is selected for use.
[0047] 3) The register model is connected to the register configuration UVC to manage and configure the registers of the design under test (DUT).
[0048] 4) The ring buffer UVC is connected to the memory read / write access bus interface of the design DUT to be tested, and is used to receive the access request of the memory read / write access bus interface of the design DUT to be tested, and return the required data stream (such as audio data stream) to the design DUT to be tested. The ring buffer UVC includes a master agent Master Agent and a slave agent Slave Agent, and which agent to use is selected by configuring CFGis_master_slave. In the present invention, the design DUT to be tested actively initiates a data stream read / write request, so the slave agent Slave Agent verification component is selected for use.
[0049] 5) The data bus UVC is connected to the data bus interface of the design under test DUT to receive the serial output data of the design under test DUT. The data bus interface UVC includes the master agent and the slave agent. The agent to be used is selected by configuring CFGis_master_slave. When the design under test DUT is not implemented, the master agent and the slave agent can be used as part of the test platform verification environment to debug whether the function of the verification environment is correct.
[0050] Optionally, the signal interface of the design under test DUT and the corresponding universal verification component UVC are connected by means of virtual interface (Virtual Interface) Bind.
[0051] Optionally, the DUT includes a delay monitoring status register, which is used to count the total delay of the memory read and write access system of the channel of the DUT.
[0052] Optionally, the test platform also includes a bandwidth monitoring module, and the memory read and write access bus interface of the DUT under test is connected to the bandwidth monitoring module. The bandwidth monitoring module performs performance monitoring on the memory read and write access bus interface of the DUT under test, records the monitoring results into a record file, and forms a performance bandwidth report after script processing and calculation.
[0053] The design DUT under test reads a data stream (e.g., an audio data stream) from the front door of the ring buffer UVC through the memory read and write access bus interface, and the ring buffer UVC returns a data stream (e.g., an audio data stream), and the numerical range of its return delay Latency can be configured in the test platform verification environment configuration TB_Cfg verification component.
[0054] The test platform also performs performance monitoring on the memory read / write access bus interface of the DUT, records the monitoring results into a record file, and forms a performance bandwidth report after script processing and calculation for subsequent analysis.
[0055] like Figure 1 As shown, the embodiment of the present invention discloses a universal accurate performance verification system, including a design under test DUT and a test platform verification environment TB_Env; wherein,
[0056] The design DUT to be tested is a multi-channel data DMA design, and its design interface is divided into a clock reset interface, a register configuration bus interface, a memory read-write access bus interface, and a data bus interface according to the functional type;
[0057] The test platform verification environment TB_Env is used to perform functional verification on the design under test DUT, which includes clock reset UVC, register configuration UVC, ring buffer UVC, data bus UVC, as well as register model, reference model and scoreboard verification components.
[0058] Next, the signal interface of the design DUT to be tested and the universal verification components UVC and their connection methods are explained:
[0059] 1) The clock reset interface of the multi-channel data DMA of the design under test DUT is connected to the clock reset UVC of the test platform verification environment TB_Env through the clock reset virtual interface. The design under test DUT generally has multiple clock and reset signals. The clocks and resets in different clock domains need to be configured with different clock frequencies and reset release times in the test platform verification environment. A clock and the reset in this clock domain are used as a group of signals to form a clock reset UVC, and then multiple groups of signal UVCs are instantiated into a clock reset UVC to form a clock reset UVC corresponding to the design under test DUT.
[0060] As an example, the DUT clock reset interface includes X clocks clk1, clk2, ..., clkx, ..., clkX, and the reset corresponding to each clock is resetn1, resetn2, ..., resetx, ..., resetX. clkx and resetnx are the x-th clock resets in the clock reset interface. The clock frequencies corresponding to the X clocks are freq1, freq2, ..., freqx, ..., freqX, where freqx is the clock frequency of the x-th clock. At the same time, the number of cycles of reset relative to clock release is cycle1, cycle2, ..., cyclex, ..., cycleX, where cyclex is the number of clock cycles of the x-th reset release.
[0061] The clock reset UVC of the test platform verification environment TB_Env instantiates X single-group clock reset UVCs. The frequency freq of each clock and the number of reset release cycles can be defined in the configuration verification component of the clock reset UVC of the test platform verification environment TB_Env. For example, the x-th clock reset clkx and resetnx can configure the frequency range of the clock frequency freqx {a,b,…,n,…,N} and the probability of occurrence in each range {a%,b%,…,n%,…,%N} to be random Random; the number of clock cycles released by reset resetnx can be set to be random Random within the cycle range {A,B}.
[0062] 2) The register configuration bus interface of the multi-channel data DMA of the design under test includes multiple groups of register configuration bus interfaces {cfg_bus1, cfg_bus1, ..., cfg_busx, ..., cfg_busX} according to the division of the internal functional modules of the design under test DUT. cfg_busx is the xth register configuration bus interface, which connects the xth register configuration UVC and the xth register model. The clock reset domain of the register configuration bus interface is connected to the clock reset of the clock reset interface.
[0063] The register configuration bus interface of the multi-channel data DMA of the design under test DUT is the slave interface Slave configured by the receiving system, and the system is the master interface Master at this time. Therefore, the register configuration UVC will contain a master agent and a slave agent. Whether to use the master agent or the slave agent is selected by the is_master_slave parameter in the configuration verification component of the register configuration UVC. Before the RTL code of the design under test DUT is ready, the correctness of the register configuration UVC environment function can be verified by connecting the master agent and the slave agent in the register configuration UVC. Similarly, multiple register configuration UVCs are instantiated in one register configuration UVC, and then instantiated into the test platform verification environment TB_Env.
[0064] 3) The register model in the test platform verification environment TB_Env is used to organize and configure the registers of the design under test DUT. Each register of the design under test DUT has read and write properties. It is necessary to construct test cases to verify the correctness of the register read and write properties. The register model can access the registers through the front door to check whether the register read and write properties are consistent. When testing each application scenario, the register model can configure the corresponding registers to achieve the correct functional configuration.
[0065] 4) The memory read-write access bus interface of the multi-channel data DMA of the design DUT to be tested accesses the data in the ring buffer in the memory. The design DUT to be tested uses direct memory access (DMA) to read the multi-channel data from the ring buffer in the memory and stores it in the local buffer of the corresponding channel in the design DUT to be tested for use. The ring buffer UVC connected to the memory read-write access bus interface of the multi-channel data DMA of the design DUT to be tested realizes the multi-channel {pipe0, pipe1, ..., pipex, ..., pipeX} ring buffer function, pipex is the xth channel of the design DUT to be tested, and the corresponding ring buffer is mem0, mem1, ..., memx, ..., memX, where memx is the ring buffer accessed by the channel pipex.
[0066] The memory read and write access bus interface of the multi-channel data DMA of the design DUT to be tested accesses the ring buffer as the master interface, and the ring buffer is a slave interface at this time. Therefore, the ring buffer UVC will contain a master agent and a slave agent. Whether to use the master agent or the slave agent is selected by the is_master_slave parameter in the configuration verification component of the register configuration UVC. Before the RTL code of the design DUT to be tested is ready, the correctness of the function of the ring buffer UVC environment can be verified by connecting the master agent and the slave agent in the register configuration UVC. The local memory model in the slave agent can load data through the backdoor access form. After the data is loaded into the corresponding ring buffer, the channel of the design DUT to be tested can start DMA to read data from the ring buffer in the form of front-door access to the local buffer of the channel in the design DUT to be tested.
[0067] As an example, the data of the channel pipex is backdoored into the memx ring buffer of the local memory model of the ring buffer UVC. The starting address of the memx ring buffer is 0x1000, and the size of the ring buffer is 1K Byte. First, the test case sequence Sequence loads data into the memx ring buffer in the local memory model of the ring buffer UVC through backdoor access. The data is loaded from address 0x1000, and the address increases to 0x1000+0x4, 0x1000+0x8, ... in a way of loading 4 bytes at a time, and finally the entire 1K Byte space of the ring buffer is filled with data. To facilitate debugging and problem location, data can be loaded in 0x0, 0x1, 0x2, ... in a way of increasing by 0x1.
[0068] 5) The I2S serial bus interface of the design under test (DUT) sends the data to the multi-channel data DMA post-processing in the standard format of the integrated circuit built-in audio bus (Inter-ICSound, referred to as I2S). At this time, the I2S serial bus interface of the multi-channel data DMA of the design under test (DUT) is the master interface Master, and the I2S serial interface UVC connected to I2S is the slave interface Slave. The I2S serial interface UVC will contain a master agent and a slave agent. Whether to use the master agent or the slave agent is selected by the is_master_slave parameter in the configuration verification component of the register configuration UVC. Before the RTL code of the design under test DUT is ready, the correctness of the ring buffer UVC environment function can be verified by connecting the master agent and the slave agent in the register configuration UVC.
[0069] As an example, the data of the channel pipex is transmitted to the I2S serial interface UVC. After the I2S serial interface UVC receives the data as the slave interface, it needs to check the correctness of the data. The verification component that completes this function is the scoreboard, which compares the data output by the reference model of the channel pipex with the data monitored by the I2S serial interface UVC to check whether the data is consistent and confirm that the function of the design DUT under test is correct.
[0070] 6) The reference model verifies that the output data of the component is sent to the scoreboard, and the data in the ring buffer of the UVC local memory model is sent to the reference model at the same time. The reference model simulates the behavior of the DUT and processes the data to generate data that is compared with the multi-channel data DMA output of the DUT.
[0071] As an example, the data of the channel pipex in the ring buffer UVC is transmitted to the design under test DUT and the reference model, and the data is 0x0, 0x1, 0x2, ... until all the data in the address space of 1K Byte is sent. The I2S serial interface of the design under test DUT transmits the data to the I2S serial interface UVC, and the I2S serial interface UVC restores the serial data into parallel data transactions according to the I2S standard protocol and transmits them to the scoreboard; the reference model generates the same data transactions and sends them to the scoreboard. The scoreboard checks whether the data output from the design under test DUT is the same as the data of the reference model, so as to determine whether the function of the design under test DUT is correct.
[0072] Figure 2 The figure shows the system delay monitoring diagram of the memory read and write access of the design under test (DUT). The design under test (DUT) reads and writes data from the memory through the system path. There will be delays in the system path, and there will also be delays in the memory read and write data operation process. These two parts of the delay determine the total delay of the memory read and write data access. The size of the system delay will affect the continuity of data processing. Too large a system delay will cause data processing interruption, thereby affecting the function of the design under test (DUT).
[0073] As an example, the channel pipex of the design under test DUT initiates a read / write data operation request to the memory Memory. The request is sent from the memory read / write access bus interface of the design under test DUT, marked as point A of the system path entry. The request is transmitted from point A of the system path to the memory Memory from point B of the system path after the system path delay, and the delay is DelayAB. The memory Memory receives the request, processes the request, and after the processing delay, the memory Memory feeds back the response to point C of the system path entry, and the delay is DelayM. The response is transmitted from point C of the system path to the design under test DUT from point D of the system path after the system path delay, and the delay is DelayCD. Therefore, the total system delay of the entire memory Memory data read / write operation is Delay=DelayAB+DelayM+DelayCD.
[0074] The ring buffer UVC can return the system delay by configuring the total_delay parameter in the verification component, and the DUT can add a delay monitoring status register to count the total system delay of the memory read and write access of the pipex channel. The test case can verify whether the functional design of the DUT is correct by comparing whether the value of the delay monitoring status register of the DUT is consistent with the configuration value of the total_delay parameter in the ring buffer UVC configuration verification component, and can also verify the extreme value scenario of the system delay of the DUT.
[0075] Figure 3 The figure shows a bandwidth monitoring block diagram of the memory read / write access bus interface of the design under test DUT. The design under test DUT reads and writes the memory Memory, and the memory read / write access bus interface of the design under test DUT is connected to the bandwidth monitoring module of the test platform. The bandwidth monitoring module monitors and counts the read and write operations of the memory read / write access bus interface, and stores the statistical results in a file in a certain statistical format. After the bandwidth monitoring module completes the monitoring and statistics, the statistical result file is processed by a script to analyze the bandwidth of the read / write access memory Memory of the design under test DUT.
[0076] As an example, the channel pipex of the design under test DUT initiates a read and write data operation request to the memory Memory. Within a period of time T1, the memory read and write access bus interface issues i read access requests, and each read response data is x Byte in size. In the T1 period, the read access data bandwidth is BW1=x*i Byte; within a period of time T2, the memory read and write access bus interface issues j write access requests, and each write access request data is y Byte in size. When all write responses are returned, the write access data bandwidth in the T2 period is calculated to be BW2=j*y Byte. The bandwidth monitoring module of the test platform records the time tx when the memory read and write access bus interface issues a read and write access request, the time ty when the response is received, and the data width W in the file. The script uses these keyword information to sort out and count the read and write bandwidth in any time period.
[0077] The system delay of the DUT to be tested accessing the memory will also affect the read and write access data bandwidth. The bandwidth data monitored and counted by different system delay conditions can comprehensively reflect the functional boundaries of the DUT to be tested. When the system delay is reduced, the read and write access data bandwidth will increase; when the system delay is increased, the read and write access data bandwidth will decrease. System bandwidth statistics need to meet the needs of application scenarios, while ensuring that when multiple modules are working at the same time, the read and write requests of other modules occupy the system path, blocking the transmission of the request response of the DUT to be tested, increasing the system delay, and thus reducing the bandwidth of the DUT to be tested accessing the memory.
[0078] The bandwidth monitoring of the test platform can be used as a part of the DUT. The DUT is designed with a bandwidth monitoring module code RTL. The read and write request response signals of the memory read and write access bus interface are monitored and counted inside the DUT, and the statistical results are stored in the status register of the bandwidth monitoring module. The test case can use the register model to read the value of the status register and analyze the bandwidth performance data through the script. This data is compared with the bandwidth monitoring statistics of the test platform to verify the correctness of the bandwidth monitoring module function of the DUT. During the chip testing phase, the software driver can actually test the bandwidth performance data through the bandwidth monitoring module, and can also analyze the real delay of the system.
[0079] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present invention, all of which belong to the scope of protection of the present invention.
Claims
1. A general accurate performance verification method, characterized in that: The steps include: Classify the signal interfaces of the DUT in the test platform according to different functional types; Connecting each of the signal interfaces belonging to different functional categories with the corresponding universal verification component UVC; Integrate all common verification components UVC into the test platform verification environment TB_Env; The signal interface of the design DUT to be tested is divided into a clock reset interface, a register configuration bus interface, a memory read and write access bus interface, and a data bus interface according to the function; the universal verification component UVC includes a clock reset UVC, a register configuration UVC, a ring buffer UVC, and a data bus UVC; The signal interfaces belonging to different functional categories are connected with the corresponding universal verification components UVC, specifically: 1) The clock reset UVC is connected to the clock reset interface of the design under test DUT, including multiple clocks and resets. The frequency of each clock is defined in the environment configuration Cfg verification component of the clock reset UVC, and the frequency variation range can be configured to achieve randomization of the clock frequency; 2) The register configuration UVC is connected to the register configuration bus interface of the design under test DUT to configure the register of the design under test DUT; the register configuration UVC includes the master agent Master Agent and the slave agent Slave Agent, and which agent to use is selected by configuring CFG is_active; 3) The register model is connected to the register configuration UVC to manage and configure the registers of the design under test (DUT); 4) The ring buffer UVC is connected to the memory read-write access bus interface of the design DUT to be tested, and is used to receive the access request of the memory read-write access bus interface of the design DUT to be tested, and return the required data stream to the design DUT to be tested; the ring buffer UVC includes the master agent Master Agent and the slave agent Slave Agent, and which agent to use is selected by configuring CFG is_master_slave; 5) The data bus UVC is connected to the data bus interface of the design under test DUT to receive the serial output data of the design under test DUT; The data bus interface UVC includes the master agent and the slave agent. The CFG is_master_slave is configured to select which agent to use. When the design under test DUT is not implemented, the master agent and the slave agent are used as part of the test platform verification environment to debug whether the verification environment functions correctly. The design under test DUT includes a delay monitoring status register, which is used to count the total delay of the memory read and write access system of the channel of the design under test DUT; Among them, the channel pipex of the design DUT to be tested initiates a read and write data operation request to the memory Memory, and the request is sent from the memory read and write access bus interface of the design DUT to be tested, marked as point A of the system path entrance; the request is transmitted from point A of the system path to the memory Memory from point B of the system path after the system path delay, and the delay is DelayAB; the memory Memory receives the request, processes the request, and after the processing delay, the memory Memory feeds back the response to point C of the system path entrance, and the delay is DelayM; the response is transmitted from point C of the system path to the design DUT to be tested from point D of the system path after the system path delay, and the delay is DelayCD; therefore, the total system delay of the entire memory Memory data read and write operation is Delay=DelayAB+DelayM+DelayCD; The test platform also includes a bandwidth monitoring module, the memory read / write access bus interface of the design DUT to be tested is connected to the bandwidth monitoring module, the bandwidth monitoring module performs performance monitoring on the memory read / write access bus interface of the design DUT to be tested, records the monitoring results into a record file, and forms a performance bandwidth report after script processing and calculation; Among them, the channel pipex of the design DUT to be tested initiates a read and write data operation request to the memory Memory; within a period of time T1, the memory read and write access bus interface issues i read access requests, and each read response data is x Byte in size. Therefore, during the T1 time period, the read access data bandwidth is BW1=x*i Byte; within a period of time T2, the memory read and write access bus interface issues j write access requests, and each write access request data is y Byte in size. When all write responses are returned, the write access data bandwidth during the T2 time period is calculated to be BW2=j*y Byte; the bandwidth monitoring module of the test platform records the time tx when the memory read and write access bus interface issues a read and write access request, the time ty of the response, and the data width W in the file. The script uses these keyword information to organize and count the read and write bandwidth in any time period.
2. A general accurate performance verification method according to claim 1, characterized in that: The test platform verification environment TB_Env also includes three verification components: register model, reference model and scoreboard; Among them, the register model is used to organize and configure the registers in the design under test (DUT); the reference model also generates data flow; the scoreboard is used to check whether the data flow output by the data bus interface is consistent with the data flow output by the reference model.
3. A general accurate performance verification method according to claim 1, characterized in that: The signal interface of the design under test DUT and the corresponding universal verification component UVC are connected by means of virtual interface binding Bind.
4. A general accurate performance verification system, the system is based on the method according to any one of claims 1 to 3, characterized in that: Including the design under test DUT and the test platform verification environment TB_Env; among them, The design DUT to be tested is a multi-channel data DMA design, and its design interface is divided into a clock reset interface, a register configuration bus interface, a memory read-write access bus interface, and a data bus interface according to the functional type; The test platform verification environment TB_Env is used to perform functional verification on the design under test DUT, which includes clock reset UVC, register configuration UVC, ring buffer UVC, data bus UVC, and register model, reference model and scoreboard verification components; The design under test DUT includes a delay monitoring status register, which is used to count the total delay of the memory read and write access system of the channel of the design under test DUT; The test platform also includes a bandwidth monitoring module. The memory read and write access bus interface of the DUT to be tested is connected to the bandwidth monitoring module. The bandwidth monitoring module performs performance monitoring on the memory read and write access bus interface of the DUT to be tested, records the monitoring results into a record file, and forms a performance bandwidth report after script processing and calculation.
Citation Information
Patent Citations
Chip verification device of nonstandard bus protocol for simulation
CN115345122A
SOC chip performance verification method, system and device and storage medium
CN117610494A