Front-end verification method and device, equipment and storage medium

Abstract

The invention discloses a front-end verification method and device, equipment and a storage medium, and relates to the technical field of front-end processing. The method comprises the following steps: constructing a first incentive scene and obtaining a first incentive data packet; the first excitation scene is a scene for performing interface transmission by using a general protocol; determining a second excitation scene and acquiring a second excitation data packet; the second excitation scene is a specific excitation scene used for transmitting specific demand information of hardware; unpacking the first excitation data packet in the second excitation data packet and re-packing the first excitation data packet and the second excitation data packet to generate a new excitation data packet; constructing a conditional constraint of a new excitation data packet by using a filter class mapping the first excitation scene to the second excitation scene; and transmitting the new incentive data packet based on the conditional constraint to the corresponding agent component so as to carry out incentive sending through the agent component to carry out front-end verification. Through the technical scheme of the invention, the development difficulty of the new data packet in the front-end verification process can be reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of front-end processing, and particularly relates to a front-end verification method, apparatus, device, and storage medium. Background Art

[0002] Currently, for front-end verification, in an actual DUT (Design Under Test), verification personnel often need to extract relevant information contained in a general protocol and convert it into a form conforming to the on-chip transmission protocol to construct stimuli for specific scenarios. The traditional method is to construct specific stimulus scenarios for each specific scenario. After obtaining the transaction-level data packets (Transactions) corresponding to the general protocol from the UVM (Universal Verification Methodology) VIP (Verification Intellectual Property), corresponding packet assembly is performed to construct the corresponding object-oriented programming objects (objects); then, leveraging the corresponding advantages of the UVM verification method OOP (Object Oriented Programming) based on SV (System Verilog, a verification design language), dedicated transaction packets required for constructing specific stimulus scenarios are derived from the transaction objects, and specific constraints are added to the specific information (Userdefine) related to the general protocol for this scenario in the new transaction packets, followed by re-packing. The assembled transaction packets are sent to the VIP corresponding to the on-chip transmission protocol; the VIP then sends the transaction packets to the DUT under test in the form of specific stimuli. The class diagram is as Figure 1 shown.

[0003] However, when the traditional method needs to reconstruct some information in the general protocol by constructing specific stimulus scenarios using a specific on-chip transmission protocol in front-end verification, there are many deficiencies. For example, the generated data packets are not easily reusable, the constraint blocks constructed by traditional constraint methods are cumbersome and complex, making them difficult to maintain, it is easy to cause omissions and errors when there is a large amount of data and constraints, and some hidden errors are likely to occur when simply deriving and calling the built-in methods of UVM in the new stimulus packets, resulting in poor reusability and reduced verification efficiency, etc.

[0004] Therefore, how to provide a solution to the above technical problems is an issue that those skilled in the art need to solve currently. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a front-end verification method, device, equipment and storage medium, which can break the traditional construction method of incentive data packets based on derivation, simplify a large number of hierarchical constraints that may occur in the complex packet assembly process, and reduce the development difficulty of new data packets in the front-end verification process. The specific scheme is as follows:

[0006] In a first aspect, the present application discloses a front-end verification method, including:

[0007] Construct a first incentive scenario and obtain a first incentive data packet corresponding to the first incentive scenario; the first incentive scenario is a scenario for interface transmission using a general protocol;

[0008] Determine a second incentive scenario and obtain a second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting specific incentive information including hardware-specific requirements;

[0009] Unpack the first incentive data packet in the second incentive data packet, and packetize the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet;

[0010] Construct a filter class for mapping the first incentive scenario to the second incentive scenario, and construct conditional constraints for the new incentive data packet using the filter class;

[0011] Pass the new incentive data packet based on the conditional constraints to the corresponding proxy component for incentive sending through the proxy component for front-end verification.

[0012] Optionally, the constructing a first incentive scenario and obtaining a first incentive data packet corresponding to the first incentive scenario includes:

[0013] Select a target incentive scenario from several incentive scenarios based on a preset selection strategy and obtain a target incentive data packet corresponding to the target incentive scenario;

[0014] Obtain a transaction-level data packet provided by a verification component corresponding to the general protocol, and instantiate the transaction-level data packet in the target incentive data packet to construct the first incentive scenario;

[0015] Associate the protocol domain segment of the target incentive scenario with the general protocol based on the first incentive scenario to obtain a first incentive data packet corresponding to the first incentive scenario.

[0016] Optionally, the unpacking the first incentive data packet in the second incentive data packet and packetizing the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet includes:

[0017] Define a first interface in the second incentive data packet for obtaining the first incentive data packet;

[0018] Randomize the first incentive data packet and obtain the randomized first incentive data packet based on the first interface, so as to load the randomized first incentive data packet into the second incentive data packet;

[0019] Define a second interface in the second incentive data packet for calling the protocol domain segment corresponding to the general protocol in the first incentive data packet, so as to unpack the first incentive data packet based on the second interface to obtain the unpacked first incentive data packet;

[0020] Define a third interface in the second incentive data packet for packing and reorganizing the incentive data packet, and initialize the unpacked first incentive data packet by packing and transmitting it to the corresponding protocol domain segment in the second incentive data packet based on the third interface;

[0021] After the initialization of the second incentive data packet is completed, packetize the unpacked first incentive data packet and the second incentive data packet to generate the new incentive data packet.

[0022] Optionally, the steps of constructing a filter class for mapping the first incentive scenario to the second incentive scenario and using the filter class to construct the conditional constraints of the new incentive data packet include:

[0023] Construct a filter class for mapping the first incentive scenario to the second incentive scenario and instantiate the filter class into the new incentive data packet;

[0024] Define a fourth interface in the new incentive data packet for starting the filter class to perform scenario label calculation, and transmit the calculated scenario label to the corresponding variable in the new incentive data packet based on the fourth interface, so that the variable constructs the conditional constraints of the new incentive data packet according to the scenario label;

[0025] Wherein, the scenario label is a vector label describing any specific incentive scenario including hardware-specific requirement information; the fourth interface encapsulates a calculation method for calculating the scenario label.

[0026] Optionally, after constructing the filter class for mapping the first incentive scenario to the second incentive scenario and using the filter class to construct the conditional constraints of the new incentive data packet, it further includes:

[0027] Encapsulate the first interface, the second interface, the third interface, the fourth interface, and the randomization method in the second incentive data packet to generate a fifth interface for invoking the new incentive data packet;

[0028] Correspondingly, the step of passing the new incentive data packet based on the conditional constraint to the corresponding proxy component for incentive sending through the proxy component for front-end verification includes:

[0029] Pass the new incentive data packet based on the conditional constraint to the corresponding proxy component through the fifth interface, so that the proxy component can send incentives for front-end verification.

[0030] Optionally, the step of passing the new incentive data packet based on the conditional constraint to the corresponding proxy component for incentive sending through the proxy component for front-end verification includes:

[0031] Pass the new incentive data packet based on the conditional constraint to the corresponding proxy component, so that the proxy component can obtain the scenario tag through the filter class and send incentives for the new incentive data packet for front-end verification according to the scenario tag.

[0032] Optionally, the front-end verification method further includes:

[0033] When the conditional constraint changes, derive the filter class to generate a new filter, and reload the new filter into the new incentive data packet.

[0034] In a second aspect, the present application discloses a front-end verification device, including:

[0035] A first incentive scenario construction module for constructing a first incentive scenario and obtaining a first incentive data packet corresponding to the first incentive scenario; the first incentive scenario is a scenario for interface transmission using a general protocol;

[0036] A second incentive scenario determination module for determining a second incentive scenario and obtaining a second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting specific incentive information including hardware-specific requirements;

[0037] A new incentive data packet generation module for unpacking the first incentive data packet in the second incentive data packet and repackaging the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet;

[0038] A filter class construction module for constructing a filter class for mapping the first excitation scenario to the second excitation scenario, and constructing a conditional constraint for the new excitation data packet by using the filter class;

[0039] A front-end verification module for passing the new excitation data packet based on the conditional constraint to a corresponding proxy component, so as to perform excitation sending through the proxy component for front-end verification.

[0040] In a third aspect, the present application discloses an electronic device, which includes a processor and a memory; wherein, the memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the front-end verification method as described above.

[0041] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the front-end verification method as described above when executed by a processor.

[0042] The present application provides a front-end verification method, including: constructing a first excitation scenario and obtaining a first excitation data packet corresponding to the first excitation scenario; the first excitation scenario is a scenario for interface transmission using a general protocol; determining a second excitation scenario and obtaining a second excitation data packet corresponding to the second excitation scenario; the second excitation scenario is a specific excitation scenario for transmitting specific excitation information including hardware-specific requirements; unpacking the first excitation data packet in the second excitation data packet, and repackaging the unpacked first excitation data packet and the second excitation data packet to generate a new excitation data packet; constructing a filter class for mapping the first excitation scenario to the second excitation scenario, and constructing a conditional constraint for the new excitation data packet by using the filter class; passing the new excitation data packet based on the conditional constraint to a corresponding proxy component, so as to perform excitation sending through the proxy component for front-end verification.

[0043] The beneficial technical effects of this application are as follows: On the one hand, this application breaks the traditional construction method of incentive data packets based on derivation. Instead, it directly constructs new data packets in the second incentive data packet corresponding to a specific incentive scenario by reorganizing the existing complete first incentive data packet, enabling the existing complete incentive data packet to be instantiated in the new data incentive packet. This is applicable to the situation of converting a general protocol into other specific incentive scenarios suitable for transmitting information on hardware-specific requirements. Compared with the traditional method, there is no need to construct complex hierarchical constraints again. Only by unpacking and then repackaging can a brand-new incentive packet be obtained. In this way, the development difficulty of new data packets in the front-end verification process is reduced, and the process of constructing incentive packets for this general protocol in different on-chip transmission protocols is simplified, eliminating repetitive code writing. On the other hand, a dedicated filter class for processing a large amount of general protocol information is introduced in the constraint part of the new incentive data. In this way, the original multi-layer constraints are replaced, which not only simplifies the constraints but also decouples complex data calculations from the data packet itself while improving the reusability of the data packet. Through the filter class, the mapping between the general protocol and the corresponding domain segment values of the incentive scenario can be decoupled from the constraint block, simplifying the constraint block. When the mapping relationship changes, the complex constraint block does not need to be rewritten by overloading the filter class. It can be seen that when there is a scenario requirement of converting a general protocol into different transmission methods in front-end verification, adopting the method in this application can simplify the verification process, improve the reusability of the verification platform, save verification costs, and improve verification efficiency.

[0044] In addition, a front-end verification device, equipment, and storage medium provided by this application correspond to the above front-end verification method, and the effects are the same. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0046] Figure 1 It is a class diagram of a traditional general-protocol-based data incentive packet derivation disclosed in this application;

