A method and device for processing FPGA engineering files

Abstract

The present application relates to the field of computers, and more particularly to a method and apparatus for processing FPGA project files. The method comprises: obtaining a project file package to be tested; the project file package to be tested includes multiple FPGA project files; determining a top-level file from the multiple FPGA project files; obtaining a correspondence between keywords in a target keyword set and configuration information in the top-level file; wherein the target keyword set includes multiple keywords; each keyword in the multiple keywords corresponds to one of three file types; the three file types include: IP core files, constraint files, and handwritten files; and determining the file types corresponding to the multiple FPGA project files based on the correspondence between keywords in the target keyword set and configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project files.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a method and device for processing FPGA engineering files. Background Art

[0002] Field-Programmable Gate Array (FPGA) is a commonly used programmable logic device.

[0003] In existing technology, each FPGA software test typically requires testers to manually sort through the multiple FPGA project files included in the FPGA software to identify the intellectual property (IP) core files, constraint files, and handwritten files contained within the FPGA project files before proceeding with the subsequent testing process. This severely impacts test efficiency.

[0004] Therefore, how to avoid the low testing efficiency caused by manual classification of FPGA engineering files is a problem that needs to be solved at present. Summary of the Invention

[0005] In order to solve the above technical problems, the present application provides a method and device for processing FPGA engineering files.

[0006] In a first aspect, the present application provides a method for processing FPGA project files, the method comprising: obtaining a project file package to be tested; the project file package to be tested includes multiple FPGA project files; determining the top-level file of the project file package to be tested from the multiple FPGA project files; the top-level file includes multiple configuration information; by identifying keywords in a target keyword set in the top-level file, obtaining a correspondence between the keywords in the target keyword set and the configuration information in the top-level file; wherein, the target keyword set includes multiple keywords; each keyword in the multiple keywords corresponds to one of three file types; the three file types include: IP core files, constraint files, and handwritten files; according to the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file, determining the file types corresponding to the multiple FPGA project files respectively.

[0007] In some implementations, determining the top-level file of the project file package to be tested from the multiple FPGA project files includes: determining a target search rule corresponding to the target FPGA development tool from a preset rule library based on the target FPGA development tool corresponding to the project file package to be tested; the preset rule library includes: search rules corresponding to multiple FPGA development tools respectively; each of the search rules is used to indicate: the position of the top-level file in the project file package or at least one of the naming rules of the top-level file; and determining the top-level file corresponding to the project file package to be tested from the multiple FPGA project files based on the target search rule.

[0008] In some implementations, determining the top-level file corresponding to the project file package to be tested from the multiple FPGA project files based on the target search rule includes: determining multiple candidate files that meet the target search rule from the multiple FPGA project files; displaying a candidate interface; the candidate interface is used to display the multiple candidate files and prompt the user to select a top-level file from the multiple candidate files; and determining the top-level file corresponding to the project file package to be tested in response to a first user operation of selecting a candidate file from the candidate interface.

[0009] In some implementations, the method further includes: determining the target keyword set from a preset keyword library based on the target FPGA development tool corresponding to the project file package to be tested; the preset keyword library includes: keyword sets corresponding to multiple FPGA development tools, and the keywords in each keyword set correspond to one of the three file types.

[0010] In some implementations, obtaining the project file package under test includes: displaying a device under test management interface; the device under test management interface includes: a first interactive area for inputting the FPGA device under test, and a second interactive area for inputting the name of the FPGA software project; obtaining the target FPGA device under test based on a second user operation on the first interactive area; determining the target project name based on a third user operation on the second interactive area; and determining the project file package under test whose file name corresponds to the target project name from the target FPGA device under test.

[0011] In some implementations, the method further includes: displaying a file list; the file list includes: the multiple FPGA project files and the file types corresponding to the multiple FPGA project files.

[0012] In some implementations, the method further includes: storing the multiple FPGA project files in a database according to the file types corresponding to the multiple FPGA project files.

