Verification platform construction method and device, equipment and storage medium
Through the automated identification of the mutually exclusive function of integrated circuit design, the multi-domain verification platform code is generated, which solves the problem of insufficient accuracy and scalability in traditional methods, and realizes efficient and flexible verification platform construction.
Patent Information
- Application Number
- CN202510549428.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-28
- Publication Date
- 2025-08-12
AI Technical Summary
Traditional single-domain verification methods are difficult to meet the verification requirements of mutually exclusive functional areas in complex integrated circuits, with low accuracy and low efficiency in manual analysis, and multi-domain verification architectures are difficult to flexibly expand and adapt.
By automatically identifying the function description documents and register transmission-level codes of the design to be tested, a list of mutually exclusive functions is generated, and multi-domain verification platform code is rendered based on these lists, avoiding manual intervention and improving accuracy and flexibility.
It realizes an efficient and accurate multi-domain verification platform construction, can adapt to design changes, improve verification efficiency and accuracy, and reduce the influence of human factors.
Smart Images
Figure CN120470985A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of integrated circuit technology, and in particular to a verification platform construction method, apparatus, device and storage medium. Background Art
[0002] With the development of integrated circuit technology, the number of designs under test (DUT) with mutually exclusive functional areas is increasing, and the traditional single-domain verification method is difficult to meet the verification requirements of the DUT.
[0003] In related technologies, a multi-domain verification architecture based on UVM (Universal Verification Methodology) verifies designs under test (DUTs) with mutually exclusive functional areas. However, these solutions often rely on manual analysis of the DUT to identify the mutually exclusive domains in the DUT, and require manual configuration of the multi-domain verification architecture. This is significantly affected by human factors, resulting in low accuracy and efficiency. Furthermore, as the functions of the DUT continue to increase and change, the above-mentioned solutions are difficult to flexibly expand and adapt, making it increasingly difficult to maintain and update the multi-domain verification architecture, resulting in low verification efficiency. Summary of the Invention
[0004] The present application provides a verification platform construction method, apparatus, device and storage medium to at least solve the problems of low efficiency, low accuracy and poor flexibility in the related art when constructing a multi-domain verification architecture for a design to be tested with mutually exclusive functional areas.
[0005] This application provides a verification platform construction method, including:
[0006] Obtain the functional description document and register transfer level code of the design to be tested;
[0007] Identifying mutually exclusive functions on the function description document to obtain a first mutually exclusive function list;
[0008] performing mutually exclusive function identification on the register transfer level code to obtain a second mutually exclusive function list;
[0009] Based on the first mutually exclusive function list and the second mutually exclusive function list, the verification platform template file is rendered to generate a multi-domain verification platform code corresponding to the design to be tested; wherein each mutually exclusive function corresponds to an intelligent agent.
[0010] This application also provides a verification platform construction device, including:
[0011] An acquisition module is used to obtain the functional description document and register transfer level code of the design to be tested;
[0012] a first identification module, configured to identify mutually exclusive functions in the function description document to obtain a first mutually exclusive function list;
[0013] a second identification module, configured to identify mutually exclusive functions on the register transfer level code to obtain a second mutually exclusive function list;
[0014] A generation module is used to perform template rendering on the verification platform template file based on the first mutually exclusive function list and the second mutually exclusive function list to generate a multi-domain verification platform code corresponding to the design to be tested; wherein each mutually exclusive function corresponds to an intelligent agent.
[0015] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned verification platform construction methods when executing the computer program.
[0016] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned verification platform construction methods are implemented.
[0017] Through this application, it is possible to automatically identify mutually exclusive functions based on the functional description document of the design to be tested, obtain a first mutually exclusive function list for indicating the mutually exclusive relationship of the functions of the design to be tested, and automatically identify mutually exclusive functions based on the register transfer level code of the design to be tested, obtain a second mutually exclusive function list for indicating the mutually exclusive relationship of the hardware logic of the design to be tested, thereby efficiently and accurately identifying the mutually exclusive function information contained in the design to be tested, without the need to manually analyze the design to be tested and configure the verification platform, avoiding the influence of human factors on the construction of the verification platform, and improving the efficiency and accuracy of the subsequent establishment of multi-domain verification platform code based on the mutually exclusive function information. Moreover, when the design to be tested changes, it only needs to update the corresponding functional description document and register transfer level code to regenerate the corresponding multi-domain verification platform code. The solution is flexible and highly scalable. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0019] Figure 1 A flow chart of a verification platform construction method provided by an embodiment of the present invention;
[0020] Figure 2 A schematic flow chart of another verification platform construction method provided by an embodiment of the present invention;
[0021] Figure 3 A schematic diagram of a process for generating a complete mutually exclusive function list according to an embodiment of the present invention;
[0022] Figure 4 A schematic diagram of a process for generating a multi-domain verification platform according to an embodiment of the present invention;
[0023] Figure 5 A schematic diagram of the structure of a multi-domain verification platform provided by an embodiment of the present invention;
[0024] Figure 6 A structural block diagram of a verification platform construction device according to an embodiment of the present application;
[0025] Figure 7 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION
[0026] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0027] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.
[0028] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.
[0029] UVM (Universal Verification Methodology) is a standardized verification methodology based on SystemVerilog (a hardware description and verification language). It is widely used in the field of integrated circuit verification. It constructs a hierarchical verification platform using modular, reusable verification components. It supports transaction-level modeling (TLM), random constraint testing, functional coverage collection, and automated regression testing, enabling efficient verification of complex designs for correctness, timing, and power consumption. When verifying the DUT, UVM employs a transaction-level modeling mechanism. A stimulus transaction sequencer schedules stimulus transactions, which are then converted by a driver into timing signals for the DUT interface. Monitors collect DUT outputs in real time and transmit them to a scoreboard via TLM ports. These outputs are automatically compared with expected values and combined with SystemVerilog assertions (SVAs) to detect protocol and timing violations in real time. Functional coverage models (covergroups) are defined to track key metrics such as signal combinations and state machine paths. In verification, a UVM domain refers to a collection of logically or physically isolated functional modules. Mutual exclusion refers to operations that cannot be performed simultaneously, either logically or behaviorally (such as read / write conflicts or mode switching). The UVM multi-domain verification platform can structurally isolate and manage multiple domains, enabling simultaneous or time-sharing verification of different domains as needed, while ensuring the correctness of the test logic for conflicting domains. Scripts written in a general-purpose scripting language can be used to call EDA (Electronic Design Automation) tools to initiate the UVM verification platform and verify the design under test.
[0030] With the development of integrated circuit technology, the number of devices under test (DUTs) with mutually exclusive functional areas (Mutually Exclusive Functional Areas) is increasing. For example, in the design of complex communication equipment and processors, there are multiple reset regions, channels with different rates or protocols, and these functional modules are independent of each other. Traditional single-domain verification methods are difficult to meet the verification requirements of the DUT. Specifically, in a single-domain verification environment, all components in the design are controlled by the UVM single-stage scheduler, which cannot effectively handle the mutually exclusive functions within the DUT. This leads to high error rates and low efficiency when facing dynamic configuration and function switching.
[0031] In the related art, a multi-domain verification architecture based on UVM verifies the design to be tested with mutually exclusive functional areas. However, the above schemes often rely on manual analysis of the design to be tested to identify the mutually exclusive domains in the design to be tested. This manual analysis method not only takes a lot of time and energy, but also manual judgment may miss some potential mutually exclusive functions, or misjudge non-mutually exclusive functions as mutually exclusive functions, resulting in low accuracy. In addition, when creating a multi-domain verification architecture, it relies on manual configuration. Since the relationship between the components and the various domains in the multi-domain verification architecture is relatively complex, it requires a high level of professionalism from the human beings, and is also greatly affected by human factors, affecting the accuracy and reliability of the verification and low efficiency. In addition, with the diversification of the types and scales of the designs to be tested, as well as the continuous increase and change of functions, the above schemes are difficult to achieve flexible expansion and adaptation, and the maintenance and updating of the multi-domain verification architecture are becoming increasingly difficult. It is impossible to quickly and effectively adapt to new design requirements, resulting in low verification efficiency and affecting the progress of the entire work.
[0032] The embodiment of the present application provides a verification platform construction method, Figure 1 This is a flow chart of a verification platform construction method provided by an embodiment of the present invention. Figure 1 As shown, the process includes the following steps.
[0033] The specific steps are as follows:
[0034] Step S101: Obtain a functional description document and register transfer level code of a design to be tested.
[0035] The design under test is the target design that needs to be tested and verified. The functional description document of the design under test is used to indicate the functions, interfaces and performance indicators of the design under test, such as basic information, function definition, implementation specifications and auxiliary information. Basic information includes version number, release date, associated design documents and verification scope. Function definition includes test objectives, test types, test scenarios and verification methods. Implementation specifications include stimulus rules, expected responses, coverage indicators, etc. Auxiliary information includes version traceability information. The register transfer level (RTL) code of the design under test uses a hardware description language to describe the hardware logic structure and behavior of the design under test, including port definitions, configurable parameters, global control logic, combinational logic, timing logic, storage structure, bus protocol, error detection mechanism, etc. It can be directly used as input for simulation and formal verification to map out the hardware circuit corresponding to the design under test. When building a verification platform, first obtain the functional description document and register transfer level code of the design under test. For example, export the functional description document of the design under test from the design requirements library and load the register transfer level code of the design under test from the code repository.
[0036] Step S102: performing mutually exclusive function identification on the function description document to obtain a first mutually exclusive function list.
[0037] Specifically, the function description document is segmented into text and then matched with preset keywords describing mutually exclusive functions. For example, the keywords may be "cannot be performed simultaneously", "forbidden to be enabled simultaneously", etc., so as to identify mutually exclusive functions in the function description document, and record the identified mutually exclusive function pairs in a table to obtain a first mutually exclusive function list.
[0038] Step S103: performing mutually exclusive function identification on the register transfer level code to obtain a second mutually exclusive function list.
[0039] Specifically, the hardware logic relationship in the register transfer level code is parsed, functional modules with mutually exclusive relationships at the hardware implementation level are identified, corresponding functional information is extracted, and mutually exclusive functional pairs are recorded in a table to obtain a second mutually exclusive function list.
[0040] Step S104 : Based on the first mutually exclusive function list and the second mutually exclusive function list, the verification platform template file is rendered to generate a multi-domain verification platform code corresponding to the design to be tested.
[0041] The verification platform template file is a pre-created template file that defines the basic architecture and component framework of the verification platform. It contains dynamically replaceable or generated parts. Specifically, the first and second mutually exclusive function lists are converted into a data dictionary as input parameters for template rendering. Based on this data dictionary, the replaceable parts in the verification platform template file are replaced accordingly and logical execution is performed, generating the final code text as the template rendering result. The template rendering result is then written into a newly created target file, generating the final executable code file as the multi-domain verification platform code corresponding to the design under test. Logical execution refers to generating corresponding agent code blocks based on mutually exclusive functions, with each mutually exclusive function corresponding to an independent agent.
[0042] The verification platform construction method provided in this embodiment can automatically identify mutually exclusive functions based on the functional description document of the design to be tested, obtaining a first mutually exclusive function list used to indicate the mutually exclusive relationship between the functions of the design to be tested, and automatically identify mutually exclusive functions based on the register transfer level code of the design to be tested, obtaining a second mutually exclusive function list used to indicate the mutually exclusive relationship between the hardware logic of the design to be tested, thereby efficiently and accurately identifying the mutually exclusive function information contained in the design to be tested, eliminating the need for manual analysis of the design to be tested and configuration of the verification platform, avoiding the impact of human factors on the construction of the verification platform, and improving the efficiency and accuracy of the subsequent establishment of multi-domain verification platform code based on the mutually exclusive function information. In addition, when the design to be tested changes, only the corresponding functional description document and register transfer level code need to be updated to regenerate the corresponding multi-domain verification platform code. The solution is flexible and highly scalable.
[0043] In this embodiment, a verification platform construction method is provided, which can be used for notebook computers, desktop computers, servers, etc. Figure 2 This is a flow chart of another verification platform construction method provided by an embodiment of the present invention. Figure 2 As shown, the process includes the following steps.
[0044] The specific steps are as follows:
[0045] Step S201: Obtain a functional description document and register transfer level code of the design to be tested.
[0046] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.
[0047] Step S202: performing mutually exclusive function identification on the function description document to obtain a first mutually exclusive function list.
[0048] Specifically, the above step S202 includes:
[0049] S2021, performing a word segmentation operation on the function description document to obtain each segmented word.
[0050] Optionally, a pre-created function description document recognition script can be used in conjunction with the Natural Language Processing Library (NLTK) to perform mutually exclusive function recognition on the function description document. First, the function description document is segmented using the document segmentation function of the function description document recognition script, thereby segmenting the function description document from continuous text into independent words or symbols to obtain the individual segmented words. In other words, the segmented words here refer to the independent words or symbols obtained after segmentation.
[0051] Exemplarily, the text of the function description document is tokenized by the word_tokenize function (a function for text segmentation) in the natural language processing library. Taking the sentence "The data sending function and the data receiving function cannot be carried out simultaneously" as an example, after tokenization, it becomes "['data','sending', 'function', 'and', 'data','receiving', 'function', 'cannot','simultaneously', 'carry out']".
[0052] S2022, stopword filtering is performed on the multiple tokenized words obtained after the segmentation to obtain the filtered tokenized words.
[0053] Then, through the preprocessing function of the function description document recognition script, stopword filtering is performed on the multiple tokenized words obtained after the segmentation to remove common words that are not substantially helpful for the recognition of mutually exclusive functions, so as to reduce the data volume and improve the analysis efficiency, and obtain the filtered tokenized words.
[0054] Exemplarily, stopwords in the text are removed through the stopwords set (stopword set) in the natural language processing library, such as "and", "of", "in".
[0055] S2023, the filtered tokenized words are lemmatized to obtain the lemmatized tokenized words.
[0056] Exemplarily, through the WordNetLemmatizer tool (lemmatization tool) in the natural language processing library, the filtered tokenized words are lemmatized, and the words in the tokenized words are converted into the basic form. For example, "running" is lemmatized to "run", so that the same word in different forms can be uniformly processed, reducing the data volume and improving the analysis efficiency.
[0057] S2024, keyword matching and syntactic structure analysis are performed on the lemmatized tokenized words to obtain the mutually exclusive relationship between the functions corresponding to the lemmatized tokenized words, so as to establish the first mutually exclusive function list.
[0058] Finally, through the function description document recognition script, keyword matching and syntactic structure analysis are performed on the lemmatized tokenized words to identify the mutually exclusive relationship between the functions corresponding to the lemmatized tokenized words. For example, when keywords such as "cannot be carried out simultaneously", "mutually exclusive", "prohibited from being enabled simultaneously" and related function description statements appear in the document, the corresponding function information is extracted and the mutually exclusive function pairs are recorded in the tabular document to obtain the first mutually exclusive function list.
[0059] Exemplarily, if it is detected that the description is "Function A is mutually exclusive with Function B", then Function A and Function B are recorded as a mutually exclusive function pair in the tabular document.
[0060] Step S203: performing mutually exclusive function identification on the register transfer level code to obtain a second mutually exclusive function list.
[0061] Specifically, the above step S203 includes:
[0062] S2031, parsing the register transfer level code to extract the signal assignment relationship and logic judgment statements of each functional module in the design to be tested.
[0063] Optionally, in conjunction with an RTL code parsing library, a pre-created register transfer level code recognition script can be used to identify mutually exclusive functions within the register transfer level code. The RTL code parsing library can convert the register transfer level code into an operational internal representation, facilitating analysis of the signals and logical relationships therein. Specifically, the register transfer level code is first parsed using the register transfer level code recognition script to extract the signal assignment relationships and logical judgment statements of each functional module in the design under test.
[0064] S2032: Analyze the mutual exclusion relationship between the functional modules based on the signal assignment relationship and the logic judgment statements of the functional modules to establish a second mutually exclusive function list.
[0065] Next, based on the signal assignment relationship and logic judgment statements of each functional module, functional modules with mutually exclusive relationships at the hardware implementation level are identified and recorded as mutually exclusive function pairs in a table document to obtain a second mutually exclusive function list.
[0066] Specifically, when analyzing the mutually exclusive relationship between various functional modules, the signal assignment relationship between different functional modules can be analyzed. When the enable signals of different functional modules are controlled by the same control signal, and the control signal can only control the enable signal of one functional module at the same time, it is determined that there is a mutually exclusive relationship between the different functional modules; and, by analyzing the logical judgment statements of different functional modules (such as if-else statements), it is determined that the functional modules corresponding to different judgment branches of the logical judgment statements are in a mutually exclusive relationship.
[0067] Optionally, when analyzing the mutually exclusive relationship between various functional modules, the state machine information in the register transfer level code can also be extracted, and then the state machine information is analyzed to obtain the state transfer conditions and the state transition diagram. Finally, based on the state transfer conditions and the state transition diagram (STD), different state transitions that cannot occur simultaneously at the same time are identified and marked as mutually exclusive functions. Among them, the state machine is a model used to describe the transition of a system between different states. The state machine information includes state, event, transition and action. The state is used to indicate the state of the system at a certain moment, the event is used to indicate the external signal or condition that triggers the state transition, the transition is used to indicate the transfer condition between states, and the action is used to indicate the operation performed during the state transition.
[0068] Step S204 : Based on the first mutually exclusive function list and the second mutually exclusive function list, the verification platform template file is rendered to generate a multi-domain verification platform code corresponding to the design to be tested.
[0069] Since the mutually exclusive function pairs included in the first mutually exclusive function list and the mutually exclusive function pairs included in the second mutually exclusive function list may be repeated, it is necessary to remove duplicates when merging the first mutually exclusive function list and the second mutually exclusive function list to reduce repeated calculations, improve efficiency, and form a complete and accurate mutually exclusive function list. Taking the example of converting the first mutually exclusive function list and the second mutually exclusive function list into corresponding data dictionaries and then merging them, the mutually exclusive function pairs in the first mutually exclusive function list are first extracted to generate a first intermediate data dictionary, and the hardware mutual exclusion logic (also recorded as mutually exclusive function pairs) in the second mutually exclusive function list is extracted to generate a second intermediate data dictionary. Then, the first intermediate data dictionary and the second intermediate data dictionary are compared to perform mutually exclusive function conflict detection and fusion to obtain a complete mutually exclusive function data dictionary.
[0070] It should be noted that in actual application scenarios, the first mutually exclusive function list and the second mutually exclusive function list can also be merged first, and the merged mutually exclusive functions can be recorded in a table document to form a complete mutually exclusive function list and then converted into a data dictionary. Figure 3 A flow chart of generating a complete mutually exclusive function list provided by an embodiment of the present invention is shown as follows: Figure 3As shown, the mutually exclusive functions of the function description document and RTL code (register transfer level code) of the design to be tested are first identified through a script. Specifically, the function description document is analyzed and keywords are extracted to obtain a first mutually exclusive function list, and the RTL code is analyzed for signal assignment relationships and logical judgment statements to obtain a second mutually exclusive function list. The first mutually exclusive function list and the second mutually exclusive function list are then merged to obtain a complete mutually exclusive function list.
[0071] Then, the template rendering library Jinja2 is adopted to perform template rendering on the verification platform template file. First, the template class (Template class) of the template rendering library Jinja2 is used to load the pre-created verification platform template file, in which the basic architecture and component framework of the UVM verification platform are defined. In the verification platform template file, a special markup syntax is used to identify the part that needs to be dynamically replaced or generated according to the mutual exclusion function, i.e., the placeholder. Then, the mutual exclusion function data dictionary is passed in through the rendering method (render method), and the placeholder in the verification platform template file is replaced based on the mutual exclusion function data dictionary to perform template rendering on the verification platform template file, so as to obtain the rendered verification platform template file, i.e., complete code text.
[0072] Finally, the rendered verification bench template file is compiled and executed, dynamically generating the components and connections between them corresponding to each mutually exclusive function in the mutually exclusive function data dictionary. These components are then written into the newly created target file, resulting in the multi-domain verification bench code corresponding to the design under test. Each mutually exclusive function corresponds to an agent.
[0073] It should be noted that the number of verification domains (UVM domains) does not correspond to the number of agents. They need to be set based on the actual functional complexity and verification requirements. For example, a single agent can cover the entire domain, multiple mutually exclusive functions in the same domain can be assigned independent agents, and multiple functions within the same domain or across domains can share a single agent. Taking a single agent covering the entire domain as an example, when performing template rendering, a verification platform with multiple verification domains is generated by rendering the verification platform template file based on the identified mutually exclusive functions, with each verification domain corresponding to an agent.
[0074] Optionally, the verification platform template file contains the general structure of the UVM verification platform and replaceable placeholders. During rendering, the placeholders are replaced with the configuration and test case code of a specific verification domain, such as environment configuration code, agent code, sequence code, and test case code, based on the mutually exclusive functions. Multiple verification platform template files can also be defined, each containing the structure and configuration for different types of verification domains, and each containing different placeholders, so as to flexibly adapt to different types and sizes of designs under test. During template rendering, the mutually exclusive function information in the data dictionary is replaced with the corresponding placeholders through the template rendering engine.
[0075] Optionally, the template rendering engine also adjusts the configuration in the UVM environment based on the mutually exclusive function information, such as the resource allocation in the UVM environment (including the size and number of mailboxes, events, and queues) to adapt to the verification requirements of different mutually exclusive functions. The template rendering engine also configures the execution frequency and timeout period of different UVM components in the verification platform template file based on the performance requirements of the mutually exclusive functions to ensure that the performance characteristics of different mutually exclusive functions can be fully tested.
[0076] Optionally, the generated multi-domain verification platform code is used to verify the design under test. First, the multi-domain verification platform code corresponding to the design under test is launched. Next, the input and output characteristics and state transition conditions of each function in the mutually exclusive function data dictionary are analyzed, and different stimulus data and test processes are set. Specifically, the input and output characteristics of each function in the mutually exclusive function data dictionary are analyzed, and different stimulus data are set to ensure that the stimulus data meets the constraints of the mutually exclusive function and can fully test the boundaries and abnormal conditions of the mutually exclusive function. The state transition conditions of each function in the mutually exclusive function data dictionary are analyzed, and different test processes are set, including sequential access of multiple states and branch testing under different conditions, to test the correctness of the mutually exclusive function under different states and conditions. This generates test case sequences corresponding to each verification domain, improving the accuracy of verification. The test case sequences are customized according to the mutually exclusive function, ensuring that each test case sequence only verifies the corresponding mutually exclusive function. Finally, the test case sequences corresponding to each verification domain are sent to the corresponding test interface to test the design under test and obtain the mutually exclusive function verification results. Specifically, the agent in each verification domain sends the generated test case sequence to the corresponding design interface under test. During the test process, the agent uses UVM's built-in mechanisms, such as the UVM analysis port, transaction recording, and reporting mechanisms, to collect and analyze the data and transactions during the test. After the test is completed, a detailed test report is generated based on the UVM reporting mechanism. This report contains the test results of different verification domains and presents the verification results separately according to different mutually exclusive functions, such as information indicating whether the verification was successfully completed, whether the verification was passed, and the corresponding test coverage information.
[0077] As one or more specific application examples of the embodiments of the present invention, the optimal implementation scheme or the solution that the inventor most wants to embody is described below in combination with specific application scenarios.
[0078] The present invention pre-creates a verification platform template file containing dynamic fields, which contains an environment, an agent, a reference model, and a scoreboard. The environment serves as the top-level container of the entire verification environment and is responsible for managing and coordinating the agent, the reference model, and the scoreboard. The agent class in the verification platform template file is defined as having a general structure, including subcomponents such as a driver, a monitor, and an incentive transaction sequencer. The driver is responsible for sending the incentive data to the design under test, the monitor is used to monitor the output response of the design under test, and the incentive transaction sequencer is responsible for managing the execution of the incentive sequence. In the verification platform template file, a special tag syntax (Jinja2's syntax {{variable_name}}) is used to identify the parts that need to be dynamically replaced or generated according to mutually exclusive functions. When defining an agent instance, the name of the agent is represented by the {{agent_name}} tag. For parts that need to be cyclically generated according to the number of mutually exclusive functions, such as when defining multiple agent instances, Jinja2's loop control structure is used to mark them.
[0079] Figure 4A flow chart of generating a multi-domain verification platform provided by an embodiment of the present invention. The multi-domain verification platform is generated by a pre-created multi-domain verification platform generation script. A generate_uvm_platform function is defined in the multi-domain verification platform generation script. The input parameters of the generate_uvm_platform function are the mutually exclusive function list mutual_exclusive_functions and the verification platform path template_path (custom name) obtained after the mutually exclusive function identification of the function description document and the register transfer level code. The generate_uvm_platform function uses the Jinja2 library for template rendering. Specifically, the verification platform template file is loaded using the Template class of Jinja2, and the data dictionary converted from the mutually exclusive function list is passed in for template rendering through the render method. During rendering, the corresponding agent instance and incentive transaction are generated for each function according to the mutually exclusive functions in the data dictionary, and the function-related parameters (such as function name, signal port, etc.) are passed to the agent through variable substitution, so that the agent can realize the adaptation of the function to the specific function (Specific Function, referring to the independent logical unit or behavior that needs to be verified in the design to be tested, such as protocol function, hardware operation, etc.). Next, based on the tags in the verification platform template file and the incoming data, the corresponding UVM component instances and connection relationships are dynamically generated to obtain the code text. Finally, the code text is written to a new file, which is the automatically generated multi-domain verification platform code.
[0080] For example, Figure 5 The structural diagram of the multi-domain verification platform provided for the embodiment of the present invention. Taking two agents as an example, the multi-domain verification platform includes agent A and agent B, agent A corresponds to the design to be tested of UVM domain A (Domain_A), and agent B corresponds to the design to be tested of UVM domain B (Domain_B). The driver is responsible for sending the incentive transaction (agent A corresponds to incentive transaction Sequence_A, and agent B corresponds to incentive transaction Sequence_B) to the design to be tested, the monitor is used to monitor the output response of the design to be tested, and the incentive transaction sequencer is responsible for managing the execution of the incentive transaction. The number of agents in the multi-domain verification platform is determined based on the mutually exclusive function obtained in the aforementioned steps, and a corresponding agent and incentive transaction are created for each function that is mutually exclusive with other functions.
[0081] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.
[0082] The embodiment of the present application also provides a verification platform construction device, such as Figure 6 As shown, it includes: an acquisition module 601, a first recognition module 602, a second recognition module 603 and a generation module 604.
[0083] An acquisition module 601 is used to acquire a functional description document and register transfer level code of a design to be tested;
[0084] A first identification module 602 is configured to identify mutually exclusive functions in the function description document to obtain a first mutually exclusive function list;
[0085] A second identification module 603 is configured to identify mutually exclusive functions on the register transfer level code to obtain a second mutually exclusive function list;
[0086] The generation module 604 is used to perform template rendering on the verification platform template file based on the first mutually exclusive function list and the second mutually exclusive function list to generate a multi-domain verification platform code corresponding to the design to be tested; wherein each mutually exclusive function corresponds to an intelligent agent.
[0087] For the description of the features in the embodiment corresponding to the verification platform construction device, please refer to the relevant description of the embodiment corresponding to the verification platform construction method, and no further details will be given here.
[0088] The embodiment of the present application also provides an electronic device, such as Figure 7 As shown, it includes a memory 10 and a processor 20, the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above-mentioned verification platform construction method embodiments.
[0089] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned verification platform construction method embodiments when running.
[0090] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.
[0091] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned verification platform construction method embodiments are implemented.
[0092] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned verification platform construction method embodiments.
[0093] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0094] The above is a detailed introduction to a verification platform construction method, device, equipment and storage medium provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of this application.
Claims
1. A verification platform construction method, characterized in that: The method comprises: Obtain the functional description document and register transfer level code of the design to be tested; Identifying mutually exclusive functions on the function description document to obtain a first mutually exclusive function list; performing mutually exclusive function identification on the register transfer level code to obtain a second mutually exclusive function list; Based on the first mutually exclusive function list and the second mutually exclusive function list, the verification platform template file is rendered to generate a multi-domain verification platform code corresponding to the design to be tested; wherein each mutually exclusive function corresponds to an intelligent agent.
2. The verification platform construction method according to claim 1, characterized in that: The step of identifying mutually exclusive functions on the function description document to obtain a first mutually exclusive function list includes: Performing a word segmentation operation on the function description document to obtain segmented words; Performing stop word filtering on the multiple segmented words to obtain filtered segmented words; Perform word form restoration on each filtered word to obtain the restored word; Keyword matching and grammatical structure analysis are performed on each restored word segment to obtain mutually exclusive relationships between functions corresponding to each restored word segment, so as to establish a first mutually exclusive function list.
3. The verification platform construction method according to claim 1, characterized in that: The step of performing mutually exclusive function identification on the register transfer level code to obtain a second mutually exclusive function list includes: Parsing the register transfer level code to extract the signal assignment relationship and logic judgment statements of each functional module in the design to be tested; Based on the signal assignment relationship and logic judgment statements of the various functional modules, the mutual exclusion relationship between the various functional modules is analyzed to establish a second mutually exclusive function list.
4. The verification platform construction method according to claim 3, characterized in that: The analyzing the mutually exclusive relationship between the functional modules based on the signal assignment relationship and the logical judgment statement of each functional module includes: Analyze the signal assignment relationship between different functional modules. When the enable signals of different functional modules are controlled by the same control signal, and the control signal can only control the enable signal of one functional module at a time, it is determined that there is a mutually exclusive relationship between the different functional modules. The logic judgment statement is analyzed to determine that the functional modules corresponding to different judgment branches of the logic judgment statement are in a mutually exclusive relationship.
5. The verification platform construction method according to claim 3, characterized in that: The method further comprises: extracting state machine information from the register transfer level code; Analyze the state machine information to obtain state transfer conditions and state transition diagram; Based on the state transition conditions and the state transition diagram, different state transitions that cannot occur simultaneously at the same time are identified and marked as mutually exclusive functions.
6. The verification platform construction method according to any one of claims 1 to 5, characterized in that: The step of rendering a verification platform template file based on the first mutually exclusive function list and the second mutually exclusive function list to generate a multi-domain verification platform code corresponding to the design to be tested includes: Extracting mutually exclusive function pairs from the first mutually exclusive function list to generate a first intermediate data dictionary; extracting hardware mutual exclusion logic from the second mutually exclusive function list to generate a second intermediate data dictionary; Comparing the first intermediate data dictionary with the second intermediate data dictionary, performing mutually exclusive function conflict detection and merging, and obtaining a mutually exclusive function data dictionary; Loading the verification platform template file, replacing placeholders in the verification platform template file based on the mutually exclusive function data dictionary, so as to perform template rendering on the verification platform template file to obtain a rendered verification platform template file; Compile and execute the rendered verification platform template file to generate components corresponding to each mutually exclusive function in the mutually exclusive function data dictionary and connection relationships between components, and obtain a multi-domain verification platform code corresponding to the design to be tested.
7. The verification platform construction method according to claim 6, characterized in that: The method further comprises: Starting the multi-domain verification platform code corresponding to the design to be tested; Analyze the input and output characteristics and state transition conditions of each function in the mutually exclusive function data dictionary, set different stimulus data and test processes to generate test case sequences corresponding to each verification domain; The test case sequence corresponding to each verification domain is sent to the corresponding test interface to test the design to be tested and obtain the mutually exclusive function verification result.
8. A verification platform construction device, characterized in that: The device comprises: An acquisition module is used to obtain the functional description document and register transfer level code of the design to be tested; a first identification module, configured to identify mutually exclusive functions in the function description document to obtain a first mutually exclusive function list; a second identification module, configured to identify mutually exclusive functions on the register transfer level code to obtain a second mutually exclusive function list; A generation module is used to perform template rendering on the verification platform template file based on the first mutually exclusive function list and the second mutually exclusive function list to generate a multi-domain verification platform code corresponding to the design to be tested; wherein each mutually exclusive function corresponds to an intelligent agent.
9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the verification platform construction method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the verification platform construction method according to any one of claims 1 to 7 are implemented.