Register model generation method and device for chip verification platform

Abstract

The present application provides a register model generation method and device for a chip verification platform. After obtaining a register description file, since the register description file is determined for the registers of the chip to be verified, the register attribute information of each specified type contained in the register description file can be classified and stored, and one register corresponds to each specified type of register attribute information. Therefore, according to the register model syntax format of the chip verification platform, the classified and stored register attribute information of each specified type is formatted and output to generate a register model for the corresponding register of the chip verification platform.

Description

Technical Field

[0001] The present application relates to the field of chip verification technology, and in particular to a register model generation method and device for a chip verification platform. Background Art

[0002] In the process of chip project development, in order to save chip verification costs and improve verification convenience, verification engineers usually use the register model provided by the UVM (Universal Verification Methodology) verification platform to model the registers in the design under test (DUT). Through a series of register access interfaces, they can efficiently implement read and write access to the registers in the DUT and fully verify its functions.

[0003] Among them, the above register model is usually manually written based on the register form provided by the designer. In this way, facing the large-scale register model with complex chip functions, the writing workload is heavy and prone to errors, thereby reducing the chip verification efficiency and the reliability of the verification results. Summary of the invention

[0004] In view of the above problems, this application provides the following solutions:

[0005] In a first aspect, the present application provides a register model generation method for a chip verification platform, the method comprising:

[0006] Obtain a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0007] Classify and store each specified type of register attribute information contained in the register description file; one register corresponds to each specified type of register attribute information;

[0008] According to the register model syntax format of the chip verification platform, the register attribute information of each specified type that has been classified and stored is formatted and outputted to generate a register model of the corresponding register for the chip verification platform.

[0009] In a possible implementation, the classifying and storing each specified type of register attribute information included in the register description file includes:

[0010] Based on the register model generation requirements of the chip verification platform, extracting register attribute information corresponding to a specified type from the register description file for classified storage;

[0011] Wherein, if the register attribute information of each specified type of any of the registers has been classified and stored, in the execution process of the step of classifying and storing the register attribute information of each specified type contained in the register description file, the register model generation step of the register is executed:

[0012] According to the register model syntax format of the chip verification platform, the register attribute information of each specified type corresponding to the classified and stored register is formatted and outputted to generate a register model of the register for the chip verification platform.

[0013] In a possible implementation, the register model generation requirement based on the chip verification platform extracts register attribute information corresponding to a specified type from the register description file for classified storage, including:

[0014] Based on the register model generation requirements of the chip verification platform, the register description file is matched line by line to obtain register attribute information of each specified type matched to the same register;

[0015] The register attribute information of each specified type is stored in an array data structure.

[0016] In a possible implementation, the register model generation requirement based on the chip verification platform extracts register attribute information corresponding to a specified type from the register description file for classified storage, including:

[0017] Acquire multiple information collection functions required by register model generation based on a chip verification platform; different information collection functions are used to collect register attribute information of different specified types;

[0018] The plurality of information collection functions are called to extract register attribute information of corresponding specified types from the register description file for classified storage.

[0019] In a possible implementation, formatting the classified and stored register attribute information of each specified type and then outputting it according to the register model syntax format of the chip verification platform to generate a register model of the corresponding register of the chip verification platform includes:

[0020] In the process of extracting register attribute information of each register in the register description file, determining to extract register attribute information of a specified type of a new register;

[0021] In the process of extracting register attribute information of each register from the register description file, formatting the register attribute information of each specified type of the previous register that has been classified and stored is output according to the register model syntax format of the chip verification platform to generate a register model of the previous register;

[0022] Determine that the classified storage of the register attribute information of each specified type contained in the register description file is completed, and format the register attribute information of each specified type of the last register that has been classified and stored according to the register model syntax format and then output it to generate a register model of the last register.

[0023] In a possible implementation, the step of determining to extract register attribute information of a specified type of the new register includes:

[0024] Extract register address information from the register description file to obtain current address information of the register tag variable;

[0025] Determine that the register address information does not match the current address information, use the register address information to update the register tag variable, and execute the step of formatting and outputting the register attribute information of each specified type of the previous register that has been classified and stored according to the register model syntax format of the chip verification platform to generate a register model of the previous register.

[0026] In a possible implementation, extracting register attribute information corresponding to a specified type includes:

[0027] Extract register domain range information;

[0028] Based on the register domain range information, determining the number of bits included in the corresponding register domain;

[0029] If the bit number is one bit, extract the starting bit in the register domain range information, and configure the corresponding register domain size to 1;

[0030] If the bit number is multiple bits, the minimum boundary value of the register domain range information is determined as the starting bit of the corresponding register domain, and the change amount of the register domain range information is configured as the corresponding register domain size.

[0031] In a possible implementation, storing each of the register attribute information of the specified type in an array data structure respectively includes:

[0032] Performing hash calculations on register attribute information of each specified type respectively to obtain hash values ​​corresponding to the specified type;

[0033] The hash values ​​corresponding to the respective specified types are stored in array data structures respectively.

[0034] In a possible implementation, the method further includes:

[0035] Acquire service information for implementing a specified service; the specified service includes at least one of a first service for building a register function coverage model and a second service for implementing a register backdoor access function;

[0036] In the process of formatting and outputting the classified and stored register attribute information, the business information is formatted and output according to the register model syntax format, so that the register model corresponding to the register generated for the chip verification platform can realize the specified business.

[0037] A second aspect of the present application provides a register model generation device for a chip verification platform, the device comprising:

[0038] An acquisition module is used to acquire a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0039] A classification storage module, used for classifying and storing each specified type of register attribute information contained in the register description file; one of the registers corresponds to each of the specified types of register attribute information;

[0040] A generation module is used to format and output the classified and stored register attribute information of each specified type according to the register model syntax format of the chip verification platform, so as to generate a register model of the corresponding register for the chip verification platform.

[0041] A third aspect of the present application provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed on an electronic device, the electronic device implements the register model generation method for a chip verification platform provided in an embodiment of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 A flowchart of generating a register model based on an EDA tool;

[0044] Figure 2 A flow chart of a register model generation method for a chip verification platform proposed in the first embodiment of the present application

[0045] Figure 3 A flow chart of a register model generation method for a chip verification platform proposed in Embodiment 2 of the present application;

[0046] Figure 4 A schematic diagram of a flow chart for classifying and storing attribute information of registers of various specified types in a register model generation method for a chip verification platform proposed in Embodiment 2 of the present application;

[0047] Figure 5 A schematic diagram of a flow chart of a register model generation method for a chip verification platform proposed in Embodiment 3 of the present application;

[0048] Figure 6 A flowchart of a register model generation method for a chip verification platform proposed in Embodiment 4 of the present application;

[0049] Figure 7 A schematic diagram of the structure of a register model generation device for a chip verification platform provided in an embodiment of the present application;

[0050] Figure 8 A schematic diagram of the hardware structure of an electronic device applicable to the register model generation method for a chip verification platform proposed in this application;

[0051] Fig. 9 A schematic diagram of a scenario architecture applicable to the register model generation method for a chip verification platform proposed in this application. DETAILED DESCRIPTION

[0052] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation mode of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application. The embodiments of the present application are described below in conjunction with the drawings. It is known to those of ordinary skill in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0053] The terms "first", "second" etc. in the full text of the application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable in appropriate circumstances, and this is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0054] In order to solve the technical problems existing in the manual writing of register models, it is proposed to use a series of functions provided by EDA (Electronic Design Automation) tools to assist engineers in quickly generating the required register models and reduce the error rate of manual writing. For example, VCS (Verification Compiler System) developed by Synopsys, an EDA verification tool with an embedded ralgen engine module, and iRun developed by Cadence, an EDA verification tool with an embedded iregGen module, etc. After obtaining the license of the corresponding EDA verification tool, the embedded ralgen / iregGen module can be used to quickly generate a standard UVM (Universal Verification Methodology) register model according to the register form content provided by the designer, so as to be integrated into the verification environment for use, to achieve chip verification and improve chip verification efficiency.

[0055] However, this register model generation method using EDA verification tools is too dependent on EDA verification tools. It is easy to be unable to use the corresponding EDA verification tools due to failure to obtain licenses or the existing licenses being banned, which reduces the reliability and stability of the generated register model and also affects the product release time. In addition, in the implementation process of using EDA verification tools to generate register models, VCS tools are used as an example. Figure 1 As shown in the flowchart, after obtaining the register form, the register RALF (Register Abstraction Layer File, a file format for defining the register model) file needs to be generated based on it to define the various registers and memories of the design, allowing the verification personnel to describe the registers in an abstract way. After that, the VCS tool can be used to automatically generate the register model. It can be seen that this process of generating an intermediate format file from the register form before generating the register model is relatively cumbersome, which affects the efficiency of register model generation.

