Bitstream verification method, device, equipment and medium for HardIP

Abstract

The present invention relates to the field of chip testing technology, and discloses a bitstream verification method, device, equipment and medium for HardIP, the method comprising: obtaining parameter types and parameter constraints of the HardIP to be tested; generating an RTL file set based on the parameter types and parameter constraints, wherein the RTL file set includes a plurality of RTL files; obtaining a bitstream file and a reference file based on the RTL file, wherein the bitstream file is generated by EDA software, and the reference file is generated based on the RTL parameters in the RTL file; comparing the bitstream file and the reference file, and obtaining a bitstream verification result based on the comparison result. The present invention can reduce the computing resources required for HardIP bitstream verification.

Description

Technical Field

[0001] The present invention relates to the technical field of chip testing, and in particular to a bit stream verification method, device, equipment and medium for HardIP. Background Art

[0002] HardIP (hardware intellectual property) is a verified design layout that has been optimized through layout and routing under a specific process. Designers cannot modify it. To ensure that the EDA (Electronic Design Automation) software can generate a bitstream file that supports hardware functions, the bitstream of HardIP needs to be verified.

[0003] In the related art, the bitstream verification of HardIP is mainly performed by building a simulation environment. However, HardIP has many parameters and complex functions to implement. The simulation environment is difficult to build and requires a lot of computing resources and time.

[0004] In view of this, a bitstream verification method for HardIP that requires less computing resources is needed. Summary of the invention

[0005] In view of this, the present invention provides a method, apparatus, device and medium for HardIP bitstream verification to reduce the computing resources required for HardIP bitstream verification.

[0006] In a first aspect, the present invention provides a bitstream verification method for HardIP, which obtains parameter types and parameter constraints of a HardIP to be tested; generates an RTL file set based on the parameter types and parameter constraints, wherein the RTL file set includes several RTL files; obtains a bitstream file and a reference file based on the RTL file, wherein the bitstream file is generated by EDA software and the reference file is generated based on the RTL parameters in the RTL file; compares the bitstream file and the reference file, and obtains a bitstream verification result based on the comparison result.

[0007] In this embodiment, by parsing the parameter type and parameter constraint conditions of the HardIP to be tested, the RTL files of multiple groups of test cases are automatically generated. The problem of lack of specific RTL files due to the large number of HardIP parameters and complex functions can be solved. A reference file is generated based on the parameters of the RTL file, and a bitstream file is obtained based on the running result of the RTL file running by the EDA software. By comparing the consistency of the reference file and the bitstream file, the HardIP to be tested can be quickly verified, thereby ensuring the accuracy of the HardIP configuration.

[0008] In an optional implementation, the parameter type includes at least one of the original name of the parameter, the module name in the RTL file, the bit width of the parameter, and the possible values ​​of the parameter.

[0009] In this implementation, the problem of difficulty in covering the HardIP solution space can be solved by limiting the parameter types.

[0010] In an optional implementation, generating an RTL file set based on parameter types and parameter constraints includes: generating several groups of test parameters of the HardIP to be tested based on the parameter types and parameter constraints; generating an RTL file based on one of the several groups of test parameters; and constructing an RTL file set including several RTL files.

[0011] In this embodiment, multiple groups of valid parameters to be tested are generated through parameter types and constraints of the parameters to be tested, and corresponding RTL files are generated, which can improve the test coverage. At the same time, automatic generation of parameters to be tested can also improve the efficiency of test case preparation.

[0012] In an optional implementation, based on parameter types and parameter constraints, generating several groups of test parameters for the HardIP to be tested includes: obtaining a set of possible values ​​for the parameters to be tested, wherein the possible values ​​in the possible value set satisfy the parameter constraints; obtaining a weight set, wherein the parameters in the weight set correspond one-to-one to the possible values ​​in the possible value set; and selecting several groups of parameters to be tested, wherein the values ​​of the parameters to be tested are selected based on the weights corresponding to the possible values ​​in the possible value set.

[0013] In this embodiment, by adding a weight mechanism and generating parameters to be tested that meet the conditions, the coverage of the HardIP solution space can be improved. It is also possible to assign higher weights to key parameter values ​​according to the actual application scenarios of the HardIP to be tested, ensuring that important parts of the HardIP to be tested are fully tested.

