An extensible automated method for FPGA simulation and verification

Abstract

The present invention relates to a scalable automated method for FPGA simulation verification. The steps include: establishing a standard specification file; establishing a converter model through meta-syntax symbols and a template engine; designing a converter according to the meta-model to provide a dedicated environment for reading information of the unit under test; designing a converter according to the meta-meta model, inputting verification case steps according to a form-based view, and generating a verification report in a user-defined format; defining a new type of standard specification file for function expansion, and designing an abstract model to implement view conversion at a higher abstract sequence layer. The present invention enhances the adaptability of the verification tool and improves the flexibility of tool application.

Description

Technical Field

[0001] The present invention relates to an extensible FPGA simulation verification automation method, belonging to the technical field of large-scale programmable logic automated design and verification. Background Art

[0002] In recent years, there have been some methods for quickly building an FPGA simulation verification environment, which have improved partial verification efficiency and met partial reusability. However, for different design platforms provided by different FPGA chip suppliers or different simulation software platforms, corresponding functions still need to be achieved by modifying the tool source code, and these methods also lack the automated implementation of verification test cases and the automatic combination of verification test case tools and verification environments. For example, the test case tool obtains the results of the simulation tool and accesses specific registers in the design under test (DUT). On the other hand, the portability, collaborative working ability, maintainability of the verification environment, and the convenience of documentation compilation also need to be further strengthened. Summary of the Invention

[0003] The technical problem solved by the present invention is: overcoming the deficiencies of the prior art, and proposing an extensible FPGA simulation verification automation method to achieve the full automation of extracting the design under test from different design platforms to the simulation verification environment, verification test cases, and verification reports, effectively combining the entire verification workflow, data flow, and information flow, realizing the synchronization of the verification file view and the environment code view, standardizing the file list and communication protocol, making the system no longer dependent on specific chip suppliers and verification service providers, thereby further improving the scalability and verification efficiency of the FPGA simulation verification system.

[0004] The solution for the present invention to solve the technology is:

[0005] An extensible FPGA simulation verification automation method, the steps include:

[0006] S1. Establish standard specification files:

[0007] The standard specification files include eight types of description file types: component files, design files, design configuration files, bus definition files, abstract definition files, abstractor files, generator chain files, and directory files;

[0008] S2. Establish a converter model through meta-syntax symbols and a template engine, and the mapping relationship between different converter models and the standard specification files in S1;

[0009] The converter model includes a basic model, a meta-model, and a meta-meta model:

[0010] S3. Design a converter according to the meta-model, provide a dedicated environment to read the information of the unit under test, pack all components of the information of the unit under test into an XML file in a standard format according to the standard mode, and fill in the XML fields of all component description attributes of the unit under test: physical ports, interfaces, parameters, generics, register mappings, and physical attributes, and store them in the database;

[0011] Control the registers accessed by the system bus, create and call the verification module VIP. In the dedicated environment, match the simulation verification environment configuration information input by the user with the information of the unit under test, and complete the connection between the verification module VIP and the unit under test; Automatically generate simulation verification code through the design file to complete the construction of the functional verification environment for the unit under test;

[0012] S4. Design a converter according to the meta-meta-model, input the verification case steps according to the form view, automatically generate case code through the design file, integrate it into the verification environment generated in S3, start the script to execute the simulation verification, and automatically read the simulation verification results to generate a verification report in the user-defined format;

[0013] S5. Define a new standard specification file type for function extension, and design an abstract model to achieve view conversion at a higher abstract sequence layer.

[0014] Furthermore, the component file accesses the information of the unit under test through XML and records the interfaces of the information of the unit under test.

[0015] Furthermore, the design file defines component configuration and component interconnection configuration, generates views related to logical interconnection and physical interconnection, realizes the instances of sub-components of the component, the parameter values of the component instances, and the connections between the component instances, and records the internal structure of the component.

[0016] Furthermore, the design configuration file selects an appropriate view combination for the component instance to achieve a specific-purpose configuration design, defines additional configuration information for the generation chain or design description, and compiles and simulates the register transfer level circuit RTL and executes the transaction-level communication TLM according to the component configuration and component interconnection configuration in the design file.