[0056] In order to further improve the above problems, the present application proposes a register model generation method and device for a chip verification platform. After obtaining the register form provided by the designer, it is not necessary to load any EDA tool or obtain relevant licenses, and the register model of each register can be generated efficiently and reliably, without being restricted by the EDA tool developer. At the same time, it solves the heavy workload caused by manually writing register models, and the problem of easy errors and reduced reliability of register models. The register model generation method for a chip verification platform of the present application embodiment is described in detail below in conjunction with the accompanying drawings.

[0057] Reference Figure 2 , is a flow chart of the register model generation method for a chip verification platform proposed in the first embodiment of the present application. The method proposed in the present application can be applied to an electronic device, which can be a server or a terminal device with data processing capabilities, or a server in conjunction with a terminal device. The product form of the electronic device can be determined according to actual needs. In the scenario of verifying the register configuration content designed by the chip designer for the chip function, such as Figure 2 As shown, the register model generation method for a chip verification platform proposed in this embodiment may include:

[0058] Step S21, obtaining a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0059] Combined with the above description of the chip verification scenario, the register description file is obtained using the register form provided by the chip designer. This application can use the CSV (Comma-Separated Values) file format to process the table data in the register form to obtain a register description file. This text format is used to store the detailed information of each register described in the register form to implement the chip function design, such as the register address, name, bit width, access rights, reset value and other register attribute information, to generate a register model for each register in the chip verification platform (such as the UVM verification platform) to achieve register function verification of the design to be verified on the chip.

[0060] Among them, the register description file of the present application adopts the CSV file format, which is a lightweight text data format, easy to operate, supports multi-platform compatibility, and can be used without relying on a dedicated application (such as a Microsoft Excel table). Compared with the register form directly using the Excel format, the register description file in the CSV file format obtained by the present application has a wider applicability, especially in an environment where Excel is not installed. It can still process the register form data, so that the verification personnel can flexibly choose the type of electronic device to execute the method proposed in the present application, and is no longer limited to electronic devices with specific configurations. It should be noted that in the process of obtaining the register description file, the present application is not limited to using the CSV file format to represent the register form and obtain the register description file in the CSV file format. The electronic device can also support the use of other file formats (such as JSON (JavaScript Object Notation, a lightweight data exchange format) or XML (eXtensible Markup Language, a markup language) through an extension program to represent the register form and obtain a register description file in the corresponding file format. Subsequently, by using a parsing module corresponding to the file format (such as a json library or an xml.etree.ElementTree library, etc.), the register description file in the corresponding file format is imported for parsing and processing to generate various register models required for chip verification.

[0061] It can be seen that for register forms recorded in different file formats, the present application can automatically adapt to the parsing module using the corresponding file format to implement the method proposed in the present application, reliably meet the requirements of register model generation, avoid dependence on a single file format, and improve the diversity and extensibility of register form processing, as well as the reliability of generating register models. The present application embodiment only takes the processing process of the register description file in the CSV file format as an example to illustrate, and the processing process of register files in other file formats is similar, and the present application does not give detailed examples one by one.

[0062] Step S22, classifying and storing each designated type of register attribute information contained in the register description file; one register corresponds to each designated type of register attribute information;

[0063] Following the above analysis, the register description file is a description of all register information for the design to be verified on the chip, and the description of each register needs to describe the various register attributes of the register, which usually includes the definition and explanation content of each field required by its description format in addition to the description content of the register attribute of this application, and some register attribute information needs to be analyzed and processed before it can be determined, making the description language content in the entire register description file complex. Therefore, if the register description file is used directly to generate the register model of each register, its generation tool needs to spend a certain amount of time to parse the register description file, identify the multiple specified types of register attribute information required to generate the register model of each register, and then use these multiple specified types of register attribute information to execute the register model generation step, which affects the generation efficiency.

[0064] In order to improve the efficiency and reliability of generating each register model, the present application proposes to first classify and store the register attribute information of each specified type corresponding to each register in the register description file, so that each storage file (or storage area, etc.) records a specified type of register attribute information. Obviously, this classified storage method supports the rapid and accurate reading of each specified type of register attribute information required for the subsequent register model generation of a register. Compared with identifying each specified type of register attribute information of a register from the entire register description file, it can shorten the time for obtaining the required register attribute information, reduce the risk of errors in obtaining register attribute information, and lay a solid foundation for subsequent register model generation.

[0065] It should be noted that the present application does not impose any restrictions on the classification storage method of various register attribute information of each register described in the register description file, the storage file format used to store each type of register attribute information, and the storage method of such register attribute information, and can be flexibly configured or adjusted according to actual conditions.

[0066] Moreover, as analyzed above, in the case where the register description file obtained by the present application is a file in the CSV file format, the use of the CSV file format makes the data processing process more efficient, especially in the scenario where a large amount of register information is described in the register description file. It may only contain information describing each register itself, without font, color or other formatting information, which can save file storage space and reduce subsequent processing time. The present application does not restrict the operation method of obtaining each register information (each register information contains at least a description of each specified type of register attribute information of the corresponding register) in the register description file in the CSV file format.

[0067] Step S23 , formatting the register attribute information of each designated type that has been classified and stored according to the register model syntax format of the chip verification platform and then outputting it to generate a register model for the corresponding register of the chip verification platform.

[0068] In actual applications, there are differences in the register model syntax formats of different chip verification platforms. In order to ensure that each generated register model can be integrated into the corresponding chip verification platform to achieve functional verification of each register to be verified on the chip and reduce subsequent register model generation steps, after determining the chip verification platform, such as the above-mentioned UVW verification platform, the embodiment of the present application directly formats the register attribute information of each specified type of the same register according to the register model syntax format of the chip verification platform for various register attribute information that have been classified and stored, and outputs the formatted register attribute information. Therefore, the register model of the corresponding register that can be used for the chip verification platform can be reliably generated, and there is no need to perform other substantial processing steps on the classified stored register attribute information, which simplifies the register model generation process and further improves the reliability of register model generation.

[0069] To summarize, after obtaining the register description file provided by the chip designer, the embodiment of the present application will directly obtain register attribute information of different specified types from the register description file for classified storage, which provides convenience for the subsequent reading of the register attribute information of each specified type directly used to generate the corresponding register model, shortens the time for obtaining the register attribute information, and then directly formats the classified and stored register attribute information of each specified type according to the register model syntax format of the chip verification platform and outputs it, so as to reliably and efficiently generate a register model for the corresponding register that can be used for the chip verification platform, solves various technical problems existing in the method of manually writing the register model of each register and relying on EDA tools to generate the register model of each register, and reduces the technical requirements for verification personnel (such as the ability to write register models, etc.).

[0070] In addition, in the method proposed in the present application, the present application integrates the generated register model for each register of the design to be verified on the chip into the chip verification platform, so that each register model is used as a register component of the chip verification platform. In this way, when the verifier uses the chip verification platform to verify any or all functions of the design to be verified on the chip, the corresponding register model required to implement the corresponding chip function can be flexibly called to better meet the flexible verification requirements for specific chip functions.

[0071] Moreover, even if the register description file changes due to chip design changes, according to the method of automatically generating each register model proposed in this application, a new register model can be quickly generated based on the updated register description file, and directly updated to the chip verification platform, without regenerating all the register models required to implement the chip function verification, avoiding repeated generation of the same register model, and improving the chip verification efficiency on the basis of reliably meeting the updated chip function verification requirements. In some embodiments, combined with the above analysis, in order to reliably ensure that the register models of each generated register can be integrated into the chip verification platform, it is necessary to ensure that the register model contains the specified type of register attributes required by the chip verification platform, so that the register attribute information can be processed in a language and format that the chip verification platform can recognize, and prepare for the subsequent generation of register models for the chip verification platform.

[0072] Therefore, after determining the chip verification platform, the present application can first determine the register model generation requirements of the chip verification platform, such as the requirements for the specified type of register attributes, as well as the representation form and identification order of register attribute information, so that the electronic device can know which specified types of register attribute information of each register need to be obtained from the register description file, and accurately extract each specified type of register attribute information from the register description file, and classify and store register attribute information of different specified types, so as to facilitate the electronic device to efficiently and reliably implement subsequent operations.

[0073] It should be understood that in the case where the register model generation requirements of the chip verification platform change, the present application can re-identify the corresponding specified type of register attribute information in the register description file according to the updated register model generation requirements for classified storage to meet the requirements for efficient and reliable generation of the register model. The present application does not limit the content of the register model generation requirements of the chip verification platform. And the present application does not limit the implementation method proposed by the present application of adaptively matching each specified type of register attribute information from the register description file according to the register model generation requirements of the chip verification platform and storing them in the corresponding storage files / areas.

[0074] In one possible implementation, the automatic acquisition of register attribute information of different specified types in the register description file can be achieved by the corresponding type of information collection function. At this time, you can first determine multiple information collection functions based on the register model generation requirements of the chip verification platform. Different information collection functions can be used to collect register attribute information of different specified types. In this way, after obtaining these multiple information collection functions, you can directly call these multiple information collection functions to extract the corresponding specified types of register attribute information from the register description file for classified storage.

[0075] Among them, in the above-mentioned register attribute information collection process, multiple task threads (for the convenience of description, they can be recorded as first threads) with the same number as the information collection function can be created, and multiple first threads can be executed at the same time, and the corresponding information collection function can be called to realize the collection of register attribute information of the corresponding specified type. In this process, each first thread can match the register description file line by line to write the matched register attribute information of the corresponding specified type into the corresponding storage file / area. After determining that all the register attribute information of the specified type of the same register has been classified and stored, the register model of the corresponding register can be directly generated in the manner described in step S23. The register model generation process does not interfere with the above-mentioned register attribute information collection process, and can be executed in parallel to improve the efficiency of register model generation.

[0076] It should be noted that the present application does not restrict the content and source of the above-mentioned information collection functions. The original basic functions of the perl (a feature-rich computer programming language) program tool can be used to automatically collect different specified types of register attribute information of each register in the register description file, that is, call the function that implements the basic function to achieve adaptive matching of different specified types of register attribute information of each register in the register description file, and then use the existing data structure of the perl program tool for classified storage. The implementation process is not described in detail in this application.

[0077] Reference Figure 3 , is a flow chart of the register model generation method for a chip verification platform proposed in the second embodiment of the present application. This embodiment can describe another optional detailed implementation method of how to extract each specified type of register attribute information from the register description file and classify and store it in the register model generation method for a chip verification platform proposed above, such as Figure 3 As shown, the register model generation method for the chip verification platform may include but is not limited to the following steps:

[0078] Step S31, obtaining a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0079] Step S32, based on the register model generation requirements of the chip verification platform, the register description file is matched line by line to obtain register attribute information of each specified type matched to the same register;

