CN115935872A - Extensible FPGA simulation verification automation method - Google Patents

Abstract

The invention relates to an extensible FPGA simulation verification automation method, which comprises the following steps: establishing a standard specification file; establishing a converter model through a metagrammar symbol and a template engine; designing a converter according to the meta-model, and providing a special environment to read the information of the tested unit; designing a converter according to the meta model, and generating a verification report in a user-defined format according to the step of inputting a verification case by a tabulated view; and defining a new standard file type for function extension, and designing an abstract model to realize view conversion of a higher abstract sequence layer. The invention enhances the adaptability of the verification tool and improves the flexibility of the tool application.

Description

Extensible FPGA simulation verification automation method

Technical Field

The invention relates to an extensible FPGA simulation verification automation method, and belongs to the technical field of large-scale programmable logic automation design and verification.

Background

In recent years, some methods for rapidly building an FPGA simulation verification environment have been provided, so that partial verification efficiency is improved, and partial reusability is met. However, for different design platforms provided by different FPGA chip suppliers or different simulation software platforms, it is necessary to modify the tool source code to implement the corresponding function, and these methods are also lack of automatic implementation of the verification case, and automatic combination of the verification case tool and the verification environment, for example, the case tool obtains the simulation tool result, accesses a specific register in the Design Under Test (DUT), etc.; on the other hand, the portability, cooperative work capability and maintainability of the verification environment and the convenience of documentation are also in urgent need to be further enhanced.

Disclosure of Invention

The invention solves the technical problems that: the method overcomes the defects of the prior art, provides an extensible FPGA simulation verification automation method, realizes the full automation of extracting a simulation verification environment, a verification case and a verification report from the design of a tested project under different design platforms, effectively combines the workflow, the data flow and the information flow of the whole verification, realizes the synchronization of a verification file view and an environment code view, standardizes a file list and a communication protocol, and ensures that a system does not depend on a specific chip supplier and a verification service party, thereby further improving the extensibility and the verification efficiency of an FPGA simulation verification system.

The technical scheme of the invention is as follows:

an extensible FPGA simulation verification automation method comprises the following steps:

s1, establishing a standard specification file:

the standard specification file comprises eight description file types, namely a component file, a design configuration file, a bus definition file, an abstract definition file, an abstractor file, a generator chain file and a directory file;

s2, establishing a converter model and a mapping relation between different converter models and the standard specification file in the S1 through a meta-grammar symbol and a template engine;

the converter model comprises a basic model, a meta model and a meta model:

s3, designing a converter according to the meta-model, providing a special environment to read the information of the unit to be tested, packaging all components of the information of the unit to be tested into an XML file with a standard format according to a standard mode, and filling XML fields of description attributes of all components of the unit to be tested: physical ports, interfaces, parameters, generics, register mapping and physical attributes are stored in a database;

the method comprises the steps that a verification module VIP is created and called by controlling a register accessed by a system bus, and simulation verification environment configuration information input by a user in a special environment is matched with information of a unit to be tested, so that the connection between the verification module VIP and the unit to be tested is completed; automatically generating simulation verification codes through the design file to complete the establishment of the functional verification environment of the tested unit;

s4, designing a converter according to the meta model, inputting a verification case according to a tabulated view, automatically generating case codes through a design file, integrating the case codes into a verification environment generated in the S3, starting a script to execute simulation verification, automatically reading a simulation verification result, and generating a verification report in a user-defined format;

and S5, defining a new standard file type for function expansion, and designing an abstract model to realize view conversion of a higher abstract sequence layer.

Furthermore, the component file accesses the information of the unit to be tested through XML and records an interface of the information of the unit to be tested.

Further, the design file defines component configuration and component interconnection configuration, generates views related to logical interconnection and physical interconnection, realizes instantiation of sub-components of the components, parameter values of the component instantiation and connection between the component instantiations, and records the internal structure of the components.

