A method for generating and running functional models based on an automated verification environment.

Abstract

This application relates to a method for generating and running functional models based on an automated verification environment. The method involves constructing several functional models according to a preset architecture; defining a general data structure matching the input / output data structures of the functional models and saving it in at least one package; defining an interface conversion function between the input / output data structures and the general data structure; configuring the functional models in a preset automated verification environment; and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models. This method can advance the start time of verification work from the time of providing design technical documents to the time when the architect provides the prototype design. After unifying the data structure of the model interfaces, it facilitates the cascading of front-end and back-end models, eliminating the need to pay extra attention to interface matching issues and reducing the difficulty of model reuse.

Description

Technical Field

[0001] This disclosure relates to the field of digital verification technology, and in particular to a method, apparatus and creation system for generating and running functional models based on an automated verification environment. Background Technology

[0002] The DPU is a new type of chip that integrates IP from multiple fields, including technologies such as SOC, NVMe controller, OVS, VirtIO, and TOE. Some of these technologies have similar functions or are hierarchical. Given this, users want verification engineers to be able to write and debug certain functions once and call them multiple times, saving verification engineers time in developing the same code repeatedly while ensuring consistent expected results in the verification environment.

[0003] Currently, the popular verification methodology, UVM, provides a general environment structure and environment reuse scheme. UVM offers reuse schemes based on agents or environments. However, as chip scale increases and R&D teams decide to adopt IP-based design to implement a large-scale chip, the reused units may be very small or very large. Therefore, the reuse form based on agents or environments becomes inconvenient: First, the verification team may not provide a verification environment for each IP to test; second, in practice, IP development and the environment development of other modules may be simultaneous, making it impossible to obtain the VIP corresponding to the required IP in a timely manner; third, writing an agent for a smaller reused unit consumes additional time.

[0004] Furthermore, with existing general-purpose technologies, the development and debugging of these functions are coordinated with the development of the entire verification environment. The entire chip development process begins with the architecture engineer defining the architecture and writing the HLD (Hardware Design Logic). Building a verification environment requires a more detailed LLD (Limited Ledger Design Logic). This means that the start time of a verification task is usually already behind schedule. If the function is very complex or the algorithm is difficult to debug, the verification work will be even more delayed.

[0005] Users prefer that the debugging of these functions be involved when the architect is writing the HLD (Hardware Implementation Design), allowing for the development of a model of the proposed solution and feasibility testing. This model code can then be reused in the subsequent verification environment as a functional model, thus bringing the entire verification task forward to the HLD stage and allowing more time for subsequent verification work.

[0006] Another discouraged approach to environment reuse is copying the desired code from another environment. This method introduces a series of negative issues, including code synchronization problems, reliability issues, readability and maintenance problems arising from the merging of different code styles, and so on. Furthermore, this method requires the copied environment to be stable before the current environment.

[0007] Finally, even if users model the architecture solution and write corresponding models during the HLD phase, making them usable in subsequent environments, the defined interface signals and models may not be entirely consistent during the actual LLD detailed design process. This is because differences in personal experience, style, and understanding lead to duplicated work and even rework. Furthermore, with this approach, all relevant verification engineers need to be notified when the architecture is updated, resulting in additional workload. If notifications are not timely or some verification engineers are missed, the environment may not be updated due to untimely information synchronization, leading to additional debugging costs. Summary of the Invention

[0008] To address the aforementioned issues, this application proposes a method, apparatus, and creation system for generating and running functional models based on an automated verification environment.

[0009] This application proposes a method for generating and running functional models based on an automated verification environment, including the following steps: S100. Construct several functional models according to the preset architecture scheme; S200. Based on the input / output data structure of the functional model, define a general data structure that matches the input / output data structure and save it to at least one package; S300, Define the interface conversion function between the input / output data structure and the general data structure; S400. Configure the functional model in a preset automated verification environment, and call the interface conversion function according to the data structure type to complete the format conversion between different functional models.

[0010] As an optional implementation of this application, optionally, in step S100, constructing several functional models according to a preset architecture scheme includes: S110, Set the conditions for establishing the data structure; S120. Based on the data structure establishment conditions, establish a unified model interface data structure, wherein the data structure includes: a transactional data structure for communication between various components and functional models of the verification environment, and an interface data structure for communication between the verification environment and the DUT. S130. Save the data structure to different packages.