[0017] Furthermore, the bus definition file describes the bus type attributes and records the attributes of the hardware communication protocol independent of the protocol representation.

[0018] Furthermore, the abstract definition file describes the bus representation attributes and defines the adapter between the structural abstraction and the content abstraction.

[0019] Furthermore, the abstractor file defines the hardware communication protocol information recorded according to the logical ports and their attributes, and describes the transaction-level communication TLM between the connected bus interfaces based on the view combination in the design configuration file.

[0020] Furthermore, the generator chain file defines the grouping and ordering of converters, describes the converter URLs to be run on the standard specification document and the input parameter names and values provided to the converters, as well as implements the process steps so that the design environment runs these converters based on the process defined in the chain.

[0021] Furthermore, the catalog file records the location of the standard specification file and the element identifiers in the file.

[0022] Furthermore, the basic model is used to implement content-based modeling, and the basic model extracts the specific content implemented by the simulation verification environment components into an abstract syntax tree.

[0023] Furthermore, the metamodel is used to implement algorithm structure modeling, define hardware resources, hardware processors, network ports, transaction ports, hardware bridges, clock resources, model libraries, describe design components, component instantiations and connections between components, and the connection interface adopts request / response communication and process-oriented communication.

[0024] Furthermore, the meta-metamodel is used to implement verification plan structure modeling, define a sequential programming language to describe software access, a transaction-level communication register model for connection interfaces, and an event-driven hardware description model.

[0025] The beneficial effects of the present invention compared with the prior art are:

[0026] (1) The method of the present invention takes object-oriented analysis as the basic method and, based on meta-modeling technology, unifies the architecture of design engineering file parsing, automatic generation of verification environment and use cases, and conversion of various views of the verification process (environment code, schematic diagram, use case table and report file). It realizes the automation of the simulation verification process to a greater extent, reduces the complexity of verification work, increases the visual experience of verification work, reduces the inconsistency between reports and use cases caused by human factors in the verification process, relieves the pressure on verification personnel, greatly improves the efficiency of verification work, and is expected to further improve productivity.

[0027] (2) The present invention converts style templates into standard specification files to achieve automatic reading of design projects under platforms provided by different chip manufacturers, automatic generation and execution of verification environments on different simulation platforms, and reuse of VIPs from different verification companies. When changing platform design or verification VIP, only the style template needs to be changed without changing the source code of the tool, which enhances the adaptability of the verification tool and improves the flexibility of tool application.

[0028] (3) The present invention can be applied as an interface between hardware and software, starting from the memory architecture specification and the hardware registers accessible to software, sharing the description data source, and filling the gap in verification design;

[0029] (4) The present invention utilizes the standard specification file extension area to establish a VIP library, a use case keyword library, and their indexes, standardizes the use case generation process in the form of graphical dialogues and spreadsheets, solidifies verification experience, improves the reuse rate of verification work, helps verification personnel focus on verification scenarios and use case analysis, reduces the omission rate of verification issues, and improves the quality of verification work.

[0030] (5) The present invention utilizes the standard specification file extension area to establish an extended description outside the source code of the design under test. In addition to implementing FPGA simulation verification, it can also be extended for other performance analyses such as power consumption and timing of the design under test, as well as for higher-level management related to the design under test, providing the possibility for extended tools starting from the same design source. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is the overall modeling hierarchy diagram of the present invention;

[0032] Figure 2 is the schematic diagram of the tool chain generation structure of the present invention;

[0033] Figure 3 is the tool implementation architecture diagram of the present invention;

[0034] Figure 4 is the schematic diagram of the standard specification file description;

[0035] Figure 5 is the schematic diagram of the extended application of the standard specification file. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0036] The present invention will be further described below in conjunction with embodiments.

[0037] EXAMPLE DESCRIPTION OF THE MODELING METHOD

