A controllable clock reset signal generation module and method based on SV and UVM
By using a controllable clock reset signal generation module based on System Verilog and UVM, the problem of the inflexible editing of clock reset signals in traditional verification methods is solved. This enables flexible configuration of multiple sets of clock reset signals and efficient operation of the verification system, and is suitable for IP module and system-on-a-chip verification.
Patent Information
- Application Number
- CN202310067067.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-01-12
- Publication Date
- 2026-03-17
- Estimated Expiration
- 2043-01-12
AI Technical Summary
In traditional verification methods, the clock reset signal cannot be flexibly edited, resulting in low verification efficiency. It cannot be temporarily modified during simulation, affecting simulation speed and the flexibility of the verification system.
A controllable clock reset signal generation module, written in System Verilog, is built using the UVM verification methodology to create a VIP environment. The module includes an RCC interface, an RCC configuration class, an RCC environment top-level layer, a sequence library, and an RCC transaction class, supporting flexible configuration and adjustment of multiple sets of clock reset signals.
It improves the flexibility and efficiency of the verification system, supports independent configuration of multiple sets of clock reset signals, is suitable for IP module and system-on-a-chip verification, reduces errors caused by clock signal frequency and reset hold time adjustment, and enhances the versatility of the verification system.
Smart Images

Figure CN115983168B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of chip testing technology, specifically relating to a controllable clock reset signal generation module based on SV and UVM, a timer verification platform based on UVM, and a method for generating an editable clock reset signal in the timer verification platform. Background Technology
[0002] Currently, with the development of integrated circuit manufacturing technology, the integration level of chips is constantly increasing, and the number and functionality of the integrated intellectual property (IP) modules are also growing. Simultaneously, due to advancements in process technology and decreasing market tolerance for product defects, the losses from each tape-out failure are becoming increasingly significant. Therefore, more and more companies are emphasizing pre-tape-out verification. In most integrated circuit design companies today, the manpower and time required for chip verification account for as much as 70% of the entire chip development process.
[0003] Traditional verification methodologies are based on Verilog-based verification platforms, which suffer from poor reusability and cannot cover all functionalities under test, significantly reducing verification efficiency and increasing chip development time and costs. To address this, engineers have developed and widely adopted a complete source code library-based verification platform development framework, namely, Universal Verification Methodology (UVM), using the System Verilog verification language. Verification engineers can use the UVM source code library to build functional verification environments that meet the design under test. Verification platforms built using the UVM methodology can achieve functions such as random test stimulus generation, automatic result comparison, and high functional coverage collection, and have become the mainstream method in the chip verification field.
[0004] In the chip verification process, to improve the convenience of verification work and the reusability of the verification environment, EDA vendors have generally introduced Verification IP (VIP) systems. A VIP is a predefined functional block that can be inserted into the verification environment to accelerate its development, thereby improving work efficiency.
[0005] However, in existing verification schemes for various test platforms, clock reset signals are generally generated using `initial` and `always` statements in the top-level test file. During simulation, the value of the clock reset signal cannot usually be changed temporarily; arbitrary changes are not only cumbersome but also prone to causing test errors. This leads to two problems in existing verification systems with different frameworks: firstly, verifying the clock frequencies of different chip functions often requires modifying the top-level test file code, necessitating recompilation of the top-level file, which impacts simulation speed; secondly, clock and reset information generated by traditional Verilog cannot be reused, requiring manual modification of signal values in the top-level test file when verifying different modules, which becomes tedious when there are many clock reset signals. Summary of the Invention
[0006] To address the problems of traditional verification environments, such as the inability to flexibly edit the value of the clock reset signal, the need to determine all aspects of the verification scheme before simulation without the possibility of temporary changes, and low testing efficiency, this invention provides a controllable clock reset signal generation module based on SV and UVM, a timer verification platform based on UVM, and a method for generating an editable clock reset signal in the timer verification platform.
[0007] This invention is achieved using the following technical solution:
[0008] A controllable clock reset signal generation module based on SV and UVM is disclosed. It is written in SV language and built using the source code library provided by UVM. This controllable clock reset signal generation module is used to provide the required clock reset signal as an excitation signal to the module under test in a test platform. Specifically, the module architecture of the controllable clock reset (rcc, resetclock control) signal generation module provided by this invention includes: an rcc interface, an rcc configuration class, an rcc environment top-level layer, a sequence library, and an rcc transaction class.
[0009] The RCC interface contains N virtual clock group interfaces, each used for communication with the respective modules under test. Each virtual clock group interface declares N clock signals and one reset signal.
[0010] The RCC configuration class defines a variable for the number of clock reset group proxies and N clock group configurations. Each clock group configuration defines the reset signal, reset delay signal, and clock enable signal, and assigns them default values. The clock group configuration is also used to declare handles to virtual interfaces and create RCC transaction class objects.
[0011] The RCC environment top layer declares an RCC virtual interface handle, an RCC configuration handle, and N clock reset group agents. The RCC virtual interface handle contains N virtual clock group interface handles; each virtual clock group interface handle interfaces with one virtual clock group interface in the RCC interface, thus establishing a communication link between the clock reset group agents and the module under test. The RCC configuration handle is used to establish a communication link between the RCC configuration class and each clock reset group agent in the RCC environment top layer, enabling the adjustment of the running state of each clock reset group agent according to the configuration information in the RCC configuration class. Each clock reset group agent declares a clock group configuration handle, a sequencer, and a driver.
[0012] The sequence library is used to call internal sequences to ultimately form corresponding test cases based on specific clock reset signal configuration requirements. The sequence library contains four functional sequences for controlling the clock signal and reset release signal in the excitation signals: clock frequency configuration sequence, automatic reset release sequence, reset-only sequence, and release-only sequence. The clock frequency configuration sequence is used to modulate the clock frequency. The automatic reset release sequence implements automatic reset according to the default reset hold time. The reset-only and release-only sequences are used to allow for autonomous adjustment of the reset hold time.
[0013] The RCC transaction class creates N CNK transaction classes and encapsulates the corresponding clock reset attribute configurations. The RCC transaction class includes N clock enable signals, reset request signals, and reset release signals. The CNK transaction classes provide default configurations for information such as clock delay, duty cycle, and clock frequency.
[0014] As a further improvement of this invention, in the phase established at the top level of the RCC environment, the RCC configuration handle obtains configuration information and the RCC virtual interface handle from outside the top level of the RCC environment; then, the number of clock reset group agents is instantiated according to the value of the clock reset group agent number variable in the obtained RCC configuration class. The controllable clock reset signal generation module can support passing up to N RCC virtual interface handles to the corresponding clock reset group agents according to the project requirements.
[0015] As a further improvement of the present invention, the clock reset group agent instantiates the sequence transmitter and driver in its establishment phase, obtains the corresponding information from the N clock group configurations, and transmits it to the driver. In the clock reset group agent link phase, a TLM mechanism is also used to establish a communication connection between the transaction send port in the sequence transmitter and the transaction receive port in the driver, and to establish a communication connection between the driver's virtual interface handle and the virtual clock group interface handle.
[0016] As a further improvement of this invention, the driver declares a clock group configuration handle, a virtual interface handle, and a clk transaction class handle. The driver obtains configuration information in its established phase, then declares an rcc transaction class handle in its linked phase, assigns the obtained clock-related information to the clk transaction class, assigns the reset signal-related information to the rcc transaction class, and finally transmits the drive signals in the transaction sequentially to the module under test through the rcc virtual interface handle and the rcc interface.
[0017] As a further improvement to this invention, the default configuration information for each clk transaction class in the rcc transaction class includes a clock delay of 0, a duty cycle of 50%, and a clock frequency of 6MHz. Simultaneously, each clk transaction class includes preset clock variable initialization functions and clock cycle generation functions, allowing for adjustments to the clock variables and clock cycle as needed in different projects.
[0018] As a further improvement of the present invention, the clock group configurations created in the rcc configuration class are used to configure the clock reset group agents respectively; at the same time, the rcc configuration class also defines a clock reset group agent count variable internally to configure the number of clock reset group agents enabled, and the default value of the clock reset group agent count variable is 1.
[0019] In the reset signal, reset delay signal, and clock enable signal defined in each clock group configuration, the default configuration is low-level reset, reset delay of 213.73μs, and all clock enable signals are disabled. Simultaneously, each clock group configuration internally declares a corresponding RCC virtual interface handle and creates an RCC transaction class object, used to update the top-level clock configuration information to the transaction in a timely manner and pass it to the module under test via the driver.
[0020] As a further improvement to this invention, the sequence library is a System Verilog file. The sequence library contains clock frequency configuration sequences, automatic reset and release sequences, reset-only sequences, and release-only sequences. The usage of these four sequences is as follows:
[0021] (1) The clock frequency configuration sequence is used separately, thereby enabling flexible configuration of the clock signal according to the specific frequency requirements of the module under test in different test items, so as to ensure the functional accuracy of the module.
[0022] (2) The automatic reset release sequence is used alone to achieve the reset signal being pulled low to the default low level and then released after 213.73μs, thus realizing the default automatic reset release function. The automatic reset release sequence is used to verify whether the values of each register of the module under test are normal after reset, so as to meet the verification requirements of the functional module in most automatic reset test tasks.
[0023] (3) Use the reset-only sequence and the release-only sequence together: This allows for flexible control of the reset hold time according to project needs, in verifying projects with non-default reset hold times, or in meeting specific requirements for reset hold time in certain scenarios.
[0024] As a further improvement of this invention, the controllable clock reset signal generation module generates a virtual sequence and determines the corresponding test cases based on a certain scenario requirement of the project. The virtual sequence calls the corresponding sequence in the sequence library and calls the pre-created RCC transaction class in the clock frequency configuration sequence. The sequence sender sends the generated virtual sequence to the driver in the corresponding clock reset group agent for execution.
[0025] This invention also includes a UVM-based timer verification platform, which combines the aforementioned architecture of a controllable clock reset signal generation module based on SV and UVM, and is used to perform functional verification of timers. The timer verification platform includes a test platform consisting of hardware and interface components, and a test layer consisting of software components.
[0026] The test platform includes an RCC interface for connecting to the module under test (DUT); the RCC interface contains a corresponding virtual clock group interface 0. After virtual clock group interface 0 connects to virtual clock group interface handle 0 in the RCC virtual interface handle of the test layer, it supports bidirectional communication between the DUT and the test layer; it also enables the RCC interface signals to be ultimately transmitted to the driver via the config_db mechanism in UVM, and then uses run_test() to start the test layer.
[0027] The test layer instantiates an RCC configuration class and an RCC environment top-level layer. The RCC configuration class configures the number of clock reset group agents and clock reset information in the timer verification platform, and then passes it to the RCC configuration handle in the RCC environment top-level layer via `config_db`. The RCC environment top-level layer obtains the configuration information from the RCC configuration class and then passes the configuration information to the driver. The test layer instantiates the RCC configuration class and the RCC environment top-level layer, and generates a virtual sequence corresponding to the test case. The virtual sequence applies a clock frequency configuration sequence and an automatic reset release sequence, and the clock frequency configuration sequence calls a pre-created RCC transaction class. The sequence sender sends the generated virtual sequence to the driver; after receiving the configuration information and the virtual sequence, the driver sends a drive signal containing a clock signal of the corresponding clock frequency and a reset signal of the corresponding reset hold time to the module under test as the excitation signal for the module under test.
[0028] This invention also includes a method for generating an editable clock reset signal in a timer verification platform. This method is used in the aforementioned UVM-based timer verification platform to adjust the default clock of the timer and achieve automatic reset release by generating a clock signal and a reset signal. The method for generating the clock reset signal includes the following steps:
[0029] S1: Analyze the operating clock of the module under test to determine that it includes the external clock extclk, the APB clock pclk, and an APB reset prst_n; and by default, the pclk frequency is 6MHz and the extclk frequency is 32kHz.
[0030] S2: Instantiate the module under test and the RCC interface in the test platform, and connect the gclk[0], gclk[1] and reset signals of the virtual clock group interface 0 of the RCC interface to the pclk, extclk and prst_n of the module under test respectively; then pass them to the virtual clock group interface handle 0 of the RCC virtual interface handle in the top layer of the RCC environment through the config_db mechanism. After receiving the information in the virtual clock group interface 0, the virtual clock group interface handle 0 finally passes it to the driver.
[0031] S3: Based on the default clock signal frequency of the module under test, set the number of clock reset group agents to 1 in the rcc configuration class in the test layer, thereby opening clock group configuration 0. In clock group configuration 0, set the default clock signal frequencies of gclk[0] and gclk[1] to 6MHZ and 32KHZ respectively.
[0032] S4: Determine whether the default clock reset configuration of the module under test needs to be changed during the simulation process, and whether the reset signal should be automatically released, based on the actual scenario requirements.
[0033] (1) If you need to change the default configuration, execute steps S5 to S9.
[0034] (2) If the default configuration does not need to be changed, proceed to steps S10 to S12.
[0035] S5: Based on the specific application scenario requirements of the module under test, the following is determined: the APB clock pclk is 3MHz, the external clock extclk is 6kHz, and automatic release during the simulation process is required.
[0036] S6: Using the sequence library, create a clock frequency configuration sequence and an auto-reset release sequence in the virtual sequence. The clock frequency configuration sequence creates an RCC transaction class, defining the reset request, reset release, and clock enable signals, and then assigns the configuration values to the CLUCK transaction class; in the configuration information, pclk is 3kHz and extclk is 6kHz. The auto-reset release sequence inherits from the clock frequency configuration sequence, internally setting both the reset request and reset release signals to 1.
[0037] S7: Write the corresponding test cases in the test layer, and finally use the default_sequence method to attach the virtual sequence to the sequence sender.
[0038] S8: After starting the test platform via run_test(), the sequence sender receives information about the RCC transaction class in the virtual sequence and passes it to the driver.
[0039] S9: After receiving the RCC transaction information and performing the corresponding data processing, the driver sends the gclk[0], gclk[1] and reset signals to the module under test through the virtual clock group interface 0. The module under test works normally after receiving the signals.
[0040] S10: Write the corresponding test cases in the test layer, and finally use the default_sequence method to attach the virtual sequence to the sequence sender.
[0041] S11: After successfully starting the test platform via run_test(), the signals set in the rcc configuration class are passed to the rcc configuration handle. After receiving the set signals, the rcc configuration handle passes them to the clock group configuration handle 0. Then, the clock group configuration handle 0 passes the obtained gclk[0] and gclk[1] signals and reset signal to the driver.
[0042] S12: After receiving the information in the clock group configuration handle 0 and performing the corresponding data processing, the driver finally sends the gclk[0], gclk[1] and reset signals to the module under test through the virtual clock group interface 0. The module under test works normally after receiving the signals.
[0043] The technical solution provided by this invention has the following beneficial effects:
[0044] 1. This invention is written in System Verilog and uses the most mainstream UVM verification methodology to build a VIP environment. Compared with the traditional method of generating clock reset signals using Verilog, it has strong reusability. This VIP is not limited to IP module-level verification platforms, but can also be reused in system-on-a-chip verification platforms. This VIP can be integrated into any UVM environment and can be configured with multiple sets of clock reset signals, making it more convenient to use in some complex IP and system-on-a-chip applications.
[0045] 2. The clock generated by this VIP is independent and multiple clocks can be configured simultaneously. When inputting different frequency clocks to the module under test, it is only necessary to configure them in the RCC configuration sequence without recompiling the top-level module. Therefore, it can improve the flexibility of the verification system and improve the efficiency of the verification system. At the same time, it can also effectively suppress errors caused by the adjustment of clock signal frequency and reset hold time in the verification process.
[0046] 3. The controllable clock reset signal generation module and method provided by this invention, after the clock reset signal is generated by calling the clock reset verification IP, allows the value of the clock reset signal to be changed at any time during simulation through the sequence mechanism in UVM. Compared with top-level modules written in Verilog, it can more flexibly and comprehensively simulate some special application scenarios; further improving the versatility of the verification system for different tasks and objects. Attached Figure Description
[0047] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:
[0048] Figure 1 This is a module architecture diagram of a controllable clock reset signal generation module based on SV and UVM provided in Embodiment 1 of the present invention.
[0049] Figure 2 This is a flowchart illustrating the operation of the controllable clock reset signal generation module in three typical scenarios in Embodiment 1 of the present invention.
[0050] Figure 3 The waveform diagram is shown in the simulation process of the controllable clock reset signal generation module based on SV and UVM in Embodiment 1 of the present invention.
[0051] Figure 4 This is a platform architecture block diagram of a UVM-based timer verification platform provided in Embodiment 2 of the present invention.
[0052] Figure 5This is a flowchart illustrating the steps of generating different types of clock reset signals in the timer verification platform of Embodiment 2 of the present invention. Detailed Implementation
[0053] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0054] Example 1
[0055] This embodiment provides a controllable clock reset signal generation module based on SV and UVM. It is written in SV language and built using the source code library provided by UVM. This type of controllable clock reset signal generation module is used to provide the required clock reset signal as an excitation signal to the module under test in a test platform. Specifically, as shown... Figure 1 As shown, the module architecture of the controllable clock reset (RCC) signal generation module provided in this embodiment includes: an RCC interface, an RCC configuration class, an RCC environment top-level layer, a sequence library, and an RCC transaction class. Specifically, in this case... Figure 1 The architecture of the controllable clock reset signal generation module includes eight independent channels, each capable of independently completing its own signal generation task in different scenarios. The eight channels in this embodiment represent a typical general-purpose architecture that can generally meet the performance requirements of conventional verification platforms. Of course, depending on hardware performance capabilities, different numbers of channels can be configured as needed.
[0056] Specifically, in this embodiment, the RCC interface includes N virtual clock group interfaces, each used for communication with each module under test. The RCC interface declares N clock signals and one reset signal.
[0057] The RCC configuration class defines a variable for the number of clock reset group proxies and N clock group configurations. Each clock group configuration defines the reset signal, reset delay signal, and clock enable signal, and assigns them default values. The clock group configuration is also used to declare handles to virtual interfaces and create RCC transaction class objects.
[0058] The clock group configurations created in the rcc configuration class are used to configure the respective clock reset group agents. At the same time, the rcc configuration class also defines an internal variable for the number of clock reset group agents to configure the number of clock reset group agents to be enabled. The default value of the number of clock reset group agents variable is 1.
[0059] In the reset signal, reset delay signal, and clock enable signal defined in each clock group configuration, the default configuration is low-level reset, reset delay of 213.73μs, and all clock enable signals are disabled. Simultaneously, each clock group configuration internally declares a corresponding RCC virtual interface handle and creates an RCC transaction class object, used to update the top-level clock configuration information to the transaction in a timely manner and pass it to the module under test via the driver.
[0060] The RCC environment top layer declares an RCC virtual interface handle, an RCC configuration handle, and N clock reset group agents. The RCC virtual interface handle contains N virtual clock group interface handles; each virtual clock group interface handle interfaces with one virtual clock group interface in the RCC interface, thus establishing a communication link between the clock reset group agents and the module under test. The RCC configuration handle is used to establish a communication link between the RCC configuration class and each clock reset group agent in the RCC environment top layer, enabling the adjustment of the running state of each clock reset group agent according to the configuration information in the RCC configuration class. Each clock reset group agent declares a clock group configuration handle, a sequencer, and a driver.
[0061] In the phase established at the top level of the RCC environment, the RCC configuration handle obtains configuration information and the RCC virtual interface handle from outside the top level of the RCC environment; then, it instantiates the number of clock reset group agents based on the value of the clock reset group agent number variable in the obtained RCC configuration class. The controllable clock reset signal generation module supports passing up to N RCC virtual interface handles to the corresponding clock reset group agents according to the project requirements.
[0062] The clock reset group agent instantiates the sequence transmitter and driver in its setup phase, obtains the corresponding information from the N clock group configurations, and transmits it to the driver. In the link phase of the clock reset group agent, it also establishes a communication connection between the transaction send port in the sequence transmitter and the transaction receive port in the driver through the TLM mechanism, and establishes a communication connection between the driver's virtual interface handle and the virtual clock group interface handle.
[0063] The driver declares a clock group configuration handle, a virtual interface handle, and a clk transaction class handle. The driver obtains configuration information in its established phase, then declares an rcc transaction class handle in its linked phase, assigns the obtained clock-related information to the clk transaction class, assigns the reset signal-related information to the rcc transaction class, and finally transmits the drive signals from the transaction to the module under test sequentially through the rcc virtual interface handle and the rcc interface.
[0064] The sequence library receives calls from the clock reset group agent to form corresponding test cases. The library contains four functional sequences for controlling the clock and reset release signals in the excitation signals: clock frequency configuration sequence, automatic reset release sequence, reset-only sequence, and release-only sequence. The clock frequency configuration sequence modulates the clock frequency. The automatic reset release sequence performs an automatic reset according to the default reset hold time. The reset-only and release-only sequences allow for autonomous adjustment of the reset hold time.
[0065] The sequence library is a System Verilog file. It contains clock frequency configuration sequences, auto-reset / release sequences, reset-only sequences, and release-only sequences. The usage of these four sequences is as follows:
[0066] (1) The clock frequency configuration sequence is used separately, thereby enabling flexible configuration of the clock signal according to the specific frequency requirements of the module under test in different test items, so as to ensure the functional accuracy of the module.
[0067] (2) The automatic reset release sequence is used alone to achieve the reset signal being pulled low to the default low level and then released after 213.73μs, thus realizing the default automatic reset release function. The automatic reset release sequence is used to verify whether the values of each register of the module under test are normal after reset, so as to meet the verification requirements of the functional module in most automatic reset test tasks.
[0068] (3) Use the reset-only sequence and the release-only sequence together: This allows for flexible control of the reset hold time according to project needs, in verifying projects with non-default reset hold times, or in meeting specific requirements for reset hold time in certain scenarios.
[0069] The RCC transaction class creates N CNK transaction classes and encapsulates the corresponding clock reset attribute configurations. The RCC transaction class includes N clock enable signals, reset request signals, and reset release signals. The CNK transaction classes provide default configurations for information such as clock delay, duty cycle, and clock frequency.
[0070] In the default configuration information of each clk transaction class within the RCC transaction class, the clock delay is set to 0, the duty cycle to 50%, and the clock frequency to 6MHz. Additionally, each clk transaction class includes preset clock variable initialization functions and clock cycle generation functions to allow for adjustments to clock variables and clock cycles as needed in different projects.
[0071] The controllable clock reset signal generation module generates a virtual sequence and determines the corresponding test cases based on a specific project scenario. The virtual sequence calls the corresponding sequence from the sequence library and invokes a pre-created RCC transaction class within the clock frequency configuration sequence. The sequence sender then sends the generated virtual sequence to the driver in the corresponding clock reset group agent for execution.
[0072] The following are provided in this embodiment: Figure 1 The controllable clock reset signal generation module based on SV and UVM can achieve three main types of typical scenarios: First, it enables flexible configuration of specific clock parameters. Second, it implements automatic reset and release, with the reset hold time set to a default value. Third, it enables "manual" reset and release, with the reset hold time arbitrarily configurable as needed.
[0073] The operation process of the verification platform in the three different application scenarios implemented in this embodiment is roughly as follows: Figure 2 As shown, the process includes the following:
[0074] First, the module under test and the RCC interface are instantiated in the test platform. The clock reset signal in the virtual clock group interface of the RCC interface is connected to the clock reset signal of the module under test. Then, the information is passed to the virtual clock group interface handle of the RCC virtual interface handle in the top layer of the RCC environment through the config_db mechanism. After receiving the information in the virtual clock group interface, the virtual clock group interface handle finally passes it to the driver.
[0075] Secondly, based on different scenario requirements, the corresponding sequences in the sequence library are instantiated and started in the virtual sequence. For example, when using the clock frequency configuration sequence and the auto-reset release sequence to verify whether the process of changing clock frequency and other information, as well as the auto-reset and release process, is successfully implemented during simulation, the clock frequency configuration sequence creates an RCC transaction class, defines the reset request, reset release, and clock enable signal (used to enable the number of clocks), and then assigns the configuration values to the CLUCK transaction class. Specifically, the APB clock pclk is configured to be 3kHz, and the external clock extclk is configured to be 6kHz. The auto-reset release sequence inherits from the clock frequency configuration sequence, internally simply setting both the reset request and reset release signals to 1, and finally sending them to the driver through the sequence transmitter. The latter receives the configured transaction class and passes it to the interface of the timer module.
[0076] At this point, part of the code in the virtual sequence is as follows:
[0077] rcc_reset_auto_sequencerst_at_seq;
[0078] rcc_common_sequencercc_seq;
[0079] rcc_seq = new("rcc_seq");
[0080] rcc_seq.h_clock_req = 'h3;
[0081] rcc_seq.h_gclk[0].clk_unit=KHZ;
[0082] rcc_seq.h_gclk[0].clk_freq=3;
[0083] rcc_seq.h_gclk[1].clk_unit=KHZ;
[0084] rcc_seq.h_gclk[1].clk_freq=6;
[0085] #10
[0086] rst_at_seq=new("rst_at_seq");
[0087] rst_at_seq.start(p_sequencer.rcc_sqr);
[0088] rcc_seq.start(p_sequencer.rcc_sqr);
[0089] Next, corresponding test cases are written and inherited from the test layer. Since the external working clock extclk of a certain module under test is 32kHz and the APB clock is 6MHz under normal circumstances, it is only necessary to enable one clock reset group, enable two clocks, and configure the above clock frequencies as default values in the rcc configuration class. Finally, the virtual sequence is mounted to the virtual transmitter and the corresponding sequence is started using the default_sequence method.
[0090] The following is a portion of the code in the RCC configuration class:
[0091] group_num = 1;
[0092] gp_cfg[0].clk_en = 'b11;
[0093] gp_cfg[0].gp_rcc_tr.gclk[0].clk_freq=6;
[0094] gp_cfg[0].gp_rcc_tr.gclk[0].clk_unit=MHZ;
[0095] gp_cfg[0].gp_rcc_tr.gclk[1].clk_unit=KHZ;
[0096] gp_cfg[0].gp_rcc_tr.gclk[1].clk_freq=32;
[0097] Finally, the UVM verification platform is started in the test platform by running_test(). A uvm_test_top instance is generated according to the test case name in the previous step. Then, each component of uvm_test is executed in sequence according to the phase mechanism. The simulation ends after all phases are executed.
[0098] Figure 3 To verify the platform's performance Figure 2 The simulation waveform diagram after the steps are executed shows that, after calling the clock frequency configuration sequence during the simulation, the APB clock pclk will change from 6MHz to 3kHz, the external working clock extclk will change from 32kHz to 6kHz, and the reset signal will be released 213.73μs after being pulled low after calling the automatic reset release sequence. This time is the default configuration in the clock reset verification IP.
[0099] Example 2
[0100] Building upon the scheme in Embodiment 1, this embodiment further provides a UVM-based timer verification platform. This platform combines the architecture design of the controllable clock reset signal generation module based on SV and UVM as described in Embodiment 1, and is used to perform functional verification of the timer. Figure 4 As shown, the timer verification platform includes a test platform consisting of hardware and interface components, and a test layer consisting of software components.
[0101] The test platform includes an RCC interface for connecting to the module under test (DUT); the RCC interface contains a corresponding virtual clock group interface 0. After virtual clock group interface 0 connects to virtual clock group interface handle 0 in the RCC virtual interface handle of the test layer, it supports bidirectional communication between the DUT and the test layer; it also enables the RCC interface signals to be ultimately transmitted to the driver via the config_db mechanism in UVM, and then uses run_test() to start the test layer.
[0102] The test layer instantiates an RCC configuration class and an RCC environment top-level layer. The RCC configuration class configures the number of clock reset group agents and clock reset information in the timer verification platform, and then passes it to the RCC configuration handle in the RCC environment top-level layer via `config_db`. The RCC environment top-level layer obtains the configuration information from the RCC configuration class and then passes the configuration information to the driver. The test layer instantiates the RCC configuration class and the RCC environment top-level layer, and generates a virtual sequence corresponding to the test case. The virtual sequence applies a clock frequency configuration sequence and an automatic reset release sequence, and the clock frequency configuration sequence calls a pre-created RCC transaction class. The sequence sender sends the generated virtual sequence to the driver; after receiving the configuration information and the virtual sequence, the driver sends a drive signal containing a clock signal of the corresponding clock frequency and a reset signal of the corresponding reset hold time to the module under test as the excitation signal for the module under test.
[0103] In the UVM-based timer verification platform provided in this embodiment, the default clock of the timer is adjusted and automatic reset and release are achieved through the generated clock signal and reset signal. Figure 5 As shown, the method for generating the clock reset signal includes the following steps:
[0104] S1: Analyze the operating clock of the timer module to determine that it includes the external clock extclk, the APB clock pclk, and an APB reset prst_n; and by default, the pclk frequency is 6MHz and the extclk frequency is 32kHz.
[0105] S2: Instantiate the timer module and the RCC interface in the test platform, and connect the gclk[0], gclk[1] and reset signals of the virtual clock group interface 0 of the RCC interface to the pclk, extclk and prst_n of the timer module respectively; then pass them to the virtual clock group interface handle 0 of the RCC virtual interface handle in the top layer of the RCC environment through the config_db mechanism. After receiving the information in the virtual clock group interface 0, the virtual clock group interface handle 0 finally passes it to the driver.
[0106] S3: Based on the default clock signal frequency of the timer module, set the number of clock reset group agents to 1 in the rcc configuration class in the test layer, thereby opening clock group configuration 0. In clock group configuration 0, set the default clock signal frequencies of gclk[0] and gclk[1] to 6MHZ and 32KHZ respectively.
[0107] S4: Determine whether the default clock reset configuration of the timer module needs to be changed during simulation and whether the reset signal should be automatically released based on the actual scenario requirements:
[0108] (1) If you need to change the default configuration, execute steps S5 to S9.
[0109] (2) If the default configuration does not need to be changed, proceed to steps S10 to S12.
[0110] S5: Based on the specific application requirements of the timer module, the following is determined: the APB clock pclk is 3MHz, the external clock extclk is 6kHz, and automatic release during the simulation process is required.
[0111] S6: Using the sequence library, create a clock frequency configuration sequence and an auto-reset release sequence in the virtual sequence. The clock frequency configuration sequence creates an RCC transaction class, defining the reset request, reset release, and clock enable signals, and then assigns the configuration values to the CLUCK transaction class; in the configuration information, pclk is 3kHz and extclk is 6kHz. The auto-reset release sequence inherits from the clock frequency configuration sequence, internally setting both the reset request and reset release signals to 1.
[0112] S7: Write the corresponding test cases in the test layer, and finally use the default_sequence method to attach the virtual sequence to the sequence sender.
[0113] S8: After starting the test platform via run_test(), the sequence sender receives information about the RCC transaction class in the virtual sequence and passes it to the driver.
[0114] S9: After receiving the RCC transaction information and performing the corresponding data processing, the driver sends the gclk[0], gclk[1] and reset signals to the timer module through the virtual clock group interface 0. The timer module works normally after receiving the signals.
[0115] S10: Write the corresponding test cases in the test layer, and finally use the default_sequence method to attach the virtual sequence to the sequence sender.
[0116] S11: After successfully starting the test platform via run_test(), the signals set in the rcc configuration class are passed to the rcc configuration handle. After receiving the set signals, the rcc configuration handle passes them to the clock group configuration handle 0. Then, the clock group configuration handle passes the obtained gclk[0] and gclk[1] signals and reset signal to the driver.
[0117] S12: After receiving the information in the clock group configuration handle 0 and performing the corresponding data processing, the driver finally sends the gclk[0], gclk[1] and reset signals to the timer module through the virtual clock group interface 0. The timer module works normally after receiving the signals.
[0118] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A controllable clock reset signal generation module based on SV and UVM, characterized in that: The controllable clock reset signal generation module is written in SV language and is built based on a source code library provided by UVM. The controllable clock reset signal generation module comprises: An rcc interface, which comprises N virtual clock group interfaces, each of which is used for communication connection with each to-be-tested module; the virtual clock group interface declares N clock signals and a reset signal; An rcc configuration class, which defines a clock reset group agent number variable and N clock group configurations; each clock group configuration is used for defining a reset signal, a reset delay signal and a clock enable signal, and is assigned a default value; the clock group configuration is also used for declaring a handle of a virtual interface and creating an rcc transaction class object; An rcc environment top layer, which declares an rcc virtual interface handle, an rcc configuration handle and N clock reset group agents; the rcc virtual interface handle comprises N virtual clock group interface handles; each virtual clock group interface handle is connected with a virtual clock group interface in the rcc interface, thereby constructing a communication link between the clock reset group agent and the to-be-tested module; the rcc configuration handle is used for establishing a communication link between the rcc configuration class and each clock reset group agent in the rcc environment top layer, so as to adjust the running state of each clock reset group agent according to the configuration information in the rcc configuration class; the clock reset group agent declares a clock group configuration handle, a sequence sender and a driver; A sequence library, which is used for calling internal sequences to finally form corresponding test cases according to specific clock reset signal configuration requirements; the sequence library comprises four functional sequences for controlling the clock signal and the reset release signal in the excitation signal, namely a clock frequency configuration sequence, an automatic reset release sequence, a reset only sequence and a release only sequence; the clock frequency configuration sequence is used for modulating the clock frequency; the automatic reset release sequence realizes automatic reset according to a default reset holding time; the reset only sequence and the release only sequence are used for realizing self-regulation of the reset holding time; and An rcc transaction class, which creates N clk transaction classes and encapsulates attribute configurations of corresponding clock resets; the rcc transaction class comprises N clock enable signals, a reset request signal and a reset release signal, and the clk transaction class is used for default configuration of clock delay, duty cycle and clock frequency.
2. The SV and UVM based controllable clock reset signal generation module of claim 1, wherein: In the phase established in the rcc environment top layer, the rcc configuration handle obtains configuration information from outside the rcc environment top layer and the rcc virtual interface handle; then the number of clock reset group agents is instantiated according to the value of the clock reset group agent number variable in the rcc configuration class; the controllable clock reset signal generation module supports passing the N virtual clock group interface handles to the corresponding clock reset group agents at most according to the requirements of a project.
3. The SV and UVM based controllable clock reset signal generation module of claim 2, wherein: The clock reset group agent instantiates a sequence sender and a driver in its establishment phase, obtains corresponding information from N clock group configurations and transmits the information to the driver, and further communicates a transaction sending port in the sequence sender and a transaction receiving port of the driver through a TLM mechanism in the link phase of the clock reset group agent, and communicates a virtual interface handle of the driver with a virtual clock group interface handle.
4. The SV and UVM based controllable clock reset signal generation module of claim 3, wherein: The driver declares a clock group configuration handle, a virtual interface handle and a clk transaction class handle; the driver obtains configuration information in its establishment phase, then declares an rcc transaction class handle in its link phase, assigns the obtained clock related information to the clk transaction class, assigns the related information of the reset signal to the rcc transaction class, and finally the driver transmits the driving signal in the transaction to the module to be tested through the rcc virtual interface handle and the rcc interface in turn.
5. The SV and UVM based controllable clock reset signal generation module of claim 1, wherein: In the default configuration information of each clk transaction class in the rcc transaction class, the clock delay is 0 by default, the duty cycle is 50%, and the clock frequency is 6MHZ; meanwhile, each clk transaction class contains a preset clock variable initialization function and a clock period generation function, so as to adjust the clock variable and the clock period according to the needs in different projects.
6. The SV and UVM based controllable clock reset signal generation module of claim 1, wherein: Each clock group configuration created in the rcc configuration class is used to configure each clock reset group agent; meanwhile, the rcc configuration class further defines a clock reset group agent number variable in the internal for configuring the number of clock reset group agents to be started, and the default value of the clock reset group agent number variable is 1. In the reset signal, the reset delay signal and the clock enable signal defined in each clock group configuration, the default configuration is low-level reset, the reset delay is 213.73us, and the clock enable signal is all off; meanwhile, each clock group configuration internally declares a corresponding rcc virtual interface handle and creates an rcc transaction class object, which is used to update the clock configuration information of the top layer to the transaction in time, and further transmit the clock configuration information to the module to be tested through the driver.
7. The SV and UVM based controllable clock reset signal generation module of claim 1, wherein: The sequence library is a System Verilog format file, and the sequence library internally writes a clock frequency configuration sequence, an automatic reset release sequence, a reset only sequence and a release only sequence; the functions of the four sequences are as follows: (1) The clock frequency configuration sequence is used alone, and then the clock signal is flexibly configured according to the requirement of the module to be tested in different test projects, so as to ensure the functional accuracy of the module; (2) The automatic reset release sequence is used alone, and then the reset signal is pulled low to the default low-level state and released after 213.73us, that is, the reset function of the default automatic reset release is realized; the automatic reset release sequence is used to verify whether the values of the registers of the module to be tested after reset are normal, so as to meet the verification requirement of the functional module in most automatic reset test tasks; (3) only reset sequence and only release sequence are used together: further realize flexible control of reset holding time according to project requirements, verify projects under certain non-default reset holding time, or meet certain requirements of reset holding time in some scenarios.
8. The SV and UVM based controllable clock reset signal generation module of claim 1, wherein: The controllable clock reset signal generation module generates a virtual sequence according to the requirements of a certain scenario of the project and determines the corresponding test case; the virtual sequence calls the corresponding sequence in the sequence library, and the rcc transaction class created in advance is called in the clock frequency configuration sequence; the sequence sender sends the generated virtual sequence to the driver in the corresponding clock reset group agent for execution.
9. A UVM based timer verification platform, characterized in that, It is combined with the architecture design of the controllable clock reset signal generation module based on SV and UVM of any one of claims 1-8, and is further used for functional verification of a timer; the timer verification platform includes a test platform composed of hardware and interface parts, and a test layer composed of software parts; The test platform includes an rcc interface for connecting with the module to be tested, and the rcc interface includes a corresponding virtual clock group interface 0; after the virtual clock group interface 0 is connected with the virtual clock group interface handle 0 in the rcc virtual interface handle in the test layer, the module to be tested and the test layer support bidirectional communication; the rcc interface signal is finally transmitted to the driver through the config_db mechanism in UVM, and then the test layer is started by run_test(); The rcc configuration class and the rcc environment top layer are instantiated in the test layer; the rcc configuration class is used to configure the number of clock reset group agents and the clock reset information in the timer verification platform, and then the configuration is transmitted to the rcc configuration handle in the rcc environment top layer through config_db; the configuration information in the rcc configuration class is obtained in the rcc environment top layer, and then the configuration information is transmitted to the driver; the rcc configuration class, the rcc environment top layer are instantiated in the test layer, and a virtual sequence corresponding to the test case is generated; the clock frequency configuration sequence and the automatic reset release sequence are applied in the virtual sequence, the clock frequency configuration sequence calls the pre-created rcc transaction class; the sequence sender sends the generated virtual sequence to the driver; after the driver obtains the configuration information and the virtual sequence, the driving signal containing the clock signal of the corresponding clock frequency and the reset signal of the corresponding reset holding time is sent to the module to be tested as the excitation signal of the module to be tested.
10. A method for generating an editable clock reset signal in a timer verification platform, characterized in that, It is used in the UVM-based timer verification platform of claim 9 to adjust the default clock of the timer by generating clock signals and reset signals, and to realize automatic reset release; the clock reset signal generation method includes the following steps: S1: analyze the working clock of the module to be tested, determine that it includes an external clock extclk, an APB clock pclk, and an APB reset prst_n; and in the default case, the pclk frequency is 6MHZ, and the extclk is 32KHZ; S2: instantiate the module under test and the rcc interface in the test platform, connect the gclk[0], gclk[1] and reset signals of the virtual clock group interface 0 of the rcc interface to the pclk, extclk and prst_n of the module under test respectively, then pass the signals to the virtual clock group interface handle 0 of the rcc virtual interface handle in the top layer of the rcc environment through the config_db mechanism, and the virtual clock group interface handle 0 finally transmits the signals in the virtual clock group interface 0 to the driver after receiving the signals; S3: set the clock reset group agent number variable to 1 in the rcc configuration class in the test layer according to the default clock signal frequency of the module under test, so as to open the clock group configuration 0, and set the default clock signal frequencies of gclk[0] and gclk[1] to 6MHZ and 32KHZ respectively in the clock group configuration 0; S4: determine whether the default clock reset configuration of the module under test needs to be changed in the simulation process and whether the reset signal needs to be automatically released according to the actual scene requirements: (1) if the default configuration needs to be changed, execute steps S5-S9, (2) if the default configuration does not need to be changed, jump to steps S10-S12; S5: according to the requirements of the module under test in a special application scenario, it is concluded that the APB clock pclk is 3MHZ, the external clock extclk is 6KHZ, and the reset needs to be automatically released in the simulation process; S6: create a clock frequency configuration sequence and an automatic reset release sequence in the virtual sequence by using the sequence library; the clock frequency configuration sequence creates an rcc transaction class, defines reset request, reset release and clock enable signals, and then assigns the configuration values to the clk transaction class; in the configuration information, pclk is 3KHZ and extclk is 6KHZ; the automatic reset release sequence inherits the clock frequency configuration sequence, and internally sets the reset request and reset release signals to 1; S7: write the corresponding test case in the test layer, and finally mount the virtual sequence to the sequence transmitter in the form of default_sequence; S8: start the sequence transmitter to receive the information of the rcc transaction class in the virtual sequence and transmit it to the driver through run_test() in the test platform; S9: after receiving the rcc transaction class information and performing corresponding data processing, the driver sends the gclk[0], gclk[1] and reset signals to the module under test through the virtual clock group interface 0, and the module under test works normally after receiving the signals; S10: write the corresponding test case in the test layer, and finally mount the virtual sequence to the sequence transmitter in the form of default_sequence; S11: pass the signals set in the rcc configuration class to the rcc configuration handle through run_test() successfully, and then pass the gclk[0] and gclk[1] signals and the reset signal obtained by the clock group configuration handle 0 to the driver after the rcc configuration handle receives the signals; S12: After the driver receives the information in the clock group configuration handle 0 and performs corresponding data processing, the driver finally sends the gclk[0], gclk[1] and reset signals to the to-be-tested module through the virtual clock group interface 0, and the to-be-tested module normally works after receiving the signals.