[0011] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models includes: S411. Pre-construct the expected transactional data through transactions; S421. Call the first data structure, input the transactional data into the corresponding functional model through the first data structure, and process the data into required data that meets the preset conditions through the functional model; S431. Call the second data structure to convert the requirement data obtained from the functional model into interface data, and send it to the driver via the sequence.

[0012] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S412, Receive the transaction forwarded by the sequence through the driver; S422. Preset judgment conditions, analyze and judge the incentive of the transaction, and determine whether the incentive exists in an interface data structure or a transactional data structure: If interface data exists, then the interface data will be driven to the DUT according to the timing sequence; If no interface data exists, the fifth data structure is invoked to convert the transactional data contained in the transaction into interface data, and the interface data is driven to the DUT in sequence.

[0013] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S431. Receive the transaction forwarded by the agent through the RM; S432. Call the third data structure to convert the interface data contained in the transaction into transactional data required by the corresponding functional model, and send it to the functional model. The functional model processes the data into required data that meets preset conditions and outputs it. S433. Call the fourth data structure to convert the data output by the functional model into transactional data, encapsulate it into a transaction and send it to the scoreboard, waiting to compare it with the output of the DUT.

[0014] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S441. Obtain the driver's excitation signal; S442. According to the preset encapsulation model, the excitation signal is encapsulated to obtain data in the expected format; S443. Obtain the successor model format according to the preset model format acquisition method, select the successor model according to the successor model format, and send the expected format data to the successor model for data processing.

[0015] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S444. Obtain the data processing results of the successor model; S445. Using a bit stream endianness conversion model, the data processing result is identified to confirm the data type of the data processing result; S446. Determine the format of the successor model based on the data type, and convert the bitstream into the format required by the target model.

[0016] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S451. Set the RTL file list and the verification platform file list. The RTL file list specifies all the RTL code files required by the current DUT, and the verification platform file list specifies all the files required by the verification platform. S452. Parse the RTL file list and the verification platform file list to generate a compilation file list for VCS to compile. S453. Reference the DUT file list in the RTL file list, reference the VIP file list in the verification platform file list, load the package file after the verification platform file list, and save.

[0017] In another aspect, this application proposes an apparatus for implementing the above-described method for generating and running functional models based on an automated verification environment, comprising: The model creation module is used to build several functional models based on a preset architecture scheme; The data structure definition module is used to define a general data structure that matches the input / output data structure of the functional model and save it to at least one package. An interface conversion module is used to define interface conversion functions between the input / output data structure and the general data structure; The running module is used to configure the functional model in a preset automated verification environment and, according to the data structure type, call the interface conversion function to complete the format conversion between different functional models.

[0018] In another aspect, this application also proposes a creation system, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method described above for generating and running a functional model based on an automated verification environment when executing the executable instructions.

[0019] Technical effects of the present invention: This application constructs several functional models according to a preset architecture scheme; defines a general data structure matching the input / output data structure of each functional model and saves it in at least one package; defines an interface conversion function between the input / output data structure and the general data structure; configures the functional models in a preset automated verification environment, and calls the interface conversion function according to the data structure type to complete the format conversion between different functional models. This allows verification engineers to start writing models during the prototype design phase of the architecture, advancing the start time of verification work from the time when the design engineer provides the design technical documents to the time when the architect provides the prototype design. It also allows for rapid integration into existing verification environments.

[0020] The model uses standard data structures for input and output to ensure its versatility. Conversion only requires calling data structure conversion functions where necessary, facilitating model reuse and reducing the time and effort spent by validation engineers on environment setup. Only the conversion functions for transactional and interface data structures need to be maintained. Unifying the model interface to a standard protocol or architectural design-compliant interface data structure facilitates the cascading of preceding and following models, eliminating the need for additional attention to interface matching issues and reducing the difficulty of model reuse.

[0021] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0022] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0023] Figure 1 The diagram shown is a schematic representation of the implementation process of the present invention; Figure 2 The diagram shown illustrates the connection between the functional model and the transaction of this invention. Figure 3 The flowchart shown illustrates how the driver of this invention processes transactional and interface data. Figure 4 The diagram shown is a schematic representation of the functional model of the present invention and its connection to the RM. Figure 5 This is a template of a verification environment for one design of the present invention; Figure 6 The diagram shown is a schematic of the NVME SQE package model of the present invention; Figure 7 The diagram shown is a schematic of network frame encapsulation for the three-layer protocol of the present invention. Figure 8 The diagram shown is a schematic of network frame encapsulation for the seven-layer protocol of this invention. Figure 9 The diagram illustrates how the present invention uses big-endian or little-endian bit streams as intermediate data types to confirm the subsequent model format. Detailed Implementation