[0038] The present invention defines an extensible FPGA simulation verification automation method. Four levels and three hierarchies of models are introduced in the FPGA simulation verification process to abstract views at different levels for verification personnel to build a functional simulation verification environment, as Figure 1 shown. Among them, the view reader and generator can either originate from meta-syntax symbols such as extended Backus-Naur form or be based on a template engine, which can not only automatically generate views but also automatically construct various parts of the automation solution; meta-modeling is the key technology for code generation and formal generation of the data structure of the target code in this method, and is particularly useful for bridging the verification of designs with both hardware and software.

[0039] There are multiple views during the design process at Level 1. One of them is the document. The tabular representation of this document view is shown in Table 1. This component has two 16-bit registers, R0 and R1. R0 is located at the relative address 0, and R1 is located at the relative address 1. Its two registers, R1 and R2, and its four bit fields, B1 to B4, have all Name attributes set to meet multiple constraints imposed by subsequent modeling. All other necessary attributes, including Offset and Size, are set to integer values. It also includes the interoperability between hardware and software, HWr, HWw, SWr, and SWw, which are set to boolean values True or False. This view is used by verification engineers to verify the interface, software and hardware engineers who develop the interface, and customers when developing software for the product integrating the DUT. Table 1 and Figure 1 All views shown have been simplified to provide a better and more intuitive understanding of the overall design.

[0040] Table 1 Figure 1 The underlying code corresponding register table in

[0041]

[0042] Another possible RTL view is as shown Figure 1 in the bottom document. Assume that the bus interface only contains Addr, DataIn, DataOut, En, and Wr. If the DUT is accessed, En is "1", and if a register should be written, Wr is "1". Assume that the bus and the register have the same clock and reset signals, and there is no pipeline or other delay on the bus. In addition, there are firmware views and inline function views, which use code to describe the interface between hardware and software.

[0043] Level 2 gives an example of a model specified graphically (using a UML object diagram). The model describes the instances in Level 1, provides an addressable shell; the bit fields specify access permissions and are responsible for software to save data; read and write flags are set to determine if there is such a Wire from the register field to the hardware core under test; the value written to the hardware is stored in a temporary register, and the value read is directly taken from the hardware under test. There are other constraints on the semantics of the modeled domain, which are annotated by using a specific constraint language (such as the Object Constraint Language OCL or a programming language). For example, each bit field can be readable or writable from each design domain (software side or hardware side), and the size of the bit field is less than the size of the register, etc.

[0044] Level 3 abstraction shows the meta-model of the DUT register interface component, which is a key component of the general hardware or software interface. The software side can be developed in C / C++, Python, or other similar languages and executed sequentially. The hardware side can be modeled using gate-level descriptions such as Verilog, VHDL, or SystemVerilog. Transaction-level communication is written in SystemVerilog or SystemC. The read and write processes are as follows:

[0045] In the software read process, the hardware address is regarded as a special variable, similar to accessing the bit field of a storage unit and accessing the hardware line. When the register where the bit field is located is read, the software further processes the value of the register according to the verification requirements;

[0046] The software write process is also similar to operating on a storage unit. The interface passes the value from the software to the hardware by writing the numerical value to the base address of the IP plus an internal offset. On the other hand, the hardware can be connected to the register. For example, an operation is triggered when the register is accessed or a specific value is written. The connection between the software register and the IP hardware is completed through Wires, and the IP hardware then processes the values of these Wires.

[0047] Level 4 shows a further abstraction of the meta-modeling, that is, the meta-meta model, which describes that a meta-model has a root class that has other classes and attributes, all of which have multiplicities. Therefore, a class references the container of its subclasses, which may redefine the name and specify the multiplicity. Figure 1 Middle Level 4 shows the component meta-model in Level 1 as an instance of the meta-meta model. The object ComponentMM is the root node in the instance of the meta-meta model named ComponentMM. The only associated object of type Class, Register, is the root node of the meta-model. Its associated objects of type Attribute, Offset, Size, and Name, specify the attributes of Register. The object register also has an associated subclass object that defines the associated object bit field of type Class. The multiplicity of this association, 1..*, is represented by MaxOccurs = 1 and MinOccurs = -1. The Bitfield class has seven associated attribute objects, three of which are not fully shown.

