CN115455877B

CN115455877B - Verification platform generation device, method, medium and electronic equipment

Info

Publication number: CN115455877B
Application number: CN202211400432.2A
Authority: CN
Inventors: 王晶
Original assignee: Xinyaohui Technology Co ltd
Current assignee: Xinyaohui Technology Co ltd
Priority date: 2022-11-09
Filing date: 2022-11-09
Publication date: 2023-03-21
Anticipated expiration: 2042-11-09
Also published as: CN115455877A

Abstract

The application provides a verification platform generation device, a verification platform generation method, a verification platform generation medium and electronic equipment. The verification platform generation device comprises an interactive interface and a processor. The interactive interface includes a first area and a second area, the second area including a plurality of standard cells. The processor is configured to: according to the component combination, a first verification platform is generated based on the first template, and at least one second verification platform is generated based on a second template selected by a user in the at least one second template, wherein the plurality of standard components correspond to the first template, and the visual structure of the component combination corresponds to the first verification platform. The first template and each of the at least one second template differ at least in one of: verification methodology, simulation tools, version and scenario requirements. The interactive interface displays the functional verification of the DUT as it passes on the first verification platform and on the at least one second verification platform. Thus, the verification efficiency is improved and the development period is shortened.

Description

Verification platform generation device, method, medium and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a verification platform generation apparatus, a verification platform generation method, a verification platform generation medium, and an electronic device.

Background

An Integrated Circuit (IC) is also sometimes called a chip, and the chip integrates various elements such as a large number of transistors, diodes, resistors, capacitors, and inductors, and wiring on a wafer by a semiconductor process to form a circuit having a specific function. For example, very Large Scale Integration (VLSI) can integrate millions of transistors on a micron-sized silicon die and the complex wiring between these transistors. Since it is necessary to complete the transistor and other elements and wiring at once, the man-hour and cost of chip production are deeply influenced by the chip design. The chip design process generally starts from specification formulation, namely, the purpose and the efficiency of the chip, protocol standards required to be met and the like are set, and function allocation and unit division are carried out; then, the hardware behavior, structure and data flow of the circuit system are described by using a Hardware Description Language (HDL), such as a common Verilog HDL; converting the HDL code into a logic circuit diagram through an Electronic Design Automation (EDA) tool, and performing simulation verification; and finally, converting the logic circuit diagram into a gate-level circuit netlist through the automatic synthesis function of the EDA tool, and performing circuit layout and winding to obtain a specific circuit wiring structure. With the widespread use of System On Chip (SOC) and the increasing scale and complexity of hardware integrated on a single chip as well as the development of more advanced process, chip verification occupies most of the workload of the entire chip design flow. The improvement of the chip verification efficiency and the improvement of the chip verification environment directly affect the research and development period of the chip project and the guarantee of the subsequent production efficiency. Front-end functional verification in chip integration development. A verification engineer typically formulates a verification scheme according to a Design Under Test (DUT), and draws and configures an environment block diagram through a platform tool provided by a verification platform to generate a verification environment. The functional verification helps to verify whether the chip design meets requirements such as correctness of logic sequence and the like before chip production, and provides specification of corresponding standards, coding style and environment architecture of a unified verification platform and the like through verification methodology. Common validation methodologies include Universal Validation Methodology (UVM), which provides a validation platform development framework based on a system verilog class library. Other validation methodologies include the Verification Methodology Manual (VMM) and Open Verification Methodology (OVM).

In practice, there are a variety of EDA tools, including related integrated circuit design layout design software, electronic circuit design software, etc., provided by various EDA vendors or software companies specializing in EDA, new and old versions, and custom or semi-custom versions, which may vary in verification methodology, verification tools, and specific technical details from one source to another. Therefore, when the EDA tools or versions need to be switched, for example, from the EDA tool provided by one manufacturer to the EDA tool provided by another manufacturer, and for example, when different customers are delivered, the verification problem introduced by tool switching and methodology switching needs to be revised again and the verification use case needs to be returned again, which is not favorable for improving the verification efficiency and shortening the chip development cycle.

In summary, the problem to be solved at present is how to improve the verification efficiency and shorten the chip development cycle.

Disclosure of Invention

The embodiment of the application provides a verification platform generation device, a verification platform generation method, a verification platform generation medium and electronic equipment, and aims to solve the problems in the prior art, namely how to improve verification efficiency and shorten a chip development cycle.

In a first aspect, the present application provides a verification platform generation apparatus. The verification platform generation apparatus includes an interactive interface and at least one processor. The interactive interface includes a first area and a second area, the second area including a plurality of standard components including at least a first component for stimulus generation, a second component for representing an environment, and a third component for representing a connection relationship. The plurality of standard cells may be pulled to the first area to construct a combination of cells.

The at least one processor is configured to: generating, according to the combination of components, a first verification platform based on a first template and at least one second verification platform based on one or more of at least one second template selected by a user, wherein the plurality of standard components correspond to the first template and a visual structure of the combination of components corresponds to the first verification platform, the first template and each of the at least one second template differing by at least one of: verification methodology, simulation tools, version and scenario requirements; the interactive interface displays functional verification of at least one DUT when the at least one DUT passes functional verification on the first verification platform and functional verification on the at least one second verification platform.

According to the first aspect of the application, considering the development project of a chip and the interference (such as loss of authorization or legal use channel of the current EDA tool or version) possibly suffered by the chip verification link, and also considering the requirement of pursuing better comprehensive optimization effect and development design effect, aiming at the situation that different sources and different versions of EDA tools have differences in verification science, verification tools and specific technical details, the first verification platform is generated according to the component combination and based on the first template, and the at least one second verification platform is generated based on one or more second templates selected by a user in the at least one second template, so that the influence on the chip function verification process and the verification result caused by the change of macroscopic factors can be effectively coped with, and the visualization structures of various standard components corresponding to the first template and the component combination correspond to the first verification platform, so that an environmental block diagram can be conveniently built through an interactive interface, and the subsequent switching of the EDA tools or versions or the adaptation of two or more EDA tools or versions is facilitated.

In one possible implementation manner of the first aspect of the present application, the interactive interface further includes a template selection component for a user to select the one or more second templates.

In one possible implementation manner of the first aspect of the present application, the first template is a default template, and the at least one second template is an optional template.

In one possible implementation of the first aspect of the present application, the one or more second templates are in one-to-one correspondence with the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employ a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology are different in at least one of: engineering scripts, stimulus generation, data types, printing mechanisms, environment integration, and environment startup.

In one possible implementation of the first aspect of the present application, the first verification methodology and the second verification methodology differ in stimulus generation, wherein the first verification methodology controls stimulus generation by controlling stimulus combination sequence, and the second verification methodology controls stimulus generation by invoking macro-calls as stimulus classes of the stimulus generator.

In one possible implementation of the first aspect of the present application, the first verification methodology and the second verification methodology differ in printer-to-printer, wherein the printing of the first verification methodology inherits uvm _ report _ server class, and the printing of the second verification methodology calls vmm _ log class and the printing of macro implementation components and objects corresponding to vmm _ log class.

In one possible implementation of the first aspect of the present application, the first validation methodology implements factory model through macro declaration and data transfer between different components through global resource configuration, and the second validation methodology implements data transfer through external declaration definition.

In one possible implementation of the first aspect of the present application, the first and second validation methodologies further differ in validation environment level divisions.

In one possible implementation of the first aspect of the present application, the first validation methodology is UVM and the second validation methodology is VMM or OVM.

In a possible implementation manner of the first aspect of the present application, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template adopts a UVM first version, the one or more second templates adopt a UVM second version, and the UVM first version and the UVM second version are different in at least one of the following items: an incentive exit mechanism, an incentive send mechanism, a printing format, and name checking rules.

In one possible implementation manner of the first aspect of the present application, the first UVM version and the second UVM version are different in a stimulus exit mechanism, the first UVM version controls the stimulus exit mechanism by invoking a cross _ object and a drop _ object, and the second UVM version controls the stimulus exit mechanism by invoking a set _ starting _ phase and a get _ starting _ phase.

In one possible implementation manner of the first aspect of the present application, the first UVM version and the second UVM version are different in name check rule, the second UVM version checks usage of a meta character in a domain segment name through resource _ db and generates a warning, and the first UVM version does not check usage of a meta character in a domain segment name or filters the warning.