Further, the design configuration file selects the appropriate view combinations for the component instances to configure the design for a specific purpose, defines additional configuration information for generating chains or design descriptions, compiles and emulates register transfer level circuitry RTL according to the design file component configuration and component interconnect configuration, and performs transaction level communications TLM.

Further, the bus definition file describes the attribute of the bus type and records the attribute of the hardware communication protocol independent of the protocol representation.

Further, the abstract definition file describes bus representation attributes, and defines adapters between the structural abstraction and the content abstraction.

Further, the abstract file defines hardware communication protocol information recorded according to the logical ports and their attributes, and describes transaction level communication TLM between the connected bus interfaces based on the view combinations in the design configuration file.

Further, the generator chain file defines the grouping and ordering of the converters, describes the converter URLs that run on the standard specification documents and the input parameter names and values provided to the converters, and implements the process steps that cause the design environment to run these converters based on the processes defined in the chain.

Further, the directory file records the location of the standard specification file and the element identifier in the file.

Further, the basic model is used for realizing content mode modeling, and the basic model extracts concrete contents realized by the simulation verification environment component into an abstract syntax tree.

Furthermore, the meta-model is used for realizing algorithm structure modeling, defining hardware resources, hardware processors, net ports, transaction ports, hardware bridges, clock resources and a model library, describing design components, instantiation of the components and connection among the components, and the connection interface adopts request/response type communication and flow-oriented communication.

Further, the meta model is used to implement verification plan structure modeling, define a sequential programming language that describes software access, a transaction level communication register model of the connection interface, and an event driven hardware description model.

Compared with the prior art, the invention has the beneficial effects that:

(1) The method uses object-oriented analysis as a basic method, and based on a meta-modeling technology, unifies the architecture of design engineering file analysis, automatic generation of verification environment and use case, and conversion of each view (environment code, schematic diagram, use case table and report file) in the verification process, realizes automation of the simulation verification process on a larger level, reduces the complexity of the verification work, increases the visual experience of the verification work, reduces the inconsistency of the report and the use case brought by human factors in the verification process, relieves the pressure of verification personnel, greatly improves the verification work efficiency, and is expected to further improve the productivity;

(2) According to the invention, the pattern template is converted through the standard specification file, so that the automatic reading of design projects under platforms provided by different chip manufacturers, the automatic generation and execution of verification environments of different simulation platforms and the reutilization of VIPs of different verification companies are realized, the pattern template only needs to be changed when the platform is replaced for designing or verifying the VIP, the source code of a tool does not need to be changed, the adaptability of the verification tool is enhanced, and the flexibility of the tool application is improved;

(3) The invention can be applied as an interface of hardware and software, and starts from the memory architecture specification and a hardware register accessible by the software, and shares a description data source, thereby making up the verification design vacancy;

(4) The method utilizes the standard file expansion area to establish the VIP library, the case keyword library and the indexes thereof, standardizes the case generation process in a graphic conversation and spreadsheet mode, solidifies the verification experience, improves the reusability of verification work, is beneficial to the verification personnel to concentrate on the verification scene and the case analysis, reduces the omission rate of the verification problem and improves the verification work quality;

(5) The invention utilizes the standard file extension area to establish the extension description except the source code of the design to be tested, realizes FPGA simulation verification, can be applied to other performance analysis such as power consumption, time sequence and the like of the design to be tested in an extension way, is related to the management of the design to be tested at a higher level, and provides possibility for an extension tool starting from the same design source.

Drawings

FIG. 1 is an overall modeling hierarchy of the present invention;

FIG. 2 is a schematic diagram of a tool chain generation structure according to the present invention;

FIG. 3 is a diagram of a tool implementation architecture of the present invention;

FIG. 4 is a standard specification file description diagram;

FIG. 5 is a diagram of a standard specification file extension application.

Detailed Description

The invention is further illustrated by the following examples.

Example description of modeling method