[0013] In a second aspect, the present application provides an FPGA test management device, comprising: an acquisition unit, for acquiring a project file package to be tested; the project file package to be tested includes multiple FPGA project files; a processing unit, for determining the top-level file of the project file package to be tested from the multiple FPGA project files; the top-level file includes multiple configuration information; the processing unit is also used to obtain the correspondence between the keywords in the target keyword set and the configuration information in the top-level file by identifying the configuration information matching the keywords in the target keyword set in the top-level file; wherein the target keyword set includes multiple keywords; each keyword in the multiple keywords corresponds to one of three file types; the three file types include: IP core files, constraint files and handwritten files; the processing unit is also used to determine the file types corresponding to the multiple FPGA project files respectively based on the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file.

[0014] In some implementations, the processing unit is used to determine the top-level file of the project file package to be tested from the multiple FPGA project files, including: a processing unit is used to determine the target search rule corresponding to the target FPGA development tool from a preset rule library based on the target FPGA development tool corresponding to the project file package to be tested; the preset rule library includes: search rules corresponding to multiple FPGA development tools respectively; each of the search rules is used to indicate: the position of the top-level file in the project file package or at least one of the naming rules of the top-level file; the processing unit is used to determine the top-level file corresponding to the project file package to be tested from the multiple FPGA project files according to the target search rule.

[0015] In some implementations, the processing unit is used to determine the top-level file corresponding to the project file package to be tested from the multiple FPGA project files according to the target search rule, including: a processing unit is used to determine multiple candidate files that meet the target search rule from the multiple FPGA project files; a processing unit is used to display a candidate interface; the candidate interface is used to display the multiple candidate files and prompt the user to select a top-level file from the multiple candidate files; the processing unit is used to determine the top-level file corresponding to the project file package to be tested in response to a first user operation of selecting a candidate file from the candidate interface.

[0016] In some implementations, the processing unit is further used to determine the target keyword set from a preset keyword library based on the target FPGA development tool corresponding to the project file package to be tested; the preset keyword library includes: keyword sets corresponding to multiple FPGA development tools, and the keywords in each keyword set correspond to one of the three file types.

[0017] In some implementations, an acquisition unit, used to acquire a file package of a project under test, includes: an acquisition unit, used to display a management interface for a device under test; the management interface for a device under test includes: a first interactive area for inputting an FPGA device under test, and a second interactive area for inputting a name of an FPGA software project; an acquisition unit, used to acquire a target FPGA device under test based on a second user operation on the first interactive area; an acquisition unit, used to determine a target project name based on a third user operation on the second interactive area; and an acquisition unit, used to determine, from the target FPGA device under test, the file package of the project under test whose file name corresponds to the target project name.

[0018] In some implementations, the processing unit is further configured to display a file list; the file list includes: the multiple FPGA project files and the file types corresponding to the multiple FPGA project files.

[0019] In some implementations, the processing unit is further configured to store the multiple FPGA project files into a database according to the file types corresponding to the multiple FPGA project files.

[0020] In a third aspect, an FPGA test management device is provided, comprising: a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to enable the FPGA test management device to implement the method as in the first aspect or any implementation method of the first aspect when executing the computer program.

[0021] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computing device, the computing device implements the method as in the first aspect or any implementation method in the first aspect.

[0022] In a fifth aspect, a computer program product is provided, which, when executed on a computer, enables the computer to implement the method according to the first aspect or any one of the implementations of the first aspect.

[0023] The technical solution provided by the embodiments of the present application has the following advantages compared with the prior art:

[0024] In the embodiments of the present application, it is considered that within an FPGA project file, the top-level file serves as the master file for the entire FPGA design. It is primarily responsible for integrating the various sub-modules, defining the overall design's interfaces with the outside world, and describing the connections between the sub-modules. Therefore, the top-level file typically contains numerous pieces of configuration information for the FPGA project file. The configuration information corresponding to different types of FPGA project files often includes specific keywords. For example, if a piece of configuration information includes the keyword "IPcore," it can generally be determined that the project file corresponding to that configuration information is an IP core file. For another example, in the top-level file of FPGA software developed using the Libero development tool, if a piece of configuration information includes the keyword "valuehdl," it can generally be determined that the project file corresponding to that configuration information is a handwritten file. Based on the above principles, the embodiments of the present application consider that the correspondence between the keywords carried in the configuration information within the top-level file and the file types can be summarized to construct a keyword set (hereinafter referred to as the "target keyword set"). This target keyword set can include multiple keywords, each of which corresponds to one of three file types: an IP core file, a constraint file, and a handwritten file. In this way, when it is necessary to classify multiple FPGA project files included in a project file package to be tested, after obtaining the project file package to be tested, the top-level file can be first determined from the multiple FPGA project files; the top-level file includes multiple configuration information. Then, by identifying keywords in the target keyword set in the top-level file, a correspondence between the keywords and the configuration information is obtained. Furthermore, based on this correspondence and the correspondence between the configuration information and the FPGA project files, the file type corresponding to each FPGA project file can be determined. This avoids the problem of low test efficiency caused by manual classification of FPGA project files. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0026] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0027] Figure 1 One of the methods for processing FPGA project files provided in the embodiments of this application;

[0028] Figure 2A second method for processing FPGA project files provided in an embodiment of the present application;

[0029] Figure 3 This is one of the interface diagrams provided in the embodiment of the present application;

[0030] Figure 4 The third method for processing an FPGA project file provided in an embodiment of the present application;

[0031] Figure 5 This is a second interface diagram provided in an embodiment of the present application;

[0032] Figure 6 A fourth method for processing an FPGA project file provided in an embodiment of the present application;

[0033] Figure 7 A fifth method for processing an FPGA project file provided in an embodiment of the present application;

[0034] Figure 8 The sixth method for processing an FPGA project file provided in an embodiment of the present application;

[0035] Figure 9 This is one of the structural diagrams of an FPGA test management device provided in an embodiment of the present application;

[0036] Figure 10 This is a second structural diagram of an FPGA test management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to more clearly understand the above-mentioned objectives, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that, in the absence of conflict, the embodiments of the present application and the features therein can be combined with each other.

[0038] In the following description, many specific details are set forth to facilitate a full understanding of the present application, but the present application can also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present application, not all of the embodiments.

[0039] First, the relevant technologies involved in the embodiments of this application are introduced:

[0040] Field-Programmable Gate Arrays (FPGAs) are commonly used programmable logic devices, widely used in digital circuit design and embedded system development. FPGA development tools are a collection of software tools used to design, implement, and verify FPGA circuits. Currently, there are several mainstream FPGA development tools on the market, such as ISE, Vivado, Libero, and Quartus II.

[0041] The FPGA development process involves a large number of FPGA project files. These files can include code files written in hardware description languages ​​such as Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL) or Verilog Hardware Description Language (Verilog HDL). Depending on their content, FPGA project files can be categorized as intellectual property (IP) core files, constraint files, and handwritten files.

[0042] In the prior art, each FPGA software test typically requires testers to manually sort the multiple FPGA project files included in the FPGA software to identify the IP core files, constraint files, and handwritten files within the FPGA project files before proceeding with the subsequent testing process. This significantly impacts test efficiency. Furthermore, the structure and naming conventions of different types of FPGA project files vary depending on the development environment, further increasing the difficulty of FPGA project file classification.

[0043] The following is an introduction to the technical solutions provided by the embodiments of the present application with reference to examples:

[0044] In response to the above technical problems, in the embodiments of the present application, the first consideration is: if FPGA project files can be automatically classified using software or hardware, the speed and accuracy of FPGA project file classification can be improved, thereby improving the efficiency of FPGA software testing.

[0045] Furthermore, in the embodiments of the present application, it is taken into account that: in the FPGA project file, the top-level file serves as the main file of the entire FPGA design, and is mainly responsible for integrating the various sub-modules, defining the interface between the entire design and the outside, and describing the connection relationship between the various sub-modules. Therefore, the top-level file usually includes a lot of configuration information for the FPGA project file. Among them, the configuration information corresponding to different types of FPGA project files often includes specific keywords. For example, if a certain configuration information includes the keyword "IPcore", it can usually be determined that the project file corresponding to the configuration information is an IP core file. For another example, in the top-level file of the FPGA software developed using the Libero development tool, if a certain configuration information includes the keyword "value hdl", it can usually be determined that the project file corresponding to the configuration information is a handwritten file.