[0024] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0025] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0026] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0027] Example 1 To verify the separation of the verification environment and the model, enabling the verification environment to construct test cases using transactional data structures at a higher level of abstraction, this application unifies the model interface into an interface data structure conforming to standard protocols or architectural designs. This facilitates the cascading of front- and back-end models without requiring additional attention to interface matching issues, reducing the difficulty of model reuse. Verification engineers can begin writing models during the architecture prototyping phase, advancing the verification start time from when design engineers provide design technical documents to when architects provide prototype designs. Simultaneously, it allows for rapid integration into existing verification environments.

[0028] The setup of the automated verification environment is not limited in this embodiment. In one implementation, a set of env_base and ENV generation tools can be used to complete the basic environment setup. Then, the design and implementation of the RUN tool need to be completed. Finally, the functional models of the standard protocols and predefined architectures required need to be functionally modeled. Based on this, the verification engineer only needs to complete the driver part, the monitor sampling part, and the RM transaction-VIP API transformation call part. In practice, using this solution to build the verification environment can provide a working verification platform on the same day that the designer provides the list of RTL files.

[0029] Next, based on the functional divisions of the architect, model development is carried out to create functional models. These functional models are then integrated into the verification environment to establish a connection between the environment and the functional models. The creation scheme for the functional models will be described in detail below.

[0030] First, by understanding the architecture, we divide the model into functional units and define a set of general data structures based on the input and output data structures of each model. These general data structures are then placed in one or more packages. At the same time, we define the interface conversion functions between the input and output data structures of each model and the general data structure.

[0031] like Figure 1As shown, this application discloses one aspect of a method for generating and running functional models based on an automated verification environment, comprising the following steps: S100. Construct several functional models according to the preset architecture scheme; To ensure the created functional models and the verification platform where the automated verification environment resides are compatible, a set of general data structures needs to be defined first. This set of general data structures is placed in different packages, allowing all models to select them as needed. As an optional implementation of this application, optionally, in step S100, the construction of several functional models according to a preset architecture scheme includes: S110, Set the conditions for establishing the data structure; S120. Based on the data structure establishment conditions, establish a unified model interface data structure, wherein the data structure includes: a transactional data structure for communication between various components and functional models of the verification environment, and an interface data structure for communication between the verification environment and the DUT. S130. Save the data structure to different packages.

[0032] The principle of building a functional model is to constrain the model's input and output into data structures agreed upon by standard protocols or architectural schemes, using System Verilog syntax such as structs or unions in conjunction with keywords like typedef and packed. Defining data structures in this way facilitates maintenance and analysis of data structure content during location. Furthermore, the combination of unions and packed allows for the control of multiple related data structures with the same data width. For example, in NVME, commands are transmitted via SQE, which is 64 bytes long, but different commands may have different definitions for certain bits within those 64 bytes.

[0033] When the model is based on protocol requirements, the input and output data formats are specified by the protocol. For example, the input of NVME's IO cmd is generally an SQE, and the output is a CQE.

[0034] When the model uses a non-protocol architecture without explicit requirements, a data structure can be defined to store information such as {bit stream, number of valid bits, and optional processing status}. For example, OVS does not have a protocol constraint, so users can uniformly input data into the model as big-endian data with data length as parameters, and the model will return big-endian data and data length after processing. The core idea is to unify the model's input and output according to a single rule.

[0035] In addition, functions and variables that need to be called across components are required to be declared as static types in this design, so that they can be operated on from any location and can also serve as a cross-component notification mechanism.

[0036] Using the construction principles of the above functional model, a feasibility analysis of the architecture scheme can be performed. For example, if the functional model is completed according to all requirements but still cannot meet the architecture requirements, then the architecture engineer needs to analyze the reasons and improve the architecture scheme they provided. If the architecture requirements can be met, then the design and verification can be carried out according to the guidance of this functional model for RTL development. This embodiment mainly focuses on the data transformation application of the functional model; therefore, the specific model development can be improved and adjusted according to the architecture scheme.

