Design Method for Automatically Generating and Running a Verification Environment Based on DPU

Abstract

The present application relates to a design method for realizing automatic generation and operation of verification environment based on DPU. By presetting environment creation conditions, an ENV generation tool is established and called, a basic environment framework is generated by the ENV generation tool, and the expected DPU_ENV verification environment is created based on the basic environment framework; the ENV interface connection tool is called to generate and obtain the required interface signal, and the expected DPU_ENV verification environment and DUT are connected; the RUN tool is defined to establish a connection between the functional options and the EDA tool, and the simulation of different modes and different options is realized by the RUN tool. By generating a verification environment through a standard, it is less difficult for new verification engineers to accept the handover of the verification environment. By advancing the start time of the verification work to the architecture design stage, starting work synchronously or earlier than the design engineer, testing can be carried out quickly.

Description

Technical Field

[0001] The present disclosure relates to the technical field of chip design, and particularly to a design method, device, and design system for automatically generating and running a verification environment based on a DPU. Background Art

[0002] The DPU is a new type of chip integrating multi-domain IPs, including technologies such as SOC, NVMe controller, OVS, VirtIO, TOE, etc. This requires verification engineers to have a set of tools for quickly building a verification environment, and the verification environment generated by the tools needs to be able to parameterize and quickly incorporate various types and sources of VIPs. In addition, verification engineers are required to submit multiple simulation commands for testing in parallel as quickly as possible.

[0003] To meet the above requirements, a unified set of tools for environment generation and simulation running is needed to cooperate with each other to complete various ideas of verification engineers. At the same time, a method is needed to quickly incorporate, replace, and remove certain VIPs, and ensure the reliability and completeness of the VIPs under development.

[0004] First of all, the currently popular verification methodology - UVM, the environment generated in this design also refers to UVM. However, there is no strict requirement for the verification environment built by verification engineers in UVM. Verification engineers can choose to use multiple small and refined sequences to cooperate with the functions of virtual sequence and virtual sequencer, or choose a large and comprehensive sequence to drive different stimuli. This may result in verification environments with very different styles written by verification engineers with different experiences and backgrounds, bringing additional time and learning costs to subsequent work handover and verification plan review.

[0005] At the same time, the R & D of the entire chip starts from the architecture engineer formulating the architecture and writing the HLD, while building a set of verification environments requires more detailed LLD. That is to say, the start time of a verification task usually lags behind RTL development.

[0006] In addition, there is an un-recommended way of environment reuse, which is to copy the code required by another set of environments. This way will bring a series of negative problems, including code synchronization problems, reliability problems, readability and maintenance problems caused by the integration of codes with multiple styles, etc. This way also requires the environment to be copied to be stable prior to the current environment.

[0007] Users hope to participate in the verification work when the architecture engineer is writing the HLD, and quickly generate a dedicated environment in advance according to the design scheme of the architecture engineer. After that, when the design engineer completes the RTL coding or provides the RTL top-level file, we also hope to quickly connect this dedicated environment with the RTL. At the same time, it is more hoped that the main framework of the environments built by all verification engineers is the same, which is convenient for work handover, simplifies the review process of the verification plan, and saves the time of verification engineers.

[0008] This requires users to have a relatively basic template environment (env_base) and an ENV generation tool that can automate the creation of a dedicated environment based on the template environment. At the same time, an ENV interface connection tool is also needed to complete functions such as instantiating the DUT in the generated environment, perfecting the interface, and connecting the generated environment with the DUT.

[0009] On the other hand, for EDA tools, the existing EDA tools are started by writing a Makefile file through the Make command. However, if only relying on the Make command to run a large number of test cases, first, verification engineers need to maintain a relatively complex Makefile file to support various usage scenarios; second, verification engineers either write multiple make commands into a file and run them sequentially, or execute them one by one manually. The former needs to pay attention to the correctness of the make command and cannot view the simulation results of test cases in a timely manner. The latter can view the results of all test cases in a timely manner, but it will consume a lot of the energy of verification engineers. Therefore, in actual work, tools with more abundant functions are needed to assist verification engineers in submitting simulation commands, recovering, and statistically analyzing simulation results. Summary of the Invention

