CN104811259B - A kind of satellite communication frequency deviation verification method - Google Patents

Abstract

The invention relates to a satellite communication frequency offset verification method, which belongs to the technical field of special integrated circuit verification. This method is aimed at the frequency offset module in the satellite communication baseband chip, and uses the OVM verification methodology popular in integrated circuit verification as the basic structure of the verification system, and uses transaction-based verification technology, coverage-driven verification technology and assertion-based verification technology Integrate into it, and conduct joint simulation with the C algorithm model to realize automatic comparison and continuous simulation, improve verification efficiency and shorten verification cycle. The verification method realizes the function verification of the frequency offset module of the satellite communication baseband chip, improves the verification efficiency of the frequency offset module, and can play a non-negligible role in the success of the one-time tape-out of the satellite communication baseband chip.

Description

A satellite communication frequency offset verification method

technical field

The invention belongs to the technical field of application-specific integrated circuit verification, and relates to a satellite communication frequency offset verification method.

Background technique

In the ASIC chip development process, the time required for functional verification often accounts for more than 70% of the entire chip development time. The higher the abstraction level of the design, the simpler the design, but there may be more design loopholes at the same time. If If it is an architectural defect, the damage to the chip is even more immeasurable. Therefore, the functional simulation verification before tape-out is the top priority for the entire verification process.

Currently, there are mainly three types of simulation-based functional verification technologies: transaction-based verification technology, coverage-driven verification technology, and assertion-based verification technology. Transaction-based technology mainly converts transaction-level information into signal-level digital information required by the verification module through the transaction verification model TVM, and drives it into the test module to complete the functional verification of the module under test. The verification model TVM (Transaction Verification Model) is the core. The transaction verification model converts the existing transaction-level test cases into the signal-level information required by the test design. This verification method does not need to formulate specific protocols, only need to define The transmission direction of the signal is enough, and it has good reusability. However, when the functions of the design under test are different, the types and quantities of interfaces required may be different. At this time, multiple different verification models are required to meet the requirements. Verify requirements. In the functional verification process, the coverage rate is an important criterion to measure whether the verification is complete, and it runs through the entire verification process. The coverage-driven verification technology is to judge whether the module to be tested is correct and feasible by making statistics on the function coverage and code coverage information of the module to be tested during the verification process, and as an important guide for the formulation of the verification plan in the next step. index. However, this verification technology needs to define functional coverage points, and whether the defined coverage points are complete requires a certain understanding of the module to be tested. As the design scale and complexity continue to increase, there are more and more functional coverage points. It is necessary to continuously improve the coverage points in the verification to meet the requirements of design and verification. Assertion-based verification mainly improves the efficiency of verification by inserting assertions into the design under test to quickly locate errors in the design. However, this verification technology does not improve the verification efficiency of the external functional attributes of the test module. It is only suitable for verifying the internal functions of the test module, and this verification technology is based on clock-driven, so it is not suitable for clock-independent design modules. Functional Verification.

Contents of the invention

In view of this, the object of the present invention is to provide a satellite communication frequency deviation verification method, the method is aimed at the frequency deviation module in the satellite communication baseband chip, taking the OVM verification methodology popular in current integrated circuit verification as the basis of the verification system The architecture integrates transaction-based verification technology, coverage-driven verification technology and assertion-based verification technology, and performs joint simulation with C algorithm model to realize automatic comparison and continuous simulation, improve verification efficiency and shorten verification cycle.

To achieve the above object, the present invention provides the following technical solutions:

A satellite communication frequency offset verification method, comprising the following steps:

Step 1: Use the tree structure in the OVM verification methodology as the infrastructure of the entire verification system to build a basic verification system framework; in the OVM tree structure, each OVC (Open Verification Component) component is a node in the tree, and these OVC Components include Environment, Agent, Monitor, Driver, Sequencer, Reference, Scoreboard, etc. The nodes of the tree are divided into parent nodes and child nodes. In the OVC component represented by the parent node, the OVC component represented by the new child node can be declared as its Internal variables, through this layer-by-layer control method, realize the coordinated work in the verification components.