[0037] S200. Based on the input / output data structure of the functional model, define a general data structure that matches the input / output data structure and save it to at least one package; The verification environment and functional model need to be matched and connected, therefore, model development is required based on the data structures already defined in each package. In practice, template classes are used as the main body of the model for development, and functional development is carried out through template parameters in the template, member variables of functions in the class, and global variables in the class.

[0038] In this embodiment, the development of the functional model should, in principle, use the data structures that have been defined in each package. However, when it is necessary to define a new data structure as a data structure for passing between functions within the model, this design requires that it be defined in the header of the template class. If the verification environment needs the results of this intermediate function, the scope operator (::) can be used to call this structure.

[0039] In this application, the specific number and type of functional models can be designed or customized by the user according to their needs. However, in this embodiment, the functional model design is mainly used to implement the following functions separately or at one time: as a data generator in the transaction; as an incentive generator in the driver; as a standard value generation model in the RM; and as a notification mechanism in each verification environment component.

[0040] S300, Define the interface conversion function between the input / output data structure and the general data structure; Interface conversion functions are essentially designed to address the issue of model versatility. For example, the input to an NVME model is typically SQE, while the input to an OVS model is usually a bitstream formed from network frame data structures. If a user needs to implement NVME over TCP, i.e., sending SQE to a remote server's SSD for operation over the network, they need to convert the SQE generated by the NVME data generator into the OVS input data format. This requires a conversion function to convert SQE to a network frame bitstream. Therefore, the user needs to write an interface conversion function to encapsulate and convert the SQE for NVME over TCP into the bitstream required by OVS.

[0041] S400. Configure the functional model in a preset automated verification environment, and call the interface conversion function according to the data structure type to complete the format conversion between different functional models.

[0042] Once the data structure and corresponding functional model are created, the verification environment can be combined with the functional model, integrating the functional model into the verification environment. With the transformation function in place, the verification environment's calls to the functional model are simple function calls, primarily consisting of two parts, which will be described in detail below.

[0043] The first part of the function call: Add all files of the functional model to the compilation file list. After setting up a general verification environment, the DPU also needs to be able to quickly integrate VIPs from multiple sources. As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models includes: S451. Set the RTL file list and the verification platform file list. The RTL file list specifies all the RTL code files required by the current DUT, and the verification platform file list specifies all the files required by the verification platform. S452. Parse the RTL file list and the verification platform file list to generate a compilation file list for VCS to compile. S453. Reference the DUT file list in the RTL file list, reference the VIP file list in the verification platform file list, load the package file after the verification platform file list, and save.

[0044] Therefore, a directory structure needs to be designed to encapsulate the aforementioned environment components within a package. A file list, consisting of `rtl_filelist.f` and `tb_filelist.f`, needs to be designed, along with a simulation startup tool (RUN tool) to parse these two files and generate a compiled file list file (`gen.f`) for VCS to compile. The DUT's file list is referenced in `rtl_filelist.f`, and the VIP's file list is referenced in `tb_filelist.f`. The environment package file is then added to the end of `tb_filelist.f`. Based on these two filelists, the model files are merged into a single filelist file and added to `tb_filelist`. The compiled filelist can then be used for calling the code.

[0045] The second part is divided into three types of call relationships: the function model call in the transaction; the function model call in the RM; and the function model call in the driver. These will be described in detail below.

[0046] The three types of calls in Part Two will be described in detail below.

[0047] The interaction between a transaction and the functional model involves the transaction first constructing the expected transactional data structure, and then sending the transactional data structure to the driver via a sequence as needed, or sending it to a specified model to be converted into an interface data structure and then sending it to the driver via a sequence.

[0048] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models includes: S411. Pre-construct the expected transactional data through transactions; S421. Call the first data structure, input the transactional data into the corresponding functional model through the first data structure, and process the data into required data that meets the preset conditions through the functional model; S431. Call the second data structure to convert the requirement data obtained from the functional model into interface data, and send it to the driver via the sequence.

[0049] like Figure 2The diagram illustrates the connection between the functional model and the transaction. First, the expected transactional data structure is constructed through the transaction. Then, as needed, the transactional data structure is sent to the driver via a sequence, or it is sent to a specified model, converted into an interface data structure, and then sent to the driver via a sequence.

[0050] In practice, the process first involves calling a data generation model to generate raw data, then calling a communication model interface of an interface data structure, such as AXI, to input transactional data into the corresponding functional model. After data processing by the functional model, the required data is obtained. Then, a conversion function or model of a transactional data structure is used to convert the required data obtained by the functional model into interface data, which is then sent to the driver via a sequence.