[0047] Figure 2 It is a flowchart of a front-end verification method disclosed in this application;

[0048] Figure 3 It is a structural diagram of a verification platform for a multi-transmission-protocol DUT based on a general protocol disclosed in this application;

[0049] Figure 4Schematic diagram of the implementation code of a filter class that uses a new incentive data packet in the environment disclosed in this application;

[0050] Figure 5 Flowchart of a specific front - end verification method disclosed in this application;

[0051] Figure 6 Schematic diagram of the construction of a data incentive packet for the basic transmission protocol A1 disclosed in this application;

[0052] Figure 7 Flowchart of a specific front - end verification method disclosed in this application;

[0053] Figure 8 Schematic diagram of the construction of a data incentive packet for the transmission protocol A2 based on a combination method disclosed in this application;

[0054] Figure 9 Flowchart of a specific front - end verification method disclosed in this application;

[0055] Figure 10 Schematic diagram of the working structure of a filter class disclosed in this application;

[0056] Figure 11 Schematic diagram of the implementation code of a new incentive data packet disclosed in this application;

[0057] Figure 12 Schematic diagram of the structure of a front - end verification device disclosed in this application;

[0058] Figure 13 Schematic diagram of the structure of an electronic device disclosed in this application. Specific implementation manners

[0059] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0060] With the development of computer and integrated circuit technologies, in order to facilitate technological progress and unified iteration, companies in related fields have established committees to develop general protocols with unified standards. These excellent general protocols that have passed the test of practice have been widely used in various electronic products, including NVME (Non-Volatile Memory Express), AHCI (Advanced Host Controller Interface), SCSI (Small Computer System Interface), MAC (Media Access Control), USB (Universal Serial Bus), etc. The hardware related to these general protocols is widely used in various SOC (System-on-a-chip) chips in the form of IP, accelerating the R & D of SOC chips with the idea of modular design.

[0061] Currently, for front-end verification, each manufacturer provides VIPs that match the corresponding general protocols to improve verification efficiency and reduce the proportion of chip verification time in chip R & D, so as to achieve the purpose of accelerating the chip R & D cycle. In the actual DUT, verification personnel often need to extract the relevant information contained in the general protocol and convert it into a form that conforms to the on-chip transmission protocol to construct stimuli for specific scenarios. The biggest limitation of this verification method lies in:

[0062] 1. After unpacking the relevant information contained in the general protocol data packet and then repackaging it through the derived method, a large number of constraint blocks need to be added according to the scenario hierarchy to limit the constructed stimulus space. There are a large number of similar constraints for each transmission method, and the data packets generated in this way are not easy to reuse;

[0063] 2. There is a large amount of information in the general protocol, and there are mutually coupled constraint relationships between various pieces of information. The constraint blocks constructed by traditional constraint methods are numerous and complex, and are not easy to maintain;

[0064] 3. When directly deriving data packet classes from existing stimulus scenarios to construct new stimulus scenarios, when there are a large number of constraint blocks in the existing stimulus scenario data packets that cannot be reused in the new stimulus scenario, the constraint blocks and constraint variables that cannot be reused need to be turned off one by one in the newly derived subclass data packets. When there is a large amount of data and constraints, this method is prone to omissions and errors;

[0065] 4. After a large number of fields are registered in the existing incentive scenario data packet in the Field (implicit inheritance) mechanism provided by UVM, simple derivation cannot simply and efficiently remove a large number of fields that will not be used in the new incentive scenario data packet. Therefore, when calling the built-in methods of UVM in the new incentive packet, some hidden errors are likely to occur, resulting in problems such as poor reusability and reduced verification efficiency.

[0066] For this reason, the present application provides a front-end verification solution, which can break the traditional construction method of incentive data packets based on derivation, and simplify a large number of hierarchical constraints that may occur in the complex packet assembly process, reducing the development difficulty of new data packets in the front-end verification process.

[0067] An embodiment of the present invention discloses a front-end verification method. Refer to Figure 2 As shown, the method includes:

[0068] Step S11: Construct a first incentive scenario and obtain a first incentive data packet corresponding to the first incentive scenario; the first incentive scenario is a scenario for interface transmission using a general protocol.

[0069] In the embodiments of the present application, it is applicable to the situation of converting a general protocol into multiple specific incentive scenarios (such as AMBA, AXI, AHB). In an actual front-end verification scenario, this requirement will occur when the DUT is a central processing module and has multiple different on-chip protocol transmission interfaces.

[0070] As Figure 3 shown, the DUT has different transmission interfaces A1, A2, etc. with different upstream hardware to match the processing requirements of different efficiency hardware; at the same time, the firmware can also directly access the DUT in the manner of interface B. At this time, when module-level verification of the DUT is required, front-end verification engineers need to integrate VIPs of multiple transmission protocols in the verification environment, and these VIPs are integrated in the verification environment in the form of environment container classes or proxy components. When constructing an incentive packet, it is necessary to instantiate the data packet provided in the VIP that matches the corresponding on-chip transmission protocol and fill in the field information in the data packet. The specific information sources in the data packet are divided into two categories. One category is the information carried by the general protocol, and the other category is the additional information due to the specific requirements of the hardware. This type of additional information often has a certain degree of constraint relationship with the first type of information. The focus of the embodiments of the present application is on how to quickly construct incentive packets such as incentive packet A2, B, etc. when there is already a mature and correct incentive packet A1.