[0010] In view of this, the present disclosure proposes a design method and device for automatically generating and running a verification environment based on a DPU.

[0011] According to one aspect of the present disclosure, a design method for automatically generating and running a verification environment based on a DPU is provided, including the following steps:

[0012] S100. Call the ENV generation tool to generate a basic environment framework through the ENV generation tool, and create an expected DPU_ENV verification environment based on the basic environment framework;

[0013] S200. Call the ENV interface connection tool to generate required interface signals and connect the expected DPU_ENV verification environment with the DUT;

[0014] S300. Define the RUN tool, establish the connection between the function options and the EDA tool, and implement the simulation of different modes and different options through the RUN tool.

[0015] As an optional implementation solution of the present application, optionally, in step S100, the ENV generation tool is called, and a basic environment framework is generated through the ENV generation tool, and an expected DPU_ENV verification environment is created based on the basic environment framework, including:

[0016] S110. Preset the environment creation conditions, and establish a verification environment framework env_base based on the UVM template;

[0017] S120. Preprocess the verification environment framework env_base to obtain a preprocessed verification environment of env_base;

[0018] S130. Use a preset tool, and define the harness and interface in the preprocessed verification environment of env_base by given preset parameters;

[0019] S140. According to the preset environment creation conditions, write environment plugins and combine various functional components, and call the ENV generation tool to generate and obtain an expected DPU_ENV verification environment by given specific parameters.

[0020] As an optional implementation solution of the present application, optionally, in step S200, the ENV interface connection tool is called to generate and obtain the required interface signals, and the expected DPU_ENV verification environment and the DUT are connected, including:

[0021] S210. Call the ENV interface connection tool and give parameters to instantiate the RTL top-level module into the harness in the expected DPU_ENV verification environment as the DUT;

[0022] S220. Based on the environment directory of the expected DPU_ENV verification environment, call the ENV interface connection tool and give specific parameters to connect the preprocessed verification environment of env_base to the RTL top-level of the functional model through the RTL top-level interface to obtain a complete DPU_ENV verification environment;

[0023] S230. Based on the expected DPU_ENV verification environment, connect the interface and the DUT in the harness to obtain a complete verification environment.

[0024] As an alternative implementation of the present application, optionally, in step S200, when calling the ENV interface to connect to the tool, generating and obtaining the required interface signals, and connecting the expected DPU_ENV verification environment and the DUT, it further includes:

[0025] S211. Preset a packaging directory, and package the complete verification environment in a package through the packaging directory;

[0026] S221. Set up the RTL file list and the verification platform file list. Specify all the RTL code files required by the current DUT through the RTL file list, and specify all the files required by the verification platform through the verification platform file list.

[0027] As an alternative implementation of the present application, optionally, in step S300, when defining the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations with different modes and different options through the RUN tool, it further includes:

[0028] S311. Set the construction conditions and create a RUN tool for use as the simulation start;

[0029] S321. Preset the function options and establish an associated matching connection relationship between the preset function options and the EDA tool;

[0030] S331. Through the RUN tool, call the EDA tool and implement simulations with different modes and different options according to the preset simulation selection conditions.

[0031] As an alternative implementation of the present application, optionally, in step S300, when defining the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations with different modes and different options through the RUN tool, it further includes:

[0032] S312. Parse the RTL file list and the verification platform file list through the RUN tool, and generate a compilation file for vcs to compile;

[0033] S322. According to the reference relationship, reference the file list of the DUT in the RTL file list and reference the file list of the VIP in the verification platform file list;

[0034] S332. Load the package file after the verification platform file list and save it.

[0035] As an alternative implementation of the present application, optionally, in step S300, when defining the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations of different modes and different options through the RUN tool, it further includes:

[0036] S313. Determine the number of List loops according to the value of round in the reg mode;

[0037] S323. Perform one round of List simulation through the RUN tool;

[0038] S333. Confirm whether the number of idle child processes is greater than 1 and check the number of child processes.