In one possible implementation of the first aspect of the present application, the second UVM version is different from the first UVM version.

In one possible implementation of the first aspect of the present application, the UVM second version is an updated version relative to the UVM first version.

In a possible implementation manner of the first aspect of the present application, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template uses a first simulation tool, the one or more second templates uses a second simulation tool, and the first simulation tool and the second simulation tool are different in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling.

In a possible implementation manner of the first aspect of the present application, the first simulation tool is configured to adapt to a compiling manner and a simulation option call of the VCS, and the second simulation tool is configured to adapt to a compiling manner and a simulation option call of an xrun, irun, or modelsim.

In a possible implementation manner of the first aspect of the present application, the first simulation tool and the second simulation tool are different in compilation manner, the first simulation tool regards the virtual interface as an error at the time of compilation, and the second simulation tool does not consider the virtual interface as an error at the time of compilation.

In a possible implementation manner of the first aspect of the present application, the first simulation tool and the second simulation tool use different compiling manners and simulation options.

In a possible implementation manner of the first aspect of the present application, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of the following: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement.

In one possible implementation of the first aspect of the present application, the first scenario requirement and the second scenario requirement are both associated with a complexity of the at least one DUT.

In one possible implementation of the first aspect of the present application, the first template selects a first verification methodology, a first simulation tool, and a first version, and the selection of the first verification methodology, the first simulation tool, and the first version is based on the first scenario requirements and a complexity of the at least one DUT.

In one possible implementation of the first aspect of the present application, when the at least one DUT is a multiplier, an asynchronous FIFO, a clock generator, or a divider, the first scenario requirement has a higher priority on the environment running speed requirement and the verification efficiency than on the environment hierarchical level requirement.

In a second aspect, the present application provides a verification platform generation method. The verification platform generation method comprises the following steps: providing an interactive interface, wherein the interactive interface comprises a first area and a second area, the second area comprising a plurality of standard components, the plurality of standard components comprising at least a first component for stimulus generation, a second component for representing an environment, and a third component for representing a connection relationship; building a combination of elements by dragging said plurality of standard elements to said first area; according to the component combination, generating a first verification platform based on a first template and generating at least one second verification platform based on one or more second templates selected by a user, wherein the plurality of standard components correspond to the first template and a visual structure of the component combination corresponds to the first verification platform, and each of the first template and the at least one second template is different from each other at least in one of: verification methodology, simulation tools, version and scenario requirements; displaying, via the interactive interface, at least one DUT functional verification pass when the at least one DUT functional verification passes on the first verification platform and the at least one second verification platform.

According to the second aspect of the application, considering that the development project of the chip and the interference possibly suffered by the verification link of the chip (such as the loss of authorization or legal use channel of the current EDA tool or version) and the requirement of pursuing better comprehensive optimization effect and development design effect, aiming at the EDA tools of different sources and different versions, differences exist in verification science, verification tools and specific technical details, the first verification platform is generated according to the component combination and based on the first template, and the at least one second verification platform is generated based on one or more second templates selected by the user in the at least one second template, so that the influence on the chip function verification process and the verification result caused by the change of macroscopic factors can be effectively coped with, and the visual structures of the plurality of standard components corresponding to the first template and the component combination correspond to the first verification platform, so that an environmental block diagram can be conveniently built through an interactive interface, and the subsequent switching of the EDA tool or version or the adaptation of two or more EDA tools or versions is facilitated.

In one possible implementation of the second aspect of the present application, the one or more second templates are in one-to-one correspondence with the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employs a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology are different in at least one of: engineering scripts, stimulus generation, data types, printing mechanisms, environment integration, and environment startup.

In one possible implementation manner of the second aspect of the present application, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template adopts a UVM first version, the one or more second templates adopt a UVM second version, and the UVM first version and the UVM second version are different in at least one of the following items: an incentive exit mechanism, an incentive send mechanism, a printing format, and name checking rules.

In a possible implementation manner of the second aspect of the present application, the one or more second templates correspond to the at least one second verification platform one to one, the first template employs a first simulation tool, the one or more second templates employ a second simulation tool, and the first simulation tool and the second simulation tool are different in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling.

In a possible implementation manner of the second aspect of the present application, the one or more second templates correspond to the at least one second verification platform one to one, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of the following items: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement.

In a third aspect, an embodiment of the present application further provides a computer device, where the computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the method according to any implementation manner of any one of the above aspects when executing the computer program.

In a fourth aspect, embodiments of the present application further provide a computer-readable storage medium storing computer instructions that, when executed on a computer device, cause the computer device to perform the method according to any one of the implementation manners of any one of the above aspects.

In a fifth aspect, the present application further provides a computer program product, which includes instructions stored on a computer-readable storage medium, and when the instructions are run on a computer device, the computer device is caused to execute the method according to any one of the implementation manners of any one of the above aspects.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a schematic diagram of a verification platform generation apparatus according to an embodiment of the present disclosure;

FIG. 2 is a schematic illustration of a first template and a plurality of second templates provided by an embodiment of the present application;

fig. 3 is a schematic flowchart of a verification platform generation method according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of a computing device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The embodiment of the application provides a verification platform generation device, a verification platform generation method, a verification platform generation medium and electronic equipment, and aims to solve the problems in the prior art, namely how to improve verification efficiency and shorten a chip development cycle. The method and the device provided by the embodiment of the application are based on the same inventive concept, and because the principles of solving the problems of the method and the device are similar, the embodiments, the implementation modes, the examples or the implementation modes of the method and the device can be mutually referred, and repeated parts are not described again.

It should be understood that in the description of the present application, "at least one" means one or more than one, and "a plurality" means two or more than two. Additionally, the terms "first," "second," and the like, unless otherwise noted, are used for descriptive purposes only and are not to be construed as indicating or implying relative importance, nor order.

It should be understood that the verification platform generation apparatus, method, medium, and electronic device provided in the embodiments of the present application are used for functional verification of a DUT, that is, a design to be tested, in a chip design flow and a chip integration development process, for example, chip front-end functional verification. The meaning and definition of the chip mentioned in the embodiments of the present application should be understood to cover integrated circuits, ICs or chips in general and various related subclasses, sub-fields, etc. The verification platform generation device, the verification platform generation method, the verification platform generation medium and the electronic device are suitable for functional verification of chips in a general sense, and include functional verification of chips which are defined by a general chip, a customized chip, a chip defined for processing signals, a chip defined for an application field and any other suitable chips defined based on a mode of distinguishing chip design concepts, chip types, chip architectures and the like. The verification platform generation apparatus, method, medium, and electronic device provided in the embodiments of the present application are suitable for function verification of a general-purpose chip, including function verification of a DUT during design and integrated development related thereto, and exemplary and non-limiting examples of the general-purpose chip include a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC), a No Instruction Set Computing (NISC), and any other suitable general-purpose chip based on an instruction set system, and further include a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), and the like. The verification platform generation apparatus, method, medium, and electronic device provided in the embodiments of the present application are suitable for functional verification of custom chips (including fully custom chips and semi-custom chips), including functional verification of DUTs during design and integrated development related thereto, and exemplary and non-limiting examples of the custom chip include an application-specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), a coarse-grained reconfigurable architecture (CGRA), and any other suitable custom chip, such as a software-defined chip. The verification platform generation device, method, medium and electronic device provided by the embodiments of the present application are suitable for functional verification of chips defined for processing signals, including functional verification of DUTs in design and integration development processes related thereto, and exemplary and non-limiting examples of chips defined for processing signals include chips for digitally processing signals, chips for analog processing signals, hybrid chips and the like. The verification platform generation device, method, medium, and electronic device provided in the embodiments of the present application are suitable for functional verification of a chip defined for an application field, including functional verification of a DUT during design and integrated development related thereto, and exemplary and non-limiting examples of the chip defined for the application field include a processor chip, a sensor chip, a power supply chip, a communication chip, an interface chip, a chip for artificial intelligence algorithm acceleration, and the like for a general-purpose computer.