[0046] Based on the above rules, the embodiment of the present application considers that the correspondence between the keywords carried by the configuration information in the top-level file and the file type can be summarized to construct a keyword set (hereinafter referred to as the "target keyword set"), which can include: multiple keywords, wherein each keyword in the multiple keywords corresponds to one of the three file types (i.e., IP core file, constraint file, and handwritten file). In this way, when it is necessary to classify the multiple FPGA project files included in the project file package to be tested, it can be done as follows Figure 1 As shown, after obtaining the project file package to be tested (i.e., S101), the top-level file can be first determined from multiple FPGA project files (i.e., S102), where the top-level file includes multiple configuration information. Then, by identifying keywords in the target keyword set in the top-level file, a correspondence between the keywords and the configuration information can be obtained (i.e., S103). Furthermore, based on the above correspondence and the correspondence between the configuration information and the FPGA project file, the file type corresponding to each FPGA project file can be determined (i.e., S104). This avoids the problem of low test efficiency caused by manual classification of FPGA project files.

[0047] The technical solution provided by the embodiment of the present application is described in detail below with reference to examples. Specifically, the embodiment of the present application provides a method for processing FPGA project files. The execution subject of the method for processing FPGA project files may be an FPGA test management device. When the FPGA test management device is running, it can be used to execute all or part of the steps in the method for processing FPGA project files provided by the embodiment of the present application. In actual application, the functions of the FPGA test management device may be implemented by a personal computer (including desktop computers, laptop computers, handheld computers, and notebook computers, etc.), or electronic devices such as smart phones and servers; or, the functions of the above-mentioned FPGA test management device may also be implemented by some hardware / software devices in the above-mentioned electronic devices. The embodiment of the present application does not impose any special restrictions on the specific form of the FPGA test management device.

[0048] like Figure 1 As shown, the method for processing FPGA project files provided in the embodiment of the present application may include:

[0049] S101. The FPGA test management device obtains a file package of a project to be tested.

[0050] The project files to be tested may include multiple FPGA project files, which may include: IP core files, constraint files, and handwritten files.

[0051] In actual application, the project file package to be tested may specifically be a compressed project file package including multiple FPGA project files.

[0052] In one implementation, it is considered that in actual application, the DUT to be tested may contain not only the DUT project file package but also other technical documents. In order to more quickly locate the DUT project file package containing multiple FPGA project files from the DUT, in this method, Figure 2 As shown, S101 may specifically include:

[0053] S1011. The FPGA test management device displays a device under test management interface.

[0054] The DUT management interface includes: a first interactive area for inputting the FPGA DUT, and a second interactive area for inputting the FPGA software project name.

[0055] S1012: The FPGA test management device obtains a target FPGA device under test according to a second user operation on the first interactive area.

[0056] S1013: The FPGA test management device determines a target project name according to a third user operation on the second interactive area.

[0057] For example, in Figure 3 The DUT management interface 20 shown includes a control 201 titled "Select DUT." By clicking this control 201, the user can enter the DUT. In this case, control 201 can be understood as the first interactive area. Furthermore, the DUT management interface 20 also includes an input box 202 titled "FPGA Software Project Name." By entering text into this input box 202, the user can enter the FPGA software project name. In this case, input box 202 can be understood as the second interactive area.

[0058] On the one hand, after receiving a user operation (ie, a second user operation) on the control 201 for inputting an input to the device under test, the FPGA test management apparatus can obtain the target FPGA device under test.

[0059] On the other hand, after receiving a user operation (ie, a third user operation) on input box 202 for inputting an FPGA software project name, the FPGA test management apparatus may determine the FPGA software project name (ie, target project name) included in the target FPGA device under test.

[0060] S1014. The FPGA test management device determines a project file package to be tested corresponding to a file name and a target project name from the target FPGA device under test.

[0061] For example, the FPGA test management device may use the target project name to filter the file packages included in the target FPGA device under test, thereby obtaining the project file package to be tested whose file name corresponds to the target project name.

[0062] S102 : The FPGA test management device determines a top-level file of a project file package from a plurality of FPGA project files.