[0080] Combined with the above description of the register description file, it can use the CSV file format to record the functional description of each register through one or more lines of table data, and separate different fields (such as different types of register attributes, field values ​​are register attribute information of corresponding types) through separators (such as commas, semicolons or tabs, etc.). The file description content is often relatively large. In order to avoid omissions, a line-by-line matching method can be used to perform adaptive matching according to the register model generation requirements of the chip verification platform to collect register attribute information of each specified type in the register description file.

[0081] In one possible implementation, for a register description file in a CSV file format, the present application can directly implement the reading of each row of data in the register description file one by one through scripting tools such as Python or Perl scripts, and obtain the register attribute information of each specified type required for classification and storage, that is, generate all types of register attribute information directly used by the register model of the corresponding register, without the need for file format conversion or reliance on other software to implement step S32, thereby simplifying the execution process of step S32 and helping to improve processing efficiency.

[0082] Among them, when the electronic device uses the CSV library of the Python script (or the Text::CSV module of the Perl script), after obtaining (such as loading / importing the system) the register description file in the CSV file format, the register description file can be quickly read and the table data therein can be parsed, and the register description file can be automatically reloaded in time when the register information in the register description file changes, and the register model actually required can be reliably generated according to the method proposed in the present application, avoiding the tedious steps of manually entering the register description file, and the problem of inaccurate chip verification results based on the register model generated thereby due to failure to update the register description file in time.

[0083] According to the above analysis, in order to reliably generate the various register models required for chip verification, this application can determine the various specified types of register attribute information that need to be obtained based on the register model generation requirements of the chip verification platform, such as determining the register attribute identifier of the specified type, so as to match the register description file line by line, and obtain each line of content in the register description file, match it with each specified type of register attribute identifier (such as field type), and determine which one or more specified types of register attribute information (such as field value) it contains. For example, according to the attribute name / field name of each specified type of register attribute information, match it with the current matching line of content, and obtain the matched register attribute information of each specified type, etc.

[0084] In a possible implementation, if the register description file is a table format file (such as a CSV file format file, etc.), the different register attribute information of each register is organized into corresponding lists, and each list records a field content, that is, a register attribute information, so that each specified type of register attribute information is recorded in the same list, and the register attribute information of the specified type in the list description can be read line by line according to the list field categories in the table header. The present application does not limit the implementation method of matching the register description file line by line in step S32, and can be implemented by calling the information collection function for each list field as described above, but is not limited to it.

[0085] In the line-by-line matching process under the above-mentioned different implementation methods, the present application can adopt but is not limited to Python scripts or Perl scripts or a combination of program tools (also referred to as script tools) of the two scripting languages ​​(it should be understood that program tools of other scripting language types can also be supported according to actual needs, and the present application only uses these two program tools as examples for explanation), so as to adaptively match to each specified type of register attribute information, such as calling the information collection function of the corresponding scripting language to implement, and is no longer limited to a single scripting language to describe the register attribute information. The present application does not elaborate on the line-by-line matching process of register description files implemented by different script tools.

[0086] Among them, in the scenario where the Python script and the Perl script are combined and implemented in the embodiment of the present application, the register form in the CSV text format can be read and preliminarily parsed by the Perl script tool, and the powerful text processing ability of the Perl script tool itself can be used to extract and preliminarily structure the register attribute description content. After obtaining the register description file, the Python script tool is used to extract the register attribute information of each specified type from the register description file for classified storage, so as to reliably and quickly generate the corresponding register model. When the register description file contains complex data, Python's rich data processing libraries (such as Numpy (Numeric Python, an open source numerical computing extension), Pandas (an open source data analysis tool library built on Numpy), etc.) can be used to process and improve the processing performance of large-scale register description files.

[0087] In the above-mentioned line-by-line matching process, the description information of the same register usually occupies multiple lines of the register description file, and different lines thereof may describe the register attribute information of the same specified type of the register multiple times. According to but not limited to the line-by-line matching process described above, in a possible implementation, each specified type of register attribute information of the register may be stored after being matched for the first time, and the specified type of register attribute information of the register that is not matched for the first time may not be stored, and even in the above-mentioned matching process based on attribute name / field name, etc., the same attribute name / field name of the same register may not be matched repeatedly, so as to reduce the matching workload and subsequent resource occupation.

[0088] In a possible implementation, in the process of line-by-line matching of the register description file, multiple pre-configured information collection functions for collecting register attribute information of different specified types may also be called to extract one or more specified types of matched register attribute information from the current line description content. Preferably, in order to improve processing efficiency, in this matching process, the electronic device may perform matching of a large amount of register attribute information in parallel in multiple processing units to reduce the matching time. As analyzed above, parallel processing of multiple threads (such as the multiple first threads mentioned above, each first thread constituting a processing unit) may be implemented through a script tool, so that the corresponding information collection functions are respectively called by the multiple first threads running in parallel to perform line-by-line matching and extract register attribute information of the corresponding specified type. The implementation process may refer to the description of the corresponding part of the information collection function in the context embodiment, but is not limited to this register attribute information extraction method.

[0089] Step S33, storing register attribute information of each specified type in an array data structure;

[0090] In the process of classified storage of register attribute information of different specified types for the same register, the present application can pre-configure the same number of storage files / areas, etc., and respectively configure each to store which specified type of register attribute information. In the row-by-row matching process of step S32, each time a new specified type of register attribute information is obtained, it is written into the corresponding configured storage file / area for storage according to the configuration relationship of different storage files / areas.

[0091] Among them, each register attribute information of each specified type of each register extracted from the register description file can be stored in the form of an array data structure. The array data structure is a structure that stores data in a continuous manner, and each element stored in the array can be accessed by an index, that is, the register attribute information of the same specified type of each register stored in each array can be randomly and quickly accessed according to the index to support the subsequent generation of any register model and improve the generation flexibility of different register models.

[0092] Of course, for the classified storage of register attribute information of each instruction type of each register extracted from the register description file, other types of data structures can also be used, such as arrays, queues, stacks, multi-layer nested hash tables / tree structures or linked lists, etc., which can be determined according to actual needs. The present application adopts any data structure to realize efficient classified storage of register attribute information of each specified type, and according to the query method of the corresponding data structure, quickly and reliably executes the query operation of register attribute information of each specified type required to generate a register model, so as to continue to perform subsequent processing, significantly improving the processing speed of large-scale data.

[0093] Step S34 , formatting the register attribute information of each designated type that has been classified and stored according to the register model syntax format of the chip verification platform and then outputting it to generate a register model for the corresponding register of the chip verification platform.