[0014] In an optional embodiment, based on the RTL file, obtaining the bitstream file includes: generating an initial bitstream file, wherein the initial bitstream file is generated by running the RTL file through EDA software; extracting the bitstream to be tested in the initial bitstream file, wherein the bitstream to be tested is obtained based on the coordinate information of the HardIP to be tested; based on the bitstream to be tested, obtaining the bitstream file.

[0015] In this embodiment, the RTL file is run through the EDA software to generate an initial bitstream file, and then the HardIP bitstream to be tested is extracted from the initial bitstream file to obtain the final bitstream file. The efficiency and quality of design verification can be improved. The bitstream to be tested is extracted through coordinate information, which has high flexibility and applicability.

[0016] In an optional embodiment, obtaining a reference file includes: extracting RTL parameters in the RTL file, wherein the RTL parameters include RTL parameter names and RTL parameter values; obtaining hardware parameter names corresponding to the RTL parameter names, and updating the RTL parameter names in the RTL parameters; and generating a reference file based on the updated RTL parameters.

[0017] In this embodiment, the reference file is generated by extracting and modifying the parameters of the RTL file, which can ensure the consistency between the reference file and the bitstream file and avoid errors in the bitstream verification result caused by inconsistent parameter names.

[0018] In an optional implementation, comparing the bitstream file with the reference file and obtaining the bitstream verification result based on the comparison result includes: comparing the storage data of the bitstream file with the reference file; and generating the bitstream verification result of the HardIP to be tested based on the storage data comparison result.

[0019] In this embodiment, by comparing the stored data to obtain the bit stream verification result of the HardIP to be tested, the accuracy of the data can be guaranteed. By storing the data comparison result, the data with problems can also be accurately located to facilitate subsequent maintenance.

[0020] In a second aspect, the present invention provides a bitstream verification device for HardIP, the device comprising: an acquisition module, used to obtain parameter types and parameter constraints of the HardIP to be tested; an RTL generation module, used to generate an RTL file set based on the parameter types and parameter constraints, wherein the RTL file set includes several RTL files; a file generation module, used to obtain a bitstream file and a reference file based on the RTL file, wherein the bitstream file is generated by EDA software, and the reference file is generated based on the RTL parameters in the RTL file; an output module, used to compare the bitstream file and the reference file, and obtain a bitstream verification result based on the comparison result.

[0021] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the bitstream verification method for HardIP of the above-mentioned first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0022] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the bitstream verification method for HardIP of the above-mentioned first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0024] Figure 1 is a flow chart of a bit stream verification method for HardIP according to an embodiment of the present invention;

[0025] Figure 2 is a flow chart of another bit stream verification method for HardIP according to an embodiment of the present invention;

[0026] Figure 3 is a flow chart of another bit stream verification method for HardIP according to an embodiment of the present invention;

[0027] Figure 4 is a flow chart of another bit stream verification method for HardIP according to an embodiment of the present invention;

[0028] Figure 5 is a structural block diagram of a bit stream verification device for HardIP according to an embodiment of the present invention;

[0029] Figure 6 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0031] HardIP (hardware intellectual property) is one of the most complex functional modules in the chip, including EMAC (Ethernet MAC controller module), PCIE (PCI Express), etc. Since HardIP contains many parameters and complex functions, simulation takes a long time, requires large computing resources, and is difficult to build a simulation environment. Due to the limitation of hardware resources, it is often impossible to fully simulate HardIP, so it is difficult to implement solutions to verify the bit stream of HardIP and obtain the functional implementation status through simulation. If the board test is directly carried out without verification, it will greatly increase the time cost of locating and correcting the problem.

[0032] Therefore, during the bitstream verification phase, the bitstream status of HardIP needs to be verified.

[0033] The purpose of bitstream verification is to verify through simulation whether the specific functions of the binary bitstream file generated by the EDA software are correct, and to ensure that the software can correctly generate the bitstream file that is expected to support the relevant hardware functions.