The invention defines an extensible FPGA simulation verification automation method, introduces four layers and three levels of models in the FPGA simulation verification process, abstracts the views of different layers, and facilitates a verifier to build a functional simulation verification environment, as shown in FIG. 1. The view reader and the generator can be derived from a meta-grammar symbol in an extended Backos-Nual form, and can also automatically generate a view and automatically construct each part of an automatic solution based on a template engine; meta-modeling is a key technique for the method to code and formalize the data structures that generate the object code, and is particularly useful for verification of designs that bridge the simultaneous presence of hardware and software.

Level one there are multiple views in the design process. One of these is the document, and the tabular representation of this document view is shown in Table 1, where the component has two 16-bit registers R0 and R1, with R0 at relative address 0, R1 at relative address 1, its two registers R1 and R2 and its four bit fields B1 through B4, all Name attributes are set to satisfy the multiple constraints imposed by the back-level modeling, all other required attributes are set to include Offset and Size, with the attributes set to integer values, and interoperations HWr, HWw, SWr, and SWw between hardware and software, set to Boolean values True or False. The verification engineer uses this view when verifying the interface, the software and hardware engineers who make the interface, and the customer developing software for the product of the integrated DUT. Table 1 and all of the views shown in fig. 1 have been simplified to provide a better and more intuitive understanding of the overall design.

Table 1 underlying code correspondence register table in fig. 1

Another possible RTL view is shown in the bottom-most document of FIG. 1, assuming that the bus interface contains only Addr, dataIn, dataOut, en, and Wr. En is "1" if the DUT is accessed, and Wr is "1" if the register should be written. It is assumed that the bus and registers have the same clock and reset signals and that there is no pipelining or other delay on the bus. In addition, there are a firmware view and an inline function view, which describe the interface between the connecting hardware and software in code.

Level two gives an example of a model specified graphically (using a UML object diagram), which describes the instances in level one, providing addressable shells; the bit field designates the access authority and is responsible for storing data by software; setting a read-write mark, and determining whether the Wire exists from a register field to a tested hardware kernel; the values written into the hardware are stored in temporary registers and the values read are taken directly from the hardware under test. The semantics of the modeled domains have other constraints, annotated using a particular constraint language (e.g., object constraint language, OCL, or programming language), for example, each bit field may be readable or writable from each design domain (software-side or hardware-side), the size of the bit field being smaller than the size of a register, and so on.

The three-layer abstraction displays a meta-model of a DUT register interface component, which is a key component of general hardware or software interface, the software side can be developed by C/C + +, python or other similar languages and sequentially executed, the hardware side can be gate-level description Verilog, VHDL or SystemVerilog modeling, the transaction-level communication is written by SystemVerilog or SystemC, and the read-write process is as follows:

in the reading process of the software, the hardware address is taken as a special variable, the bit field of the memory unit is accessed similarly, the hardware line is accessed, and after the register in which the bit field is read is finished, the software further processes the value of the register according to the verification requirement;

the writing process of the software is also similar to the operation of the memory unit, and the interface writes the value into the base address of the IP plus an internal offset, so that the value is transmitted from the software to the hardware; on the other hand, hardware may be connected to the register, for example, triggering an operation when accessing the register or writing a specific value. The connection of the software registers to the IP hardware is done over wires, which then process the values of these wires.

Level four shows a further abstraction of the meta-modeling, i.e. the meta-model, describing that a meta-model has a root class with other classes and properties, all of which have multiplicity. Thus, classes reference containers of sub-classes, which may redefine names and specify multiplicity. The component meta-model in level one is shown in level four in fig. 1 as an example of a meta-model. The object ComponentMM is the root node in the meta-model instance named ComponentMM. The object Register of the Class type uniquely associated with the object Register is the root node of the meta-model, the attributes of the Register are specified by the associated objects Offset, size and Attribute of the Name type, and the object Register also has an associated subclass object defining the associated object bit field of the Class type. The multiplicity of the association is denoted by MaxOccurs =1 and minoccrs = -1. The Bitfield class has seven attribute objects associated with it, three of which are not fully displayed.