[0039] The second aspect of the present invention provides a device for implementing the above-mentioned design method for automatically generating and running a verification environment based on a DPU, including:

[0040] An ENV generation tool call unit for calling an ENV generation tool, generating a basic environment framework through the ENV generation tool, and creating an expected DPU_ENV verification environment based on the basic environment framework;

[0041] An ENV interface connection tool call unit for calling an ENV interface connection tool, connecting the expected DPU_ENV verification environment and the DUT, and generating and obtaining the required interface signals;

[0042] A RUN tool call unit for defining a RUN tool, establishing a connection between preset function options and an EDA tool, and implementing simulations of different modes and different options through the RUN tool.

[0043] The third aspect of the present invention provides a design system, including:

[0044] A processor;

[0045] A memory for storing executable instructions of the processor;

[0046] Wherein, the processor is configured to implement the above-mentioned design method for automatically generating and running a verification environment based on a DPU when executing the executable instructions.

[0047] The technical effects of the present application:

[0048] The present invention generates a basic environment framework by invoking an ENV generation tool, creates an expected DPU_ENV verification environment based on the basic environment framework, invokes an ENV interface connection tool to generate required interface signals, and connects the expected DPU_ENV verification environment with the DUT. A RUN tool is defined to establish a connection between function options and EDA tools, and simulations of different modes and different options are implemented through the RUN tool. It is possible to generate a verification environment based on an env_base and an edited environment generation tool, which to a certain extent avoids the time wasted by verification engineers due to possible environment bugs during the stage of building the verification environment.

[0049] Since all environments are generated according to a standard, the acceptance difficulty for new verification engineers is relatively low when handing over the verification environment. The start time of the verification work is advanced to the architecture design stage, starting work synchronously or earlier than the design engineers. After the design engineers complete the design, testing can be carried out quickly.

[0050] Since it is not necessary for each verification engineer to develop a set of similar models separately, the reliability of the verification results is improved.

[0051] By using the RUN tool, a specified file can be quickly added to the compilation list, providing more possibilities and feasibility for multi-VIP co-simulation.

[0052] According to the following detailed description of exemplary embodiments with reference to the accompanying drawings, other features and aspects of the present disclosure will become apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The drawings included in and constituting a part of this specification, together with the specification, illustrate exemplary embodiments, features, and aspects of the present disclosure and are used to explain the principles of the present disclosure.

[0054] Figure 1 It shows a schematic diagram of the real-time process of the design method for automatically generating and running a verification environment based on DPU in the present invention;

[0055] Figure 2 It shows a schematic diagram of invoking the ENV generation tool in the present invention;

[0056] Figure 3 It shows a schematic diagram of invoking the ENV interface connection tool in the present invention;

[0057] Figure 4 It shows a schematic diagram of the command introduction of the RUN tool in the present invention;

[0058] Figure 5 It shows a schematic diagram of the parameter introduction of the RUN tool in the present invention;

[0059] Figure 6 It shows a schematic diagram of the verification environment template designed in one of the embodiments of the present invention;

[0060] Figure 7 It shows a schematic diagram of the running process of the RUN tool in reg mode of the present invention;

[0061] Figure 8 It shows a schematic diagram of the process of running a round of List simulation of the present invention;

[0062] Figure 9 It shows a schematic diagram of the process of checking the number of subprocesses of the RUN of the present invention. Detailed implementation manners

[0063] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0064] The special term "exemplary" here means "serving as an example, embodiment or illustration". Any embodiment described as "exemplary" here does not necessarily need to be construed as superior to or better than other embodiments.

[0065] In addition, for a better illustration of the present disclosure, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present disclosure can also be implemented without some specific details. In some instances, methods, means, elements and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0066] Embodiment 1

[0067] In order to advance the start time of the verification work to the architecture design stage and reduce the time spent by verification engineers in building the verification environment and executing test cases, the present technology adopts the following technical solutions:

[0068] 1), Write a script tool for automatically running simulations to quickly complete functions such as parameter addition, automatic submission of multiple test cases, and timed submission of tasks. Solve the problem that verification engineers need to spend a lot of time submitting simulation commands.