[0051] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S412, Receive the transaction forwarded by the sequence through the driver; S422. Preset judgment conditions, analyze and judge the incentive of the transaction, and determine whether the incentive exists in an interface data structure or a transactional data structure: If interface data exists, then the interface data will be driven to the DUT according to the timing sequence; If no interface data exists, the fifth data structure is invoked to convert the transactional data contained in the transaction into interface data, and the interface data is driven to the DUT in sequence.

[0052] like Figure 3 The diagram shows the flowchart for the driver processing transactional and interface data. Upon receiving a transaction forwarded from a sequence, the driver first analyzes whether the stimulus exists as an interface data structure or a transactional data structure. If it is a transactional data structure, a conversion function is called to convert it to an interface data structure. Finally, the interface data structure is sent to the DUT via the interface.

[0053] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S431. Receive the transaction forwarded by the agent through the RM; S432. Call the third data structure to convert the interface data contained in the transaction into transactional data required by the corresponding functional model, and send it to the functional model. The functional model processes the data into required data that meets preset conditions and outputs it. S433. Call the fourth data structure to convert the data output by the functional model into transactional data, encapsulate it into a transaction and send it to the scoreboard, waiting to compare it with the output of the DUT.

[0054] like Figure 4 The diagram shows the connection between the functional model and the RM. After receiving the transaction forwarded by the agent, the RM converts the transactional data structure into the interface data structure required by the corresponding model, then sends it to the corresponding model for processing. It then collects the output of the functional model, converts it into a transactional data structure, encapsulates it into a transaction, and sends it to the scoreboard to be compared with the output of the DUT.

[0055] like Figure 5 The image shows a template for a design verification environment. Both the estBase and Harness sections are generated by the ENV generation tool, but the DUT in Harness does not yet exist, and the interface has no definition. The Harness section is actually completed by the ENV interface connection tool in conjunction with the top-level RTL file provided by the design engineer. After designing and implementing the verification platform's runtime tools, the required standard protocols and predefined architectures are functionally modeled. Based on this, the verification engineer only needs to complete the driver's part, the monitor's sampling part, and the RM's transaction-VIP API conversion call part. Experience shows that using this approach to build a verification environment can provide a running verification platform on the same day the designer provides the RTL file list.

[0056] In this design, Testcase inherits from TestBase and places the transactions it wants to send into the `trans_q` queue in TestBase's Config. Sequences are then sent to the Driver one by one via the UVM TLM mechanism. The Driver analyzes the contents of the transaction and drives the interface according to the transaction-driven mechanism described above. The In_monitor collects interface information from the interface's output, reconstructs it into a transactional data structure, and sends it to the RM. The Out_monitor collects interface information from the interface's input, organizes it into a data structure to be compared, stores it in the transaction, and sends it to the SCB. The RM parses the transactions sent by the In_monitor, calls the relevant functional models to complete the data processing, and organizes the output of the functional models into a data structure to be compared, stores it in the transaction, and sends it to the SCB. The SCB calls `uvm compare` to compare the results of the transactions received from the RM and Out_monitor.

[0057] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S441. Obtain the driver's excitation signal; S442. According to the preset encapsulation model, the excitation signal is encapsulated to obtain data in the expected format; S443. Obtain the successor model format according to the preset model format acquisition method, select the successor model according to the successor model format, and send the expected format data to the successor model for data processing.

[0058] like Figure 6 The diagram shows a schematic of the NVME SQE encapsulation model. The principle for building the functional model based on this design is to constrain the model's input and output to data structures agreed upon by standard protocols or architectural schemes, using System Verilog structures (structs) or unions combined with the `packed` keyword. The advantage of this approach is that it facilitates maintenance and locating analysis content. Furthermore, the combination of `union` and `packed` allows for the control of multiple related data structures with the same data width. For example, in NVME, commands are transmitted via SQE, which is 64 bytes long, but different commands may have different definitions for certain bits within those 64 bytes.

[0059] When the model is protocol-driven, the input and output data formats are defined by the protocol. For example, NVME's IO command typically inputs a Single Quantization (SQE) and outputs a Single Quantization (CQE). When the model is not protocol-driven and the architecture doesn't have explicit requirements, the input and output can be adjusted to a bitstream with a defined number of valid bits and optional processing states. For example, OVS doesn't have a protocol constraint, so we can uniformly input data as big-endian data with the data length as parameters. After processing, the model will also return big-endian data and the data length. The core idea is to unify the model's input and output according to a single rule.