Implementation of a kit

The tool kit designed under this method is shown in fig. 2, wherein both the use case automation tool and the verification environment automation tool are realized under this modeling method. The models are packaged in tools with separate data read-write interfaces (setAPI and getAPI), with which data can be dumped via simple network protocols into an intermediate storage based on XML format, and then validation is performed using a meta model or a constraint checking function provided by the advanced application layer of the meta model in use to provide a GUI for editing or provision. All of these components of the meta-modeling framework may be automatically generated using meta-model descriptions, and additional checks may be generated from object constraint language constraints associated with the meta-model or portions thereof.

The high-level application layer in fig. 2 refers to a higher abstract sequence layer, such as a management platform, which is responsible for flow-related control such as distribution of a tested project and collection of verification conditions, or a data pool, which is responsible for generation of a data source sequence for realizing flexible application; the example of the meta modeling tool provides a use case automation tool, the view is the man-machine interaction level of the tool, a verifier carries out information interaction with the tool through a user interface, selects a tested project, or reads engineering information from a management platform, selects a corresponding function or performance verification use case according to a task book, reads a test frame required by the use case in a data pool, generates a complete use case file, converts the complete use case file into an XML format file through a generator for storage, carries out interaction of environment information and simulation result information through a converter and the meta modeling tool, and judges a use case result to form a report file in a Word or Html format and outputs the report file to the verifier; the element modeling tool example gives a verification environment automation tool, finishes automatic extraction of the DUT and automatic generation of the verification environment, and accesses a third-party simulation verification tool through a conversion interface for simulation verification; the modeling tool is used for directly abstracting the hardware programming code to realize the compiling and simulation of the programmable logic.

Tool implementation architecture

FIG. 3 illustrates a specific architecture of the implementation of the simulation verification automation component of the toolkit for generating classes similar to the structure of the input XML specification document, which populates instances of these classes with information from the XML requirement specification and creates an instance for each use case. The automated testbed generator module then uses this XML specification to generate case and test case objects, which are generated by the transformer shown in FIG. 2. Each case object contains a list of test case objects, and each test case object also contains a linked list of subsequent test cases specified in the case scenario. These lists cover all the effects of the current step on the DUT output in the use case scenario. The test case generator is a SystemVerilog model, which adopts UVM methodology to complete environment building and realizes three independent threads: random test generation, simulation verification execution and functional and non-functional requirement check.

Structural description of standard specification document

The standard specification file used in the present invention provides XML description of components and systems, including eight description file types of components, design configuration, bus definition, abstract definition, abstractor, generator chain and directory, each type contains extensible area description, the size of the file is determined by the complexity of DUT, the structure is shown as component register XML description in fig. 4, and the structure of each type is specifically described as follows:

the component description aims to access the DUT through XML, and records interfaces of the DUT, such as parameters, registers, port lists and embedded types; views of the DUT, such as RTL and transaction level communication (TLM) descriptions; and files that implement each view, e.g., as Verilog, VHDL, systemveilog, and SystemC files; in order to be able to verify the connection of interfaces other than the system interface that the DUT cannot directly access, an additional verification component is usually required that can be connected to the description file, e.g. the IP interface of the USB under test with register control accessed by UTMI + VIP over the system bus in fig. 4. To simplify the processing of the VIP, a set of predefined functions may be used, operating as a simple software stack, to facilitate the transmission or reception of USB packets;

the design describes a hierarchical DUT, defines component configurations and component interconnect configurations, and is able to generate views related to logical interconnects (e.g., system memory maps) and physical interconnects (e.g., structural HDL). Recording the internal structure of the component by describing the instantiation of the sub-component for implementing the component, the parameter values of the component instantiation, and the connection between the component instantiations;