[0071] Therefore, in the first step, construct a complete first incentive scenario A1 applicable to the general protocol and obtain the first incentive data packet corresponding to the first incentive scenario A1. It can be understood that the first incentive scenario is a scenario for interface transmission using the general protocol; the first incentive data packet corresponding to the first incentive scenario A1 can perform data transmission on the A1 interface.

[0072] Step S12: Determine the second incentive scenario and obtain the second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting information on hardware-specific requirements.

[0073] In the embodiment of the present application, based on the data packet corresponding to the transmission protocol of the complete first incentive scenario A1 constructed in the first step, create the transmission protocol data packets in the second incentive scenarios such as A2 and B. Therefore, determine the second incentive data packet in the specific incentive scenario containing the hardware-specific requirement information, and construct a new data packet based on the second incentive data packet.

[0074] Step S13: Unpack the first incentive data packet in the second incentive data packet, and packetize the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet.

[0075] It should be noted that the data packets corresponding to the transmission protocols A2 and B should contain the data packets corresponding to the transmission protocol A1 instead of being derived from the existing data packet classes. Therefore, by instantiating the relatively complete first incentive data packet in the second incentive data packet, unpacking and packetizing the first incentive data packet in the second incentive data packet, the combination between data packets is realized. In this way, new incentive packets are constructed by combining the incentive data packets with each other.

[0076] It can be understood that constructing a new incentive packet by combining on the basis of an existing complete first incentive data packet, compared with the traditional method, does not require constructing complex hierarchical constraints again. Only by unpacking and then repacketing according to the regulations can a brand-new incentive packet be obtained. This reduces the development difficulty of new data packets in the front-end verification process, simplifies the process of constructing incentive packets in the general protocol for different on-chip transmission protocols, and abandons the repetitive code writing.

[0077] Step S14: Construct a filter class for mapping the first incentive scenario to the second incentive scenario, and use the filter class to construct the conditional constraints of the new incentive data packet.

[0078] In the embodiments of the present application, a large number of layering constraints that may occur in the complex packet assembly process are simplified into simple constraints based on filter class processing. According to the specific information associated with the general protocol information, that is, non-direct information, required in a specific excitation scenario, a filter class dedicated to calculation is constructed, which is responsible for the mapping relationship between the general protocol and the specific excitation scenario.

[0079] It should be noted that the filter class described in the embodiments of the present application is a type of data processing class used to process the domain segment information in a large number of general protocols and convert it into a series of scenario tags concerned by front-end verification engineers. The purpose of introducing this class is to simplify the constraints by decoupling the calculation process from the excitation data packet itself. Abstracting the calculation process into a dedicated class can also achieve the purpose of improving reuse.

[0080] In some special scenarios: 1. When the calculation involved in solving the constraints is too complex and the calculation efficiency using SV is not satisfactory, a lower-level compiled language such as C (The C Programming Language) can be considered to implement the corresponding calculation process to speed up the calculation, and the call to C is completely included in the filter class for convenient subsequent maintenance; 2. When some core algorithms are involved in the solution process, or the transmission method of the constraint excitation packet to be constructed has a certain confidentiality nature, using the filter class to encapsulate the specific implementation process can play a certain role in data confidentiality and facilitate management by a dedicated person.

[0081] Step S15: Transmit the new excitation data packet based on the conditional constraint to the corresponding proxy component for excitation sending through the proxy component for front-end verification.

[0082] In the embodiments of the present application, after obtaining the new excitation data packet, the new excitation data packet is sent to the VIP corresponding to the on-chip protocol, and the VIP then sends the new excitation data packet to the design under test in a specific form of excitation for front-end verification.

[0083] It should be noted that three steps are required when using the new excitation data packet in the environment: 1. Instantiate and randomize the original first excitation data packet A1; 2. Instantiate the second excitation data packet A2, call the interface in A2 to load the original excitation packet A1 that has been randomized in step 1, and construct a scenario tag through filter class calculation to obtain a new excitation data packet in a specific scenario containing general protocol information; 3. Transmit the new excitation data packet in the specific scenario to the corresponding proxy component for excitation sending. As Figure 4 shown is an example of an implementation code snippet for processing the new excitation data packet based on the filter class in the environment.

[0084] As can be seen from the foregoing steps, the filter class can output the scenario tags that the verifier actually cares about. Therefore, passing the new incentive data packet based on the conditional constraint to the corresponding proxy component for incentive sending through the proxy component for front-end verification includes: passing the new incentive data packet based on the conditional constraint to the corresponding proxy component, so that the proxy component obtains the scenario tag through the filter class, and sends the new incentive data packet for incentive sending for front-end verification according to the scenario tag.

[0085] In addition, since the filter class is constructed based on the mapping relationship, a compositional relationship also exists between the filter class and the new incentive data packet. When the conditional constraint changes, the filter class is derived to generate a new filter, and the new filter is reloaded into the new incentive data packet. It can be seen that when the mapping relationship changes, new functions can be achieved by reloading the filter class instead of rewriting complex constraint blocks, which greatly improves the reusability of the incentive packets constructed in this way.

[0086] The present application provides a front-end verification method, including: constructing a first incentive scenario and obtaining a first incentive data packet corresponding to the first incentive scenario; the first incentive scenario is a scenario for interface transmission using a general protocol; determining a second incentive scenario and obtaining a second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting specific incentive information including hardware-specific requirements; unpacking the first incentive data packet in the second incentive data packet, and packing the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet; constructing a filter class for mapping the first incentive scenario to the second incentive scenario, and using the filter class to construct a conditional constraint for the new incentive data packet; passing the new incentive data packet based on the conditional constraint to the corresponding proxy component for incentive sending through the proxy component for front-end verification.