[0034] The embodiment of the present invention provides a bitstream verification method for HardIP, which automatically generates RTL files of multiple groups of test cases by parsing the parameter types and parameter constraints of the HardIP to be tested, and obtains bitstream files and reference files based on the RTL files, wherein the bitstream file is obtained by extracting the bitstream to be tested generated by running the RTL file by EDA software, the bitstream to be tested represents the bitstream corresponding to the coordinate information of the HardIP to be tested, and the reference file is generated according to the parameter configuration of the RTL file. By comparing the consistency of the bitstream file and the reference file, the bitstream verification result of the HardIP to be tested is obtained. While solving the problem of HardIP with many parameters and complex functions, the accuracy of HardIP configuration can be ensured, and the rapid verification of HardIP can be achieved.

[0035] According to an embodiment of the present invention, an embodiment of a bitstream verification method for HardIP is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0036] In this embodiment, a bit stream verification method for HardIP is provided. Figure 1 is a flow chart of a bit stream verification method for HardIP according to an embodiment of the present invention, such as Figure 1 As shown, the process includes the following steps:

[0037] Step S101, obtaining the parameter type and parameter constraint conditions of the HardIP to be tested.

[0038] Among them, the parameter types and constraint conditions of the HardIP to be tested are not restricted. The configurable parameters, parameter types, default values, value ranges, etc. of the HardIP to be tested can be obtained by consulting the technical manual of the HardIP to be tested. The data type, constraint range, etc. of each parameter can also be obtained through the configuration interface of some EDA software. Parameter types can include timing parameters, performance parameters, etc. Parameter constraint conditions can include parameter mapping relationships, parameter storage methods, etc.

[0039] Step S102: Generate an RTL file set based on the parameter type and the parameter constraint condition, wherein the RTL file set includes a plurality of RTL files.

[0040] Among them, it is necessary to first generate a set of specific parameters based on the parameter type and parameter constraints, and then generate the corresponding RTL file based on the specific parameters. The generation method of the RTL file is not restricted, and it can be directly coded or use some code generation tools. It is also possible to perform targeted tests on the parameters of the HardIP to be tested according to the actual situation.

[0041] When the HardIP to be tested has a clear application scenario, the parameters and parameter values ​​used are relatively fixed. Only some parameters need to be selected for setting, and the remaining parameters use the default configuration values. When the HardIP to be tested has parameter types that need to be tested, the parameter values ​​of these parameter types can be adjusted to obtain a more test-targeted RTL file. In the absence of special test requirements, all parameters can be randomly set to generate RTL files.

[0042] In practical applications, the possible values ​​of a parameter generally exist in two cases: discrete data and continuous data. In the case where the possible values ​​of a parameter are discrete data, the possible values ​​of the parameter are generally fixed values, such as the possible values ​​of parameter A are 1'b0 or 1'b1. Among them, 1'b0 represents a single bit with a binary value of 0, and 1'b1 represents a single bit with a binary value of 1.

[0043] When the parameter value is continuous data, the parameter value is a certain range. When selecting the value, you can focus on selecting the boundary value and then randomly generate several values ​​within the range. For example, if the parameter B value range is 3'b000 to 3'b100, the parameter B value can be set to 3'b000, 3'b100, 3'b010, 3'b001, etc. Among them, 3'b000 represents a three-digit binary number, and the decimal value is 0; 3'b100 represents a three-digit binary number, and the decimal value is 4; 3'b010 represents a three-digit binary number, and the decimal value is 2; 3'b001 represents a three-digit binary number, and the decimal value is 1.

[0044] When there are constraints between different parameters, the constraints can be set as a mapping relationship. In an actual application, when parameter C is set to 1'b0, the value of parameter D must be 1'b1, then parameter D: 1'b1 can be mapped to parameter C: 1'b0. That is, when parameter C is a single bit with a binary value of 0, parameter D must be a single bit with a binary value of 1. When such a mapping relationship is met, the generated set of parameters and the RTL file corresponding to this set of parameters are valid.

[0045] Step S103, based on the RTL file, a bitstream file and a reference file are obtained, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file.