[0060] Meanwhile, functions and variables that need to cross components are required to be declared as static types. This makes it convenient for the Driver to call and generate stimuli at any time, and also for the Monitor to call and convert the bus signals back to the structure required by the model. Finally, these signals are provided to the reference model to call the data processing model to complete the data processing.

[0061] The functional model mentioned in this design not only needs to correctly process incoming data or commands according to the protocol, like most VIPs sold on the market, but also needs to provide a model similar to a packet sender that can generate the data or commands required in this mode. For example, in OVS testing, verification engineers need to encapsulate multi-layer network protocols such as Layer 2, Layer 3, and Layer 4 into data of a specified format according to RFC standards, corresponding to, respectively, as... Figure 7 The diagram showing the network frame encapsulation of the three-layer protocol is as follows: Figure 8 The diagram shows a network frame encapsulation diagram of the seven-layer protocol. In NVME testing, verification engineers need to encapsulate SQE and other components according to the NVME protocol requirements.

[0062] Therefore, in the DPU's automated verification environment, a model might be called as a data processing model in the RM under one test mode, while under another test mode, it might be called as part of the packet sender model when constructing data packets in the driver or transaction.

[0063] As an optional implementation of this application, optionally, in step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the data structure type to complete the format conversion between different functional models further includes: S444. Obtain the data processing results of the successor model; S445. Using a bit stream endianness conversion model, the data processing result is identified to confirm the data type of the data processing result; S446. Determine the format of the successor model based on the data type, and convert the bitstream into the format required by the target model.

[0064] like Figure 9 As shown, when the result of a model is returned, if it is not immediately possible to determine which model will be the successor, or if it is not easy to directly convert the formats of the two models, big-endian or little-endian bit streams can be used as intermediate data types. After confirming the format of the successor model, the bit stream can be converted into the format required by the target model.

[0065] It should be noted that the first to fifth data structures mentioned above are merely usage codes for one model interface in different examples, and do not mean that the verification platform here only has five model interfaces. Accordingly, they can be determined according to the type and number of functional models.

[0066] Example 2 Based on the implementation principle of Embodiment 1, this embodiment proposes a device to implement the flow of the various control methods of Embodiment 1.

[0067] In another aspect, this application proposes an apparatus for implementing the above-described method for generating and running functional models based on an automated verification environment, comprising: The model creation module is used to build several functional models based on a preset architecture scheme; The data structure definition module is used to define a general data structure that matches the input / output data structure of the functional model and save it to at least one package. An interface conversion module is used to define interface conversion functions between the input / output data structure and the general data structure; The running module is used to configure the functional model in a preset automated verification environment and, according to the data structure type, call the interface conversion function to complete the format conversion between different functional models.

[0068] Obviously, those skilled in the art should understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, the present invention is not limited to any specific hardware and software combination.

[0069] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0070] Example 3 Furthermore, this application also proposes a creation system, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method described above for generating and running a functional model based on an automated verification environment when executing the executable instructions.

[0071] This disclosure describes a system comprising a processor and a memory for storing processor-executable instructions. The processor is configured to implement, when executing the executable instructions, any of the methods described above for generating and running a functional model based on an automated verification environment.

[0072] It should be noted here that the number of processors can be one or more. Furthermore, the traceability system in this embodiment may also include input devices and output devices. The processors, memory, input devices, and output devices can be connected via a bus or other means, without specific limitations herein.

[0073] Memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the method for generating and running a functional model based on an automated verification environment according to embodiments of this disclosure. The processor executes various functional applications and data processing of the traceability system by running the software programs or modules stored in the memory.

[0074] Input devices can be used to receive input digital numbers or signals. These signals can be key signals related to user settings and function control of the device / terminal / server. Output devices can include display devices such as screens.