[0048] Implementation of the tool suite

[0049] The tool suite designed under this method is as Figure 2As shown, both the use case automation tool and the verification environment automation tool are implemented under this modeling method. The model is encapsulated in a tool with separate data read and write interfaces (setAPI and getAPI). Using these interfaces, data can be dumped into an XML-based intermediate storage via a simple network protocol. Then, a GUI is provided by the high-level application layer of the metamodel or the meta-metamodel in use for editing or for implementing verification using the provided constraint checking function. All these components of the metamodeling framework can be automatically generated using the metamodel description, and additional checks can be generated from the object constraint language constraints associated with the metamodel or its parts.

[0050] Figure 2 The high-level application layer refers to a higher abstraction sequence layer, such as a management platform, which is responsible for process-related controls such as the allocation of the project under test and the collection of verification status, or a data pool, which is responsible for generating the data source sequence for flexible applications; the meta-metamodeling tool instance provides a use case automation tool. The view is its human-computer interaction level. The verification personnel interact with the tool through the user interface, select the project under test, or read project information from the management platform, and select the corresponding function or performance verification use case according to the task book, read the test frames required for the use case in the data pool, generate a complete use case file, and convert it into an XML format file for storage through a generator. Through the converter, the use case automation tool interacts with the metamodeling tool for environment information and simulation result information. The use case automation tool then judges the use case results and forms a report file in Word or Html format for output to the verification personnel; the metamodeling tool instance provides a verification environment automation tool, which completes the automatic extraction of the DUT and the automatic generation of the verification environment, and accesses a third-party simulation verification tool through the conversion interface for simulation verification; the modeling tool is a modeling process that directly abstracts the hardware programming code and realizes the compilation and simulation of programmable logic.

[0051] Tool implementation architecture

[0052] Figure 3 Shows the specific architecture of the implementation of the simulation verification automation part in the tool suite. The architecture is used to generate classes similar to the structure of the input XML specification document. It fills the instances of these classes with information from the XML requirements specification and creates an instance for each use case. Then, the automatic test bench generator module uses this XML specification to generate use cases and test case objects, and these use cases and test case objects are Figure 2Generated by the converter shown. Each use case object contains a list of test case objects, and each test case object also contains a list of links to subsequent test cases specified in the use case scenario. These lists cover all the impacts of the current step in the use case scenario on the DUT output. The test case generator is a SystemVerilog model that uses the UVM methodology to complete the environment setup and implements three independent threads: random test generation, simulation verification execution, and functional and non-functional requirement checking.

[0053] Standard Specification File Structure Description

[0054] The standard specification file used in the present invention provides XML descriptions of components and systems, including eight types of description files: component, design, design configuration, bus definition, abstract definition, abstractor, generator chain, and directory. Each type contains an extensible area description, and the size of the file is determined by the complexity of the DUT. The structure is as Figure 4 shown in the schematic XML description of the component register. The specific description of the structure of each type is as follows:

[0055] The purpose of the component description is to access the DUT through XML, record the interfaces of the DUT, such as parameters, registers, port lists, and embedded; the views of the DUT, such as RTL and transaction-level communication (TLM) descriptions; and the files implementing each view, such as Verilog, VHDL, SystemVerilog, and SystemC files. To be able to verify the connections of interfaces other than the system interfaces that the DUT cannot directly access, additional verification components that can be connected to the description file are usually required, such as Figure 4 there is register control for UTMI+VIP to access through the system bus, connected to the IP interface of the USB under test. To simplify the handling of VIP, a set of predefined functions can be used, which run like a simple software stack to conveniently transmit or receive USB packets;

[0056] The design description hierarchically describes the DUT, defines component configurations and component interconnection configurations, and can generate views related to logical interconnections (e.g., system memory mapping) and physical interconnections (e.g., structural HDL). Record the internal structure of the component by describing the instances of the sub-components used to implement the component, the parameter values of the component instances, and the connections between the component instances;

[0057] The design configuration realizes a configuration design for a specific purpose by selecting an appropriate view combination for the component instances, defines additional configuration information for the generation chain or design description, compiles and simulates the RTL according to the component configuration and component interconnection configuration of the design file, and executes TLM;