[0069] 2), Write a set of general UVM-based environment templates, write scripts to copy and rename the environment templates to a specified location to generate a set of dedicated environments, and at the same time add dedicated code to the generated dedicated environments through parameter control scripts.

[0070] 3) Connect the DUT based on the dedicated environment generated in the second step to generate the interface definition of the interface. After that, the verification engineer only needs to write specific interface driver, signal monitoring and other codes.

[0071] If the verification work is carried out according to the above three solutions, the start time of the verification work can be advanced to the architecture design stage, reducing the time spent by the verification engineer in setting up the verification environment and executing test cases.

[0072] As Figure 1 shown, according to one aspect of the present disclosure, there is provided a design method for automatically generating and running a verification environment based on a DPU, including the following steps:

[0073] S100: Invoke the ENV generation tool, generate a basic environment framework through the ENV generation tool, and create an expected DPU_ENV verification environment based on the basic environment framework;

[0074] The automated environment solution first relies on the verification engineer to write a basic verification environment framework env_base based on their own habits, and then writes a set of tools through a scripting language to copy env_base to a specified location by specifying parameters, modify it to a specified name, and then remove or add specified code to the location pointed to by the keyword according to the parameters and keywords. Finally, connect the DUT to the ENV through the interface connection tool written in the scripting language to implement the construction of the verification environment framework env_base.

[0075] Specifically, when creating, write a basic verification environment framework env_base according to the habits and experience of the verification team itself.

[0076] As an alternative solution of the present application, in step S100, the invoking the ENV generation tool, generating a basic environment framework through the ENV generation tool, and creating an expected DPU_ENV verification environment based on the basic environment framework includes:

[0077] S110: Preset environment creation conditions and establish a verification environment framework env_base;

[0078] S120: Preprocess the verification environment framework env_base to obtain a preprocessed verification environment of env_base;

[0079] S130: Use a preset tool, define the harness and interface in the preprocessed verification environment of env_base by given preset parameters;

[0080] S140. Create conditions according to the preset environment, write an environment plug-in and combine various functional components, and call the ENV generation tool to generate and obtain the expected DPU_ENV verification environment by giving specific parameters.

[0081] During specific operations, as Figure 2 shown, a workable verification environment is generated in two stages by configuring different parameters. Each verification engineer only needs to perform unique tasks such as driving, monitoring, and reference models on this basis, without repeating the basic verification environment coding, saving the time of verification engineers.

[0082] The steps to generate a complete set of environments are generally divided into preparatory work and two steps.

[0083] The preparatory work includes the following:

[0084] Write a UVM-based template environment env_base according to the coding style formulated by the verification team.

[0085] Use a scripting language to write a set of tools to copy env_base to a specified location by specifying parameters, modify it to a specified name to generate a dedicated environment, and then remove or add specified code to the location pointed to by the keyword in the dedicated environment according to the parameters and keywords.

[0086] Use a scripting language to write a set of tools to instantiate the top-level of the RTL into the top-level file (harness) of the dedicated environment by giving parameters, generate corresponding interface definitions in the interface file of the dedicated environment, and finally connect the interface of the dedicated environment to the corresponding interface of the DUT in the top-level file of the environment.

[0087] Write environment plug-ins as needed. The reusability of this part of the code is not as good as env_base, but it is also often used in various scenarios. For example, register models, responses, etc.

[0088] It is necessary to use the prepared env_base, various functional components, and call the ENV generation tool while giving specific parameters to generate a basic dedicated environment.

[0089] At this time, the generated dedicated environment only has the basic part, lacking the interface definitions in the interface, the instantiation of the DUT, and the connection code between the ENV and the DUT.

[0090] S200. Call the ENV interface connection tool, connect the expected DPU_ENV verification environment and the DUT, and generate and obtain the required interface signals;

[0091] The verification environment and the DUT implemented by the design engineer need to be connected. An ENV interface connection tool is used to connect the verification environment and the DUT. As an alternative implementation of this application, optionally, in step S200, the ENV interface connection tool is called, and the expected DPU_ENV verification environment and the DUT are connected to generate and obtain the required interface signals, including:

[0092] S210. Call the ENV interface connection tool and give parameters to instantiate the RTL top-level module into the harness in the expected DPU_ENV verification environment as the DUT;

[0093] S220. Based on the environment directory of the expected DPU_ENV verification environment, call the ENV interface connection tool and give specific parameters to connect the env_base preprocessing verification environment to the RTL top-level of the functional model through the RTL top-level interface to obtain a complete DPU_ENV verification environment;

[0094] S230. Based on the expected DPU_ENV verification environment, connect the interface to the DUT in the harness to obtain a complete verification environment.

[0095] After the design engineer defines the RTL top-level interface, under the environment directory generated in the first step, call the ENV interface connection tool and give specific parameters to connect the environment and the RTL top-level of the functional model. At the same time, generate the interface signals in the interface to obtain a complete DPU_ENV. The environment generated at this time only needs to supplement some codes such as drivers and monitors.

[0096] As Figure 3 shown, after the design engineer defines the RTL top-level interface, under the environment directory generated in the first step, call the ENV interface connection tool and give specific parameters to connect the environment and the RTL top-level, generate the interface signals in the interface, instantiate the RTL top-level module into the harness file of the dedicated environment, and at the same time connect the interface of the environment and the RTL top-level in the harness file.

[0097] Through interface connection, the files of the RTL top-level design can be added to obtain a complete DPU_ENV.

[0098] The verification environment obtained through the above steps lacks some codes such as drivers and monitors. The environment generated at this time only needs to supplement some codes such as drivers and monitors to be used for verification.

[0099] S300. Define the RUN tool, establish the connection between the function options and the EDA tool, and implement simulations of different modes and different options through the RUN tool.

[0100] To further free verification engineers from repetitive work so that they can complete more creative work, this technology redefines and creates the RUN tool. A connection is established between the RUN tool and the function options, and the RUN tool dynamically controls the data construction and data processing of the verification environment through tool parameters, maximizing the reuse of the environment and test cases, and further reducing the repetitive work of verification engineers.

[0101] As an alternative implementation of this application, in step S300, the defining the RUN tool, establishing the connection between the function options and the EDA tool, and implementing simulations of different modes and different options through the RUN tool further includes:

[0102] S311. Set the construction conditions, create the RUN tool for use as the simulation startup.

[0103] S321. Preset the function options and establish an associated matching connection relationship between the preset function options and the EDA tool.

[0104] S331. Through the RUN tool, call the EDA tool and implement simulations of different modes and different options according to the preset simulation selection conditions.

[0105] The RUN tool dynamically controls the data construction and data processing of the verification environment through tool parameters, maximizing the reuse of the environment and test cases, and further reducing the repetitive work of verification engineers. Functionally model the solutions with well-defined standard protocols and architectures that need to be used.

[0106] The RUN tool is a tool used to call the EDA tool for simulation, and its design lies in what options the user needs to provide. The function options are created or called by the user in advance on the platform according to a custom method.

[0107] The automated operation tool, the RUN tool, provides multiple options, facilitating verification engineers to manage different control macros in different simulation modes. At the same time, it provides functions such as multiple loop simulations of the test case list, regularly updating the project directory, and starting the specified simulation, further freeing verification engineers from repetitive work so that they can complete more creative work.

[0108] Such as Figure 4 and 5 shown, are respectively the schematic diagram of the command introduction of the RUN tool and the schematic diagram of its parameter introduction. The specific tool usage commands and definitions are not elaborated here.

[0109] In this embodiment, a defined env_base environment template will be specifically given below.

[0110] First, according to the above steps, a set of env_base, ENV generation tools, and ENV interface connection tools need to be completed to build the basic environment.

[0111] Then, the design and implementation of the RUN tool need to be completed.

[0112] On this basis, the verification engineer only needs to complete the driver part of the driver, the sampling part of the monitor, and the RM part. From experience, using this solution to build the verification environment can provide a verification platform that can drive the DUT on the day when the designer provides the RTL file list.