[0046] The reference file can directly refer to the parameter names and parameter arrangements in the technical document of the HardIP to be tested according to the RTL parameters in the RTL file, and output a reference file corresponding to the parameter arrangement in the technical document.

[0047] There is no restriction on how to obtain the bitstream file. You can use some chip development tools to analyze the RTL file, obtain the integrated netlist corresponding to the RTL file, and then map the generated integrated netlist to the specific logic resources of the chip to generate the bitstream file. The bitstream file is a file containing chip configuration information. The names and positions of each parameter in the bitstream file and the reference file are one-to-one corresponding.

[0048] Step S104: compare the bitstream file with the reference file, and obtain a bitstream verification result based on the comparison result.

[0049] Among them, the parameter types included in the bitstream file and the reference file are consistent. You only need to compare the values ​​of each parameter in the bitstream file and the reference file. If the values ​​are exactly the same, it means that the bitstream of the HardIP to be tested is correct. If the values ​​are different, it means that there is a problem with the bitstream of the HardIP to be tested. According to the reference file, you can quickly determine the parameter values ​​with problems and the problem parameter names corresponding to the problem parameter values, so as to quickly locate the module with problems in the HardIP to be tested.

[0050] In practical applications, the bitstream file and the reference file obtained in step S103 are arranged in the format given in the technical documentation of the HardIP to be tested, and the parameters represented in each position are the same. By using an automatic comparison tool to compare whether the data of the two files are completely consistent, the bitstream verification result of the HardIP to be tested can be obtained. In the case of inconsistent data, the line number of the inconsistent data is obtained, and the problematic bitstream of the HardIP to be tested can be located according to the reference file, which is convenient for subsequent staff to make corrections.

[0051] The bitstream verification method for HardIP provided in this embodiment can automatically generate RTL files for multiple groups of test cases by parsing the parameter types and parameter constraints of the HardIP to be tested, thereby solving the problem of lack of specific RTL files due to the large number of parameters and complex functions of HardIP. A reference file is generated based on the parameters of the RTL file, and a bitstream file is obtained based on the running result of the RTL file running by the EDA software. By comparing the consistency of the reference file and the bitstream file, rapid verification of the HardIP to be tested is achieved, thereby ensuring the accuracy of the HardIP configuration.

[0052] In this embodiment, a bit stream verification method for HardIP is provided. Figure 2 is a flow chart of a bit stream verification method for HardIP according to an embodiment of the present invention, such as Figure 2 As shown, the process includes the following steps:

[0053] Step S201, obtaining the parameter type and parameter constraint conditions of the HardIP to be tested.

[0054] In some optional implementations, the parameter type includes at least one of the original name of the parameter, the module name in the RTL file, the parameter bit width, and the possible values ​​of the parameter.

[0055] By restricting the parameter types, the problem of difficulty in covering the HardIP solution space can be solved.

[0056] Step S202: Generate an RTL file set based on the parameter type and the parameter constraint condition, wherein the RTL file set includes a plurality of RTL files.

[0057] Specifically, the above step S202 includes:

[0058] Step S2021, based on parameter types and parameter constraints, generate several groups of test parameters of the HardIP to be tested.

[0059] After a set of parameters to be tested is generated, it can be stored in a data table in csv format, where each row represents a parameter. When a corresponding RTL file is subsequently generated based on the set of parameters to be tested, the parameters can be directly obtained from the data table.

[0060] In some optional implementations, the above step S2021 includes:

[0061] Step a1, obtaining a set of possible values ​​of the parameter to be tested, wherein the possible values ​​in the set of possible values ​​satisfy the parameter constraint condition.

[0062] The method of obtaining the possible value set is not limited. The possible value range of the parameter to be tested can be obtained through the technical documentation of the HardIP to be tested, and then a possible value set containing all possible values ​​of the parameter to be tested is constructed based on the possible value range. Different types of parameters to be tested have different possible values.

[0063] Step a2, obtaining a weight set, wherein the parameters in the weight set correspond one-to-one to the possible values ​​in the possible value set.

[0064] Among them, higher weights can be set for boundary values ​​and special values ​​within the range of possible values. The parameters in the weight set can be adjusted dynamically. After generating a set of valid parameters to be tested, the weights of the corresponding parameter values ​​to be tested in the possible value set can be appropriately reduced to cover the solution space as much as possible.