[0094] Following the above analysis, the register attribute information of the same specified type of each register extracted from the register description file is stored in the corresponding array file, so that through different array files, multiple specified types of register attribute information (which can be determined according to the register model generation requirements of the chip verification platform) (that is, all types of register attribute information directly used to generate the register model of the corresponding register) are classified and stored. After that, when it is necessary to execute the register model generation step, the register attribute information of each specified type for the same register (such as a register that has just been matched and classified and stored, or any register among the various registers that have been classified and stored, etc., depending on the situation) can be quickly queried from the various array files according to the register model syntax format of the chip verification platform, and after formatting it, it is output, which can efficiently and reliably generate the register model for the corresponding register of the chip verification platform. The present application uses other types of data structures to implement the storage of register attribute information of each specified type in a similar manner. The embodiment of the present application only takes the display data structure as an example for explanation.

[0095] It should be understood that in the event that the chip verification platform or the register model syntax format required by it changes, the present application can re-acquire the register attribute information that conforms to the change and classify and store it in accordance with the method described above. Of course, if the specified type of register attribute information required by the register model generated by the changed chip verification platform remains unchanged, the register attribute information of each specified type that has been classified and stored in each array can be re-formatted in accordance with the changed register model syntax format and with reference to the description method of the corresponding part of the context embodiment, and the register model of the corresponding register is generated by outputting the formatted register attribute information. The present application does not elaborate on the formatting processing method of the register attribute information stored in each array file.

[0096] In addition, if a register information changes due to a design change, the register identifier of the changed register information can be obtained, and the register attribute information of each specified type corresponding to the register identifier can be extracted from the newly obtained register description file, and updated to the corresponding array file for storage, so that the storage content of each array file matches the content of the newly obtained register description file, thereby ensuring that the register model subsequently generated meets the verification requirements after the design change.

[0097] In summary, the embodiment of the present application obtains the register description file provided by the designer, determines the register model generation requirements of the chip verification platform, and then matches the register description file line by line accordingly, and reliably obtains the register attribute information of each specified type designed for each register, that is, generates all types of register attribute information directly used by the register model of the corresponding register, and classifies and stores them in the form of an array data structure, which provides convenience for the subsequent reading of the register attribute information of each specified type of each register, ensures that the read register attribute information is reliable, and lays a reliable foundation for the subsequent direct generation of the corresponding register model. In this way, the register attribute information of each specified type of a register can be quickly and reliably obtained from each array, and the register attribute information is simply formatted and output according to the register model syntax format of the chip verification platform, so as to reliably and efficiently generate the register model of the corresponding register for the chip verification platform, without the verification personnel spending a lot of time and energy to write each register model, avoiding human writing errors, especially in the case of a large number of registers to be verified on the chip, the present application greatly improves the generation efficiency and reliability of each register model. In some embodiments, for the above-mentioned register description file, the present application can also divide it into multiple sub-files. At this time, the description content of each specified type of register attribute information of the same register is located in the same sub-file, and one sub-file is used to describe each specified type of register attribute information corresponding to at least one register. After that, multiple task threads (referred to as second threads here) with the same number as the sub-files can be created, and multiple second threads can be run at the same time. Based on the register model generation requirements of the chip verification platform, the register attribute information of the corresponding specified type is extracted from the corresponding sub-file for classified storage, that is, the extraction and classified storage of the respective specified type of register attribute information of multiple sub-files are realized in parallel. Optionally, in this implementation process, each second thread can call multiple information collection functions to collect each specified type of register attribute information; it can also match each sub-file line by line according to the method described in the above embodiment, extract each specified type of register attribute information for classified storage, etc. The present application does not limit the register attribute information extraction method of multiple sub-files.

[0098] Based on this, after determining that all the register attribute information of the specified type corresponding to at least one register has been classified and stored, the register model of each register can be generated according to the method described in step S34. Preferably, if all the register attribute information of the specified type corresponding to multiple registers has been classified and stored, multiple third threads can be created and executed, and all the register attribute information of the specified type of the corresponding registers can be formatted and output in parallel according to the method described in step S34, that is, multiple register model generation steps are executed simultaneously, which shortens the time for generating all register models and improves the efficiency of register model generation.

[0099] It should be understood that if the designer provides multiple register forms, after being processed into multiple register description files according to the method described above, in order to improve processing efficiency, multiple threads can be run in parallel to process the assigned register description files respectively, which greatly improves the efficiency of register model generation compared to processing one register description file before processing another register description file. Optionally, a single process can be created for each register description file, and multiple threads can be run in the process. According to the method described above, the extraction of register attribute information of each specified type can be realized in parallel, and multiple processes can realize the processing of multiple register description files in parallel. The implementation process of this application embodiment will not be repeated here.

[0100] In some embodiments, since the present application follows the register model generation requirements of the chip verification platform, the various specified type register attributes required for generating the register model may include but are not limited to: register offset address (offset_addr, which may be an offset relative to the base address, used to reliably access the register or a specified location area therein), register name (register_name), register domain name (field_name), register domain start bit (field_start_bit), register domain size (field_size), register domain access attribute (field_access_type) and register domain reset value (field_reset_value), etc., that is, multiple specified type register attributes of the register itself (such as offset_addr and register_name), and multiple specified type register attributes of each domain of the register (such as field_name, field_start_bit, field_size, field_access_type and field_reset_value), which are used to jointly define the structure and behavior of the register model of the corresponding register. The register description file may adopt a fixed register attribute description order to implement the description of these multiple specified types of register attribute information for each register.

[0101] Thus, in the implementation process of step S32, the register attribute information of the specified type corresponding to each register can be extracted from the register description file according to the fixed description order of the register attributes of each specified type, such as the enumeration order of the register attribute information of each specified type in the above paragraph. If the information collection function is used for implementation, according to the register attribute description order, such as Figure 4 As shown, the corresponding information collection functions called can be: offset_addr_collect (register offset address collection function), register_name_collect (register name collection function), field_name_collect (domain name collection function of each domain in the register), field_start_bit_collect (domain start bit collection function of each domain in the register), field_size_collect (domain size collection function of each domain in the register), field_access_type_collect (domain access attribute collection function of each domain in the register), and field_reset_value_collect (domain reset value collection function of each domain in the register).

[0102] Among them, for each specified type of register attribute information extracted, if an array data structure storage method is used for classification storage, the present application can pre-configure an array for storing the corresponding specified type of register attribute information, such as Figure 4 As shown, these multiple arrays can be recorded as: offset_addr_array (offset address array), register _name_array (register name array), field_name_array (domain name array), field_start_bit_array (domain start bit array), field_size_array (domain size array), field_access_type_array (domain access attribute array) and field_reset_value_array (domain reset value array). Optionally, the present application can also construct the corresponding array after sequentially extracting the register attribute information of the corresponding specified type. The present application does not limit the construction stage and method of each array, which can be determined according to the situation.

[0103] Combination Figure 4As shown in the flow chart, in some embodiments, after completing the matching of all lines in the register description file, the register attribute information of each specified type corresponding to each register of the design to be verified can be written into the corresponding array, so that the register attribute information of the same specified type of each register can be stored in one array. When it is necessary to generate the register model of each register, the register attribute information of each specified type of the same register stored in each array is formatted and output according to the method described above to generate the register model of the register, which is integrated into the chip verification platform to complete the verification of the register design function.

[0104] Among them, in the processing method described in the above embodiment, in order to distinguish the same specified type of register attribute information belonging to different registers stored in the same array file, the register attribute information corresponding to the register of the currently generated register model can be reliably identified from the array. In the process of row-by-row matching or classified storage, the corresponding register identifier (such as register number / name, etc.) can be configured, and the matched register attribute information is associated with the register identifier of the register to which it belongs and then stored. Subsequently, the specified type of register attribute information of the corresponding register can be queried according to the register identifier;

[0105] Alternatively, after storing the register attribute information of a specified type corresponding to a register in the array file, a separator (such as a comma, semicolon, etc.) is configured, and then the register attribute information of the next register corresponding to the specified type is stored, and the separator can be used to distinguish the register attribute information of the same specified type of different registers later. The present application can realize the storage of the register attribute information of the same specified type of each register in the same array by, but not limited to, configuring, such as register identifiers or separators, so as to avoid omission or formatting of register attribute information of other registers that are incorrectly identified, which affects the efficiency and reliability of register model generation.

[0106] In order to improve processing efficiency, the present application can create multiple threads or processes, read the register attribute information of each specified type of the corresponding register at the same time, and generate multiple corresponding register models in parallel. For example, through one thread / process, according to the above description, query the register attribute information of each specified type of a register assigned to it from each array file, output it after formatting, and generate the register model of the register, but it is not limited to the above parallel processing method.