[0058] The purpose of the bus definition and the abstract definition is to describe various aspects of the hardware communication protocol, indicating which interface uses which protocol and which component ports implement the protocol. Two bus interfaces can be connected if and only if they refer to the same bus definition (or if they refer to compatible bus definitions). If two connected bus interfaces refer to different abstract definitions, then an abstractor is required on the interconnect for TLM conversion. Among them, the bus definition describes the bus type attributes, recording the attributes of the hardware communication protocol independent of the protocol representation, such as whether the protocol supports a direct connection between the master interface and the slave interface, and whether the canonical file address calculation is applicable to map the protocol slave memory map to the master address space; the abstract definition describes the bus representation attributes, defining the adapter between the structural abstraction and the content abstraction.

[0059] The abstractor definition records the representation of the hardware communication protocol according to the logical ports and their attributes (such as the direction and number of bits of the master interface and the slave interface). The purpose is to describe the TLM between the connected bus interfaces. The required conversion depends on the view of the component instances in the design configuration. Therefore, in order to model or simulate a hybrid abstract design, the abstractor is instantiated in the design configuration.

[0060] The generator chain description defines the grouping and sorting of the converters. The generator chain describes the tool URLs running on the standard specification document and the names and values of the input parameters provided to the tools, implementing the process steps to enable the design environment to run these tools based on the processes defined in the chain. The document describes the location of the tools and the tool input values, such as the design software, libraries, names, and version identifiers used by the DUT components, as well as the component view names as inputs to traverse the design hierarchy.

[0061] The purpose of the catalog is to manage a collection of files by recording the locations of the standard specification files and the identifiers of the elements recorded in these files. For each mentioned standard specification document type, the catalog document describes the URL of the specification file and the identifiers of the elements described in that specification file.

[0062] Extended application of the present invention

[0063] The present invention introduces meta-modeling technology into FPGA simulation verification. The meta-modeling technology has built-in various extensible mechanisms and can be extended according to design needs without changing the original meta-model. For example, stereotypes in UML can be used to create new model elements; tagged values are used to define additional attributes for existing modeling elements or stereotypes; constraints are used to add new rules or modify existing rules, and it can be used to delete attributes from modeling elements. Another example is that the standard specification file allows different design parties to place additional data at specific locations in the model. The introduced method of the extended area description allows the initial mode of any specific additional attribute to be extended while still being compatible with the standard. Figure 5The extension of the component description file demonstrates the extended application of such a standard specification file.

[0064] Figure 5 Each field in it is represented as a folder containing sub-folders and files. The folders and files are relatively linked in the XML file. The parameters of each field are the resource type, visibility, and access attributes or recommended editing tools, and each DUT is assigned a unique identifier. The extended area is used to implement the structural description of the project, such as the DUT requirements document, the structural description of the project; VIP, including testbenches, Test Case, verification structure, and visualization symbols, etc.; other non-functional descriptions, such as power consumption design, other performance designs, timing information, etc.; the index-related information description of this component. The most important application among them is to extend the VIP part for the FPGA simulation verification automation of the present invention.

[0065] Specifically, a scalable FPGA simulation verification automation method includes the following steps:

[0066] S1. Establish a standard specification file:

[0067] The standard specification file includes eight types of description files: component file, design file, design configuration file, bus definition file, abstract definition file, abstractor file, generator chain file, and directory file;

[0068] The component file accesses the information of the unit under test through XML and records the interface of the information of the unit under test;

[0069] The design file defines the component configuration and the component interconnection configuration, generates views related to logical interconnection and physical interconnection, realizes the instances of the sub-components of the component, the parameter values of the component instances, and the connections between the component instances, and records the internal structure of the component;

[0070] The design configuration file selects an appropriate view combination for the component instance, realizes the configuration design for a specific purpose, defines additional configuration information of the generation chain or design description, compiles and simulates the register transfer level circuit RTL according to the component configuration and the component interconnection configuration in the design file, and executes the transaction-level communication TLM;