design configuration by selecting appropriate view combinations for component instances, implementing a special purpose configuration design, defining additional configuration information for generating chains or design descriptions, compiling and simulating RTL, executing TLM according to design file component configuration and component interconnection configuration;

the purpose of the bus definitions and abstract definitions is to describe various aspects of a hardware communication protocol, indicating which interface uses which protocol and which component ports implement the protocol. Two bus interfaces may 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 reference different abstraction definitions, an abstraction is required on the interconnect to perform the TLM translation. The bus definition describes a bus type attribute, and records attributes of a hardware communication protocol independent of protocol representation, such as whether the protocol supports direct connection between a master interface and a slave interface, and whether specification file address calculation is suitable for mapping the protocol to be mapped from a memory to a master address space; the abstract definition describes the bus representation properties, defines the adapter between the structural abstraction and the content abstraction,

the abstract definition records a representation of the hardware communication protocol in terms of logical ports and their properties (e.g., direction and number of bits of the master and slave interfaces) in order to describe the TLM between the connected bus interfaces, the required translation depending on the view of the component instances in the design configuration. Thus, to model or simulate a hybrid abstract design, an abstractor is instantiated in a design configuration;

a generator chain description defining the grouping and ordering of the converters, the generator chain describing tool URLs running on standard specification documents and input parameter names and values provided to the tools, implementing flow steps to enable the design environment to run these tools based on the flows defined in the chain, the documents describing the location of the tools and tool input values, such as design software, libraries, name and version identifiers used by DUT components and component view names, as inputs traversing the design hierarchy;

the purpose of a directory is to manage a collection of files by recording the locations of standard specification files and the identifiers of the elements recorded in these files, for each of the mentioned standard specification document types, a directory document describes the URL of a specification file and the identifiers of the elements described in that specification file.

Extended application of the invention

The invention introduces the meta-modeling technology into FPGA simulation verification, and the meta-modeling technology is internally provided with a plurality of extensible mechanisms and can be extended on the basis of not changing the original meta-model according to the design requirement, for example, the construction type in the UML can be used for creating new model elements; the tag value is used to define additional attributes for an existing modeling element or stereotype; constraints are used to add new rules or modify existing rules, which can be used to delete properties from modeling elements. As another example, where a standard specification file allows different designers to place additional data at specific locations in the model, the introduced method extension area describes the initial schema that allows any particular additional attributes to be extended while still being compatible with the standard, and FIG. 5 illustrates the extended application of such a standard specification file through the extension of a component description file.

Each field in fig. 5 is represented as a folder containing subfolders and files. Folders and files are relatively linked in XML files. The parameters of each field are resource type, visibility and access attributes or suggested editing tools, and each DUT is assigned a unique identifier. The extension area is used for realizing structural description of projects, such as DUT requirement documents and structural description of the projects; VIP, including testbenches, test Case, verification structure and visual symbol, etc.; other non-functional specifications, such as power consumption design, other performance design, timing information, etc.; the index-related information description of the present component. The most important application is to extend the VIP part, and the VIP part is used in the FPGA simulation and verification automation of the invention.

Specifically, an extensible FPGA simulation verification automation method comprises the following steps:

s1, establishing a standard specification file:

the standard specification file comprises eight description file types including a component file, a design configuration file, a bus definition file, an abstract definition file, an abstractor file, a generator chain file and a directory file;

the component file accesses the information of the tested unit through XML and records an interface of the information of the tested unit;

the design file defines component configuration and component interconnection configuration, generates views related to logical interconnection and physical interconnection, realizes instantiation of sub-components of the components, parameter values of the component instantiations and connection among the component instantiations, and records the internal structure of the components;

the design configuration file selects a proper view combination for the component instance to realize the configuration design with a specific purpose, defines additional configuration information of a generating chain or design description, compiles and simulates a register transmission level circuit RTL according to the configuration of the component and the interconnection configuration of the component in the design file, and executes transaction level communication TLM;