[0107] In some other embodiments, since the register description file usually describes register information one by one, that is, after describing one register information, the next register information is described, but the order of the described register information is not limited, based on this, in the process of matching the register description file line by line, the register attribute information of each register can be extracted from the register description file, that is, after each matching and extraction of each specified type of register attribute information of a register, and storing it in the corresponding array file by classification, the register model is generated in time according to the method described in step S34. During this period, the above-mentioned line-by-line matching operation of the register description file is always executed, so that the register model generation process and the matching register attribute information storage process do not interfere with each other, and can be executed in parallel, thereby improving the processing efficiency. This processing method can refer to the description of the corresponding part of the embodiment below, and the embodiment of the present application is not described in detail here.

[0108] Among them, in the process of extracting register attribute information of each specified type for each register, the register attribute information of each specified type of a currently matched register can be extracted according to a fixed register description order (which can be based on the fixed description order of register attribute information of each specified type of each register represented by the register description file), and then classified and stored in a data format such as an array, but it is not limited to this fixed register description order extraction implementation method.

[0109] Based on this, in the above-mentioned process of row-by-row matching of each register of the design to be verified, that is, in the process of extracting each specified type of register attribute information corresponding to each register in the register description file, when it is determined that the specified type of register attribute information of the new register has been extracted, it can be indicated that the classified storage of each specified type of register attribute information of the previous register has been completed. In the process of extracting and classified storage of each specified type of register attribute information of the new register, the register attribute information of the previous register that has been classified and stored can be formatted and output directly according to the register model syntax format of the chip verification platform to generate a register model of the previous register to ensure the integrity and reliability of the register model.

[0110] Among them, in the process of row-by-row matching of register attribute information of each register described above in the present application, in order to timely determine that the matching has been completed and the register attribute information of each specified type of a register has been extracted, a register mark variable can be set to record the configuration content of a register that can identify the current match, such as any specified type of register attribute information, etc., and when the matched register changes, the configuration content of the register mark variable can be updated in time. The present application does not impose any restrictions on the configuration content of the register mark variable.

[0111] Take the configuration content of the register offset address as the register tag variable as an example. Figure 4 As shown, it can be expressed as org_off_addr. If the method proposed in this application is executed by a register model generation device (expressed as reg_model_gen) used for a chip verification platform, that is, the line-by-line matching of the above-mentioned register description file, the classified storage of the matched register attribute information of each specified type, and the subsequent formatting and output process, the register tag variable can be set in an independent storage area of ​​the register model generation device, so that in the line-by-line matching process, if the register offset address is extracted from a currently matched line in the register description file, it can be compared with the configuration content of the register tag variable. If it matches, it is considered that the currently matched register has not changed, and the register model generation step does not need to be triggered temporarily; if it does not match, it means that the currently matched register has changed, and it can be reliably determined that the register attribute information of each specified type of the previous register has been classified and stored, and the register model generation step for the previous register can be triggered.

[0112] In this way, after completing the classified storage of each specified type of register attribute information of a register, the register attribute information of this classified storage can be formatted in the process of extracting the next register information to generate a corresponding register model until the last line in the register description file is completed, that is, it is determined that the classified storage of each specified type of register attribute information of all registers contained in the register description file is completed. Since the corresponding register models have been generated for other registers except the last register, the register attribute information of the last register that has been classified and stored can be formatted and output according to the register model syntax format to generate the register model of the last register.

[0113] It should be noted that after determining that each specified type of register attribute information corresponding to any register has been classified and stored, in the execution process of classifying and storing each specified type of register attribute information contained in the register description file, the register model generation step of the register is directly executed (parallel execution), that is, according to the register model syntax format of the chip verification platform, the register attribute information of each specified type corresponding to the classified and stored register is formatted and output to generate a register model of the register for the chip verification platform. And after determining that each specified type of register attribute information corresponding to multiple registers has been classified and stored, in the execution process of classifying and storing each specified type of register attribute information corresponding to other registers contained in the register description file, the register model generation steps of each of the multiple registers can be executed in parallel. The implementation methods of these two parallel processing methods include but are not limited to the several methods listed above, which can be flexibly adjusted or combined according to actual conditions. This application does not give detailed examples one by one.

[0114] In summary, in order to further improve the reliability and accuracy of the generated register model, in the matching / collection process, classification storage process, and formatting process of each specified type of register attribute information described above, the exception handling mechanism of the script tool can be used to perform exception detection on the data processed at the corresponding stage, such as detecting the content integrity or consistency of each specified type of register attribute information (which can be implemented based on the register form), so that when an exception is detected, it can be handled in time to ensure that each register attribute information used to generate the register model is complete and correct. In some embodiments, such as Figure 4 As shown, in order to enrich the functions of the generated register model, one or more operations of adding a functional coverage model and adding a backdoor access function can be added to the formatting output processing device on the basis of the formatting processing operation of each specified type of register attribute information, so that the generated single register model has the corresponding functional coverage calculation function and backdoor access function, so as to improve the subsequent verification efficiency and reliability of different functions of the chip.

[0115] Among them, the above-mentioned script tool can adopt a modular configuration, and the above-mentioned various processing can be implemented by different modules so that the functions can be expanded or customized according to actual processing requirements, and the diversified processing requirements of different chip design requirements can be met. This application does not elaborate on the modular configuration process of the script tool.

[0116] According to the above analysis, refer to Figure 5The flowchart of the register model generation method for the chip verification platform proposed in the third embodiment of the present application is shown. This embodiment can describe an optional detailed implementation of the method proposed above to improve the efficiency and reliability of register model generation, but is not limited to this implementation. Figure 5 As shown, the method may include:

[0117] Step S51, obtaining a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0118] Step S52, performing line-by-line matching of register attribute information of a specified type of registers one by one in the register description file;

[0119] Step S53, determining whether the matched register attribute information is valid; if yes, proceeding to step S54; if no, returning to step S52 to continue matching the next row;

[0120] In the above process of matching the register description file line by line, after matching the register attribute information, it can be determined whether the matched register attribute information is valid based on the register model generation requirements of the chip verification platform. If it meets the register model generation requirements, it may include information format and type, etc., indicating that the register attribute information is valid and can continue to be classified and stored; otherwise, it means that the register attribute information is invalid, such as register attribute information of the specified type that does not belong to the register model generation requirements, etc., and the next line of the register description file can be matched.

[0121] Step S54, updating the matched register offset address, register name, register domain name, register domain range, register domain access attribute and register domain reset value to obtain corresponding register attribute information to be stored;

[0122] In the process of matching the register description file line by line, each time a valid register attribute information is matched, it can be written into the corresponding matrix for storage. That is, for each row of the register description file, the row is matched to each specified type of register attribute information, which can be updated and stored in the corresponding array. At this time, if the register attribute information of a specified type matched by the current row has been stored in the array, no processing is required.

[0123] It should be noted that register description files often do not directly describe the register attribute information content of certain specified types, such as Figure 4The register domain starting bit, register domain size, etc. shown in the figure also need to process the relevant description content to obtain the register attribute information of the corresponding specified type for classified storage. Among them, the present application uses the information collection function corresponding to each specified type to match the register description file line by line. According to the matching results, the register attribute field values ​​of the corresponding specified type in each information collection function can be updated, such as the field values ​​of each field such as the step register offset address, register name, register domain name, register domain range, register domain access attribute and register domain reset value, to obtain the required register attribute information. The implementation process of this embodiment will not be described in detail here.

[0124] Among them, it should be understood that in the process of line-by-line matching, each line does not necessarily describe all the fields. After matching a field, the present application can use the matched field value to determine the register attribute information of the corresponding specified type, that is, it may match one or more of the register offset address, register name, register domain name, register domain range, register domain access attribute and register domain reset value, and can update the matched corresponding field value to obtain the register attribute information of the corresponding specified type.

[0125] Step S55, determine whether the current row matches a new register; if not, proceed to step S56; if yes, proceed to step S57;

[0126] Step S56, classify and store the updated register attribute information of each specified type;

[0127] Step S57, generating a register model of the previous register;

[0128] Step S58, determining whether the last line of the register description file is matched, if not, returning to step S52 to continue matching the next line; if yes, proceeding to step S59;

[0129] Step S59, generating the last register model.

[0130] Following the above analysis, in the line-by-line matching process, if the register attribute information of the specified type matched by the current line belongs to the current register, that is, it belongs to the same register as the register attribute information of the guidance type matched by the previous line, then it cannot be accurately determined that the current line is the last line describing the register in the register description file. It can be considered that the extraction of the current register information has not yet ended, and the extracted register attribute information continues to be classified and stored, and the register description file continues to be matched line by line until at least one register attribute information of the specified type of a new register is matched, that is, it is determined that the current line matches the new register, and then the register model generation step of the register that has just been matched (that is, the previous register that is adjacent to the new register, the previous register detected above) is executed. The implementation process of the embodiment of the present application is not described in detail here, and you can refer to the description of the corresponding part of step S34.