[0071] The bus definition file describes the bus type attributes and records the attributes of the hardware communication protocol independent of the protocol representation;

[0072] The abstract definition file describes the bus representation attributes and defines the adapter between the structure abstraction and the content abstraction;

[0073] The abstractor file defines the hardware communication protocol information recorded according to the logical port and its attributes, and describes the transaction-level communication TLM between the connected bus interfaces based on the view combination in the design configuration file;

[0074] The generator chain file defines the grouping and sorting of converters, describes the converter URLs running on the standard specification document and the names and values of the input parameters provided to the converters, as well as the implementation process steps, enabling the design environment to run these converters based on the processes defined in the chain;

[0075] The directory file records the location of the standard specification file and the element identifiers in the file;

[0076] S2. Establish a converter model through meta-syntax symbols and a template engine, as well as the mapping relationship between different converter models and the standard specification file in S1;

[0077] The converter model includes a base model, a meta-model, and a meta-meta model:

[0078] The base model is used to implement content-based modeling. The base model extracts the specific content implemented by the simulation verification environment components into an abstract syntax tree;

[0079] The meta-model is used to implement algorithmic structure modeling, defining hardware resources, hardware processors, wire ports, transaction ports, hardware bridges, clock resources, model libraries, describing design components, the instantiation of components, and the connections between components. The connection interfaces use request / response-based communication and process-oriented communication;

[0080] The meta-meta model is used to implement verification plan structure modeling, defining the sequential programming language for describing software access, the transaction-level communication register model of the connection interface, and the event-driven hardware description model;

[0081] S3. Design a converter according to the meta-model, provide a dedicated environment to read the information of the unit under test, pack all components of the information of the unit under test into a standard-format XML file according to the standard mode, and fill in the XML fields of the description attributes of all components of the information of the unit under test: physical ports, interfaces, parameters, generics, register mappings, physical attributes, and store them in the database;

[0082] By controlling the registers accessed by the system bus, create and call the verification module VIP. Match the simulation verification environment configuration information input by the user in the dedicated environment with the information of the unit under test, and complete the connection between the verification module VIP and the information of the unit under test; Automatically generate simulation verification code through the design file to complete the construction of the functional verification environment for the information of the unit under test;

[0083] S4. Design a converter according to the meta-meta model, input the verification case steps according to the form view, automatically generate case code through the design file, integrate it into the verification environment generated in S3, start the script to execute the simulation verification, and automatically read the simulation verification results to generate a verification report in the user-defined format;

[0084] S5. Define a new standard specification file type for function extension, and design an abstract model to implement the view transformation of a higher abstraction sequence layer.

[0085] The present invention relates to a method for automating FPGA simulation verification, which realizes the automatic extraction of the engineering design under test without design platform limitations, the automatic generation of a simulation verification environment, the automatic execution of simulations, the automatic generation of verification reports, and the switching among table views, document views, schematic views, and code views under the same verification model, forming a more flexible and optimized verification environment and improving the efficiency of FPGA simulation verification. The present invention belongs to the field of large-scale programmable logic automated design and verification. It follows the generative programming method, automates the design process through the integration and interoperability of required external tools, and constructs a simulation verification environment for programmable logic devices in a development tool based on software test automation.

[0086] The method provided by the present invention is not limited to a specific operating system and a specific development environment, but is based on the existing standard extensible markup language (XML) formulated by W3C, combines the universal verification methodology (UVM), provides a formal meta-model, and the model can be gradually transformed and combined to create a more refined model for a specific design task, and has a standardized application programming interface for reader and generator integration. The descriptions of the written components and verification cases are both human-readable and machine-processable. This method describes the interconnection of the programmable logic system design and the verification environment interface with standard specifications, providing an extensible mechanism for verification automation. Through this mechanism, the reuse of environments and cases between different verification personnel and different verification service providers can become a reality.

[0087] Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications to the technical solution of the present invention by using the methods and technical contents disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention without departing from the technical solution of the present invention all belong to the protection scope of the technical solution of the present invention.

Claims