[0113] As Figure 6 shown, it is a designed verification environment template. Among them, the TestBase part and the Harness part are both generated by the ENV generation tool. However, at this time, the DUT in the Harness does not exist yet, and there are no interface definitions in the interface. The Harness part is actually completed by the cooperation of the ENV interface connection tool and the RTL top-level file given by the design engineer.

[0114] In this design, from stimulus generation to generating expected data, and then to the data path for data comparison, there are the following 7 steps, which are basically the same as UVM, including:

[0115] 1) The Testcase will inherit from TestBase and put the transaction it wants to send into the trans_q queue in the Config of TestBase;

[0116] 2) The Sequence will be sent to the Driver one by one through the uvm TLM mechanism;

[0117] 3) The Driver will analyze the content in the transaction and drive the interface;

[0118] 4) The In_monitor will collect interface information from the output end of the interface, restore it to the data structure defined in the transaction, and send it to the RM;

[0119] 5) The Out_monitor will collect interface information from the input end of the interface, organize it into the data structure to be compared, store it in the transaction, and send it to the SCB;

[0120] 6) RM parses the transactions sent by In_monitor, calls different processing functions according to the parsing results to complete data processing, and organizes the processing results into a data structure to be compared and stores it in the transaction and sends it to the SCB.

[0121] 7) The SCB calls uvm compare to compare the results of the transactions received from the RM and Out_monitor.

[0122] Based on the above implementation, this design has provided a set of tools to complete the creation of the environment and the management rules of the compilation files. At this time, it is necessary to complete the design and implementation of the RUN tool to complete direct testing, regression testing, timing testing, etc., and at the same time, it is convenient to switch the VIP reuse environment and Testcase to complete new tests.

[0123] Through the above process, a general verification environment can be quickly built, but for the DPU, it is also necessary to be able to quickly integrate VIPs from multiple sources.

[0124] The solution of this design is to design a directory structure to encapsulate the above environment part in a package.

[0125] In an optional implementation, in step S200, when calling the ENV interface connection tool to generate and obtain the required interface signals and connect the expected DPU_ENV verification environment and the DUT, it further includes:

[0126] S211. Preset a packaging directory, and encapsulate the complete verification environment in a package through the packaging directory;

[0127] S221. Set the RTL file list and the verification platform file list. Specify all the RTL code files required by the current DUT through the RTL file list, and specify all the files required by the verification platform through the verification platform file list.

[0128] The packaging directory can select the corresponding packaging model according to different RUN commands or predefined data protocols. For example, in the OVS test, the verification engineer needs to encapsulate multi-layer network protocols such as Layer2, Layer3, and Layer4 into data in a specified format according to the RFC standard; in the NVME test, the verification engineer needs to encapsulate SQE, etc. according to the NVME protocol requirements.

[0129] Redesign a set of file lists, which are divided into an RTL file list (rtl_filelist.f) and a verification platform file list (tb_filelist.f). The RTL file list is used to specify all the RTL code files required for the current DUT, and the verification platform file list is used to specify all the files required for the verification platform, including the verification environment, VIP, etc.

[0130] As an alternative solution of the present application, optionally, in step S300, the defining of the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations of different modes and different options through the RUN tool further includes:

[0131] S312. Parse the RTL file list and the verification platform file list through the RUN tool, and generate a compilation file to be provided to vcs for compilation;

[0132] S322. According to the reference relationship, reference the file list of the DUT in the RTL file list, and reference the file list of the VIP in the verification platform file list;

[0133] S332. Load the package file behind the verification platform file list and save it.

[0134] Parse the two file lists through the RUN tool, and generate a compilation file (gen.f) to be provided to vcs for compilation.

[0135] Reference the file list of the DUT in rtl_filelist.f, reference the file list of the VIP in tb_filelist.f, and then add the package file of the environment at the end of the tb_filelist.f file and save it in the platform.

[0136] Based on the above implementation, complete a set of tools for environment creation and compilation file management rules. At this time, it is necessary to complete the design and implementation of the RUN tool to complete direct testing, regression testing, timing testing, etc. At the same time, it is possible to conveniently switch the VIP reuse environment and Testcase to complete new tests.