[0065] Step a3, selecting several groups of parameters to be tested, wherein the values ​​of the parameters to be tested are selected based on the weights corresponding to the possible values ​​in the possible value set.

[0066] There is no restriction on the selection method of the parameter to be tested. The possible values ​​can be determined by weight distribution, and the probability of being selected is calculated based on the weight corresponding to the possible value, and the possible value of the parameter to be tested is selected according to the probability.

[0067] In practical applications, for any parameter E to be tested, its possible value set can be V = (V1, V2, ..., V n ), whose initial weight set is W = (W1, W2, ..., W n ). Then for any possible value V of the parameter E to be tested i The probability of being selected is

[0068] After generating a set of parameters to be tested, it is also necessary to verify whether the set of parameters to be tested is valid according to the parameter constraints. This is to facilitate the subsequent generation of the correct RTL file. In an actual application, the possible values ​​of parameter A and parameter B are both 1'b0 and 1'b1. The mapping relationship is similar to the following: B: 1'b1 maps to A: 1'b0. That is, when parameter A is a single bit with a binary value of 0, parameter B must be a single bit with a binary value of 1. Obviously, when parameter A takes the value of 1'b0 and parameter B takes the value of 1'b0, that is, parameter A and parameter B are both single bits with a binary value of 0. If the value of parameter B does not satisfy the parameter constraint relationship, the set of parameters to be tested is deemed invalid. Parameter B needs to reselect the value until the constraint is met before it can be used as a valid set of parameters to be tested.

[0069] By adding a weight mechanism and generating parameter values ​​that meet the conditions, the coverage of the HardIP solution space can be improved. It is also possible to assign higher weights to key parameters based on the actual application scenarios of the HardIP to be tested to ensure that important parts are fully tested.

[0070] Step S2022: Generate an RTL file based on one of the groups of parameters to be tested.

[0071] Among them, the code can be written through programming software according to a set of parameters to be tested, and after the code is simulated, the simulation result is saved as an RTL file.

[0072] Step S2023, constructing an RTL file set including a plurality of RTL files.

[0073] Among them, all generated RTL files can be included in the RTL file set to improve the accuracy and reliability of bitstream verification. Some RTL files can also be selected to be included in the RTL file set according to test requirements to improve the efficiency of bitstream verification.

[0074] Step S203, based on the RTL file, a bitstream file and a reference file are obtained, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file.

[0075] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0076] Step S204: compare the bitstream file with the reference file, and obtain a bitstream verification result based on the comparison result.

[0077] For details, please see Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

[0078] The bitstream verification method for HardIP provided in this embodiment generates multiple groups of valid parameters to be tested through parameter types and constraints of the parameters to be tested, and generates corresponding RTL files, which can improve the test coverage. At the same time, the automatic generation of parameters to be tested can also improve the efficiency of test case preparation.

[0079] In this embodiment, a bit stream verification method for HardIP is provided. Figure 3 is a flow chart of a bit stream verification method for HardIP according to an embodiment of the present invention, such as Figure 3 As shown, the process includes the following steps:

[0080] Step S301, obtaining the parameter type and parameter constraint conditions of the HardIP to be tested.

[0081] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0082] Step S302: Generate an RTL file set based on the parameter type and the parameter constraint condition, wherein the RTL file set includes a plurality of RTL files.

[0083] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0084] Step S303, based on the RTL file, a bitstream file and a reference file are obtained, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file.

[0085] Specifically, the above step S303 includes:

[0086] Step S3031, generating an initial bitstream file, wherein the initial bitstream file is generated by running the RTL file through EDA software.

[0087] The initial bitstream file is a file containing complete bitstream information and can be directly downloaded to the FPGA to complete the hardware configuration.

[0088] Step S3032: extracting the bit stream to be tested from the initial bit stream file, wherein the bit stream to be tested is obtained based on the coordinate information of the HardIP to be tested.

[0089] The coordinate information can be obtained from the technical document of the HardIP to be tested. The specified bit stream information is extracted from the initial bit stream file as the bit stream to be tested.