Step 2: Define transaction-level data items (items) according to the functional characteristics of the frequency offset module in the satellite communication chip. These transaction-level data items are implemented by classes in the System Verilog verification language. If there are special requirements, multiple transaction data items can be defined. To facilitate subsequent verification work, two transaction data items need to be defined here, one is used to transmit the parameter configuration information of the frequency offset module, and the other is used for subsequent automatic comparison, that is, the output data required for self-test.

Step 3: According to the port signal of the frequency offset module, define the interface interface, which is convenient for verifying the communication between the system and the design under test, and reduces the possibility of signal connection errors.

Step 4: Since the variables transmitted by DPI need two matching definitions, one is System Verilog and the other is C language, so according to the port signal of the frequency offset module, without changing the C algorithm, change the C algorithm to The configuration parameters are converted into data types corresponding to the corresponding mapping relationship in the System Verilog verification language to prepare for subsequent DPI calls.

Step 5: According to the functional characteristics of the frequency offset module, create bins in Driver or Monitor according to requirements, define coverage groups and coverage points, and instantiate them.

Step 6: Design the top layer of the entire verification system. In the top layer, it is necessary to realize the definition of global variables, the generation of clock clk, the DPI declaration of the C algorithm, the instantiation between the verification system and the design under test, the verification system and the design under test The interconnection between, the initialization of the design under test and the startup of the verification system.

Step 7: Add test cases according to the verification goal, and conduct directional and random tests.

Further, in step five, if there is a specific time sequence that requires supervision and inspection, an assertion can be added for detection.

The beneficial effect of the present invention is that: compared with the traditional verification system or method, this method uses the tree structure in the OVM verification methodology as the basic structure of the verification system, and integrates into some current mainstream verification methods, including transaction-based The verification method, the verification method based on coverage rate and the verification method based on assertion, etc., have realized the functional verification of the frequency offset module of the satellite communication baseband chip, improved the verification efficiency of the frequency offset module, and can be used in the satellite communication baseband chip. It plays a role that cannot be ignored in the success of tape-out.

Description of drawings

In order to make the purpose, technical scheme and beneficial effect of the present invention clearer, the present invention provides the following drawings for illustration:

Fig. 1 is the OVM tree structure diagram in the verification system in the present invention;

Fig. 2 is a verification system architecture diagram in the present invention;

Fig. 3 is a flow chart of the execution of the verification system in the present invention.

detailed description

The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Fig. 1 is the OVM tree structure diagram in the verification system in the present invention, as shown in the figure:

The frequency offset module verification system with the OVM tree structure has a clear affiliation relationship, which is very important for the management of transaction data transfer in the verification system, and can reasonably arrange the OVC components as nodes in the tree structure. data transfer. The nodes here are divided into two types, parent node and child node. In the parent node, one or more OVC components represented by child nodes can be declared and used as internal variables, so that the OVC components can be realized through the method of layer-by-layer progression. The coordinated work among them enables the entire verification system to operate reasonably and effectively. The specific construction process of the OVC component in the OVM tree structure is as follows:

1. It can be seen from Figure 1 that in the entire OVM tree structure diagram, Env is the top layer and integrates all OVC components together. In Env, you first need to declare the sub-nodes. The OVC represented by these sub-byte nodes The components include Agent, Reference, and Scoreboard. Since the verification system needs to configure some parameters of the frequency offset module to be tested, and the frequency offset verification system needs to supervise and detect the operation results of the frequency offset module during operation, two different agents are required. Secondly, in Env, you need to declare the FIFO that comes with the OVM library, and connect these OVC components through FIFO. The connection method is performed through the unique port of OVM, so that they can perform normal transaction-level communication.

2. After the Env is built, it is necessary to configure the mode of the Agent. In the Agent, the Driver, Sequencer, Monitor, and the port required for transaction-level data transmission need to be defined and declared. When the verification system needs to generate or send the frequency offset module to start running When the data is needed, configure the Agent as ACTIVE mode, and complete the instantiation of the Sequencer and Driver in this mode. At this time, the Monitor is in a non-working state. When it is necessary to capture the output results of the frequency offset module, configure the Agent as PASSIVE mode. , in this mode, the Monitor module will be instantiated to pave the way for verifying the output results of the frequency offset module to be tested when the system is running. After the instantiation of these sub-nodes is completed, it needs to be connected to the Interface interface according to the configured Agent mode, so that the verification system can perform normal data interaction with the frequency offset module.

