Function verification system and verification method of synchronous static random access memory
By constructing a functional verification system based on a synchronous static random access memory, the problem of the lack of hierarchical design in the verification structure was solved, and an efficient and easy-to-maintain verification method was achieved, which simplified the workload and improved the verification efficiency.
Patent Information
- Application Number
- CN202510744524.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-04
- Publication Date
- 2025-10-31
AI Technical Summary
Existing functional verification methods for synchronous static random access memory cannot meet the verification requirements of the current design. The verification structure lacks hierarchical design and has poor engineering reusability.
A functional verification system for synchronous static random access memory is provided, including a top-level module, a macro definition module, a test case module, and a verification environment module. Data communication is achieved through a virtual interface, configuration parameters are configurable, test stimuli for different operating modes are generated, and data transmission and comparison are achieved through transaction-level modeling.
It simplifies the verification workload, improves verification efficiency, enables accurate identification of synchronous static random access memory in different modes, and is easy to maintain and reuse.
Smart Images
Figure CN120874705A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of chip technology, and in particular relates to a functional verification system and verification method for synchronous static random access memory. Background Technology
[0002] With the rapid development of integrated circuits, chips are becoming more complex in function, more SOC-based in design, more collaborative in software and hardware, and more integrated in systems. Traditional targeted verification can no longer meet the verification needs of very large-scale integrated circuits, and the workload and difficulty of chip verification are increasing.
[0003] Static Random Access Memory (SRAM) uses transistors to store data. It is fast and is generally used as a high-speed cache between the CPU and main memory. There are two types: one is a cache memory fixed on the motherboard, and the other is a cache memory that is inserted into a card slot for expansion.
[0004] SRAM can be classified in many ways. Based on the presence or absence of an input clock, it can be divided into synchronous SRAM and asynchronous SRAM. In synchronous SRAM, each input signal is sampled on the rising edge of the clock, and the circuit is controlled based on the sampled signal. Asynchronous SRAM initiates operations on the circuit based on changes in certain input signals. Although asynchronous SRAM has low power consumption, it is slower and more complex to control. Synchronous SRAM is more suitable for a System-on-a-Chip (SoC) that uses a clock for synchronization. These devices are typically used as data buffers (temporary storage) and can be randomly accessed through their high-speed, single data rate (SDR) interface. They can be selected between linear and interleaved burst modes and pass-through (FT) or pipelined (PL) architectures. Synchronous burst SRAM is well-suited for dominant read or write operations.
[0005] However, the function of synchronous static random access memory (SRAM) is relatively simple. But the design of synchronous SRAM will vary depending on the required capacity and speed. The conventional method of verifying the function of synchronous static random access memory is to write a simple testbench to verify the correctness of the logic timing in a simulated way. This method cannot meet the verification requirements of the current design. The verification structure lacks hierarchical design and the reusability of the project verification process is poor. Summary of the Invention
[0006] This application provides a functional verification system and method for synchronous static random access memory, which can solve the technical problem mentioned in the background art that conventional functional verification methods for synchronous static random access memory cannot meet the verification requirements of the current design and lack hierarchical design in the verification structure.
[0007] In a first aspect, embodiments of this application provide a functional verification system for a synchronous static random access memory, comprising:
[0008] The top-level module is used to enable data communication between the unit under test (UDT) and the system via a virtual interface.
[0009] The macro definition module is used to configure the address bit width and data bit width of the synchronous static random access memory, so as to make the parameters configurable;
[0010] The test case module is used to generate test stimuli for different operating modes of the synchronous static random access memory, so as to complete at least one of directional testing, random testing, boundary testing and anomaly testing.
[0011] The verification environment module is used to encapsulate each first component and realize data transmission between each first component through transaction-level modeling; the types of the first components include at least a proxy, a reference model, and a comparator.
[0012] In one example of the first aspect, the described proxy includes an active proxy and a passive proxy:
[0013] The active agent includes at least one of a sequence generator, a driver, a first monitor, and a functional coverage collection module;
[0014] The passive agent includes a second monitor for converting the actual data output by the unit under test into transaction-level data packets and sending them to the comparator.
[0015] In one example of the first aspect, the sequence generator is configured to connect to the driver;
[0016] The driver is used to drive the test stimulus to the virtual interface and send the test stimulus data to the reference model to generate the desired data.
[0017] In one example of the first aspect, the first monitor is used to monitor signals on the virtual interface and send the monitored signals to the functional coverage collection module or the comparator.
[0018] In one example of the first aspect, the reference model is configured to mimic the behavior of the unit under test in order to generate the desired data and send it to the comparator;
[0019] The comparator is configured to compare the expected data generated by the reference model with the actual data received by the second monitor, obtain a comparison result, and determine the correctness of the function of the synchronous static random access memory based on the comparison result.
[0020] In one example of the first aspect, the verification environment module implements data transmission between the agent, the reference model, and the comparator through a transaction-level modeled first-in-first-out queue.
[0021] Secondly, embodiments of this application provide a method for verifying the functionality of a synchronous static random access memory, comprising the following steps:
[0022] Configure the address and data bit widths of the SRAM using the macro definition module;
[0023] The test case module generates test stimuli for different operating modes of the synchronous static random access memory.
[0024] The test stimulus is driven to the cell under test of the synchronous static random access memory by an active agent to generate the desired data.
[0025] The actual data output by the unit under test is monitored by a passive agent.
[0026] The correctness of the function of the synchronous static random access memory is determined by comparing the expected data with the actual data using a comparator.
[0027] In one example of the second aspect, monitoring the actual data output by the unit under test via a passive agent includes:
[0028] The passive agent monitors the actual data output by the unit under test, converts the actual data into transaction-level data packets, and sends them to the comparator.
[0029] In one example of the second aspect, the step of generating the desired data includes:
[0030] The reference model is used to mimic the behavior of the unit under test in order to generate the desired data for the unit under test.
[0031] In one example of the second aspect, the method further includes:
[0032] The functional coverage collection module collects test coverage data and adjusts test stimuli based on the coverage results.
[0033] The beneficial effects of this application are as follows: The synchronous static random access memory (SRAM) functional verification system provided by this application is easy to maintain, reusable, and highly efficient. Relevant personnel only need to configure the address and data bit widths of the SRAM in the macro definition module to reuse the functional verification system for SRAM verification work, without needing to rebuild the verification environment. Furthermore, the system's comparator accurately judges the read and write operations of the SRAM in different modes, helping relevant personnel directly determine the correctness of SRAM read and write operations, simplifying their workload and improving verification efficiency. Attached Figure Description
[0034] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0035] Figure 1 This is a structural system block diagram of a synchronous static random access memory functional verification system provided in an embodiment of this application;
[0036] Figure 2 This is a schematic flowchart of a method for verifying the functionality of a synchronous static random access memory provided in an embodiment of this application;
[0037] Figure 3 This is a structural system block diagram of another embodiment of the synchronous static random access memory functional verification system provided in this application;
[0038] Figure 4 A tree structure diagram of the functional verification system for the synchronous static random access memory of this application;
[0039] Figure 5 This is a timing diagram of the synchronous static random access memory in pass-through (FT) mode according to this application;
[0040] Figure 6 This is a timing diagram of the synchronous static random access memory in pipelined (PP) mode according to this application;
[0041] in, Figure 5 and Figure 6 middle:
[0042] Clock indicates the clock signal;
[0043] Addr represents the address line, which is used to specify the location of the SRAM memory cell to be accessed; where A, B, C, and D on Addr represent different bits on the address line, from the least significant bit to the most significant bit.
[0044] R / W stands for Read / Write Control, used to indicate whether the current operation is a read operation or a write operation;
[0045] Ctrl Signals refers to control signals, which are auxiliary signals used to control SRAM operations and may include chip select signals, output enable signals, etc.
[0046] DQ stands for data line, used to transfer data between SRAM and external circuitry; in a write operation, data is written to SRAM via the DQ line; in a read operation, data is read from SRAM via the DQ line.
[0047] The signals on DQ indicate writing data (D) or reading data (Q);
[0048] D(A): can represent the data written to the memory unit corresponding to address A;
[0049] QQ(B), QQ(B+1): QQ can represent the data read, while B and B+1 may represent the data read in two consecutive clock cycles (or adjacent memory cells);
[0050] D(C): can represent the data written to the memory unit corresponding to address C;
[0051] Q(D): can represent the data read from the memory unit corresponding to address D. Detailed Implementation
[0052] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0053] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0054] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0055] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0056] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0057] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0058] Firstly, this application provides a functional verification system for a synchronous static random access memory (SRAM). This system includes a top-level module 10, a macro definition module 20, a test case module 30, and a verification environment module 40. The SRAM functional verification system provided in this application is easy to maintain, reusable, and highly efficient. Relevant personnel only need to configure the address and data bit widths of the SRAM in the macro definition module to reuse the system for SRAM verification work. There is no need to rebuild the verification environment. Furthermore, the system's comparator accurately judges the read and write operations of the SRAM in different modes, helping personnel directly determine the correctness of SRAM read and write operations, simplifying their workload and improving verification efficiency.
[0059] The functional verification system of this application embodiment includes:
[0060] Top-level module 10 is used to realize data communication between the SRAM cell under test (DUT) and the verification platform through a virtual interface;
[0061] For example, the top-level module 10 represents the top-level file of the functional verification system, and realizes data communication between the unit under test (DUT) and the verification platform through the virtual interface.
[0062] The macro definition module 20 is used to configure the address bit width and data bit width of the synchronous static random access memory, so as to make the parameters configurable;
[0063] For example, the macro definition module 20 can reuse the function to verify the synchronous SRAM by configuring the address width and data width of the synchronous SRAM, without having to rebuild the verification environment, thus realizing the configurability of the synchronous SRAM parameters.
[0064] The test case module 30 is used to generate test stimuli for different operating modes of the synchronous static random access memory, so as to complete at least one of directional testing, random testing, boundary testing and anomaly testing.
[0065] For example, the test case module 30 represents the test case layer test, which creates different test stimuli for different operations supported by the synchronous SRAM to complete targeted testing, random testing, boundary testing and exception testing of different functions of the SRAM.
[0066] The verification environment module 40 is used to encapsulate each first component and realize data transmission between each first component through transaction-level modeling (TLM); the types of the first components include at least a proxy, a reference model, and a comparator.
[0067] For example, this embodiment constructs the functional verification system using System Verilog and the UVM (Universal VerificationMethology Manual) library.
[0068] For example, the verification environment module 40 represents the environment layer of the verification platform, which internally encapsulates the first components required for verification synchronization SRAM, including an agent, a reference model, and a scoreboard.
[0069] In some embodiments, the agent includes an active agent and a passive agent:
[0070] The passive agent contains only a second monitor, which is used to convert the actual data output by the unit under test (DUT) into transaction-level data packets and send them to the comparator.
[0071] The active agent includes at least one of a sequencer, a driver, a first monitor, and a functional coverage collection module;
[0072] The sequencer is configured to connect to the driver.
[0073] The driver is used to drive the test stimuli generated by the test case module 30 to the virtual interface, and send the data of the test stimuli to the reference model, so that the reference model generates the expected data.
[0074] The reference model is used to mimic the behavior of the unit under test (DUT), perform the same functions as the DUT, and send the mimicry results as expected data to the comparator for comparison with the actual results.
[0075] It is used to simulate the behavior of the unit under test (DUT), while performing the same functions as the module, and sending the results as expected data to the comparator for comparison with the actual results.
[0076] The first monitor-1 is used to monitor the signals on the virtual interface and send the monitored signals to the function coverage monitor module or the comparator.
[0077] The function coverage monitor module is used to collect signals from the first monitor-1 in the active agent and collect function coverage based on the combination of these signals.
[0078] The scoreboard is configured to compare the expected data generated by the reference mode with the actual data received by the monitor, obtain a comparison result, and determine the correctness of the function of the synchronous static random access memory based on the comparison result.
[0079] Secondly, based on the functional verification system for synchronous static random access memory provided in the first aspect, this application also provides a functional verification method for synchronous static random access memory, including the following steps:
[0080] Step S1: Configure the address width and data width of the synchronous static random access memory through the macro definition module;
[0081] Step S2: Generate test stimuli for different operating modes of the synchronous static random access memory through the test case module;
[0082] Step S3: Drive the test stimulus to the cell under test (DUT) of the synchronous static random access memory through the active agent to generate the desired data;
[0083] For example, the behavior of the unit under test (DUT) can be mimicked using the reference model to generate the desired data for the DUT.
[0084] Step S4: Monitor the actual data output by the unit under test (DUT) through a passive agent;
[0085] For example, after obtaining the actual data, the actual data will be converted into a transaction-level data packet and sent to the comparator;
[0086] Step S5: Compare the expected data with the actual data using a comparator to determine the correctness of the function of the synchronous static random access memory.
[0087] In other embodiments, reference is made to... Figure 3 ( Figure 3 The blue arrows indicate that the components communicate with each other by transmitting data packets through TLM, and the red arrows indicate that the functional verification system and the unit under test (DUT) communicate with each other through the interface module. The functional verification system of the synchronous static random access memory described in this embodiment can represent a verification platform, which includes a top-level file top layer (corresponding to top-level module 10), a macro definition module 20, a test case layer (corresponding to test case module 30), and a verification environment layer (corresponding to verification environment module 40).
[0088] In its specific implementation, the structure of the functional verification system (i.e., the verification platform) is as follows: Figure 4 As shown:
[0089] The top-level file (corresponding to top-level module 10) enables data communication between the unit under test (DUT) and the verification platform through a virtual interface. It can also generate waveforms in VCD (Value Change Dump), VPD (Value Plus Delay), or FSDB (Fast Signal Database) formats through macro definitions, allowing verification engineers to select the required waveform format according to their needs.
[0090] Test case module 30 (test case layer) runs the simulation script; simply execute the test start command in the terminal. The synchronous static random access memory (SRAM) operates in modes including basic write / read operations, sleep mode, and suspend mode. It can also be selected between linear and interleaved burst modes, as well as pass-through (FT) or pipelined (PL) architectures. Timing diagrams for different architectures are shown below. Figure 5 and Figure 6 As shown, different test stimuli are created for different operations supported by the synchronous static random access memory to complete directional testing, random testing, boundary testing, and anomaly testing. Error information is viewed through the generated log files, and the corresponding waveforms are then opened to locate the specific problem.
[0091] The verification environment module 40 (verification environment layer) is used to instantiate agents (active agent and passive agent), reference models, and scoreboards. The components communicate with each other through transaction-level modeling (TLM) to transmit data packets.
[0092] The active agent communicates with the reference model via a Transaction-Level Modeling First-In-First-Out Queue (TLM FIFO) to send data packets to the reference model to generate the expected data. The passive agent communicates with the comparator via a TLM FIFO to send the actual data generated by the DUT to the comparator. The expected data generated by the reference model is sent to the comparator via the TLM FIFO between the reference model and the comparator. The comparator compares the received actual data with the expected data. If the results match, the functional verification is passed; otherwise, relevant error information is printed in the log file so that relevant personnel can quickly find the problem and locate the vulnerability / bug by combining it with waveform analysis.
[0093] For example, the active agent encapsulates first components such as a generator, a driver, a first monitor, and a function coverage collection module. The sequence generator is connected to the driver. The driver is responsible for driving the transaction-level data packets (items) related to the test stimuli obtained from the sequence generator to the virtual interface. These transaction-level data packets are sent out through the first analysis port of the functional verification system in this embodiment. The virtual interface receives the signal and sends it to the unit under test (DUT). Simultaneously, the transaction-level modeling FIFO queue between the active agent and the reference model also receives these signals through the second analysis export port of the functional verification system in this embodiment. The first monitor (monitor-1) monitors the signals on the virtual interface. The first analysis port defined by the first monitor (monitor-1) is connected to the second analysis export port of the function coverage collection module, and is used to send the signals monitored by the first monitor to the function coverage collection module. The function coverage collection module... The monitor collects signals monitored by the first monitor-1 through the second analysis port analysisexport, and completes the collection of functional coverage based on the combination of these signals.
[0094] In some embodiments, the functional coverage collection module statistically analyzes test coverage and adjusts test stimuli based on the coverage results. This allows for adaptive adjustments to subsequent comparison results, making the final verification results more accurate and reliable.
[0095] In this embodiment, the passive agent only includes the second monitor component. It sends out the data packets monitored on the virtual interface through the first analysis port built into UVM. The transaction-level modeling first-in-first-out queue between the passive agent and the comparator obtains these signals through the second analysis port built into UVM.
[0096] For example, the reference model connects the active agent and the reference model via a data receiving port (blocking get port) to a transaction-level modeling first-in-first-out queue to receive transaction-level data packets related to the test stimulus sent by the driver as input to the reference model, thereby generating the desired data to be sent to the comparator.
[0097] The comparator defines two data receiving ports: one is the blocking get port, which connects the front head reference model and the comparator to the transaction-level modeling FIFO queue to obtain the expected data; the other is the blocking get export port, which connects the passive agent and the comparator to the transaction-level modeling FIFO queue to obtain the actual data. Finally, the expected data and the actual data are compared. If the results match, the functional verification is passed; otherwise, relevant error information is printed in the log file to help relevant personnel quickly find the problem and locate bugs and vulnerabilities by combining waveform analysis.
[0098] Furthermore, since the inputs and outputs of the DUT are low-level signals (such as clock, address lines, and data lines), directly comparing signal waveforms requires processing a large number of timing details (such as clock edge alignment and signal settling time). Therefore, in some embodiments, the actual data and the expected data are converted into transaction-level data packets and sent to the comparator separately. This can abstract the signal interaction and improve verification efficiency. At the same time, it can shield the underlying timing differences, and the comparator only needs to focus on the data content rather than the transmission timing (How), simplifying the comparison logic.
[0099] In addition, the transformed transaction-level data packets can be cached in a FIFO to resolve the speed mismatch problem between components (for example, the data collected by the first / second monitor is faster than the comparison operation of the comparator).
[0100] The functional verification method for synchronous static random access memory (SRAM) provided in this application embodiment allows relevant personnel to reuse the functional verification system for SRAM verification work simply by configuring the address and data bit widths of the SRAM in the macro definition module of the SRAM. This eliminates the need to rebuild the verification environment. Furthermore, the system's comparator accurately judges the read and write operations of the SRAM in different modes, helping relevant personnel directly determine the correctness of SRAM read and write operations, simplifying their workload and improving verification efficiency.
[0101] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.
[0102] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.
[0103] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium.
[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0105] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0106] In the embodiments provided in this application, it should be understood that the disclosed systems / terminal devices and methods can be implemented in other ways. For example, the system / terminal device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0107] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A functional verification system for a synchronous static random access memory, characterized in that, The system includes: The top-level module is used to enable data communication between the unit under test (UDT) and the system via a virtual interface. The macro definition module is used to configure the address bit width and data bit width of the synchronous static random access memory, so as to make the parameters configurable; The test case module is used to generate test stimuli for different operating modes of the synchronous static random access memory, so as to complete at least one of directional testing, random testing, boundary testing and anomaly testing. The verification environment module is used to encapsulate each first component and realize data transmission between each first component through transaction-level modeling; the types of the first components include at least a proxy, a reference model, and a comparator.
2. The system as described in claim 1, characterized in that, The agent includes active agents and passive agents: The active agent includes at least one of a sequence generator, a driver, a first monitor, and a functional coverage collection module; The passive agent includes a second monitor for converting the actual data output by the unit under test into transaction-level data packets and sending them to the comparator.
3. The system as described in claim 2, characterized in that, The sequence generator is configured to connect to the driver; The driver is used to drive the test stimulus to the virtual interface and send the test stimulus data to the reference model to generate the desired data.
4. The system as described in claim 2, characterized in that, The first monitor is used to monitor the signals on the virtual interface and send the monitored signals to the functional coverage collection module or the comparator.
5. The system as described in claim 3, characterized in that: The reference model is configured to mimic the behavior of the unit under test in order to generate the desired data and send it to the comparator; The comparator is configured to compare the expected data generated by the reference model with the actual data received by the second monitor, obtain a comparison result, and determine the correctness of the function of the synchronous static random access memory based on the comparison result.
6. The system as described in claim 1, characterized in that, The verification environment module implements data transmission between the agent, the reference model, and the comparator through a transaction-level modeling first-in-first-out queue.
7. A method for verifying the functionality of a synchronous static random access memory, characterized in that, Includes the following steps: Configure the address and data bit widths of the synchronous static random access memory using the macro definition module; The test case module generates test stimuli for different operating modes of the synchronous static random access memory. The test stimulus is driven to the cell under test of the synchronous static random access memory by an active agent to generate the desired data. The actual data output by the unit under test is monitored by a passive agent. The correctness of the function of the synchronous static random access memory is determined by comparing the expected data with the actual data using a comparator.
8. The method as described in claim 7, characterized in that, The monitoring of the actual data output by the unit under test through a passive agent includes: The passive agent monitors the actual data output by the unit under test, converts the actual data into transaction-level data packets, and sends them to the comparator.
9. The method as described in claim 7 or 8, characterized in that, The steps for generating the desired data include: The reference model is used to mimic the behavior of the unit under test in order to generate the desired data for the unit under test.
10. The method as described in claim 7 or 8, characterized in that, The method further includes: The functional coverage collection module collects test coverage data and adjusts test stimuli based on the coverage results.