Referring to fig. 1, fig. 1 is a schematic diagram of a verification platform generation apparatus according to an embodiment of the present disclosure. The verification platform generation apparatus includes an interactive interface 102 and at least one processor 104. The interactive interface 102 includes a first region 110 and a second region 112. The second region 112 includes a plurality of standard components including at least a first component 122 for stimulus generation, a second component 124 for representing an environment, and a third component 126 for representing a connection relationship. The plurality of standard cells may be pulled to the first region 110 to build a cell assembly 130. The at least one processor 104 is configured to: according to the described combination of components 130, a first verification platform 152 is generated based on the first template 142 and at least one second verification platform 154 is generated based on one or more of at least one second template (not shown) selected by the user (the one or more second templates selected by the user are exemplarily shown in fig. 1 as second template 144). Wherein the plurality of standard components corresponds to the first template 142 and the visual structure of the combination of components 130 corresponds to the first verification platform 152. The first template 142 and each of the at least one second template differ at least in one of: verification methodology, simulation tools, version and scenario requirements. When at least one design under test DUT functional verification passes on the first verification platform 152 and functional verification passes on the at least one second verification platform 154, the interactive interface 102 displays the at least one DUT functional verification passing.

The interactive interface 102 may be understood as a graphical operation interface which is presented to the user and facilitates the operation of the user, and allows the user to input a corresponding instruction or perform a corresponding operation through an interactive control. The interactive interface 102 is presented to the user in a visual manner. The visualization manner may be a graph, a chart, an icon, or any suitable form, and is not limited in detail herein. Various standard components may be dragged to the first area 110 to construct the component assembly 130, where the standard components may be dragged by a user operating a precisely positionable device such as a mouse, a stylus, or any suitable pointing device to perform the dragging operation, or by a user entering a code to perform the dragging operation equivalently by the system. The component combination 130 in the first area 110 may be understood as a combination of standard components built on the visual interface by the user through the standard components, that is, a graph drawn on the visual interface, so that the user draws and configures the environment block diagram by using a platform tool, such as the standard components, provided by the interactive interface 102, so as to be used for subsequently generating the verification environment. The component assembly 130 includes connecting one standard component with another standard component, and the drawing may be from a blank environment block diagram, or may be from an existing template or a past saved draft, and is not limited in detail herein. The verification platform generation device shown in fig. 1 is used for functional verification of a chip development front end. Specifically, the functions of the chip may be decomposed into one or more Design Under Test (DUT). In one possible embodiment, the chip functional verification includes designing a corresponding verification environment for each DUT, and comparing outputs respectively made by the DUT and a Reference Model (RM) on the same input or stimulus signal can determine whether the DUT passes the functional verification in the corresponding verification environment. In order to simplify user operations when building a verification environment, various standard components are provided for generating the verification environment based on a visual interface. Wherein the plurality of standard components may include a plurality of levels of standard components, such as a first component 122 for stimulus generation, a second component 124 for representing an environment, and a third component 126 for representing a connection relationship, as shown in fig. 1. It should be understood that the second region 112 may provide a variety of standard components, and that different levels, different types of standard components may be provided according to any suitable validation methodology, platform architecture, or classification method. In some embodiments, the various standard components provided by the second area 112 include an environment component (ENV) at the top level, an AGENT component (AGENT), a SCOREBOARD Component (SCOREBOARD), and other components. With these standard components, a graphic on the visual interface (e.g., the first region 110 of the interactive interface 102) is rendered on the visual interface, i.e., a combination of standard components such as the component combination 130 is built. The user may connect one standard cell to another and draw a graph representing the connection relationships and logical timing between the plurality of cells, i.e., the combination of cells 130, by a drag operation of the drag cell and other suitable positioning operations. An executable code file is then automatically generated by a built-in system, such as the processor 104 of fig. 1, based on the environment diagram drawn on the first area 110, such as the component assembly 130, and the code file is available for functional verification of the DUT. In the process of automatically generating a code file according to the combination of standard components, a system such as the processor 104 automatically generates connections, inputs, outputs, and the like of Transaction Level Modeling (TLM) and generates interface classes such as port, interface, and the like according to the attributes (class name, instantiation name, file path, working mode, and the like) of each component in the combination of standard components, the connection relationship between the components (through a user dragging component, mouse operation, or direct input). Furthermore, the user may construct an excitation signal, i.e. construct an input excitation for functional verification, e.g. include in the combination of components 130 a component representing the input excitation, such as the first component 122 for excitation generation, and complete functional verification of the DUT. It should be understood that the interactive interface 102 shown in FIG. 1 can be used for functional verification of a single DUT or multiple DUTs, such as disassembling a system-on-chip, also called SOC, into multiple DUTs and performing functional verification on the multiple DUTs together. In some embodiments, the plurality of environment components may be integrated into a whole by respectively corresponding the plurality of topmost environment components to different DUTs.

The verification platform generation apparatus of fig. 1 is used for front-end functional verification in chip integration development, a verification scheme is formulated according to at least one DUT, and a verification environment or a verification platform is generated by drawing and configuring an environment block diagram through tools provided by the verification platform generation apparatus, such as standard components of the second area 112. In generating a verification environment or verification platform from a drawn environment block diagram, such as the component assembly 130, how to translate the visual structure of the component assembly 130 (arrangement, assembly, etc. of multiple components presented on the interactive interface 102) in the first area 110 into connection relationships between components, parameter configurations, signaling, etc., and may involve how to generate corresponding connections, inputs, outputs, and various interface classes, macros, class libraries, sending mechanisms, exit mechanisms, etc., and may also involve specific inspection rules and warning mechanisms, such as identifying inappropriate names, use of characters, etc. On the one hand, there are various EDA tools, including related integrated circuit design layout design software, electronic circuit design software, etc., which are provided by various EDA vendors or software companies specializing in EDA, and new and old versions and custom or semi-custom versions, which may differ from one source to another in verification methodology, verification tools, and specific technical details, and thus may generate different verification environments or verification platforms in the face of the visualization structure of the same component assembly 130, including possibly employing different code verification, inspection rules, warning strategies, etc. in a specific generation process. On the other hand, sometimes a user needs to switch EDA tools or versions or a chip for functional verification may need to adapt two or more EDA tools or versions. For example, a chip that passes functional verification under an old version may now need to adapt to the new version or the custom version because of version iteration; for another example, in some cases, because a new version of authorization or a legal use channel is lost, a chip or a part of chip design which is developed and functionally verified under the new version needs to be adapted to an old version; for another example, a chip developed and functionally verified under an EDA tool provided by a previous manufacturer now needs to be adapted to an EDA tool provided by another manufacturer. In some specific cases, a chip development project that is not done, e.g., halfway through, faces the problem of needing to switch EDA tools or versions, possibly because the chip development project has lost the authorization or legal usage rights of the EDA tools or specific versions that were originally used or for other possible reasons. Considering that different EDA tools or versions are used in the process of generating a verification environment or a verification platform, the specific tool and platform architecture, the processing method for the connection relationship, the input/output configuration, and the parameter configuration, and the processing method for the interface, the class library, the mechanism, the detection rule, the risk control, and the like are different in one or more of these aspects, and the influence caused by these differences is difficult to estimate in advance and difficult to judge in advance the range of the difference between different EDA tools or versions, so that the EDA tools or versions are difficult to adapt, and even difficult to perform function verification again or to change the design when switched. Further, as the software defined chip becomes one of the major trends of the industry development, the chip development also needs to be optimized in consideration of specific application scenarios, for example, according to the actual needs of different customers, such as optimization in combination with the application scenarios of the data center or the data processing requirement characteristics (voice communication, short connection, etc.). To achieve a comprehensive better optimization, it may be necessary to combine the respective advantages or strengths of different EDA tools or versions, for example, one EDA tool or version is suitable for a development project for a chip in one application scenario and another EDA tool or version is suitable for a development project for a chip in another application scenario. In addition, the time and economic cost of a chip's development project may also impact the selection of a particular EDA tool or version, for example, it is sometimes desirable to select an EDA tool or version that is less economically costly or has a shorter development time. Chip verification occupies most of the workload of the entire chip design flow. Therefore, the choice of EDA tools or versions for chip integration development and functional verification affects chip verification efficiency and chip verification environment and also affects development time and economic cost. In order to better plan the development project of the chip and the chip verification link to deal with the interference that may be received in the future (such as losing the authorization or legal use channel of the current EDA tool or version) and to pursue better comprehensive optimization effect and development design effect, in the chip verification such as the chip front-end function verification link, the situation that the EDA tool or version is switched or two or more kinds of EDA tools or versions are adapted needs to be considered, and therefore, different sources and different versions of EDA tools may be different in verification methodology, verification tools and specific technical details. How the verification platform generation apparatus and method according to the embodiment of the present application, for example, the verification platform generation apparatus in fig. 1, meets the above requirements is further described in detail with reference to fig. 1.