[0137] To meet the above test requirements, it is also necessary for the RUN tool to meet the following test conditions during simulation.

[0138] As an alternative solution of the present application, optionally, in step S300, the defining of the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations of different modes and different options through the RUN tool further includes:

[0139] S313. Determine the number of List loops according to the value of round in the reg mode;

[0140] As Figure 7 shown, first, it is necessary to run the command in the "reg mode" through the RUN tool. Determine the number of List loops according to the value of round; secondly, determine the log file name according to the current number of loops; then replace some parameters and perform and complete one round of List simulation until the last loop.

[0141] S323. Perform one round of List simulation through the RUN tool;

[0142] As Figure 8 shown, the process of one round of simulation is as follows:

[0143] First, determine whether the number of idle child processes is greater than 1, and then obtain each line starting with tc= in the List line by line; complete the test case path referred to by tc, and generate the gen.f file according to the specified rtl_filelist.f and tb_filelist.f parsed by the parameters, and store the parsing results.

[0144] Convert the parameters into the format of Makefile, create a child process and execute the simulation.

[0145] S333. Confirm whether the number of idle child processes is greater than 1 and check the number of child processes.

[0146] As Figure 9 shown, first, it is necessary to collect the child process P created by this tool process, collect the completed and revoked child process NP, and judge whether the value of P - NP is less than subproc? If so, end the check, otherwise continue to collect.

[0147] Embodiment 2

[0148] Based on the implementation of Embodiment 1, this embodiment correspondingly provides, according to another aspect of the present disclosure, a device for implementing the design method for automatically generating and running a verification environment based on DPU as described above, including:

[0149] An ENV generation tool call unit, configured to call the ENV generation tool, generate a basic environment framework through the ENV generation tool, and create an expected DPU_ENV verification environment based on the basic environment framework;

[0150] An ENV interface connection tool call unit, configured to call the ENV interface connection tool, connect the expected DPU_ENV verification environment and the DUT, and generate and obtain the required interface signals;

[0151] The RUN tool call unit is used to define the RUN tool, establish the connection between the preset function options and the EDA tool, and implement simulations in different modes and with different options through the RUN tool.

[0152] For the functions and implementation principles of the above-mentioned various modules / units / hardware, please refer to the descriptions in the above embodiments for details, and will not be elaborated here.

[0153] Obviously, those skilled in the art should understand that the various modules or steps of the present invention described above can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. Optionally, they can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0154] Embodiment 3

[0155] Furthermore, according to another aspect of the present disclosure, the third aspect of the present application further provides a design system, including:

[0156] A processor;

[0157] A memory for storing instructions executable by the processor;

[0158] Wherein, when the processor is configured to execute the executable instructions, it implements the design method for automatically generating and running a verification environment based on the DPU described above.

[0159] The verification system of the embodiments of the present disclosure includes a processor and a memory for storing instructions executable by the processor. Wherein, when the processor is configured to execute the executable instructions, it implements a design method for automatically generating and running a verification environment based on the DPU described in any one of the above.

[0160] Here, it should be noted that the number of processors can be one or more. At the same time, in the verification system of the embodiments of the present disclosure, an input device and an output device can also be included. Among them, the processor, the memory, the input device and the output device can be connected through a bus or in other ways, which will not be specifically limited here.

[0161] The memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the programs or modules corresponding to a design method for automatically generating and running a verification environment based on a DPU according to an embodiment of the present disclosure. The processor executes various functional applications and data processing of the control system by running the software programs or modules stored in the memory.

[0162] The input device can be used to receive input numbers or signals. Among them, the signal can be a key signal related to the user settings and function control of the device / terminal / server. The output device can include display devices such as a display screen.

[0163] The embodiments of the present disclosure have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art in the technical field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other ordinary skill in the art in the technical field to understand the disclosed embodiments.

Claims