[0075] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for generating and running functional models based on an automated verification environment, characterized in that, Includes the following steps: S100. Construct several functional models according to the preset architecture scheme; The functional model is used to implement the following functions individually or at one time: as a data generator in the transaction; as an incentive generator in the driver; as a standard value generation model in the RM; and as a notification mechanism in various verification environment components. S200. Based on the input and output data structures of the aforementioned functional models, define a general data structure that matches the input and output data structures and save it to at least one package. The general data structure includes: a transactional data structure for communication between various components and functional models of the verification environment, and an interface data structure for communication between the verification environment and the DUT. S300, Define the interface conversion function between the input / output data structure and the general data structure; S400. Configure the functional model in a preset automated verification environment, and call the interface conversion function according to the general data structure type to complete the format conversion between different functional models, including: S411. Pre-construct the expected transactional data through transactions; S421. Call the first data structure, input the transactional data into the corresponding functional model through the first data structure, and process the data into required data that meets the preset conditions through the functional model; S431. Call the second data structure to convert the requirement data obtained from the functional model into interface data, and send it to the driver via the sequence.

2. The method for generating and running functional models based on an automated verification environment according to claim 1, characterized in that, In step S200, defining a general data structure that matches the input / output data structure and saving it to at least one package includes: S110, Set the conditions for establishing a general data structure; S120. Based on the general data structure establishment conditions, establish a general data structure for a unified model interface, wherein the general data structure includes: a transactional data structure for communication between various components and functional models of the verification environment, and an interface data structure for communication between the verification environment and the DUT. S130. Save the general data structure to different packages.

3. The method for generating and running functional models based on an automated verification environment according to claim 1, characterized in that, In step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the general data structure type to complete the format conversion between different functional models further includes: S412, Receive the transaction forwarded by the sequence through the driver; S422. Preset judgment conditions, analyze and judge the incentive of the transaction, and determine whether the incentive exists as interface data or transactional data: If interface data exists, then the interface data will be driven to the DUT according to the timing sequence; If no interface data exists, the fifth data structure is invoked to convert the transactional data contained in the transaction into interface data, and the interface data is driven to the DUT in sequence.

4. The method for generating and running functional models based on an automated verification environment according to claim 1, characterized in that, In step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the general data structure type to complete the format conversion between different functional models further includes: S431. Receive the transaction forwarded by the agent through the RM; S432. Call the third data structure to convert the interface data contained in the transaction into transactional data required by the corresponding functional model, and send it to the functional model. The functional model processes the data into required data that meets preset conditions and outputs it. S433. Call the fourth data structure to convert the data output by the functional model into transactional data, encapsulate it into a transaction and send it to the scoreboard, waiting to compare it with the output of the DUT.

5. The method for generating and running functional models based on an automated verification environment according to claim 4, characterized in that, In step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the general data structure type to complete the format conversion between different functional models further includes: S441. Obtain the driver's excitation signal; S442. According to the preset encapsulation model, the excitation signal is encapsulated to obtain data in the expected format; S443. Obtain the successor model format according to the preset model format acquisition method, select the successor model according to the successor model format, and send the expected format data to the successor model for data processing.

6. The method for generating and running functional models based on an automated verification environment according to claim 5, characterized in that, In step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the general data structure type to complete the format conversion between different functional models further includes: S444. Obtain the data processing results of the successor model; S445. Identify the data processing result and confirm the data type of the data processing result; S446. Based on the data type, determine the format of the successor model of the successor model, and use a bitstream endianness conversion model to convert the bitstream into the format required by the target model.

7. The method for generating and running functional models based on an automated verification environment according to claim 1, characterized in that, In step 400, configuring the functional model in a preset automated verification environment and calling the interface conversion function according to the general data structure type to complete the format conversion between different functional models further includes: S451. Set the RTL file list and the verification platform file list. The RTL file list specifies all the RTL code files required by the current DUT, and the verification platform file list specifies all the files required by the verification platform. S452. Parse the RTL file list and the verification platform file list to generate a compilation file list for VCS to compile. S453. Reference the DUT file list in the RTL file list, reference the VIP file list in the verification platform file list, load the package file after the verification platform file list, and save.

8. An apparatus for implementing the method for generating and running functional models based on an automated verification environment as described in any one of claims 1-7, characterized in that, include: The model creation module is used to build several functional models based on a preset architecture scheme; The data structure definition module is used to define a general data structure that matches the input and output data structures of the several functional models and save it to at least one package. An interface conversion module is used to define interface conversion functions between the input / output data structure and the general data structure; The running module is used to configure the functional model in a preset automated verification environment, and according to the general data structure type, call the interface conversion function to complete the format conversion between different functional models, and finally achieve the expected behavior and desired results required by the architecture scheme.

9. A creation system, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method for generating and running a functional model based on an automated verification environment as described in any one of claims 1 to 7 when executing the executable instructions.

Images