With continued reference to fig. 1, the at least one processor 104 is configured to: according to the described combination of components 130, a first verification platform 152 is generated based on the first template 142 and at least one second verification platform 154 is generated based on one or more of at least one second template (not shown) selected by the user (the one or more second templates selected by the user are exemplarily shown in fig. 1 as second template 144). Here, the first template 142 and the at least one second template (including the second template 144 selected by the user) embody the influence of the change of the macro factor on the chip function verification process and the verification result.

The macroscopic factor may be caused by the fact that the construction of the platform architecture of the verification environment and the construction of the excitation signal are based on specific verification methodologies obtained through experience summary in the past, such as Universal Verification Methodology (UVM), verification Methodology Manual (VMM), open Verification Methodology (OVM), and the like, and these verification methodologies have different performances in terms of simulation efficiency, stability, and the like of software simulation. In addition, macroscopic factors may also vary because of version iterations and version customizations, e.g., new industry standards or industry specifications may define new versions, and even greater variability may exist between old and new versions under the same validation methodology. In addition, the macroscopic factors may also vary because the EDA tools used, for example, come from different EDA tool suppliers, and the underlying verification logic and functional verification references of different EDA tools may differ (e.g., different syntax semantic understanding and thread scheduling implementation details in the system verilog standard), which may also result in different simulation tools compiling and simulation results for the same verification environment. To this end, variations in the various macro-level factors described above, including variations in versions embodying features from the corresponding simulation tools, verification methodologies, and verification methodologies, are reflected by providing a first template 142 and at least one second template (including a second template 144 selected by the user therein). The first template 142 and the second template 144 respectively provide details of the standardized components, such as class, base class, TLM communication mechanism, AGENT and SCOREBOARD. In addition, the first template 142 and the second template 144 respectively provide rules (including constraints, optimization strategies, etc.) for how the backend can verify the feasibility of the verification environment or the verification platform by running automatically and how to automatically generate the TLM's connections, inputs, outputs, etc. according to the drawn environment diagram (e.g., the component assembly 130 of fig. 1) when the verification environment or the verification platform is built by standardized components. For example, different verification methodologies determine the excitation signal to be constructed differently, such as UVM methodology using sequence approach and VMM methodology using generator mechanism, so that the first template 142 and the second template 144 may adopt different excitation signal construction depending on the verification methodology relied upon.

With continued reference to FIG. 1, the various standard components correspond to the first template 142 and the visual structure of the component assembly 130 corresponds to the first verification platform 152. The first template 142 and each of the at least one second templates differ at least in one of: verification methodology, simulation tools, version and scenario requirements. Thus, variations in various macro-level factors and their effects may be covered by the first template 142 and the at least one second template, that is, by providing the first template 142 and the at least one second template (including the second template 144 selected by the user therein), variations in the various macro-level factors described above, including variations in versions embodying features from the corresponding simulation tools, verification methodologies, and verification methodologies, are reflected. Further, the plurality of standard components correspond to the first template 142, the visual structure of the component combination 130 constructed by the plurality of standard components, such as the arrangement, combination, etc. of the components in the component combination 130 corresponds to the first verification platform 152, which means that the first template 142 determines the relevant details when generating the first verification platform 152, including how to convert the visual structure of the component combination 130 in the first area 110 (the arrangement, combination, etc. of the plurality of components presented on the interactive interface 102) into the connection relationship, parameter configuration, signal transmission, etc. between the components, and how to generate the corresponding connection, input, output, and various interface classes, macros, class libraries, sending mechanisms, exiting mechanisms, etc., and may also include specific checking rules and warning mechanisms, such as identifying inappropriate names, use of characters, etc. In addition, the plurality of standard components correspond to the first template 142, and the plurality of standard components provided on the second area 112 are visual structures for a user to conveniently construct the component assembly 130 in the first area 110 or for a user to conveniently draw the environment diagram in a visual manner, so that the first template 142 may correspond to a default template or a frequently used template of the user. In other words, when a visualization interface, such as the interactive interface 102 of FIG. 1, is operated to draw a block diagram of an environment, the combination of components 130 corresponding to the drawn block diagram of the environment, i.e., the plurality of standard components corresponding to the first template 142, is presented to the user, and the processor 104 translates the combination of components 130 into the first verification platform 152 (which may include a single verification environment corresponding to one DUT and/or a plurality of verification environments corresponding to a plurality of DUTs) based on the first template 142. But not presented to the user or otherwise not visible to the user, is the effect of the at least one second template (including the second template 144 selected by the user) on the finally generated executable code file. In other words, the first template 142, such as a default template or a common template, is used to draw the visual structure or drawing environment diagram of the component assembly 130 in the first area 110 of the interactive interface 102 in cooperation with the user, and the first template 142 is also used to generate the first verification platform 152 corresponding to the component assembly 130; while the second template is used to generate a second verification platform 154 corresponding to the component assembly 130, the second template does not correspond to the standard components provided by the second region 112 and is therefore not used to coordinate the user drawing of the environment block diagram, and the second template may correspond to standardized components, employed verification methodologies, and other aspects that differ from the first template 142. Further, the interactive interface 102 displays that at least one DUT functional verification passes when the at least one design under test, i.e., DUT, functional verification passes on the first verification platform 152 and functional verification passes on the at least one second verification platform 154. Thus, the user-drawn environment block diagram, i.e., the visualization structure of the component assembly 130, is used to visually present the current verification logic, which in turn needs to incorporate specific templates to generate executable code, i.e., a verification environment or a verification platform, corresponding to a particular simulation tool, a particular verification methodology, and a particular version of the verification methodology. For the user, what the user sees from the interactive interface 102 is the standard components corresponding to the second region 112 of the first template 142 and the component combination 130 of the first region 110 constructed by the standard components, so that the interactive interface 102 externally presents the visual structure based on the first template 142, but the subsequent functional verification requires that the verification of the first verification platform 152 based on the first template 142 and the verification of the second verification platform 154 based on the second template 144 selected by the user are both satisfied, so that the interactive interface 102 can display the at least one DUT functional verification. In this way, by providing various graphic controls and visualization tools of the user drawing environment block diagram based on the first template 142, such as standard components corresponding to the second region 112 of the first template 142, the user can complete drawing by using familiar development tools and habits, and then ensure that the functional verification of the at least one DUT passes through the dual functional verification of the first verification platform 152 and the second verification platform 154, the influence on the chip functional verification process and the verification result caused by the above-mentioned various macroscopic factors is considered, and it is also beneficial to cope with the situation of switching EDA tools or versions or adapting two or more EDA tools or versions subsequently.