[0131] It can be seen that in the register model generation method for a chip verification platform proposed in the embodiment of the present application, all register information in the register description file will be matched register by register, and when it is determined to start matching a new register, the register model generation step will be performed on the register that has been matched last, including the complete register attribute information of each specified type required to generate the register model, thereby improving the reliability of register model generation. Moreover, in each register matching process, a row-by-row matching method is adopted, and the register attribute information will be classified and stored only after it is determined to be valid, thereby ensuring that the stored register attribute information is valid and avoiding missing register description content, thereby further improving the reliability of the generated register model.

[0132] Reference Figure 6 The flowchart of the register model generation method for a chip verification platform proposed in the fourth embodiment of the present application is shown in FIG. 1 . In combination with the above analysis, in order to further improve the processing efficiency, the following is proposed: Figure 6 The method shown may include:

[0133] Step S61, obtaining a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0134] Step S62, based on the register model generation requirements of the chip verification platform, performing line-by-line matching of register attribute information of a specified type of registers in the register description file one by one;

[0135] In the implementation process of step S62, combined with the description of the corresponding part of the above embodiment, multiple threads running in parallel in a single process can be used to implement the matching and storage of register attribute information of the specified type. A single thread can also perform line-by-line matching of the register description file, and this application does not limit the implementation method of step S62.

[0136] Step S63, determining that the register attribute information extracted from the current row includes register address information, and obtaining the current address information of the register tag variable;

[0137] Step S64, determining whether the register address information matches the current address information, if so, executing step S65; if not, proceeding to step S67;

[0138] Following the above analysis, in the process of matching the register description file line by line in the embodiment of the present application,

[0139] You can extract the register attribute information of the specified type for each register described one by one in the order of register description, as shown above. Figure 4 The example register offset address information, register name information, register domain name information, register domain start bit information, register domain size information, register domain access attribute information, and register domain reset value information, etc. It can be seen that in the register description sequence, the register offset address is the register attribute of the specified type described for each register in the register description file. The present application can use it as a basis for judging whether to end the extraction of the register attribute information of the specified type of the previous register. The present application can configure the corresponding register tag variable (org_off_addr) accordingly, that is, the configuration content of the register tag variable is used as a basis for judging whether to start matching the register attribute information of the specified type of a new register in the subsequent line-by-line matching process.

[0140] Therefore, in the process of matching the register description file line by line according to the above-mentioned register description order, for each line of matched register attribute information, it is determined whether it contains register address information (which may be register offset address information, or address information used to calculate the register offset address information of the currently matched register, etc.), and it is matched with the current address information of the register tag variable to determine whether the current line match has entered the specified type of register attribute information extraction of a new register. If it matches, it means that the current line description is still the original register (such as the register described in the previous line, that is, the previous register described adjacent to the new register), and the next line match can be continued without updating the configuration content of the register tag variable; otherwise, it means that the current line match has entered the specified type of register attribute information extraction of a new register, and the extraction and classified storage of each specified type of register attribute information of the previous register are completed, and the register model generation step for the previous register can be executed.

[0141] It should be noted that the configuration content of the register tag variable for achieving the above-mentioned purpose includes but is not limited to the address information of the register. When the register description order of the register description file changes, that is, when the register attribute information of the specified type described in the first description is not the register address information, the register tag variable can be dynamically configured using the register attribute information of the new specified type described in the first description, thereby determining whether to end the line-by-line matching of the previous register during the line-by-line matching of the register description file. If so, the register model generation step for the previous register is triggered.

[0142] Step S65, updating and storing the register attribute information extracted from the current row into the corresponding array;

[0143] Step S66, determining whether the last line of the register description file is matched, if yes, proceeding to step S69; if no, returning to step S62 to continue matching the register description file line by line;

[0144] Taking the scenario where the register tag variable is the register offset address information of each register matched for the first time row by row as an example, if the current row matches the register address information, after comparing with the current matching content of the register tag variable, it is determined that the register address information matched by the current row is consistent with the current configuration content (i.e., current address information) of the register tag variable (i.e., matches), indicating that the register matched by the current row has not been updated. At this time, the specified type of register attribute information extraction and classification storage operations can continue to be performed. For example, an array data structure can be used to classify, update and store the register attribute information of each specified type matched by the current row, that is, the register attribute information of the specified type is updated and stored in the corresponding array, so that the array stores a register attribute information of the specified type of the currently matched register to avoid repeated storage.

[0145] In one possible implementation, if Figure 4 The information collection function of the specified type shown realizes the extraction of the corresponding register attribute information. After determining that the new register attribute information of the same specified type is matched, the new register attribute information of the specified type is extracted and classified and stored in the form of an array data structure. In this process, if the new register attribute information contains a register offset address, according to the method described in step S63 and step S64, it is determined whether to trigger the register model generation step for the previous register.

[0146] It should be understood that in the above example, if the register attribute information matched by the current row does not contain register address information, it can be classified and stored according to the method described in this application. If the row is not the last row, the next row of the register description file can be matched according to the method described above, and the matching can be repeated in this way until the matching processing of the entire register description file is completed.

[0147] Step S67, updating the register tag variable using the extracted register address information;

[0148] Step S68, while matching the register description file line by line, format the register attribute information of each specified type corresponding to the last register that has been classified and stored, and then output it according to the register model syntax format of the chip verification platform, so as to generate the register model of the last register, and then go to step S66 to continue execution;

[0149] In the process of matching the description contents of the registers of the design to be verified one by one in the register description file line by line, if the register attribute information of each specified type is extracted in sequence according to the register description order of the above example, once it is determined that the register address information obtained by matching the current line does not match the current address information of the register tag variable, it means that the current line describes a new register information. In order to avoid subsequent judgment errors, the register tag variable can be updated in time accordingly, and can be updated according to its configuration method, such as updating the offset address of a new register matched to the register tag variable, so that the current address information of the register tag variable is the offset address of the new register.

[0150] According to the method described above, after determining that the classified storage of register attribute information of each specified type of the previous register is completed, the register model generation step for the previous register can be executed, such as the description of step S68, to ensure that all specified types of register attribute information of the previous register that meet the register model generation requirements are read from each array, formatted, and output in accordance with the register model syntax format. This ensures that the generated register model can be reliably used in the chip verification platform, thereby ensuring the reliability and accuracy of the verification results.

[0151] It should be noted that the process of executing the register model generation step for the previous register does not affect the line-by-line matching of the register description file. During the execution of steps S67 and S68, the line-by-line matching of the register description file can be performed synchronously to improve processing efficiency.

[0152] Step S69, formatting the register attribute information of each specified type corresponding to the last register that has been classified and stored according to the register model syntax format and then outputting it to generate a register model of the last register.

[0153] In the process of cyclically matching each line of the register description file as described above, when the last line of the register description file is matched, the register attribute information of the specified type of the last register described in the register description file is extracted. At this time, the register models of other registers have been generated, and the next new register will not appear. Different from the processing method described in steps S67 and S68, this embodiment can directly format all the register attribute information of the specified type corresponding to the last register stored in each array classification after matching the last line, and then output it to directly generate the register model of the last register. The implementation process is similar to that of this application and will not be described in detail.

[0154] In some embodiments, the register attribute information of each specified type described above can be converted into a corresponding hash value and then stored, that is, classified storage is performed using a hash array method to speed up storage and reduce storage resource consumption, and the hash query method can be used to quickly find the required register attribute information in a short time, which greatly improves the reading efficiency and reliability of the stored content. Therefore, in the process of line-by-line matching of the register description file, each matched register attribute information of a specified type can be hashed separately, and after obtaining the hash value corresponding to the specified type, the hash value corresponding to each specified type is stored in an array data structure, that is, the hash value obtained is used to update the hash array of the corresponding specified type register attribute information, so that the updated hash array contains the hash value of the corresponding specified type register attribute information of the currently matched register, and the present application does not limit its update storage implementation method.

[0155] In practical applications, since a register of a chip to be verified can be configured with one domain or multiple domains, each register domain can include one bit or multiple bits, and different domains of this register can represent different functions designed for the register, for example, some domains may be read-only (RO), some domains may be write-only (WO), and other domains may be readable and writable (RW), etc., which can be determined according to design requirements. This application does not limit the number of domains configured in each register and the number of bits in each domain, which can be determined according to the actual situation.

[0156] Based on this, in the process of extracting register attribute information of each specified type of each register, for multiple domain attribute information such as the register domain name information, register domain starting bit information, register domain size information, register domain access attribute information, and register domain reset value information listed above, it is necessary to extract these relevant domain attribute information of each domain of each register design. Since the domain attribute information is usually not directly described in the register description file, the description of each domain range information in a register needs to be calculated to determine the content of these domain attribute information required by this application.