3. When the Agent is in the ACTIVE mode, it is necessary to configure some parameters and initialize the data of the frequency offset module to be tested, all of which are performed through the Driver. Therefore, in the Driver, it is necessary to convert the transaction-level information transmitted in the OVC component into the required level or pulse signal of the frequency offset module. These levels or pulse signals must meet the timing requirements of the frequency offset module to be tested. Normally drive the frequency offset module to be tested, this part can be realized through some tasks. At the same time, some functional coverage groups can be added to this component to perform coverage point statistics on the parameters and data input to the frequency offset module.

4. The parameter configuration data and calculation data required by the entire verification system are generated through Sequence. When the Driver needs data, it will send a transaction-level data request to the Sequencer. After receiving the data, the Sequencer will drive the Sequence to generate data and generate these After the required data, the Sequencer bridge will pass it to the Driver. Multiple Sequences can be designed in the entire verification system. Different Sequences can generate different stimulus data for the frequency offset module to be tested. The Sequence can determine the content of the generated transaction-level data through macros such as OVM’s ovm_do or ovm_do_with.

5.Monitor is mainly used to monitor the output of the frequency offset module, and send the collected output results to the Scoreboard through the port for comparison of the results. Therefore, in this module, the output results of the frequency offset module to be tested need to be tested first through the Interface interface. To collect, this process needs to be carried out according to the timing requirements of the frequency offset module, otherwise the collected results may be incorrect. Secondly, after collecting the operating results of the frequency offset module, since these operating structures are signal-level information, it is necessary to It is converted into transaction-level information required by the verification system, and all of the above processes can be completed through tasks.

6. The reference model Reference is a model used to simulate the frequency offset module to be tested, so it needs the same input as the frequency offset module, and completes the same calculation process as the frequency offset module through these inputs, and sends the calculated results to the Scoreboard. Therefore, there must first be a port that interacts with the Agent and Scoreboard to transmit transaction-level information. When the verification system is started, in the agent mode of ACTIVE, the driver can use the internal functions of OVM to send transaction-level data to the reference through the port. Participate in the calculation, and after the reference completes the calculation, the result is sent to the Scoreboard through the port. Secondly, the reference model in this part can be written in SystemVerilog or other high-level languages, but it is better to be C or C++, because currently only C and C++ can be embedded into the verification system based on SystemVerilog verification language through DPI In , after the collaborative testing of the frequency offset module to be tested and the reference model is completed, the results calculated in the reference model need to be converted into transaction-level information.

7. The verification system uses Scoreboard to compare the results sent by Monitor and Reference to determine whether the design of the frequency offset module is reasonable. Therefore, it is also necessary to define two ports to receive transaction-level data from Monitor and Reference respectively. After the results of partial module and reference model, the comparison result needs to be output. If it is correct, the correct conclusion is needed. If it is wrong, the data that has been stored in the top-level array needs to be written into the file to help the next step of debugging.

After completing the design of each OVC component in the OVM tree structure, it can be seen from Figure 2 that other modules of the entire verification system need to be designed and improved, including the definition of transaction information transmitted in the verification system, the definition of Interface interface, and how to verify Adding coverage points, as well as the top-level design of the entire verification system, the design of test cases, etc., the specific design methods are as follows:

1. Definition of transaction information: Transaction is the medium of data transmission between OVC components in the verification system. These transactions are derived from the ovm_sequence_item class library, including all internal functions and variables. In the frequency offset verification system, two Transactions need to be defined, one is used to transmit the parameter configuration information and sampling point data of the frequency offset module, and the other is used to realize automatic comparison later, that is, the output data required for self-test. Among them, the first transaction Transaction, that is, the transaction used to transfer configuration parameters is generated and packaged in Sequence. When generating this type of transaction information, it is necessary to follow the algorithm requirements of the frequency offset module to verify the generated transaction. Information is properly bound. The second type of transaction is generated in Reference. In Reference, the collected data information of the frequency offset module is converted into the second type of transaction information and sent to Scoreboard for data comparison.