The second template 144 is one or more second templates selected by the user and selected from at least one second template, and the first template 142 and each of the at least one second templates differ at least in one of: verification methodology, simulation tools, version and scenario requirements. In some embodiments, the user may pre-enter personal needs or preferences for determining the first template 142, e.g., the user may pre-select common or preferred simulation tools, verification methodologies, versions of verification methodologies, etc. For example, assuming that the default or user-familiar version of the simulation tool and verification methodology is Cadence simulation tool and UVM 1.1, after a user draws a graphic or environment block diagram, a first template 142 corresponding to the user-familiar tool and version is invoked to generate a code file corresponding to the drawn graphic or environment block diagram and the first template 142, thereby generating a first verification platform 152. Also, the second template 144 is selected by the user, the selection of the second template 144 may be based on variations of the various possible macroscopic factors described above, e.g., it may be considered to switch EDA tools or versions or to adapt two or more EDA tools or versions, and it may be considered that, for example, verification methodologies, verification tools, and specific technical details may differ between different sources, different versions of EDA tools. The result of functional verification of the at least one DUT is ensured by the dual functional verification of the first verification platform 152 and the second verification platform 154, which means that the functional verification (also applicable to subsequent automatic error correction and automatic optimization) of the DUT is performed under the first verification platform 152 generated based on the default template of the user, i.e. the first template 142, and at the same time, the functional verification, error correction and optimization and the like under the second verification platform 154 generated based on other templates, e.g. the second template 144, are also completed. That is, a user can quickly build a verification platform framework through a visual interface by using familiar or commonly-used simulation tools and verification methodology versions, and the finally obtained verification process and verification result can be applicable to other simulation tools, other verification methodologies, other versions and the like. And the user can select the second template 144 and the second verification platform 154 generated based on the second template 144 according to a specific strategy to combine the above-mentioned various considerations, which cover the specific situations that the EDA tools or versions need to be switched or the chips for performing function verification may need to be adapted to two or more EDA tools or versions. Exemplary considerations or particular circumstances include, but are not limited to, that a chip that passed functional verification under an old version may now need to adapt to the new version or the custom version because of version iterations; the chip which is developed and functionally verified under the new version or part of the chip is designed to be adapted to the old version when the new version authorization or legal use channel is lost; a chip developed and functionally verified under an EDA tool provided by a previous manufacturer now needs to be adapted to an EDA tool provided by another manufacturer; the chip development project faces the difficulty of switching EDA tools or versions when the project is not completed, such as half; chip development projects lose the originally used EDA tools or the authorized or legal use approaches of specific versions; optimizing according to the actual needs of different customers, such as optimizing by combining the application scene of a data center or the data processing demand characteristics (voice communication, short connection and the like); to achieve a comprehensive better optimization it is necessary to combine the respective advantages or strengths of different EDA tools or versions, e.g. one EDA tool or version is suitable for a development project for a chip in one application scenario and another EDA tool or version is suitable for a development project for a chip in another application scenario; it is desirable to select EDA tools or versions that are less economical or have shorter development times. In summary, in order to better plan the development project of the chip and the chip verification process to deal with the possible interference in the future (such as losing the authorization or legal use channel of the current EDA tool or version) and to pursue better comprehensive optimization and development design effect, in the chip verification process such as the chip front-end function verification process, the EDA tool or version needs to be switched or adapted to two or more EDA tools or versions, and therefore, different sources and different versions of EDA tools may be different in verification methodology, verification tool and specific technical details. The differences between these EDA tools from different sources and different versions ensure that the functional verification of the at least one DUT is successful by the aforementioned dual functional verification based on the first template 142 to provide various graphical controls and visualization tools of the user-drawn environment block diagram, such as the standard components corresponding to the second region 112 of the first template 142, and by the first verification platform 152 and the second verification platform 154, while providing convenience to the user operation and achieving better comprehensive optimization effects against possible future interferences.

It should be noted that the first template 142 and each of the at least one second template differ at least in one of: verification methodology, simulation tools, version and scenario requirements. The second template 144 selected by the user is selected from the at least one second template, and thus the first template 142 and the second template 144 also differ in at least one of: verification methodology, simulation tools, version and scenario requirements. As described above, the variations of the various macro-level factors described above, including variations arising from versions of the corresponding simulation tool, verification methodology, and verification methodology, are reflected by the first template 142 and the at least one second template (including the second template 144 selected by the user therein). This is explained in detail below in connection with fig. 2. Fig. 2 is a schematic diagram of a first template and a plurality of second templates provided in an embodiment of the present application. As shown in fig. 2, a first template 242 and three second templates (second template 244, second template 246, and second template 248, respectively). Wherein the first template 242 corresponds to the verification methodology 252, the simulation tool 262, the version 272, and the scenario requirements 282; the second template 244 corresponds to the verification methodology 252, the simulation tool 262, the version 272, and the scenario requirements 284; the second template 246 corresponds to the verification methodology 252, the simulation tool 262, the version 274, and the scenario requirements 282; the second template 248 corresponds to the verification methodology 254, the simulation tool 264, the version 276, and the scenario requirements 282. As can be seen by comparing the first template 242 and the second template 244, the two use the same verification methodology, the same simulation tool, the same version but different scenario requirements, and therefore when the DUT is verified on the verification platform generated based on the first template 242 and the second template 244, respectively, this means that the DUT adapts to the first scenario requirements 282 and the second scenario requirements 284 at the same time, which means that the chip including the DUT has better comprehensive optimization effect. Similarly, it can be seen by comparing the first template 242 and the second template 246 that both employ the same verification methodology, the same simulation tool but different versions, also adapt to the same scenario requirements, where the version 274 corresponding to the second template 246 may be an old version relative to the version 272 corresponding to the first template 242, so that when the DUT is verified on a verification platform generated based on the first template 242 and the second template 246, respectively, this means that the DUT can adapt to both the relatively newer version 272 and the relatively older version 274, that is, when the chip developer encounters a situation where the relatively newer version 272 cannot be used (e.g., may be out of authorization or a legitimate use channel), the chip developer can continue to develop and verify under the relatively older version 274, that is, continue to use the verification platform based on the second template 246 to complete subsequent chip development work. Similarly, as can be seen by comparing the first template 242 with the second template 248, the second template 248 employs a different verification methodology than the first template 242, and also employs a different simulation tool and a different version, but adapts to the same scenario requirements 282. This may be because the first template 242 corresponds to a development tool provided by a given EDA tool vendor and the second template 248 corresponds to a development tool provided by another EDA tool vendor that is different from the given EDA tool vendor. EDA tools from different EDA tool vendors typically design the platform architecture and build stimulus signals, etc. of their respective verification environments based on their long-term accumulated empirical summaries, i.e., typically employ different verification methodologies (or at least remain different in local detail), and typically differ in the underlying verification logic and functional verification references (e.g., different in syntax semantic understanding and thread scheduling implementation details in the system verilog standard). These differences are present in the second template 248 described above, which employs a different verification methodology, simulation tool, and version than the first template 242. Thus, when a DUT passes verification on a verification platform generated based on the first template 242 and the second template 248, respectively, which means that the DUT can adapt to both an EDA tool corresponding to the first template 242 and another EDA tool corresponding to the second template 248, that is, when a chip developer encounters a condition that the EDA tool corresponding to the first template 242 cannot be used (e.g., authorization may be lost or a channel of legitimate use), the chip developer can continue to develop and verify under the other EDA tool corresponding to the second template 248, that is, continue to use the verification platform based on the second template 248 to complete subsequent chip development work.

Referring to fig. 1 and fig. 2, the verification platform generation apparatus provided in the embodiment of the present application considers that development projects of a chip and possible interferences to a chip verification link (such as loss of authorization or legal use channel of a current EDA tool or version) also consider demands for pursuing better comprehensive optimization effects and development design effects, and differences may exist in verification methodologies, verification tools and specific technical details between EDA tools of different sources and different versions, so that at least one second verification platform is generated according to a component combination and based on a first verification platform and based on one or more second templates selected by a user in at least one second template, thereby effectively coping with influences on a chip function verification process and verification results caused by changes of macroscopic factors, and a visual structure of a plurality of standard components corresponding to the first template and the component combination corresponds to the first verification platform, thereby making it possible to conveniently build a block diagram of an EDA environment through an interactive interface, which is beneficial for subsequent switching of EDA tools or versions or two or more EDA tools or versions.

With continued reference to fig. 1, in some embodiments, the functional verification of the verification platform based on different templates, such as an analog simulation process, may perform a full-flow verification, including performing an overall evaluation on code coverage, functional coverage, simulation efficiency, stability, and the like, which is beneficial for a user to compare functional verification performances under different templates. In addition, local comparison can be performed through full-process evidence storage. For example, a user-built verification platform framework includes multiple ENVs that respectively verify multiple DUTs, such as multiple ENVs that functionally verify a system-on-chip SOC. The performance of the verification platform or verification environment under different templates, for example, the performance of each of UVM 1.1 and UVM 1.2, may be compared for a DUT. When different verification methodologies are employed, such as UVM verification methodology and OVM verification methodology, different standardized components are often involved, including their definition and packaging details, such as different names, compilation languages, base class templates, etc. While the user-drawn block diagram of the environment may be used to characterize the verification logic (built from standard components corresponding to a first template) and thus may be used for other templates, such as a second template. By comparing the performance of verification environments of a single DUT under different templates, richer reference information can be provided. Taking the functional verification of a single DUT as an example, the verification environment or verification platform of the DUT is constructed based on the UVM verification methodology, including the reference model and the DUT. The same stimulus (single INPUT signal or same INPUT AGENT component such as INPUT AGENT) is applied to the reference model and DUT, and then the output of both is used to determine if they are identical, i.e. the respective outputs are directed to the same SCOREBOARD component such as SCOREBOARD. The rendered environment block diagram, for example, the visual structure of the component assembly 130 in the first area 110 of the interactive interface 102 shown in fig. 1, is transformed into an executable code file via the corresponding template, for example, the first verification platform 152 via the first template 142 and the second verification platform 154 via the second template 144. In the process of converting the drawn environment block diagram into an executable code file according to a specific template, the packaged standardized components are converted into corresponding codes according to respective component attributes (class names, instantiation names, file paths and working modes), and a proper communication mechanism, an excitation type and the like are provided according to the connection relationship among the components on the drawn environment block diagram. That is, according to the specifically adopted template, such as the first template 142 or the second template 144, it is determined how to translate the visual structure (arrangement, combination, etc. of the plurality of components presented on the interactive interface 102) of the component combination 130 of the first area 110 into the connection relationship between the components, parameter configuration, signal transmission, etc., and how to generate the corresponding connection, input, output, and various interface classes, macros, class libraries, sending mechanisms, exiting mechanisms, etc., and also to determine specific checking rules and warning mechanisms, such as identifying inappropriate names, use of characters, etc.