[0157] Therefore, in the process of extracting the register description file line by line, the register domain range information is extracted, that is, the range information of a domain in a register. Based on the register domain range information, the number of bits contained in the corresponding register domain can be determined. If the number of bits is one bit, the register domain belongs to a single-bit domain, the starting bit in the register domain range information can be extracted, and the corresponding register domain size can be configured as 1. If the number of bits is multiple bits, it means that the register domain is a multiple-bit domain, the minimum boundary value of the register domain range information can be determined as the starting bit of the corresponding register domain, and the change amount of the register domain range information (that is, the difference between the maximum boundary value and the minimum boundary value of the register domain range information plus 1) can be configured as the corresponding register domain size.

[0158] It can be seen that for each register domain range information of each register given from the register description file, it matches the register domain start bit information and the register domain size information of two specified types of register attribute information. In the method described in the above embodiment, according to the register model generation requirements of the chip verification platform, after directly extracting the register domain range information matching the two specified types of register attribute information from the register description file, it is necessary to further determine the register domain start bit information and the register domain size information according to the method described above, but not limited to the method described above, and then classify and store them, so that when entering the next new register match, the domain attribute information of the corresponding specified type of each domain of the currently matched register will be stored in the array corresponding to each domain attribute information, such as field_name_array can store the domain name information of each domain of the register; field_start_bit_array can store the domain start bit information of each domain of the register; field_size_array can store the domain size information of each domain of the register, etc. Compared with directly storing the register domain range information, the classified storage method proposed in the embodiment of the present application records the storage content more intuitively for subsequent direct use to generate the register model.

[0159] Based on the register model generation method for a chip verification platform described in the above embodiments, in order to enrich the functions of the generated register model, the present application can, based on actual specified business needs, format the corresponding business information according to the register model syntax format during the process of formatting and outputting the register attribute information of each specified type corresponding to the corresponding register, so that the generated register model of the corresponding register itself can realize the specified business.

[0160] Optionally, the above-mentioned designated business may include a first business for building a register function coverage model, and at least one of a second business for implementing a register backdoor access function. Among them, the register function coverage model can be a measurement method for verifying whether the corresponding register and its configuration mode are fully tested. In the UVM verification platform, the register function coverage model can automatically collect information such as read and write operations and domain value changes of the corresponding register to ensure that each functional point of the register design is covered by the test, thereby improving the integrity and efficiency of the verification. The statistical implementation method of the register function coverage is not described in detail in this application.

[0161] The above-mentioned register backdoor access function can be an important feature of the register model used for the UVM verification platform, allowing verification engineers to directly access and modify the register values ​​inside the DUT (Device Under Test) without going through bus transactions, consuming simulation time and bus resources, and being able to directly read and write registers or register fields without being affected by bus timing functions, thereby improving operational flexibility and access efficiency.

[0162] According to the above analysis, the present application can obtain the service information for implementing the specified service; the specified service can be at least one of the first service and the second service. In this way, in the process of formatting and outputting the classified stored register attribute information, Figure 4 As shown, the business information can be formatted and outputted according to the above register model syntax format, so that the register model of the corresponding register generated for the chip verification platform can realize the specified business, that is, one or more of the function coverage model and the backdoor access function are added to the register model to improve the subsequent verification efficiency. Among them, the specified businesses realized by different register models can be the same or different, which can be flexibly determined according to the situation.

[0163] It should be noted that the register model generation method for the chip verification platform proposed in this application is applicable to electronic devices that support multiple operating systems. In practical applications, based on Python scripts and Perl scripts, the method can be run in electronic devices with different operating systems, does not rely on electronic devices with specific hardware or operating systems, supports cross-platform operation, and can be flexibly used in different development environments, ensuring that the chip development process is not restricted by the operating system.

[0164] Moreover, the present application can use virtualization technology to deploy the system that implements the register model generation method for the chip verification platform proposed in the present application on a cloud server or a local server, so that the method can run in a variety of hardware environments without relying on a specific hardware platform, further improving the flexibility and scalability of the method implementation.

[0165] A register model generation method for a chip verification platform provided in an embodiment of the present application is introduced above. A device for executing the register model generation method for a chip verification platform will be introduced below.

[0166] Reference Figure 7 , is a schematic diagram of a structure of a register model generation device for a chip verification platform provided in an embodiment of the present application. Figure 7 As shown, the register model generation device for a chip verification platform may include:

[0167] An acquisition module 71 is used to acquire a register description file; the register description file is determined for the register of the design to be verified on the chip;

[0168] A classification storage module 72 is used to classify and store each specified type of register attribute information contained in the register description file; one register corresponds to each specified type of register attribute information;

[0169] The generation module 73 is used to format and output the classified and stored register attribute information of each specified type according to the register model syntax format of the chip verification platform, so as to generate a register model of the corresponding register for the chip verification platform.

[0170] In some embodiments, the classification storage module 72 may include:

[0171] A classification storage unit, used for extracting register attribute information corresponding to a specified type from the register description file for classification storage based on the register model generation requirements of the chip verification platform;

[0172] Among them, if the register attribute information of each specified type of any of the registers has been classified and stored, during the execution process of the classification storage module 72 classifying and storing the register attribute information of each specified type contained in the register description file, the generation module 73 can directly execute the register model generation step of the register, that is, according to the register model syntax format of the chip verification platform, the register attribute information of each specified type corresponding to the classified and stored register is formatted and output, so as to generate a register model of the register for the chip verification platform.

[0173] In a possible implementation, the classification storage unit may include:

[0174] A first line-by-line matching unit is used to match the register description file line by line based on the register model generation requirement of the chip verification platform to obtain register attribute information matching each specified type for the same register;

[0175] The first storage unit is used to store each of the register attribute information of the specified type in an array data structure.

[0176] In a possible implementation, the classification storage unit may include:

[0177] An information collection function acquisition unit, used to acquire multiple information collection functions required to generate a register model based on a chip verification platform; different information collection functions are used to collect register attribute information of different specified types;

[0178] The second storage unit is used to call the multiple information collection functions to extract register attribute information of corresponding specified types from the register description file for classified storage.

[0179] In some embodiments, the generation module 73 may include:

[0180] A register attribute information determining unit, configured to determine the register attribute information of a specified type extracted from a new register during the process of extracting the register attribute information of each register from the register description file;

[0181] A first formatting processing unit is used for formatting and outputting the register attribute information of each specified type of the previous register that has been classified and stored in accordance with the register model syntax format of the chip verification platform during the process of extracting the register attribute information of each register one by one from the register description file, so as to generate a register model of the previous register;

[0182] The second formatting processing unit is used to determine the completion of the classified storage of the register attribute information of each specified type contained in the register description file, and format the register attribute information of each specified type of the last register that has been classified and stored according to the register model syntax format, and then output it to generate the register model of the last register.

[0183] Optionally, the register attribute information determining unit may include:

[0184] A first acquisition unit, used to extract register address information from the register description file, and acquire current address information of the register tag variable;

[0185] The first updating unit is used to determine that the register address information does not match the current address information, use the register address information to update the register tag variable, trigger the first formatting processing unit to format the register attribute information of each specified type of the previous register that has been classified and stored according to the register model syntax format of the chip verification platform, and then output it to generate a register model of the previous register.

[0186] In some embodiments, the classification storage unit may include:

[0187] A register domain range information extraction unit, used for extracting register domain range information;

[0188] A bit number determination unit, used to determine the number of bits contained in the corresponding register domain based on the register domain range information;

[0189] A first configuration unit is used for extracting the starting bit in the register domain range information if the bit number is one bit, and configuring the corresponding register domain size to 1;

[0190] The second configuration unit is used to determine the minimum boundary value of the register domain range information as the starting bit of the corresponding register domain if the bit number is multiple bits, and configure the change amount of the register domain range information as the corresponding register domain size.

[0191] In a possible implementation, the first storage unit may include:

[0192] A hash calculation unit, used to perform hash calculations on register attribute information of each specified type to obtain a hash value corresponding to the specified type;

[0193] The hash value storage unit is used to store the hash values ​​corresponding to each of the specified types in an array data structure.

[0194] Based on the above analysis, the above equipment may also include:

[0195] A service information acquisition module, used to acquire service information for implementing a specified service; the specified service includes at least one of a first service for building a register function coverage model and a second service for implementing a register backdoor access function;

[0196] A designated business processing module is used to format and output the business information according to the register model syntax format during the process of formatting and outputting the classified stored register attribute information, so that the register model corresponding to the register generated for the chip verification platform can realize the designated business.

[0197] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any register model generation method for a chip verification platform provided in the embodiment of the present application.

[0198] Wherein, the computer program product may include one or more computer program instructions. When the computer program instructions are loaded and executed on the electronic device, the process or function described in the embodiment of the present application is generated in whole or in part. The electronic device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center.