[0087] The beneficial technical effects of this application are as follows: On the one hand, this application breaks the traditional construction method of incentive data packets based on derivation. Instead, it directly constructs a new data packet in the second incentive data packet corresponding to a specific incentive scenario by reorganizing the existing and complete first incentive data packet, enabling the existing and complete incentive data packet to be instantiated in the new data incentive packet. This is applicable to the situation of converting a general protocol into other specific incentive scenarios suitable for transmitting information with hardware-specific requirements. Compared with the traditional method, there is no need to construct complex hierarchical constraints again. Only by unpacking and then repackaging can a brand-new incentive packet be obtained. In this way, the development difficulty of new data packets in the front-end verification process is reduced, and the process of constructing incentive packets for this general protocol in different on-chip transmission protocols is simplified, eliminating repetitive code writing. On the other hand, a dedicated filter class for processing a large amount of general protocol information is introduced into the constraint part of the new incentive data. In this way, the original multi-layer constraints are replaced, which not only simplifies the constraints but also decouples complex data calculations from the data packet itself while improving the reusability of the data packet. Through the filter class, the mapping between the general protocol and the domain segment values of the incentive scenario can be decoupled from the constraint block, simplifying the constraint block. When the mapping relationship changes, the complex constraint block does not need to be rewritten by overloading the filter class. It can be seen that when there is a scenario requirement of converting a general protocol into different transmission methods in the front-end verification, adopting the method in this application can simplify the verification process, improve the reusability of the verification platform, save verification costs, and improve verification efficiency.

[0088] In a specific embodiment, as Figure 5 shown, step S11, the constructing the first incentive scenario and obtaining the first incentive data packet corresponding to the first incentive scenario includes:

[0089] Step S111: Select a target incentive scenario from several incentive scenarios based on a preset selection strategy and obtain the target incentive data packet corresponding to the target incentive scenario.

[0090] In the embodiment of this application, in order to convert a general protocol into multiple specific incentive scenarios, first, a target incentive scenario is selected from several incentive scenarios based on a preset selection strategy, and then the target incentive data packet corresponding to the target incentive scenario is obtained.

[0091] It should be noted that when there are multiple transmission scenarios, the selection strategy for the target incentive data packet is as follows: 1. As many domain segments related to the general protocol as possible, and as little custom-specific information as possible; 2. The transmission protocol itself should be as simple and basic as possible; 3. The data packet that has already been constructed and contains general protocol information.

[0092] Step S112: Obtain the transaction-level data packet provided by the verification component corresponding to the general protocol, and instantiate the transaction-level data packet in the target stimulus data packet to construct the first stimulus scenario.

[0093] In the embodiment of the present application, the target stimulus data packet is instantiated, and the transaction-level data packet provided by the general protocol VIP (verification component) is instantiated in the target stimulus data packet to obtain the first stimulus scenario.

[0094] Step S113: Based on the first stimulus scenario, associate the protocol domain segment of the target stimulus scenario with the general protocol to obtain a first stimulus data packet corresponding to the first stimulus scenario.

[0095] In the embodiment of the present application, the relevant protocol domain segment of the target stimulus scenario and the relevant information of the general protocol are associated to obtain a first stimulus data packet corresponding to the first stimulus scenario. As Figure 6 shown in the relevant construction schematic diagram. In the A1 protocol transaction in the figure, the universal attributes of the universal protocol transaction are associated with the transaction attributes to construct the first stimulus data packet.

[0096] In a specific implementation manner, as Figure 7 shown, in step S13, unpacking the first stimulus data packet in the second stimulus data packet, and packing the unpacked first stimulus data packet and the second stimulus data packet to generate a new stimulus data packet, includes:

[0097] Step S131: Define a first interface in the second stimulus data packet for obtaining the first stimulus data packet;

[0098] Step S132: Randomize the first stimulus data packet, and obtain the randomized first stimulus data packet based on the first interface, so as to load the randomized first stimulus data packet into the second stimulus data packet.

[0099] It should be noted that the information in the new incentive data packet is divided into two categories: one category can be directly obtained from the information in the relevant domain segments of the general protocol; the other category needs to be obtained through relevant constraints based on the relevant information of the general protocol. For the information related to the first category, the relevant information is obtained by implementing the relevant interfaces in the corresponding category of the second incentive data packet. The following uses the construction of the new incentive data packet A2 as an example. First, define the relevant interface for obtaining the first incentive data packet, that is, the first interface. This interface is responsible for obtaining the first incentive data packet that has been randomized in the verification platform and loading it into the original data packet implemented within the transport protocol A2 data packet, that is, the second incentive data packet.

[0100] Step S133: Define a second interface in the second incentive data packet for calling the protocol domain segment corresponding to the general protocol in the first incentive data packet, so as to unpack the first incentive data packet based on the second interface to obtain the unpacked first incentive data packet;

[0101] Step S134: Define a third interface in the second incentive data packet for packing and reorganizing the incentive data packet, and based on the third interface, pack and transmit the unpacked first incentive data packet to the corresponding protocol domain segment in the second incentive data packet for initialization;

[0102] Step S135: After the initialization of the second incentive data packet is completed, packetize the unpacked first incentive data packet and the second incentive data packet to generate the new incentive data packet.