In a possible embodiment, the interactive interface further comprises a template selection component (not shown) for a user to select the one or more second templates.

In a possible embodiment, the first template is a default template and the at least one second template is an optional template. For example, a user may set default templates based on preferences and personal needs.

In one possible implementation, the one or more second templates correspond one-to-one to the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employs a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology differ in at least one of: stimulus generation, data type, printing mechanism, environment integration, and environment initiation. Here, the verification methodology represents a long-accumulated empirical summary to design the platform architecture and construct the excitation signal of the verification environment, and the different verification methodologies generally have differences in the underlying verification logic and the basis of functional verification. For example, different validation methodologies may employ different motivational construction approaches, such as UVM methodology using sequence approach and VMM methodology using generator mechanism. Furthermore, different validation methodologies differ with respect to semantic understanding of syntax and thread scheduling implementation details in the system verilog standard. Thus, the first validation methodology differs from the second validation methodology in stimuli generation, data type, printing mechanism, environment integration, and environment initiation. In some embodiments, the first validation methodology and the second validation methodology differ in stimulus generation, wherein the first validation methodology controls stimulus generation by controlling stimulus combination sequence and the second validation methodology controls stimulus generation by invoking a macro to invoke a stimulus class as a stimulus generator. For example, the verification methodology corresponding to UVM defines sequence as a combination of a series of stimuli on the stimulus process, and the stimulus generation control is implemented by controlling different sequences. The verification methodology for the VMM generates the class of stimulus generators by substituting macros, for example using macros VMM _ autoic _ gen or VMM _ scenario _ gen. The stimulus generator TLM communicates with other components and passes the generated stimulus to other components. In some embodiments, the first authentication methodology and the second authentication methodology differ in printer-engineering, wherein printing of the first authentication methodology inherits uvm _ report _ server class, and printing of the second authentication methodology calls vmm _ log class and a macro implementation component and object corresponding to vmm _ log class. For example, for component operation, the verification methodology corresponding to UVM employs a unique mechanism to control multithreading ordered operation and termination, where printing inherits the UVM _ report _ server class. And the verification methodology corresponding to the VMM realizes the modification of the printing level in a command line mode, and the printing calls VMM _ log class and the macro corresponding to VMM _ log class realize the printing of components and objects. In some embodiments, the first validation methodology implements factory patterns through macro declarations and data transfers between different components through global resource configuration, and the second validation methodology implements data transfers through external declaration definitions. For example, the verification methodology corresponding to the UVM adopts a UVM _ config _ db approach, which configures some resources of the verification environment like global variables, so that it is visible to the whole verification environment, that is, data transfer of different components is realized through the global resource configuration approach. And the verification methodology corresponding to the VMM may be passed by parameters in the new function or by external declaration definitions. In some embodiments, the first and second validation methodologies also differ in validation environment level divisions. For example, VMM corresponds to a verification methodology that distinguishes the two concepts VMM _ subenv and VMM _ env at the verification environment level division, while UVM corresponds to a verification methodology that does not have the concept of subenv at the verification environment level division. In some embodiments, the first validation methodology is UVM and the second validation methodology is VMM or OVM.

In one possible embodiment, the one or more second templates correspond to the at least one second verification platform one-to-one, the first template adopts a first UVM version, the one or more second templates adopt a second UVM version, and the first UVM version and the second UVM version differ at least in one of: engineering scripts, incentive exit mechanisms, incentive send mechanisms, print formats, and name check rules. Version iterations exist as well as custom versions, etc. of the same validation methodology, and new versions may be defined due to changes in industry standards and industry specifications. Generally, the differences between the two different versions are reflected in the engineering script, the incentive quit mechanism, the incentive send mechanism, the printing format and the name check rules. In some embodiments, the first version of the UVM and the second version of the UVM differ in a stimulus exit mechanism, the first version of the UVM controlling the stimulus exit mechanism (e.g., version UVM 1.1) by invoking a cause _ object and a drop _ object, and the second version of the UVM controlling the stimulus exit mechanism (e.g., version UVM 1.2) by invoking set _ starting _ phase and get _ starting _ phase. In some embodiments, the first and second versions of the UVM are different in name check rules, the second version of the UVM checks usage of a meta character in a domain segment name by resource _ db and generates an alert, the first version of the UVM does not check usage of a meta character in a domain segment name or filters the alert. Therefore, differences in different specifications or local details between different versions in the name check rules may affect the determination of the regression case result, and thus the warning needs to be filtered or processed in a targeted manner. In some embodiments, the UVM second version is an updated version relative to the UVM first version. For example, the first version of UVM is a UVM version 1.1 and the second version of UVM is an updated version such as a UVM version 1.2. Additionally, the two EDA tools may each employ a different engineering script, and thus, in some embodiments, the difference between the first and second versions of UVM may also be reflected in the engineering script. In some embodiments, the second version of UVM is different from the first version of UVM.