[0090] Step S3033: obtaining a bit stream file based on the bit stream to be tested.

[0091] The bit stream to be tested can be arranged according to the technical documentation of the HardIP to be tested and stored as a bit stream file.

[0092] In actual applications, according to the PRAM (Parameter Random Access Memory) document of the HardIP to be tested, every four lines of bitstream data in the bitstream to be tested constitute a complete PRAM value, and the fourth line of bitstream data is stored in the PRAM highest bit that matches the generated PRAM value. Among them, the PRAM document describes the location information of each parameter to be tested.

[0093] Step S3034, extracting RTL parameters in the RTL file, wherein the RTL parameters include RTL parameter names and RTL parameter values.

[0094] The form of the RTL parameter may be a mapping relationship between an RTL parameter name and an RTL parameter value. In an actual application, the form of the RTL parameter is: RTL parameter name: RTL parameter value.

[0095] Step S3035, obtaining the hardware parameter name corresponding to the RTL parameter name, and updating the RTL parameter name in the RTL parameter.

[0096] The RTL parameter names are not exactly the same as the actual hardware parameter names. Before generating the reference file, you need to change the RTL parameter names to the actual hardware parameter names. In actual applications, the RTL parameter format is: actual hardware parameter name: RTL parameter value.

[0097] Step S3036: Generate a reference file based on the updated RTL parameters.

[0098] According to the technical documentation of the HardIP to be tested, the updated RTL parameters are arranged to obtain a reference file. The arrangement of the RTL parameters can be based on the PRAM document of the HardIP to be tested. In an actual application, there is a PRAM with a bit width of 10, the position of parameter A is [3:0], and the position of parameter B is [9:4]. The bit stream information of this row can be formed by the combination of parameter A and parameter B. All RTL parameters after arrangement are used as reference files for subsequent comparison. Among them, [3:0] represents the lower four bits in the PRAM with a bit width of 10, and [9:4] represents the six consecutive bits from bit 9 to bit 4 in the PRAM.

[0099] Step S304: compare the bitstream file with the reference file, and obtain a bitstream verification result based on the comparison result.

[0100] For details, please see Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

[0101] The bitstream verification method for HardIP provided in this embodiment generates an initial bitstream file by running the RTL file through the EDA software, and then extracts the HardIP bitstream to be tested from the initial bitstream file to obtain the final bitstream file. The efficiency and quality of design verification can be improved. The bitstream to be tested is obtained through coordinate information, which has high flexibility and applicability. By extracting the parameters of the RTL file and modifying the parameter name according to the actual application, a reference file is generated based on the modified RTL parameters. The consistency with the bitstream file can be maintained to avoid errors in the bitstream verification results due to inconsistent parameter names.

[0102] In this embodiment, a bit stream verification method for HardIP is provided. Figure 4is a flow chart of a bit stream verification method for HardIP according to an embodiment of the present invention, such as Figure 4 As shown, the process includes the following steps:

[0103] Step S401, obtaining the parameter type and parameter constraint conditions of the HardIP to be tested.

[0104] For details, please see Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0105] Step S402: Generate an RTL file set based on the parameter type and the parameter constraint condition, wherein the RTL file set includes a plurality of RTL files.

[0106] For details, please see Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0107] Step S403, based on the RTL file, a bitstream file and a reference file are obtained, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file.

[0108] For details, please see Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0109] Step S404: compare the bitstream file with the reference file, and obtain a bitstream verification result based on the comparison result.

[0110] Specifically, the above step S404 includes:

[0111] Step S4041, comparing the stored data of the bitstream file and the reference file.

[0112] The stored data of the bitstream file and the reference file may be compared bit by bit through an automatic comparison tool.

[0113] Step S4042: Generate a bit stream verification result of the HardIP to be tested based on the comparison result of the stored data.

[0114] When the storage data comparison results are completely consistent, it means that the bit stream verification of the HardIP to be tested is successful.

[0115] When the comparison result of the stored data is inconsistent, it means that the bit stream verification of the HardIP to be tested has failed and a problem has occurred in the HardIP to be tested. The erroneous parameter name and parameter value can be quickly determined based on the stored data of the reference file, and the problem of the HardIP to be tested can be located based on the erroneous parameter name.