[0103] Secondly, define the interfaces related to unpacking and packetizing. The interface corresponding to unpacking is the second interface, and the interface corresponding to packetizing is the third interface. The purpose of this interface is to obtain the domain segments containing general information in the first incentive data packet after calling the first interface and pack and reorganize them into the relevant fields of the new transport protocol A2 data packet to complete the initialization process.

[0104] Such as Figure 8The following is a schematic diagram of the relevant construction. By using the idea of composition in the design pattern, the traditional way of derivation is replaced to construct a new incentive data packet. The reason for not using the derivation method is as follows: on the one hand, in the scenario where there are multiple incentive transmission methods, the front-end verification environment will instantiate multiple proxy components corresponding to the sending of different incentive packets. The advantage of constructing a new incentive data packet by derivation and then using overloading to send no longer exists because the corresponding proxy components will not be overloaded. Instead, the incentive packets of different transmission methods are sent to their corresponding proxy components for sending to cover the scenario of multiple proxy components sending data packets simultaneously; on the other hand, in an actual UVM-based verification environment, the constraints in the parent class and the members registered under the field mechanism will be implicitly inherited into the subclass, and the verification personnel need to manually turn off the unnecessary constraints and modify the field permissions of the registered members, which increases the maintenance difficulty of the verification platform and is prone to introducing imperceptible errors into the verification platform.

[0105] It can be seen that compared with the traditional way of using derivation, using the recombination method will not make the information registered in the UVM field mechanism redundant, so that the verification personnel can conveniently use various built-in methods provided by UVM.

[0106] In a specific implementation manner, as Figure 9 shown, step S14, constructing a filter class for mapping the first incentive scenario to the second incentive scenario, and using the filter class to construct the conditional constraints of the new incentive data packet, includes:

[0107] Step S141: Construct a filter class for mapping the first incentive scenario to the second incentive scenario, and instantiate the filter class into the new incentive data packet.

[0108] In the embodiment of the present application, according to the specific information associated with the general protocol information in the second incentive scenario, that is, the non-direct information, a filter class specifically used for calculation is constructed, which is responsible for the mapping relationship between the first incentive scenario and the second incentive scenario. This filter class has the following characteristics: 1. Its input is the first incentive data packet instantiated in the second incentive data packet; 2. Its output is a series of vector tags that can describe a specific scenario, which is named scenario tag (flag); 3. This class is only responsible for calculation and defining a series of methods related to calculating the scenario tag, and does not involve any constraints.

[0109] Step S142: Define a fourth interface in the new incentive data packet for starting the scenario tag calculation of the filter class, and transfer the calculated scenario tag to the corresponding variable in the new incentive data packet based on the fourth interface, so that the variable constructs the conditional constraints of the new incentive data packet according to the scenario tag.

[0110] Wherein, the scenario tag is a vector tag for describing any specific excitation scenario including hardware-specific requirement information; a calculation method for calculating the scenario tag is encapsulated in the fourth interface.

[0111] In the embodiment of the present application, the filter class is instantiated after the new excitation data packet, and relevant interfaces for starting the calculation of the filter class are defined in the new excitation data packet. The operations performed by the filter class calling its own methods are encapsulated therein, and the calculated scenario tag is passed to the corresponding relevant variable in the new excitation data packet, and then a simple constraint related to the specific information is constructed using the scenario tag. The working mode of the filter class is as Figure 10 shown.

[0112] It should be noted that a compositional relationship also exists between the filter class and the new excitation data packet. By using the filter class to process a large amount of data related to the general protocol in the original data packet and generate a multi-bit scenario tag, and using the scenario tag as a conditional constraint to control the constraint solving of the new data packet, the original multi-layer constraints are replaced in this way, which not only simplifies the constraints but also decouples the complex data calculation from the data packet itself and improves the reusability of the data packet.

[0113] It can be seen that a dedicated filtering class for processing a large amount of general protocol information is introduced in the constraint part of the new excitation data packet. The filter class is responsible for storing and processing a large amount of general protocol information and outputting a string of scenario tags (flags) that the verification personnel actually care about on this basis, and then constructing a hierarchical constraint block according to the values corresponding to the actually generated scenario tags. In this way, the mapping between the general protocol and the domain segment values of the excitation scenario can be decoupled from the constraint block, simplifying the constraint block.

[0114] It should be noted that when the generated new excitation data packet is called by the external environment, a unified initialization interface for the external environment to call is formed. By encapsulating the first interface, the second interface, the third interface, the fourth interface, and the randomization method in the second excitation data packet, a fifth interface for calling the new excitation data packet is generated. Further, the new excitation data packet based on the conditional constraint is passed to the corresponding proxy component through the fifth interface, so as to perform excitation sending through the proxy component for front-end verification.

[0115] As Figure 11An exemplary overall implementation code is shown. Based on the combination rather than the traditional derived incentive data packet construction, the existing and perfect incentive data packet instances are instantiated in the new data packet to construct a new data packet in a combined manner. By constructing relevant methods of recombination and recombination in the new data packet as interfaces. In the constraint part of the new incentive data, a dedicated filtering class for processing a large amount of general protocol information is introduced, and a large number of hierarchical constraints that may occur in the complex packet assembly process are simplified into simple constraints marked with switches for different scenarios after being processed by the filter class. In this way, when there is a scenario requirement to convert the general protocol into different transmission methods in the front-end verification, the method in the embodiment of the present application can simplify the verification process, improve the reusability of the verification platform, save verification costs and improve verification efficiency.