2. Interface definition and top-level design: The interface interface can be defined directly according to the port of the frequency offset module, and the definition method refers to the part about the interface definition in the SystemVerilog verification language. The top layer of the entire verification system needs to realize the definition of global variables, the generation of clock clk, the DPI declaration of the C algorithm model, the instantiation of the interface interface, the interconnection between the verification system and the frequency offset module, the initialization of the frequency offset module, and Verify the startup of the system and the declaration of the array, which is used to store the data required for each operation of the frequency offset module.

3. Writing of test cases: The test cases in the verification system are all derived from the ovm_test class library, and the design of the base class base_test can be completed first during design, which can also be derived from ovm_test, and the OVM tree is mainly completed in this base class The instantiation of the verification architecture and the determination of the time to run the functional simulation can be achieved through tasks. When designing a specific test case, you only need to derive subclasses from the base_test base class, but in each subclass, you need to confirm which verification scenario the default Sequence of Sequencer is, that is, the first sequence generated in the verification system. Class transaction information.

4. Design of coverage points and assertions: In the entire frequency offset verification system, whether the coverage points are complete is an important criterion for judging whether the verification of the frequency offset module is complete. When creating a coverage group, it must strictly follow the frequency offset module. The functions that need to be implemented define the content in the coverage group, including the coverage of a single function and the cross coverage between multiple functions. According to actual needs, the coverage group can be embedded in the Driver or Monitor of the OVC component to collect the functional coverage of the configuration parameters and output results of the frequency offset module. If there are specific requirements for the timing of the port signal of the frequency offset module, an assertion can be added to the Interface in the verification system to determine whether the timing of the signal meets the requirements. The specific design can be based on the port timing of the frequency offset module to be tested and the systemVerilog verification language Assertion techniques in .

After completing the component design required by the above verification system, the entire verification system can run normally, and the execution flow of the verification system is shown in Figure 3. Generate a test instance through OVM_TETSNAME, and instantiate the OVM tree structure, and according to the instantiation of the OVC components represented by each node in the tree structure and the connection process between components, these processes are all through the OVM library. Internal functions build () and connect () to complete. The startup of the entire verification system can be completed through the Makefile script, including the compilation and operation of the verification system and the frequency offset module to be tested.

Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that it can be described in terms of form and Various changes may be made in the details without departing from the scope of the invention defined by the claims.

Claims (3)

1. a kind of satellite communication frequency deviation verification method, it is characterised in that：Comprise the following steps：

Step one：Using in OVM verification methodologies, tree structure builds basic checking as the architecture of whole checking system System framework；

Step 2：Transaction-level data item is defined according to the functional character of satellite communication chip frequency deviation module；

Step 3：According to the port signal of frequency deviation module, defining interface interface, be easy to checking system and design to be measured it Between communication, reduce signal connection error possibility；

Step 4：According to frequency deviation module port signal, on the premise of C algorithms are not changed, the configuration parameter in C algorithms is changed Into the data type for verifying correspondence mappings relation in language with System Verilog, it is that DPI below is called and prepared；

Step 5：According to frequency deviation functions of modules feature, storehouse is created as desired in Driver or Monitor, definition is covered Group and covering point, and instantiate；

Step 6：The top layers of whole checking system are designed, in the definition that top layers need to realize global variable, the product of clock clk Raw, DPI statements of C algorithms, between the instantiation between checking system and design interface to be measured, checking system and design to be measured The startup of interconnection, the initial work of design to be measured and checking system；

Step 7：Test case is added according to checking target, is oriented and random test.

2. a kind of satellite communication frequency deviation verification method according to claim 1, it is characterised in that：In step 2, according to The functional character of satellite communication chip frequency deviation module defines transaction-level data item (item), and these transaction-level data item pass through Class in System Verilog checking language can define multiple Transaction Information items according to real needs, with convenient realizing Follow-up checking work；Need exist for defining two Transaction Information items, a parameter configuration for being used for transmitting frequency deviation module, One use automates the output data required for contrast, i.e. self-inspection later.

3. a kind of satellite communication frequency deviation verification method according to claim 1, it is characterised in that：In step 5, if There is specific sequential to need supervision and check, can increase and assert and detected.