[0116] The bitstream verification method for HardIP provided in this embodiment can ensure the accuracy of data by comparing the stored data to obtain the bitstream verification result of the HardIP to be tested. By storing the data comparison result, the problematic data can also be accurately located to facilitate subsequent maintenance.

[0117] In this embodiment, a bit stream verification device for HardIP is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used in the following embodiments, the term "module" represents a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented by software, the implementation of hardware, a combination of software and hardware is also possible and conceivable.

[0118] This embodiment provides a bit stream verification device for HardIP, such as Figure 5 As shown, the bit stream verification device includes:

[0119] The acquisition module 501 is used to acquire the parameter type and parameter constraint conditions of the HardIP to be tested.

[0120] The RTL generation module 502 is used to generate an RTL file set based on the parameter type and parameter constraint conditions of the HardIP to be tested, wherein the RTL file set includes a plurality of RTL files.

[0121] The file generation module 503 is used to obtain a bitstream file and a reference file based on the RTL file, wherein the bitstream file is generated by EDA software and the reference file is generated based on RTL parameters in the RTL file.

[0122] The output module 504 is used to compare the bitstream file with the reference file and obtain a bitstream verification result based on the comparison result.

[0123] In some optional implementations, the RTL generation module 502 includes:

[0124] A value generation unit, used for generating several groups of test parameters of the HardIP to be tested based on parameter types and parameter constraints;

[0125] A file generating unit, used for generating an RTL file based on one of the several groups of parameters to be tested;

[0126] The collection construction unit is used to construct an RTL file collection including several RTL files.

[0127] In some optional implementations, the value generating unit includes:

[0128] A set acquisition subunit is used to acquire a set of possible values ​​of the parameter to be tested, wherein the possible values ​​in the set of possible values ​​satisfy the parameter constraint condition;

[0129] A weight acquisition subunit, used to acquire a weight set, wherein the parameters in the weight set correspond one-to-one to the possible values ​​in the possible value set;

[0130] The value selection subunit is used to select several groups of parameters to be tested, wherein the values ​​of the parameters to be tested are selected based on the weights corresponding to the possible values ​​in the possible value set.

[0131] In some optional implementations, the file generation module 503 includes:

[0132] The bit stream file generating unit is used to generate a bit stream file.

[0133] The reference file generating unit is used to generate a reference file.

[0134] In some optional implementations, the bitstream file generating unit includes:

[0135] An initial bitstream generation subunit, used to generate an initial bitstream file, wherein the initial bitstream file is generated by running an RTL file through EDA software;

[0136] The bit stream to be tested extraction subunit is used to extract the bit stream to be tested from the initial bit stream file, wherein the bit stream to be tested is obtained based on the coordinate information of the HardIP to be tested;

[0137] The bitstream file acquisition subunit is used to acquire a bitstream file based on the bitstream to be tested.

[0138] In some optional implementations, the reference file generating unit includes:

[0139] A parameter extraction subunit is used to extract RTL parameters in the RTL file, wherein the RTL parameters include RTL parameter names and RTL parameter values;

[0140] A parameter updating subunit, used to obtain a hardware parameter name corresponding to the RTL parameter name, and update the RTL parameter name in the RTL parameter;

[0141] Reference file acquisition subunit: generates reference files based on the updated RTL parameters.

[0142] In some optional implementations, the output module 504 includes:

[0143] The storage data comparison unit is used to compare the storage data of the bit stream file and the reference file.

[0144] The result generating unit is used to generate a bit stream verification result of the HardIP to be tested based on the comparison result of the stored data.

[0145] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0146] The bitstream verification device for HardIP in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0147] The embodiment of the present invention also provides a computer device having the above Figure 5 The bitstream verification device for HardIP is shown.