[0199] Reference Figure 8 , is a hardware structure diagram of an electronic device applicable to the register model generation method for a chip verification platform proposed in this application. The electronic device can be a chip test device, such as a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop, a netbook, a robot or a business terminal, or one or more physical servers, or a cloud server supporting cloud computing, etc. Figure 8 As shown, the electronic device may include but is not limited to: at least one memory 81 and at least one processor 82, wherein:

[0200] At least one memory 81 and at least one processor 82 can communicate with each other via a bus. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one bidirectional line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0201] The memory 81 can be used to store a computer program that implements the register model generation method for a chip verification platform proposed in an embodiment of the present application; the processor 82 can load and execute the computer program stored in the memory 81 to implement the various steps of the register model generation method for a chip verification platform proposed in an embodiment of the present application. The implementation process can refer to the description of the corresponding part of the method embodiment above.

[0202] In the embodiment of the present application, the memory 81 may include, but is not limited to, random access memory (RAM), read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), etc. The processor 82 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), a digital signal processor (DSP), an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA).

[0203] In combination with the description of the above embodiment, the electronic device can also be used to realize the communication element of the communication connection between the electronic device and other devices. In a possible implementation, the communication element may include a communication element corresponding to the wireless communication mode such as supporting wifi, Bluetooth, 5G / 6G and other mobile communications, so as to realize wireless communication with other servers, terminals and other devices, receive the register description file sent by the designer through the wireless network, and send the register model output after the final format processing to the device deploying the chip verification platform to realize chip verification. Of course, in order to realize the data transmission between the components inside the electronic device, the communication element may also include one or more interfaces supporting wired communication mode, such as general-purpose input / output (GPIO) interface, USB interface, universal asynchronous receiver / transmitter (UART) interface, etc. This application does not limit the composition structure of the communication element to realize this function and its corresponding communication transmission mechanism, which can be determined according to the circumstances.

[0204] It should be understood that Figure 8 The structure of the electronic device shown does not constitute a limitation on the electronic device in the embodiment of the present application. In practical applications, the electronic device may include Figure 8 More or fewer components as shown, or a combination of certain components, especially when the electronic device is a terminal, may also include a microphone (which can collect user input of a target model training task creation request, etc.), a speaker, a display, various sensors, antennas, a power module, a radio frequency component, an external port and other input / output components, etc., which can be determined according to the processing function requirements, and this application does not give detailed examples one by one.

[0205] In the implementation process of the register model generation method for the chip verification platform described in the above embodiment, Fig. 9 As shown, the electronic device can use the register description file provided by the chip designer, and according to the register model generation method for the chip verification platform described in the above method embodiment, efficiently and reliably generate the register model of each register of the designed chip, and integrate it into the chip verification platform. Taking the UVM verification platform as an example, data can be transmitted through the interface between it and the DTU to flexibly realize the verification of each function of the chip. The chip function verification process is not described in detail in this application. Among them, the interface can be determined according to the communication type supported by the designed chip, such as Ethernet interface, etc. This application is for Fig. 9 There are no restrictions on the interface type and the communication mechanisms it supports.

[0206] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer program instructions. When the one or more computer program instructions are executed by an electronic device, the electronic device can implement any register model generation method for a chip verification platform provided in an embodiment of the present application.

[0207] The computer-readable storage medium may be any available medium that can be stored in an electronic device or a data storage device such as a training device or a data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0208] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0209] Through the description of the above implementation methods, in the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, disk or optical disk, etc., including several instructions for an electronic device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0210] In this specification, each embodiment is described in a progressive or parallel manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

Claims

1. A register model generation method for a chip verification platform, the method comprising: Obtain a register description file; the register description file is determined for the register of the design to be verified on the chip; Classify and store each specified type of register attribute information contained in the register description file; one register corresponds to each specified type of register attribute information; According to the register model syntax format of the chip verification platform, format the register attribute information of each specified type that has been classified and stored, and then output it to generate a register model of the corresponding register for the chip verification platform; The method further comprises: formatting and outputting the register attribute information of each specified type that has been classified and stored according to the register model syntax format of the chip verification platform to generate a register model of the corresponding register of the chip verification platform, including: According to the register model syntax format of the chip verification platform, the register attribute information of each specified type of a register stored in each classification is formatted and then outputted to generate a register model of the register; or, the register attribute information of each specified type of multiple registers stored in the classification is formatted and then outputted in parallel to simultaneously generate multiple corresponding register models; Each of the register models is integrated into the chip verification platform to implement functional verification of the design to be verified on the chip.

2. The method according to claim 1, wherein the register attribute information of each specified type contained in the register description file is classified and stored, comprising: Based on the register model generation requirements of the chip verification platform, extracting register attribute information corresponding to a specified type from the register description file for classified storage; Wherein, if the register attribute information of each specified type of any of the registers has been classified and stored, in the execution process of the step of classifying and storing the register attribute information of each specified type contained in the register description file, the register model generation step of the register is executed: According to the register model syntax format of the chip verification platform, the register attribute information of each specified type corresponding to the classified and stored register is formatted and outputted to generate a register model of the register for the chip verification platform.

3. The method according to claim 2, wherein the register model generation requirement based on the chip verification platform extracts register attribute information of a corresponding specified type from the register description file for classified storage, comprising: Based on the register model generation requirements of the chip verification platform, the register description file is matched line by line to obtain register attribute information of each specified type matched to the same register; The register attribute information of each specified type is stored in an array data structure.

4. The method according to claim 2, wherein the register model generation requirement based on the chip verification platform extracts register attribute information of a specified type from the register description file for classified storage, comprising: Acquire multiple information collection functions required by register model generation based on a chip verification platform; Different information collection functions are used to collect register attribute information of different specified types respectively; The plurality of information collection functions are called to extract register attribute information of corresponding specified types from the register description file for classified storage.

5. The method according to any one of claims 2 to 4, wherein formatting the classified and stored register attribute information of each specified type is outputted according to the register model syntax format of the chip verification platform to generate a register model for the corresponding register of the chip verification platform, comprising: In the process of extracting register attribute information of each register in the register description file, determining to extract register attribute information of a specified type of a new register; In the process of extracting register attribute information of each register from the register description file, formatting the register attribute information of each specified type of the previous register that has been classified and stored is output according to the register model syntax format of the chip verification platform to generate a register model of the previous register; Determine that the classified storage of the register attribute information of each specified type contained in the register description file is completed, and format the register attribute information of each specified type of the last register that has been classified and stored according to the register model syntax format and then output it to generate a register model of the last register.

6. The method according to claim 5, wherein the step of determining to extract register attribute information of a specified type of the new register comprises: Extract register address information from the register description file to obtain current address information of the register tag variable; Determine that the register address information does not match the current address information, use the register address information to update the register tag variable, and execute the step of formatting and outputting the register attribute information of each specified type of the previous register that has been classified and stored according to the register model syntax format of the chip verification platform to generate a register model of the previous register.

7. The method according to any one of claims 2 to 4, wherein extracting register attribute information corresponding to a specified type comprises: Extract register domain range information; Based on the register domain range information, determining the number of bits included in the corresponding register domain; If the bit number is one bit, extract the starting bit in the register domain range information, and configure the corresponding register domain size to 1; If the bit number is multiple bits, the minimum boundary value of the register domain range information is determined as the starting bit of the corresponding register domain, and the change amount of the register domain range information is configured as the corresponding register domain size.

8. The method according to claim 3, wherein storing the register attribute information of each specified type in an array data structure comprises: Performing hash calculations on register attribute information of each specified type respectively to obtain hash values ​​corresponding to the specified type; The hash values ​​corresponding to the respective specified types are stored in array data structures respectively.

9. The method according to any one of claims 1 to 4, further comprising: Acquire service information for implementing a specified service; the specified service includes at least one of a first service for building a register function coverage model and a second service for implementing a register backdoor access function; In the process of formatting and outputting the classified and stored register attribute information, the business information is formatted and output according to the register model syntax format, so that the register model corresponding to the register generated for the chip verification platform can realize the specified business.

10. A register model generation device for a chip verification platform, the device comprising: An acquisition module is used to acquire a register description file; the register description file is determined for the register of the design to be verified on the chip; A classification storage module, used for classifying and storing register attribute information of each specified type contained in the register description file; One of the registers corresponds to each of the specified types of register attribute information; A generating module, used for formatting and outputting the classified and stored register attribute information of each specified type according to the register model syntax format of the chip verification platform, so as to generate a register model of the corresponding register for the chip verification platform; Wherein, the generation module is specifically used for: According to the register model syntax format of the chip verification platform, the register attribute information of each specified type of a register stored in each classification is formatted and then outputted to generate a register model of the register; or, the register attribute information of each specified type of multiple registers stored in the classification is formatted and then outputted in parallel to simultaneously generate multiple corresponding register models; Each of the register models is integrated into the chip verification platform to implement functional verification of the design to be verified on the chip.

Images