In one possible implementation, the one or more second templates correspond to the at least one second verification platform one-to-one, the first template employs a first simulation tool, the one or more second templates employs a second simulation tool, and the first simulation tool and the second simulation tool differ in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling. Different simulation tools, typically originating from different suppliers, such as different suppliers of EDA tools. The differences between different simulation tools are generally reflected in: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling. In particular, the different simulation tools may be VCS software from Synopsis and xrun software from Cadence, or modelsim software from Mentor Graphics. Further, in some embodiments, the first simulation tool is a simulation tool provided by Synopsys and the second simulation tool is a simulation tool provided by Cadence or may also be a vendor of other EDA development tools such as Wyda Twoday or a software vendor focused on EDA software. In some embodiments, the first simulation tool and the second simulation tool differ in compilation, the first simulation tool treating the virtual interface as an error at compile time, the second simulation tool not treating the virtual interface as an error at compile time. For example, VCS software from Synopsis does not report compilation errors for interfaces defined as virtual interfaces, but xrun software from Cadence reports compilation errors for interfaces defined as virtual interfaces. In some embodiments, the first simulation tool and the second simulation tool employ different compilation styles and simulation options. For example, the first and second emulation tools may have different processing or decision criteria for the manner of invocation of the TCL script, for a particular writing (e.g., a dist { [0:'1 }), for a parameter type (e.g., try _ get), for a particular action (e.g., get action), for a particular syntax (e.g., disable table syntax), etc. In some embodiments, the first simulation tool is configured to adapt a compilation mode and a simulation option call of the VCS, and the second simulation tool is configured to adapt a compilation mode and a simulation option call of an xrun, irun, or modelsim.

In a possible implementation, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of the following items: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement. With the trend development of software defined chips and the popularization of detailed scene requirements and sinking applications, different scene requirements need to be considered to design the chips and verify the chips, and differences among the different scene requirements are reflected in customer preference, requirements on environment running speed, verification efficiency and requirements on environment layering degree. In some embodiments, the first scenario requirement and the second scenario requirement are both associated with a complexity of the at least one DUT. For example, when the complexity of the DUT is low, the function may be relatively single, and the corresponding scenario requirements are met. In some embodiments, the first template selects a first verification methodology, a first simulation tool, and a first version, and the selection of the first verification methodology, the first simulation tool, and the first version is based on the first scenario requirements and the complexity of the at least one DUT. Thus, for the case that the complexity of the DUT is low, the functions are relatively single, and the first scenario requirement emphasizes timeliness and economy, a more matched first template can be selected to shorten the development period. In some embodiments, when the at least one DUT is a multiplier, an asynchronous FIFO, a clock generator, or a divider, the first scenario requirement has a higher priority for environment speed requirements and validation efficiency than for environment level of hierarchy requirements. Here, the multiplier, the asynchronous FIFO, the clock generator, the frequency divider, or the like has a single function and a low complexity, and is suitable for giving priority to the requirement of the operating speed of the environment and the verification efficiency. For example, instead of UVM verification methodology, a simple verification platform may be built using system verilog or even verilog language for functional testing, which has the advantages of relatively low environment layering level, fast environment running speed and high verification efficiency.

Referring to fig. 3, fig. 3 is a schematic flowchart of a verification platform generation method according to an embodiment of the present disclosure. As shown in fig. 3, the verification platform generation method includes the following steps.

Step S310: an interactive interface is provided.

In step S310, the interactive interface includes a first area and a second area, the second area includes a plurality of standard components including at least a first component for stimulus generation, a second component for representing an environment, and a third component for representing a connection relationship.

Step S320: a combination of components is constructed by dragging a plurality of standard components to the first area.

Step S330: according to the combination of components, a first verification platform is generated based on the first template and at least one second verification platform is generated based on one or more of the at least one second template selected by the user.

In step S330, the plurality of standard components correspond to the first template and the visual structure of the combination of components corresponds to the first verification platform. The first template and each of the at least one second template differ at least in one of: verification methodology, simulation tools, version and scenario requirements.

Step S340: it is determined whether the at least one DUT is functionally verified on the first verification platform and functionally verified on the at least one second verification platform, if step S350 is passed, if step S360 is not passed.

Step S350: the interactive interface displays that at least one DUT function is verified.

Step S360: the interactive interface displays at least one DUT functional verification failed.

The verification platform generation method shown in fig. 3 considers the development project of the chip and the possible interference on the verification link of the chip (such as loss of authorization or legal use channel of the current EDA tool or version), and also considers the requirement of pursuing better comprehensive optimization effect and development design effect, for EDA tools of different sources and different versions, there may be differences in verification methodology, verification tools and specific technical details, the first verification platform is generated according to the component combination and based on the first template, and at least one second verification platform is generated based on one or more second templates selected by the user in the at least one second template, so as to effectively cope with the influence on the chip function verification process and verification result caused by the change of the macroscopic factors, and the visualization structure of the plurality of standard components corresponding to the first template and the component combination corresponds to the first verification platform, so that an environmental block diagram can be conveniently built through an interactive interface, which is beneficial to subsequently switch the EDA tool or adapt two or more EDA tools or versions.

In one possible implementation, the one or more second templates correspond one-to-one to the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employs a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology differ in at least one of: engineering scripts, stimulus generation, data types, printing mechanisms, environment integration, and environment startup.

In one possible embodiment, the one or more second templates correspond to the at least one second verification platform one-to-one, the first template adopts a first UVM version, the one or more second templates adopt a second UVM version, and the first UVM version and the second UVM version differ at least in one of: an incentive exit mechanism, an incentive send mechanism, a printing format, and name checking rules.

In one possible implementation, the one or more second templates correspond to the at least one second verification platform one-to-one, the first template employs a first simulation tool, the one or more second templates employs a second simulation tool, and the first simulation tool and the second simulation tool differ in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling.

In a possible implementation, the one or more second templates correspond to the at least one second verification platform in a one-to-one manner, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of the following items: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a computing device provided in an embodiment of the present application, where the computing device 400 includes: one or more processors 410, a communication interface 420, and a memory 430. The processor 410, communication interface 420, and memory 430 are interconnected by a bus 440. Optionally, the computing device 400 may further include an input/output interface 450, and the input/output interface 450 is connected with an input/output device for receiving parameters set by a user, and the like. The computing device 400 can be used to implement some or all of the functionality of the device embodiments or system embodiments described above in this application; the processor 410 can also be used to implement some or all of the operational steps of the method embodiments described above in the embodiments of the present application. For example, specific implementations of the computing device 400 to perform various operations may refer to specific details in the above-described embodiments, such as the processor 410 being configured to perform some or all of the steps or some or all of the operations in the above-described method embodiments. For another example, in this embodiment of the application, the computing device 400 may be used to implement part or all of the functions of one or more components in the above-described apparatus embodiments, and the communication interface 420 may be specifically used to implement the communication functions and the like necessary for the functions of these apparatuses and components, and the processor 410 may be specifically used to implement the processing functions and the like necessary for the functions of these apparatuses and components.

It should be understood that the computing device 400 of fig. 4 may include one or more processors 410, and the processors 410 may cooperatively provide processing capabilities in a parallelized, serialized, deserialized, or any connection, or the processors 410 may form a processor sequence or an array of processors, or the processors 410 may be separated into a main processor and an auxiliary processor, or the processors 410 may have different architectures such as employing heterogeneous computing architectures. Further, the computing device 400 shown in FIG. 4, the associated structural and functional descriptions are exemplary and non-limiting. In some example embodiments, computing device 400 may include more or fewer components than shown in FIG. 4, or combine certain components, or split certain components, or have a different arrangement of components. The processor 410 may be implemented in various specific forms, for example, the processor 410 may include one or more combinations of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a neural-Network Processing Unit (NPU), a Tensor Processing Unit (TPU), or a Data Processing Unit (DPU), and the embodiments of the present application are not limited in particular. Processor 410 may also be a single core processor or a multicore processor. The processor 410 may be comprised of a combination of a CPU and hardware chips. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The processor 410 may also be implemented as a single logic device with built-in processing logic, such as an FPGA or a Digital Signal Processor (DSP). The communication interface 420 may be a wired interface, such as an ethernet interface, a Local Interconnect Network (LIN), or the like, or a wireless interface, such as a cellular network interface or a wireless lan interface, for communicating with other modules or devices.

The memory 430 may be a non-volatile memory, such as a read-only memory (ROM), a Programmable ROM (PROM), an erasable programmable PROM (EPROM), an Electrically Erasable Programmable ROM (EEPROM), or a flash memory. The memory 430 may also be volatile memory, which may be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM, enhanced SDRAM, SLDRAM, synchronous Link DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 430 may also be used to store program codes and data for the processor 410 to call the program codes stored in the memory 430 to perform some or all of the operational steps of the above-described method embodiments or to perform corresponding functions in the above-described apparatus embodiments. Moreover, computing device 400 may contain more or fewer components than shown in FIG. 4, or have a different arrangement of components. The bus 440 may be a peripheral component interconnect express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a unified bus (UBs or UBs), a computer express link (CXL), a cache coherent interconnect protocol (CCIX) bus, or the like. The bus 440 may be divided into an address bus, a data bus, a control bus, and the like. The bus 440 may include a power bus, a control bus, a status signal bus, and the like, in addition to a data bus. However, for clarity, only one thick line is shown in FIG. 4, but this does not represent only one bus or one type of bus.

Embodiments of the present application also provide a system including a plurality of computing devices, where the structure of each computing device may refer to the structure of the computing device described above with reference to fig. 4. The functions or operations that can be implemented by the system may refer to specific implementation steps in the above method embodiments and/or specific functions described in the above apparatus embodiments, which are not described in detail herein. Embodiments of the present application also provide a computer-readable storage medium, in which computer instructions are stored, and when the computer instructions are executed on a computer device (such as one or more processors), the method steps in the above method embodiments may be implemented. The specific implementation of the processor of the computer-readable storage medium in executing the above method steps may refer to the specific operations described in the above method embodiments and/or the specific functions described in the above apparatus embodiments, which are not described herein again.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. The present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Embodiments of the present application may be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The present application may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied in the medium. The computer program product includes one or more computer instructions. When loaded or executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more collections of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium. The semiconductor medium may be a solid state disk, or may be a random access memory, flash memory, read only memory, erasable programmable read only memory, electrically erasable programmable read only memory, registers, or any other form of suitable storage medium.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. Each flow and/or block in the flow charts and/or block diagrams, and combinations of flows and/or blocks in the flow charts and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments. It will be apparent to those skilled in the art that various changes and modifications may be made in the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. The steps in the method of the embodiment of the application can be sequentially adjusted, combined or deleted according to actual needs; the modules in the system of the embodiment of the application can be divided, combined or deleted according to actual needs. If these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, then the present application is intended to include these modifications and variations as well.

Claims

1. A verification platform generation apparatus comprising an interactive interface and at least one processor, the interactive interface comprising a first region and a second region, the second region comprising a plurality of standard components, the plurality of standard components comprising at least a first component for stimulus generation, a second component for representing an environment, and a third component for representing a connection relationship, the plurality of standard components being draggable to the first region to construct a combination of components;

the at least one processor is configured to: according to the component combination, generating a first verification platform based on a first template and generating at least one second verification platform based on one or more second templates selected by a user, wherein the plurality of standard components correspond to the first template and a visual structure of the component combination corresponds to the first verification platform, and each of the first template and the at least one second template is different from each other at least in one of: verification methodology, simulation tools, version and scenario requirements; said interactive interface displaying functional verification of said at least one DUT when said at least one DUT passes functional verification on said first verification platform and functional verification on said at least one second verification platform,

wherein the interactive interface displays that the at least one design under test functional verification fails when the at least one design under test functional verification passes on the first verification platform and functional verification fails on the at least one second verification platform,

when the at least one design under test is not functionally verified on the first verification platform and is functionally verified on the at least one second verification platform, the interactive interface displays that the at least one design under test is not functionally verified.

2. The verification platform generation apparatus of claim 1, wherein the interactive interface further comprises a template selection component for user selection of the one or more second templates.

3. The verification platform generation apparatus of claim 1, wherein the first template is a default template and the at least one second template is an optional template.

4. The verification platform generation apparatus of claim 1, wherein the one or more second templates have a one-to-one correspondence with the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employ a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology differ in at least one of: engineering scripts, stimulus generation, data types, printing mechanisms, environment integration, and environment startup.

5. The verification platform generation apparatus of claim 4, wherein the first verification methodology and the second verification methodology differ in excitation generation, wherein the first verification methodology controls excitation generation by controlling excitation combination sequence, and wherein the second verification methodology controls excitation generation by invoking macro-calls as excitation classes of an excitation generator.

6. The verification platform generation apparatus according to claim 4, wherein the first verification methodology and the second verification methodology differ in printer system, wherein printing of the first verification methodology inherits uvm _ report _ server class, and printing of the second verification methodology calls vmm _ log class and a macro implementation component and object corresponding to vmm _ log class.

7. The verification platform generation apparatus of claim 4, wherein the first verification methodology implements factory mode via macro declaration and data transfer between different components via global resource configuration, and the second verification methodology implements data transfer via external declaration definition.

8. The verification platform generation apparatus of claim 4, wherein the first verification methodology and the second verification methodology further differ in verification environment hierarchy partitioning.

9. The verification platform generation apparatus of claim 4, wherein the first verification methodology is UVM and the second verification methodology is VMM or OVM.

10. The verification platform generation apparatus of claim 1, wherein the one or more second templates correspond one-to-one to the at least one second verification platform, the first template is a UVM first version, the one or more second templates are UVM second versions, and the UVM first version and the UVM second version differ at least in one of: an incentive exit mechanism, an incentive send mechanism, a printing format, and name checking rules.

11. The verification platform generation apparatus according to claim 10, wherein the first UVM version and the second UVM version differ in a stimulus exit mechanism, the first UVM version controlling the stimulus exit mechanism by invoking a cross _ object and a drop _ object, the second UVM version controlling the stimulus exit mechanism by invoking a set _ starting _ phase and a get _ starting _ phase.

12. The verification platform generation apparatus of claim 10, wherein the UVM first version and the UVM second version differ in name checking rules, the UVM second version checking usage of a meta character in a domain segment name by resource _ db and generating an alert, the UVM first version not checking usage of a meta character in a domain segment name or filtering the alert.

13. The verification platform generation apparatus of claim 10, wherein the second version of UVM is a different version number than the first version of UVM.

14. The verification platform generation apparatus of claim 13, wherein the UVM second version is an updated version relative to the UVM first version.

15. The verification platform generation apparatus of claim 1, wherein the one or more second templates correspond to the at least one second verification platform one-to-one, the first template employs a first simulation tool, the one or more second templates employs a second simulation tool, and the first simulation tool and the second simulation tool differ in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling.

16. The verification platform generation apparatus of claim 15, wherein the first simulation tool is configured to adapt a compilation mode and a simulation option call of the VCS, and the second simulation tool is configured to adapt a compilation mode and a simulation option call of an xrun, irun, or modelsim.

17. The verification platform generation apparatus of claim 15, wherein the first simulation tool and the second simulation tool differ in compilation, the first simulation tool treating the virtual interface as an error at compile time, the second simulation tool not treating the virtual interface as an error at compile time.

18. The verification platform generation apparatus of claim 15, wherein the first simulation tool and the second simulation tool employ different compilation and simulation options.

19. The verification platform generation apparatus according to claim 1, wherein the one or more second templates correspond to the at least one second verification platform one-to-one, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement.

20. The verification platform generation apparatus of claim 19, wherein the first scenario requirement and the second scenario requirement are each associated with a complexity of the at least one DUT.

21. The verification platform generation apparatus of claim 20, wherein the first template selects a first verification methodology, a first simulation tool, and a first version, and wherein the selection of the first verification methodology, the first simulation tool, and the first version is based on the first scenario requirements and a complexity of the at least one DUT.

22. The verification platform generating apparatus of claim 21, wherein when the at least one DUT is a multiplier, an asynchronous FIFO, a clock generator, or a divider, the first scenario requirement has a higher priority for environment operating speed requirement and verification efficiency than for environment layering level requirement.

23. A verification platform generation method, comprising:

providing an interactive interface, wherein the interactive interface comprises a first area and a second area, the second area comprising a plurality of standard components, the plurality of standard components comprising at least a first component for stimulus generation, a second component for representing an environment, and a third component for representing a connection relationship;

building a combination of elements by dragging said plurality of standard elements to said first area;

according to the component combination, generating a first verification platform based on a first template and generating at least one second verification platform based on one or more second templates selected by a user, wherein the plurality of standard components correspond to the first template and a visual structure of the component combination corresponds to the first verification platform, and each of the first template and the at least one second template is different from each other at least in one of: verification methodology, simulation tools, version and scenario requirements;

displaying, via the interactive interface, a functional verification of at least one DUT on the first verification platform when the at least one DUT is functionally verified on the first verification platform and functionally verified on the at least one second verification platform,

24. The verification platform generation method of claim 23, wherein the one or more second templates have a one-to-one correspondence with the at least one second verification platform, the first template employs a first verification methodology, the one or more second templates employ a second verification methodology, the first verification methodology is different from the second verification methodology and the first verification methodology and the second verification methodology differ in at least one of: engineering scripts, stimulus generation, data types, printing mechanisms, environment integration, and environment startup.

25. The verification platform generation method of claim 23, wherein the one or more second templates correspond one-to-one to the at least one second verification platform, wherein the first template is a UVM first version, wherein the one or more second templates are UVM second versions, and wherein the UVM first version and the UVM second version differ at least in one of: an incentive exit mechanism, an incentive send mechanism, a printing format, and name checking rules.

26. The verification platform generation method of claim 23, wherein the one or more second templates correspond to the at least one second verification platform one-to-one, the first template employs a first simulation tool, the one or more second templates employs a second simulation tool, and the first simulation tool and the second simulation tool differ in at least one of: semantic understanding of hardware description language, thread scheduling, compiling mode and simulation option calling.

27. The verification platform generation method of claim 23, wherein the one or more second templates correspond to the at least one second verification platform one-to-one, the first template corresponds to a first scenario requirement, the one or more second templates correspond to a second scenario requirement, and the first scenario requirement and the second scenario requirement are different in at least one of: client preference, environment running speed requirement, verification efficiency and environment layering degree requirement.

28. A non-transitory computer readable storage medium storing computer instructions which, when executed by a processor, implement the method of any one of claims 23 to 27.

29. An electronic device, characterized in that the electronic device comprises:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of claims 23 to 27 by executing the executable instructions.