[0063] The top-level file includes multiple configuration information, each of which corresponds to an FPGA project file in the project file package to be tested.

[0064] In some implementations, such as Figure 4 As shown, S102 may specifically include:

[0065] S1021. The FPGA test management device determines a target search rule corresponding to the target FPGA development tool from a preset rule library according to the target FPGA development tool corresponding to the project file package to be tested.

[0066] The preset rule base includes search rules corresponding to various FPGA development tools, each of which is used to indicate at least one of the location of a top-level file in a project file package or a naming rule of a top-level file.

[0067] For example, in some FPGA development tools, the storage location of the top-level file within the project file package is pre-set, and the corresponding search rules of the FPGA development tool include: the location of the top-level file within the project file package. For another example, in some FPGA development tools, the naming method of the top-level file is pre-set, and the corresponding search rules of the FPGA development tool include: the naming method of the top-level file.

[0068] S1022. The FPGA test management device determines the top-level file corresponding to the project file package to be tested from multiple FPGA project files according to the target search rule.

[0069] For example, the FPGA test management device can determine a file that meets the target search rule from multiple FPGA project files based on the target search rule, and use the file as the top-level file corresponding to the project file package to be tested.

[0070] In the above-described implementation of the embodiment of the present application, it is considered that within a project file package, the location of the top-level file within the project file package and the naming of the top-level file are governed by corresponding rules. Furthermore, the location of the top-level file within the project file package and the naming rules for the top-level file may vary for FPGA project files corresponding to different FPGA development tools. Therefore, the location and naming rules for the top-level file within the project file package can be summarized in advance to construct a rule library (hereinafter referred to as a preset rule library). This preset rule library can include search rules corresponding to various FPGA development tools. Each search rule indicates at least one of the location of the top-level file within the project file package or the naming rules for the top-level file. Furthermore, when determining the top-level file of the project file package to be tested, the target search rule corresponding to the target FPGA development tool corresponding to the project file package to be tested can be determined from the preset rule library. Then, based on the target search rule, the top-level file corresponding to the project file package to be tested can be determined from multiple FPGA project files. This allows for rapid and accurate determination of the top-level file.

[0071] Furthermore, in some designs, S1022 may specifically include:

[0072] S1022a. The FPGA test management device determines multiple candidate files that meet the target search rule from multiple FPGA project files.

[0073] S1022b. The FPGA test management device displays a candidate interface.

[0074] Among them, the candidate interface is used to display multiple candidate files and prompt the user to select a top-level file from the multiple candidate files.

[0075] S1022c. The FPGA test management device determines the top-level file corresponding to the engineering file package to be tested in response to a first user operation of selecting a candidate file from the candidate interface.

[0076] Exemplarily, as Figure 5 shown, in the candidate interface 30, there are three candidate files with serial numbers "①", "②", and "③" respectively, and by displaying the candidate interface 303, it can prompt the user to select a top-level file from the multiple candidate files. After receiving the user's tick operation on the checkbox 304 and click operation on the control 305 (i.e., the first user operation), the FPGA test management device can determine that the candidate file with the serial number "①" is the top-level file corresponding to the engineering file package to be tested.

[0077] In the above design, considering that: when there are multiple candidate files in multiple FPGA engineering files that all meet the target search rules, the FPGA test management device may make a misjudgment. Therefore, in this design, when the FPGA test management device determines multiple candidate files that meet the target search rules, it can display the corresponding candidate interface to enable the user to decide which candidate file is the top-level file, thereby avoiding the occurrence of misjudgment.

[0078] S103. The FPGA test management device obtains the correspondence between keywords and configuration information by identifying the keywords in the target keyword set in the top-level file.

[0079] Exemplarily, in some development tools (such as the VIVAVO development tool), when a certain configuration information in the top-level file includes "<FileSet" and "constrs_1", the engineering file corresponding to this configuration information is a constraint file. Therefore, the target keyword set can include the keywords "<FileSet" and "constrs_1". Furthermore, the FPGA test management device can identify the keywords in the target keyword set from the multiple configuration information included in the top-level file, thereby obtaining the configuration information A corresponding to the keywords "<FileSet" and "constrs_1". At this time, it can be understood that: the correspondence between keywords and configuration information obtained by S103 includes: the correspondence between the keywords "<FileSet" and "constrs_1" and the configuration information A.