1. An extensible automated method for FPGA simulation verification, characterized in that the steps Including: S1. Establish standard specification documents: The standard specification documents include eight types of description document types: component files, design files, design configuration files, bus definition files, abstract definition files, abstractor files, generator chain files, and directory files; S2. Establish a converter model through meta-syntax symbols and a template engine, as well as the mapping relationship between different converter models and the standard specification documents in S1; The converter model includes a base model, a meta-model, and a meta-meta model: S3. Design a converter according to the meta-model, provide a dedicated environment to read the information of the unit under test, pack all components of the information of the unit under test into a standard-format XML file according to the standard mode, and fill in the XML fields of all component description attributes of the unit under test: physical ports, interfaces, parameters, generics, register mappings, physical attributes, and store them in the database; Control the registers accessed by the system bus, create and call the verification module VIP, match the simulation verification environment configuration information input by the user in the dedicated environment with the information of the unit under test, and complete the connection between the verification module VIP and the unit under test; automatically generate simulation verification code through the design file to complete the construction of the functional verification environment for the unit under test; S4. Design a converter according to the meta-meta model, input the verification case steps according to the form view, automatically generate case code through the design file, integrate it into the verification environment generated in S3, start the script to execute the simulation verification, and automatically read the simulation verification results to generate a verification report in the user-defined format; S5. Define a new standard specification document type for function extension, and design an abstract model to implement the view conversion of a higher abstract sequence layer.

2. The scalable FPGA simulation and verification automation method according to claim 1, wherein The component file accesses the information of the unit under test through XML and records the interfaces of the information of the unit under test.

3. The automated method for expandable FPGA simulation verification according to claim 1, wherein The design file defines component configuration and component interconnection configuration, generates views related to logical interconnection and physical interconnection, realizes the instances of sub-components of components, the parameter values of component instances, and the connections between component instances, and records the internal structure of components.

4. An extensible FPGA simulation verification automation method according to claim 1, characterized in that The design configuration file selects an appropriate view combination for component instances, realizes the configuration design for specific purposes, defines additional configuration information for the generation chain or design description, compiles and simulates the register transfer level circuit RTL according to the component configuration and component interconnection configuration in the design file, and executes the transaction-level communication TLM.

5. The automated method for expandable FPGA simulation and verification according to claim 1, characterized in that The bus definition file describes the attributes of the bus type and records the attributes of the hardware communication protocol independent of the protocol representation.

6. The scalable FPGA simulation and verification automation method according to claim 1, characterized in that The abstract definition file describes the bus representation attributes and defines the adapter between the structure abstraction and the content abstraction.

7. The automated method for expandable FPGA simulation and verification according to claim 1, characterized in that, The abstractor file defines the hardware communication protocol information recorded according to the logical ports and their attributes, and describes the transaction-level communication TLM between the connected bus interfaces based on the view combination in the design configuration file.

8. The automated method for expandable FPGA simulation and verification according to claim 1, characterized in that The generator chain file defines the grouping and sorting of converters, describes the converter URLs running on the standard specification document, the names and values of the input parameters provided to the converters, and the implementation process steps, so that the design environment runs these converters based on the process defined in the chain.

9. The automated method for expandable FPGA simulation and verification according to claim 1, wherein The directory file records the location of the standard specification document and the element identifiers in the file.

10. The automated method for expandable FPGA simulation verification according to claim 1, wherein The base model is used to implement content-based modeling. The base model extracts the specific content implemented by the simulation verification environment components into an abstract syntax tree.

11. The automated method for expandable FPGA simulation verification according to claim 1, wherein The meta-model is used to implement algorithmic structure modeling, defining hardware resources, hardware processors, wire ports, transaction ports, hardware bridges, clock resources, model libraries, describing design components, instantiation of components, and connections between components. The connection interfaces adopt request / response-based communication and process-oriented communication.

12. The automated method for expandable FPGA simulation verification according to claim 1, characterized in that, The meta-meta model is used to implement verification plan structure modeling, defining the sequential programming language for describing software access, the transaction-level communication register model of the connection interface, and the event-driven hardware description model.

Images