[0116] Correspondingly, the embodiment of the present application also discloses a front-end verification device. Refer to Figure 12 As shown, the device includes:

[0117] The first incentive scenario construction module 11 is used to construct a first incentive scenario and obtain a first incentive data packet corresponding to the first incentive scenario; the first incentive scenario is a scenario of interface transmission using a general protocol;

[0118] The second incentive scenario determination module 12 is used to determine a second incentive scenario and obtain a second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting information containing hardware-specific requirements;

[0119] The new incentive data packet generation module 13 is used to unpack the first incentive data packet in the second incentive data packet, and packet the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet;

[0120] The filter class construction module 14 is used to construct a filter class for mapping the first incentive scenario to the second incentive scenario, and use the filter class to construct the conditional constraints of the new incentive data packet;

[0121] The front-end verification module 15 is used to transfer the new incentive data packet based on the conditional constraints to the corresponding proxy component, so as to perform incentive sending through the proxy component for front-end verification.

[0122] Among them, for the more specific working processes of the above-mentioned various modules, reference can be made to the corresponding content disclosed in the foregoing embodiments, and details will not be elaborated herein.

[0123] It can be seen that through the above solution of this embodiment, it includes: constructing a first excitation scenario and obtaining a first excitation data packet corresponding to the first excitation scenario; the first excitation scenario is a scenario for interface transmission using a general protocol; determining a second excitation scenario and obtaining a second excitation data packet corresponding to the second excitation scenario; the second excitation scenario is a specific excitation scenario for transmitting specific excitation information including hardware-specific requirements; unpacking the first excitation data packet in the second excitation data packet, and packetizing the unpacked first excitation data packet and the second excitation data packet to generate a new excitation data packet; constructing a filter class for mapping the first excitation scenario to the second excitation scenario, and constructing conditional constraints for the new excitation data packet using the filter class; and transmitting the new excitation data packet based on the conditional constraints to a corresponding proxy component for excitation sending through the proxy component for front-end verification.

[0124] The beneficial technical effects of this application are as follows: On the one hand, this application breaks the traditional construction method of excitation data packets based on derivation. Instead, it directly constructs a new data packet in the second excitation data packet corresponding to a specific excitation scenario by reorganizing the existing and perfect first excitation data packet, realizing that the existing and perfect excitation data packet is instantiated in the new data excitation packet. This is applicable to the situation of converting a general protocol into other specific excitation scenarios suitable for transmitting specific excitation information including hardware-specific requirements. Compared with the traditional method, there is no need to construct complex hierarchical constraints again. Only by unpacking and then repackaging can a brand-new excitation packet be obtained. In this way, the development difficulty of the new data packet in the front-end verification process is reduced, and the process of constructing excitation packets for this general protocol in different on-chip transmission protocols is simplified, and repetitive code writing is eliminated. On the other hand, a dedicated filter class for processing a large amount of general protocol information is introduced in the constraint part of the new excitation data. In this way, the original multi-layer constraints are replaced, which not only simplifies the constraints but also decouples complex data calculations from the data packet itself while improving the reusability of the data packet. Through the filter class, the mapping between the general protocol and the corresponding domain segment values of the excitation scenario can be decoupled from the constraint block, simplifying the constraint block. When the mapping relationship changes, the complex constraint block does not need to be rewritten by overloading the filter class. It can be seen that when there is a scenario requirement of converting a general protocol into different transmission methods in front-end verification, adopting the method in this application can simplify the verification process, improve the reusability of the verification platform, save verification costs, and improve verification efficiency.

[0125] Furthermore, the embodiment of this application also discloses an electronic device. Figure 13 It is a structural diagram of an electronic device 20 shown according to an exemplary embodiment. The content in the figure cannot be considered as any limitation on the scope of use of this application.

[0126] Figure 13Schematic diagram of the structure of an electronic device 20 provided by an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the front-end verification method disclosed in any of the foregoing embodiments. In addition, the electronic device 20 in this embodiment may specifically be a server.

[0127] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of the present application, and specific limitations are not imposed here; the input / output interface 25 is used to obtain external input data or output data to the outside, and its specific interface type can be selected according to specific application requirements, and specific limitations are not made here.

[0128] In addition, as a carrier for resource storage, the memory 22 may be a read-only memory, a random access memory, a magnetic disk, or an optical disc, etc., and the resources stored thereon may include an operating system 221, a computer program 222, and data 223, etc., and the data 223 may include various types of data. The storage method may be transient storage or permanent storage.

[0129] Among them, the operating system 221 is used to manage and control each hardware device and the computer program 222 on the electronic device 20, and it may be Windows Server, Netware, Unix, Linux, etc. In addition to the computer program that can be used to complete the front-end verification method executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program that can be used to complete other specific tasks.

[0130] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium. The computer-readable storage medium mentioned here includes random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, or optical discs, or any other form of storage medium known in the technical field. Among them, when the computer program is executed by the processor, the foregoing front-end verification method is implemented. For the specific steps of this method, reference may be made to the corresponding content disclosed in the foregoing embodiments, and details are not described herein again.

[0131] In the present specification, the various embodiments are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description in the method section.

[0132] The steps of the front-end verification method or algorithm described in combination with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium well-known in the technical field.