[0080] It can be understood that, as described in the embodiments of the present application, the correspondence between the keyword and the configuration information may specifically include: the keyword is included in the configuration information. In addition, the correspondence between the keyword and the configuration information may specifically further include: the keyword is not included in the configuration information. That is to say, in the actual application process, the keywords in the target keyword set can implement the function of the whitelist, that is, when a certain configuration information includes the keyword, it is determined that there is a correspondence between the keyword and the configuration information; in addition, the keywords in the target keyword set can also implement the function of the blacklist, that is, when a certain configuration information does not include the keyword, it is determined that there is a correspondence between the keyword and the configuration information.

[0081] S104. The FPGA test management device determines the file types corresponding to multiple FPGA project files respectively according to the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file.

[0082] Continuing with the above example, when the correspondence between the keyword and the configuration information obtained in S103 includes the correspondence between the keywords "<FileSet" and "constrs_1" and the configuration information A, if the configuration information A corresponds to the FPGA project file B (that is, the correspondence between the configuration information in the top-level file and the FPGA project file includes the correspondence between the configuration information A and the FPGA project file B), it is determined that the FPGA project file B is a constraint file.

[0083] In some implementation manners, as Figure 6 shown, before executing S103, the method may further include:

[0084] S105. The FPGA test management device determines the target keyword set from the preset keyword library according to the target FPGA development tool corresponding to the project file package to be tested.

[0085] Among them, the preset keyword library includes: keyword sets corresponding to multiple FPGA development tools respectively, and the keywords in each keyword set respectively correspond to one of the above three file types.

[0086] In the above implementation of the embodiment of the present application, considering that different FPGA development tools may correspond to different keywords, a preset keyword library can be pre-built. This preset keyword library includes keyword sets corresponding to each FPGA development tool. Therefore, when determining the file type of the FPGA project file in the FPGA project file package, the target keyword set (i.e., the keyword set corresponding to the target FPGA development tool corresponding to the current project file package under test) can be first determined from the preset keyword library. This target keyword set can then be used to perform subsequent steps. This can narrow the scope of the keyword library, thereby improving screening speed and accuracy.

[0087] In some implementations, after determining the file types corresponding to the plurality of FPGA project files, such as Figure 7 As shown, the method may further include:

[0088] S106. The FPGA test management device displays a file list.

[0089] The file list includes: multiple FPGA project files and file types corresponding to the multiple FPGA project files.

[0090] For example, Figure 5 The file list 306 includes: multiple FPGA project files and file types corresponding to the multiple FPGA project files.

[0091] Through the above implementation, after the FPGA test management device determines the file types corresponding to the multiple FPGA project files, the classification results can be displayed in the interface by displaying a file list so that the user can view the classification results.

[0092] In some implementations, such as Figure 8 As shown, the method may further include:

[0093] S107 : The FPGA test management device stores the multiple FPGA project files into a database according to the file types corresponding to the multiple FPGA project files.

[0094] For example, the FPGA test management device can store FPGA project files of different file types in different file directories in a database based on their corresponding file types, facilitating subsequent software testing tasks. For another example, the FPGA test management device can store the file type identifiers of each FPGA project file (used to identify the file type corresponding to the FPGA project file) in the database when storing the multiple FPGA project files in the database, based on their corresponding file types. This allows the device to determine the file type corresponding to the FPGA project file based on the file type identifiers when reading the FPGA project files.

[0095] Based on the same inventive concept, as an implementation of the above method, an embodiment of the present application further provides an FPGA test management device, which corresponds to the above method embodiment. For ease of reading, this embodiment will no longer repeat the details of the above method embodiment one by one, but it should be clear that the FPGA test management device in this embodiment can correspond to and implement all the contents of the above method embodiment.

[0096] The present invention provides an FPGA test management device. Figure 9 A structural diagram of the FPGA test management device is shown in FIG. Figure 9 As shown, the FPGA test management device 40 includes:

[0097] The acquisition unit 401 is used to acquire a file package of the project to be tested; the file package of the project to be tested includes multiple FPGA project files;

[0098] The processing unit 402 is configured to determine a top-level file of the project file package to be tested from the plurality of FPGA project files; the top-level file includes a plurality of configuration information;

[0099] The processing unit 402 is further configured to obtain a correspondence between the keywords in the target keyword set and the configuration information in the top-level file by identifying configuration information matching the keywords in the target keyword set in the top-level file; wherein the target keyword set includes a plurality of keywords; each keyword in the plurality of keywords corresponds to one of three file types; the three file types include: an IP core file, a constraint file, and a handwritten file;

[0100] The processing unit 402 is further configured to determine the file types corresponding to the plurality of FPGA project files based on the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file.

[0101] In some implementations, the processing unit 402 is configured to determine the top-level file of the project file package to be tested from the multiple FPGA project files, including:

[0102] Processing unit 402 is configured to determine, based on the target FPGA development tool corresponding to the project file package to be tested, a target search rule corresponding to the target FPGA development tool from a preset rule library; the preset rule library includes search rules corresponding to a plurality of FPGA development tools; each search rule is configured to indicate at least one of the location of a top-level file in the project file package or a naming rule for the top-level file;

[0103] The processing unit 402 is configured to determine, from the plurality of FPGA project files, a top-level file corresponding to the project file package to be tested according to the target search rule.

[0104] In some implementations, the processing unit 402 is configured to determine, from the plurality of FPGA project files, a top-level file corresponding to the project file package to be tested according to the target search rule, including:

[0105] The processing unit 402 is configured to determine, from the plurality of FPGA project files, a plurality of candidate files that meet the target search rule;

[0106] The processing unit 402 is configured to display a candidate interface; the candidate interface is configured to display the plurality of candidate files and prompt the user to select a top-level file from the plurality of candidate files;

[0107] The processing unit 402 is configured to determine a top-level file corresponding to the project file package to be tested in response to a first user operation of selecting a candidate file from the candidate interface.

[0108] In some implementations, the processing unit 402 is further used to determine the target keyword set from a preset keyword library based on the target FPGA development tool corresponding to the project file package to be tested; the preset keyword library includes: keyword sets corresponding to multiple FPGA development tools, and the keywords in each keyword set correspond to one of the three file types.

[0109] In some implementations, the acquiring unit 401 is configured to acquire a file package of the project to be tested, including:

[0110] The acquisition unit 401 is used to display a DUT management interface; the DUT management interface includes: a first interactive area for inputting the FPGA DUT, and a second interactive area for inputting the FPGA software project name;

[0111] An acquiring unit 401 is configured to acquire a target FPGA device under test according to a second user operation on the first interactive area;

[0112] An acquisition unit 401 is configured to determine a target project name according to a third user operation on the second interactive area;

[0113] The acquisition unit 401 is configured to determine the project file package to be tested whose file name corresponds to the target project name from the target FPGA device under test.

[0114] In some implementations, the processing unit 402 is further configured to display a file list; the file list includes: the multiple FPGA project files and the file types corresponding to the multiple FPGA project files.

[0115] In some implementations, the processing unit 402 is further configured to store the multiple FPGA project files into a database according to the file types corresponding to the multiple FPGA project files.

[0116] The FPGA test management device 40 provided in the embodiment of the present application can execute the method provided in any of the above embodiments. Its implementation principles and technical effects are similar and will not be repeated here.

[0117] Based on the same inventive concept, an embodiment of the present application also provides an FPGA test management device. Figure 10 A schematic diagram of the structure of the FPGA test management device provided in the embodiment of the present application is shown as follows: Figure 10 As shown, the FPGA test management device provided by this embodiment includes: a memory 501 and a processor 502, the memory 501 is used to store computer programs, and the processor 502 is used to execute the method provided by the above embodiment when executing the computer program.

[0118] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the computing device implements the method provided in the above embodiment.

[0119] Based on the same inventive concept, an embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computing device to implement the method provided in the above embodiment.