the bus definition file describes the attribute of the bus type and records the attribute of the hardware communication protocol independent of the protocol representation;

the abstract definition file describes bus representation attributes and defines an adapter between the structure abstraction and the content abstraction;

the abstract file defines hardware communication protocol information recorded according to the logical port and the attribute thereof, and describes transaction level communication TLM between the connected bus interfaces based on view combination in the design configuration file;

the generator chain file defines the grouping and ordering of the converters, describes the converter URLs running on the standard specification documents and the input parameter names and values provided to the converters, and implements the flow steps for the design environment to run the converters based on the flows defined in the chain;

the directory file records the position of the standard specification file and the element identifier in the file;

s2, establishing a converter model and a mapping relation between different converter models and the standard specification file in the S1 through a meta-grammar symbol and a template engine;

the converter model comprises a basic model, a meta model and a meta model:

the basic model is used for realizing content mode modeling, and the basic model extracts concrete contents realized by the simulation verification environment component into an abstract syntax tree;

the meta-model is used for realizing algorithm structure modeling, defining hardware resources, a hardware processor, a wire network port, a transaction port, a hardware bridge, clock resources and a model library, describing design components, instantiation of the components and connection among the components, and adopting request/response type communication and flow-oriented communication for a connection interface;

the meta-element model is used for realizing verification plan structure modeling, defining a sequential programming language for describing software access, a transaction-level communication register model of a connection interface and an event-driven hardware description model;

s3, designing a converter according to the meta-model, providing a special environment to read the information of the unit to be tested, packaging all components of the information of the unit to be tested into an XML file with a standard format according to a standard mode, and filling XML fields of description attributes of all components of the information of the unit to be tested: physical ports, interfaces, parameters, generics, register mapping and physical attributes are stored in a database;

the method comprises the steps that a verification module VIP is created and called by controlling a register accessed by a system bus, and simulation verification environment configuration information input by a user in a special environment is matched with information of a unit to be tested, so that information connection between the verification module VIP and the unit to be tested is completed; automatically generating simulation verification codes through the design file to complete the construction of the information function verification environment of the tested unit;

s4, designing a converter according to the meta model, inputting a verification case according to a tabulated view, automatically generating case codes through a design file, integrating the case codes into a verification environment generated in the S3, starting a script to execute simulation verification, automatically reading a simulation verification result, and generating a verification report in a user-defined format;

and S5, defining a new standard file type for function expansion, and designing an abstract model to realize view conversion of a higher abstract sequence layer.

The invention relates to an FPGA simulation verification automation method, which realizes automatic extraction of a tested engineering design which is not limited by a design platform, automatic generation of a simulation verification environment, automatic execution of simulation, automatic generation of a verification report, and switching of a form view, a document view, a schematic diagram view and a code view under the same verification model, forms a more flexible and optimized verification environment, and improves the FPGA simulation verification efficiency. The invention belongs to the field of large-scale programmable logic automatic design and verification, and relates to a method for automatically designing a flow by integrating and interoperability external tools required by design according to a generative programming method and constructing a simulation verification environment for programmable logic equipment in a development tool based on software test automation.

The method provided by the invention is not limited to a specific operating system and a specific development environment, but is established on the basis of the standard extensible markup language (XML) established by the existing W3C, and combined with the Universal Verification Methodology (UVM), a formal meta-model is provided, the model can be gradually converted and combined, a more refined model is created for a specific design task, and a standardized application program interface for integrating a reader and a generator is provided, and the description of the written components and verification cases can be both manually readable and machine-processed. The method describes the interconnection of the programmable logic system design and the verification environment interface by standard specification, provides an extensible mechanism for the verification automation, and realizes the reutilization of the environment and the use case between different verification personnel and different verification service parties through the mechanism.

Although the present invention has been described with reference to the preferred embodiments, it is not intended to limit the present invention, and those skilled in the art can make variations and modifications of the present invention without departing from the spirit and scope of the present invention by using the methods and technical contents disclosed above.