[0133] Finally, it should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0134] The above has introduced in detail a front-end verification method, apparatus, device and storage medium provided by the present invention. Specific examples are used herein to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A front-end verification method, characterized in that, Including: Construct a first incentive scenario and obtain a first incentive data packet corresponding to the first incentive scenario; The first incentive scenario is a scenario for interface transmission using a general protocol; Determine a second incentive scenario and obtain a second incentive data packet corresponding to the second incentive scenario; the second incentive scenario is a specific incentive scenario for transmitting specific incentive information including hardware-specific requirements; Unpack the first incentive data packet in the second incentive data packet, and packetize the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet; Construct a filter class for mapping the first incentive scenario to the second incentive scenario, and use the filter class to construct conditional constraints for the new incentive data packet; Pass the new incentive data packet based on the conditional constraints to the corresponding proxy component for incentive sending through the proxy component for front-end verification.

2. The front-end verification method according to claim 1, wherein The constructing a first incentive scenario and obtaining a first incentive data packet corresponding to the first incentive scenario includes: Select a target incentive scenario from several incentive scenarios based on a preset selection strategy and obtain a target incentive data packet corresponding to the target incentive scenario; Obtain a transaction-level data packet provided by a verification component corresponding to the general protocol, and instantiate the transaction-level data packet in the target incentive data packet to construct the first incentive scenario; Associate the protocol domain segment of the target incentive scenario with the general protocol based on the first incentive scenario to obtain a first incentive data packet corresponding to the first incentive scenario.

3. The front-end verification method according to claim 1, wherein The unpacking the first incentive data packet in the second incentive data packet and packetizing the unpacked first incentive data packet and the second incentive data packet to generate a new incentive data packet includes: Define a first interface in the second incentive data packet for obtaining the first incentive data packet; Randomize the first incentive data packet, and obtain the randomized first incentive data packet based on the first interface, so as to load the randomized first incentive data packet into the second incentive data packet; Define a second interface in the second incentive data packet for calling the protocol domain segment corresponding to the general protocol in the first incentive data packet, so as to unpack the first incentive data packet based on the second interface to obtain the unpacked first incentive data packet; Define a third interface in the second incentive data packet for packing and reorganizing the incentive data packet, and based on the third interface, pack and transmit the unpacked first incentive data packet to the corresponding protocol domain segment in the second incentive data packet for initialization; When the initialization of the second incentive data packet is completed, packetize the unpacked first incentive data packet and the second incentive data packet to generate the new incentive data packet.

4. The front-end verification method according to claim 3, characterized in that The constructing a filter class for mapping the first incentive scenario to the second incentive scenario and using the filter class to construct conditional constraints for the new incentive data packet includes: Construct a filter class for mapping the first excitation scenario to the second excitation scenario, and instantiate the filter class into the new excitation data packet; Define a fourth interface in the new excitation data packet for starting the filter class to perform scenario tag calculation, and transfer the calculated scenario tag to a corresponding variable in the new excitation data packet based on the fourth interface, so that the variable constructs a conditional constraint for the new excitation data packet according to the scenario tag; Wherein, the scenario tag is a vector tag describing any specific excitation scenario containing hardware-specific requirement information; the fourth interface encapsulates a calculation method for calculating the scenario tag.

5. The front-end verification method according to claim 4, wherein After constructing the filter class for mapping the first excitation scenario to the second excitation scenario and constructing the conditional constraint of the new excitation data packet using the filter class, it further includes: Encapsulate the first interface, the second interface, the third interface, the fourth interface, and the randomization method in the second excitation data packet to generate a fifth interface for calling the new excitation data packet; Correspondingly, the step of transferring the new excitation data packet based on the conditional constraint to a corresponding proxy component for performing excitation sending through the proxy component for front-end verification includes: Transfer the new excitation data packet based on the conditional constraint to a corresponding proxy component through the fifth interface, so that the proxy component performs excitation sending for front-end verification.

6. The front-end verification method according to claim 4, characterized in that The step of transferring the new excitation data packet based on the conditional constraint to a corresponding proxy component for performing excitation sending through the proxy component for front-end verification includes: Transfer the new excitation data packet based on the conditional constraint to a corresponding proxy component, so that the proxy component obtains the scenario tag through the filter class and performs excitation sending for the new excitation data packet according to the scenario tag for front-end verification.

7. The front-end verification method according to any one of claims 1 to 6, characterized in that, It further includes: When the conditional constraint changes, derive the filter class to generate a new filter, and reload the new filter into the new excitation data packet.

8. A front-end verification device, characterized in that, It includes: A first excitation scenario construction module for constructing a first excitation scenario and obtaining a first excitation data packet corresponding to the first excitation scenario; The first excitation scenario is a scenario for interface transmission using a general protocol; A second excitation scenario determination module for determining a second excitation scenario and obtaining a second excitation data packet corresponding to the second excitation scenario; the second excitation scenario is a specific excitation scenario for transmitting information containing hardware-specific requirements; A new excitation data packet generation module for unpacking the first excitation data packet in the second excitation data packet and packing the unpacked first excitation data packet and the second excitation data packet to generate a new excitation data packet; A filter class construction module for constructing a filter class for mapping the first excitation scenario to the second excitation scenario and constructing the conditional constraint of the new excitation data packet using the filter class; A front-end verification module for passing the new incentive data packet based on the conditional constraint to a corresponding proxy component, so as to perform incentive sending through the proxy component for front-end verification.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein, the memory is used for storing a computer program, and the computer program is loaded and executed by the processor to implement the front-end verification method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, For storing a computer program; wherein the computer program, when executed by a processor, implements the front-end verification method according to any one of claims 1 to 7.

Images