1. A design method for automatically generating and running a verification environment based on DPU, characterized in that It includes the following steps: S100. Call the ENV generation tool to generate a basic environment framework through the ENV generation tool, and create an expected DPU_ENV verification environment based on the basic environment framework, including: S110. Preset environment creation conditions and establish a verification environment framework env_base based on the UVM template; S120. Preprocess the verification environment framework env_base to obtain the env_base preprocessed verification environment; S130. Use a preset tool, through given preset parameters, to define the harness and interface in the env_base preprocessed verification environment; S140. According to the preset environment creation conditions, write environment plugins and combine various functional components, and call the ENV generation tool to give specific parameters to generate and obtain the expected DPU_ENV verification environment; S200. Call the ENV interface connection tool to generate the required interface signals and connect the expected DPU_ENV verification environment and the DUT, including: S210. Call the ENV interface connection tool and give parameters to instantiate the RTL top-level module into the harness in the expected DPU_ENV verification environment as the DUT; S220. Based on the environment directory of the expected DPU_ENV verification environment, call the ENV interface connection tool and give specific parameters to connect the env_base preprocessed verification environment to the RTL top-level of the functional model through the RTL top-level interface to obtain a complete DPU_ENV verification environment; S230. Based on the expected DPU_ENV verification environment, connect the interface to the DUT in the harness to obtain a complete verification environment; S300. Define the RUN tool, establish a connection between the function options and the EDA tool, and implement simulations in different modes and with different options through the RUN tool.

2. The design method for automatically generating and running a verification environment based on a DPU according to claim 1, wherein In step S200, when calling the ENV interface connection tool to generate and obtain the required interface signals and connect the expected DPU_ENV verification environment and the DUT, it further includes: S211. Preset a packaging directory and package the complete verification environment in a package through the packaging directory; S221. Set the RTL file list and the verification platform file list. Specify all the RTL code files required for the current DUT through the RTL file list, and specify all the files required for the verification platform through the verification platform file list.

3. The design method for automatically generating and running a verification environment based on DPU according to claim 2, wherein In step S300, when defining the RUN tool, establishing a connection between the function options and the EDA tool, and implementing simulations in different modes and with different options through the RUN tool, it further includes: S311. Set the construction conditions and create the RUN tool for use as the simulation startup; S321. Preset the function options and establish an associated matching connection relationship between the preset function options and the EDA tool; S331. Call the EDA tool through the RUN tool and implement simulations with different modes and different options according to the preset simulation selection conditions.

4. The design method for automatically generating and running a verification environment based on a DPU according to claim 3, characterized in that In step S300, the definition of the RUN tool, establishing the connection between the function options and the EDA tool, and implementing simulations with different modes and different options through the RUN tool further includes: S312. Parse the RTL file list and the verification platform file list through the RUN tool, generate a compilation file and provide it to vcs for compilation; S322. According to the reference relationship, reference the file list of the DUT in the RTL file list and reference the file list of the VIP in the verification platform file list; S332. Load the package file after the verification platform file list and save it.

5. The design method for automatically generating and running a verification environment based on a DPU according to claim 4, characterized in that In step S300, the definition of the RUN tool, establishing the connection between the function options and the EDA tool, and implementing simulations with different modes and different options through the RUN tool further includes: S313. Determine the List loop count in the reg mode according to the value of round; S323. Perform one round of List simulation through the RUN tool; S333. Confirm whether the number of idle child processes is greater than 1 and check the number of child processes.

6. An apparatus for implementing the design method of automatically generating and running a verification environment based on DPU according to any one of claims 1-5, characterized in that, It includes: An ENV generation tool call unit for calling the ENV generation tool, generating a basic environment framework through the ENV generation tool, and creating an expected DPU_ENV verification environment based on the basic environment framework; An ENV interface connection tool call unit for calling the ENV interface connection tool, connecting the expected DPU_ENV verification environment and the DUT, and generating and obtaining the required interface signals; A RUN tool call unit for defining the RUN tool, establishing the connection between the preset function options and the EDA tool, and implementing simulations with different modes and different options through the RUN tool.

7. A design system, characterized in that, It includes: A processor; A memory for storing the executable instructions of the processor; Wherein, the processor is configured to implement the design method for automatically generating and running a verification environment based on a DPU as described in any one of claims 1 to 5 when executing the executable instructions.

Images