Claims (12)

1. An extensible FPGA simulation verification automation method is characterized by comprising the following steps:

s1, establishing a standard specification file:

the standard specification file comprises eight description file types, namely a component file, a design configuration file, a bus definition file, an abstract definition file, an abstractor file, a generator chain file and a directory file;

s2, establishing a converter model and mapping relations between different converter models and standard files in S1 through a metagrammar symbol and a template engine;

the converter model comprises a basic model, a meta model and a meta model:

s3, designing a converter according to the meta-model, providing a special environment to read the information of the unit to be tested, packaging all components of the information of the unit to be tested into an XML file with a standard format according to a standard mode, and filling XML fields of description attributes of all components of the unit to be tested: physical ports, interfaces, parameters, generics, register mapping and physical attributes are stored in a database;

the method comprises the steps that a verification module VIP is created and called by controlling a register accessed by a system bus, and simulation verification environment configuration information input by a user in a special environment is matched with information of a unit to be tested, so that the connection between the verification module VIP and the unit to be tested is completed; automatically generating simulation verification codes through a design file to complete the construction of a function verification environment of the tested unit;

s4, designing a converter according to the meta model, inputting a verification case according to a tabulated view, automatically generating case codes through a design file, integrating the case codes into a verification environment generated in the S3, starting a script to execute simulation verification, automatically reading a simulation verification result, and generating a verification report in a user-defined format;

and S5, defining a new standard file type for function expansion, and designing an abstract model to realize view conversion of a higher abstract sequence layer.

2. The extensible FPGA simulation verification automation method of claim 1, wherein the component file accesses the information of the unit under test through XML, and the interface of the information of the unit under test is recorded.

3. The extensible FPGA simulation verification automation method of claim 1, wherein the design file defines component configuration and component interconnection configuration, generates views related to logical interconnection and physical interconnection, implements instantiation of sub-components of the components, parameter values of the component instantiation, and connection between the component instantiations, and records internal structure of the components.

4. The extensible FPGA simulation verification automation of claim 1, wherein a design configuration file selects an appropriate combination of views for a component instance, implements a purpose-specific configuration design, defines additional configuration information for a generation chain or design description, compiles and emulates register transfer level circuitry RTL, executes transaction level communications TLM according to design file component configuration and component interconnect configuration.

5. The method of claim 1, wherein the bus definition file describes bus type attributes and records attributes of the hardware communication protocol independent of the protocol representation.

6. The method of claim 1, wherein the abstraction definition file describes bus representation properties, defines adapters between structural abstractions and content abstractions.

7. The method according to claim 1, wherein the abstract file defines hardware communication protocol information recorded according to the logical ports and their attributes, and describes transaction level communication (TLM) between the connected bus interfaces based on the view combinations in the design configuration file.

8. The extensible FPGA simulation verification automation of claim 1, wherein the generator chain file defines the grouping and ordering of translators, describes translator URLs running on standard specification documents and input parameter names and values provided to the translators, and implements flow steps that cause the design environment to run the translators based on the flows defined in the chain.

9. The extensible FPGA simulation verification automation of claim 1 wherein the directory file records the location of the standard specification file and the element identifier in the file.

10. The method of claim 1, wherein the base model is used to implement content-based modeling, and wherein the base model extracts concrete content implemented by the simulation verification environment components as an abstract syntax tree.

11. The method of claim 1, wherein the meta-model is used to implement algorithmic structure modeling, define hardware resources, hardware processors, net ports, transaction ports, hardware bridges, clock resources, model libraries, describe design components, instantiation of components, and inter-component connections, and the connection interfaces employ request/response type communication and flow-oriented communication.

12. The extensible FPGA simulation verification automation method of claim 1, wherein the meta-model is used to implement a verification plan structure modeling, a sequential programming language defining description software access, a transaction level communication register model of connection interfaces, and an event driven hardware description model.

Images