[0148] See also Figure 6 , Figure 6 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 6 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0149] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0150] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0151] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0152] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0153] The computer device also includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0154] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0155] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0156] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0157] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0158] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A bit stream verification method for HardIP, characterized in that, The method comprises: Get the parameter type and parameter constraints of the HardIP to be tested; Based on the parameter type and the parameter constraint condition, generate an RTL file set, wherein the RTL file set includes a plurality of RTL files; Based on the RTL file, a bitstream file and a reference file are obtained, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file; Comparing the bitstream file with the reference file, and obtaining a bitstream verification result based on the comparison result; Based on the RTL file, obtaining a bitstream file includes: Generate an initial bitstream file, wherein the initial bitstream file is generated by running the RTL file through EDA software; Extracting a bit stream to be tested from the initial bit stream file, wherein the bit stream to be tested is obtained based on the coordinate information of the HardIP to be tested; Based on the bit stream to be tested, obtaining the bit stream file; The acquisition of the reference file includes: Extracting RTL parameters from the RTL file, wherein the RTL parameters include RTL parameter names and RTL parameter values; Obtaining a hardware parameter name corresponding to the RTL parameter name, and updating the RTL parameter name in the RTL parameter; Generate reference files based on the updated RTL parameters.

2. The method according to claim 1, characterized in that The parameter type includes at least one of the original parameter name, the module name in the RTL file, the parameter bit width, and the possible values ​​of the parameter.

3. The method according to claim 1, characterized in that The generating of the RTL file set based on the parameter type and the parameter constraint condition comprises: Based on the parameter type and parameter constraint conditions, generate several groups of test parameters of the HardIP to be tested; Based on one of the several groups of parameters to be tested, generating an RTL file; Build an RTL file set containing several RTL files.

4. The method according to claim 3, characterized in that The generating of several groups of parameters to be tested of the HardIP to be tested based on the parameter type and parameter constraint condition comprises: Obtaining a set of possible values ​​of the parameter to be tested, wherein the possible values ​​in the set of possible values ​​satisfy the parameter constraint condition; Obtaining a weight set, wherein the parameters in the weight set correspond one-to-one to the possible values ​​in the possible value set; A plurality of groups of parameters to be tested are selected, wherein the values ​​of the parameters to be tested are selected based on the weights corresponding to the possible values ​​in the possible value set.

5. The method according to claim 1, characterized in that The comparing the bitstream file with the reference file and obtaining a bitstream verification result based on the comparison result includes: comparing the stored data of the bitstream file with the stored data of the reference file; Based on the comparison result of the stored data, a bit stream verification result of the HardIP to be tested is generated.

6. A bit stream verification device for HardIP, characterized in that: The device comprises: The acquisition module is used to obtain the parameter type and parameter constraint conditions of the HardIP to be tested; An RTL generation module, used to generate an RTL file set based on the parameter type and parameter constraint condition, wherein the RTL file set includes a plurality of RTL files; A file generation module, used for acquiring a bitstream file and a reference file based on the RTL file, wherein the bitstream file is generated by EDA software, and the reference file is generated based on RTL parameters in the RTL file; An output module, used for comparing the bitstream file with the reference file, and obtaining a bitstream verification result based on the comparison result; Among them, the file generation module includes: A bit stream file generating unit, used for generating a bit stream file; A reference file generating unit, used for generating a reference file; The bitstream file generation unit includes: An initial bitstream generation subunit, used to generate an initial bitstream file, wherein the initial bitstream file is generated by running an RTL file through EDA software; The bit stream to be tested extraction subunit is used to extract the bit stream to be tested from the initial bit stream file, wherein the bit stream to be tested is obtained based on the coordinate information of the HardIP to be tested; A bitstream file acquisition subunit, used for acquiring a bitstream file based on the bitstream to be tested; The reference file generation unit includes: A parameter extraction subunit is used to extract RTL parameters in the RTL file, wherein the RTL parameters include RTL parameter names and RTL parameter values; A parameter updating subunit, used to obtain a hardware parameter name corresponding to the RTL parameter name, and update the RTL parameter name in the RTL parameter; Reference file acquisition subunit: generates reference files based on the updated RTL parameters.

7. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes a bit stream verification method for HardIP according to any one of claims 1 to 5 by executing the computer instructions.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute a bit stream verification method for HardIP according to any one of claims 1 to 5.

Images