[0120] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0121] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0122] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0123] Computer-readable media includes both permanent and non-permanent, removable and non-removable storage media. Storage media can implement any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some or all of the technical features therein, and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing FPGA project files, characterized in that: The method comprises: Obtaining a project file package to be tested; the project file package to be tested includes multiple FPGA project files; Determining, from a preset rule library, a target search rule corresponding to a target FPGA development tool corresponding to the project file package to be tested; the preset rule library includes search rules corresponding to a plurality of FPGA development tools; each search rule is used to indicate at least one of the position of a top-level file in the project file package or a naming rule of the top-level file; Determining, according to the target search rule, a top-level file corresponding to the project file package to be tested from the plurality of FPGA project files; the top-level file includes a plurality of configuration information; Obtaining a correspondence between the keywords in the target keyword set and the configuration information in the top-level file by identifying keywords in the target keyword set in the top-level file; wherein the target keyword set includes a plurality of keywords; each keyword in the plurality of keywords corresponds to one of three file types; the three file types include: an IP core file, a constraint file, and a handwritten file; The file types corresponding to the plurality of FPGA project files are determined based on the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file.

2. The method according to claim 1, characterized in that Determining, from the plurality of FPGA project files, a top-level file corresponding to the project file package to be tested according to the target search rule includes: Determining, from the plurality of FPGA project files, a plurality of candidate files that meet the target search rule; Displaying a candidate interface; the candidate interface is used to display the multiple candidate files and prompt the user to select a top-level file from the multiple candidate files; In response to a first user operation of selecting a candidate file from the candidate interface, a top-level file corresponding to the project file package to be tested is determined.

3. The method according to claim 1, characterized in that The method further comprises: According to the target FPGA development tool corresponding to the project file package to be tested, the target keyword set is determined from a preset keyword library; the preset keyword library includes: keyword sets corresponding to multiple FPGA development tools, and the keywords in each keyword set correspond to one of the three file types.

4. The method according to any one of claims 1 to 3, characterized in that The step of obtaining the project file package to be tested includes: Displaying a DUT management interface; the DUT management interface includes: a first interactive area for inputting an FPGA DUT, and a second interactive area for inputting an FPGA software project name; acquiring a target FPGA device under test according to a second user operation on the first interactive area; determining a target project name according to a third user operation on the second interactive area; The project file package to be tested corresponding to the name of the target project is determined from the target FPGA device under test.

5. The method according to any one of claims 1 to 3, characterized in that The method further comprises: Display a file list; the file list includes: the multiple FPGA project files and the file types corresponding to the multiple FPGA project files.

6. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The multiple FPGA project files are stored in a database according to the file types corresponding to the multiple FPGA project files.

7. An FPGA test management device, characterized in that: include: An acquisition unit is used to acquire a project file package to be tested; the project file package to be tested includes multiple FPGA project files; A processing unit, configured to determine, from a preset rule library, a target search rule corresponding to the target FPGA development tool according to the target FPGA development tool corresponding to the project file package to be tested; The preset rule library includes: search rules corresponding to a plurality of FPGA development tools; each search rule is used to indicate: the position of the top-level file in the project file package or at least one of the naming rules of the top-level file; The processing unit is further configured to determine, from the plurality of FPGA project files, a top-level file corresponding to the project file package to be tested according to the target search rule; the top-level file includes a plurality of configuration information; The processing unit is further configured to obtain a correspondence between keywords in the target keyword set and the configuration information in the top-level file by identifying configuration information matching keywords in the target keyword set in the top-level file; wherein the target keyword set includes a plurality of keywords; each keyword in the plurality of keywords corresponds to one of three file types; the three file types include: an IP core file, a constraint file, and a handwritten file; The processing unit is further used to determine the file types corresponding to the multiple FPGA project files based on the correspondence between the keywords in the target keyword set and the configuration information in the top-level file, and the correspondence between the configuration information in the top-level file and the FPGA project file.

8. An FPGA test management device, characterized in that: include: A memory and a processor, wherein the memory is used to store a computer program, and the processor is used to enable the FPGA test management device to implement the method according to any one of claims 1 to 7 when executing the computer program.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a computing device, enables the computing device to implement the method according to any one of claims 1 to 7.

Images