CN114239459B

CN114239459B - Processing method, device, equipment and medium for FPGA prototype design file

Info

Publication number: CN114239459B
Application number: CN202210165750.9A
Authority: CN
Inventors: 王奕; 曹蓓; 曲超; 吴睿振
Original assignee: Suzhou Inspur Intelligent Technology Co Ltd
Current assignee: Suzhou Inspur Intelligent Technology Co Ltd
Priority date: 2022-02-23
Filing date: 2022-02-23
Publication date: 2022-04-29
Anticipated expiration: 2042-02-23
Also published as: CN114239459A

Abstract

The invention relates to a processing method, a device, equipment and a medium for an FPGA prototype design file. The method comprises the following steps: acquiring a design file of an FPGA prototype and a list file of signals to be debugged; inquiring and marking a signal to be debugged in the list file in the design file by using the first batch of processing scripts; updating a preset constraint file based on a signal to be debugged in the list file to generate a first constraint file, and performing design synthesis on the first constraint file and the design file through a synthesis tool to generate a synthesis netlist; screening the signals to be debugged in the list file by using the comprehensive netlist to obtain the signals to be debugged which are not optimized; updating the first constraint file based on the screened signal to be debugged which is not optimized to generate a second constraint file; performing place and route based on the synthesis netlist and the second constraint file to generate a place and route netlist, and generating the FPGA bit stream by using the place and route netlist. The scheme of the invention saves labor cost and shortens debugging time.

Description

Processing method, device, equipment and medium for FPGA prototype design file

Technical Field

The invention relates to the field of FPGA prototype verification, in particular to a processing method, a device, equipment and a medium for an FPGA prototype design file.

Background

Verification is carried out along with the whole process of designing an Application Specific Integrated Circuit (ASIC), from the process of customizing a design system protocol and code implementation to the process of finally laying out and wiring at the back end and the like, verification work is always like shadow following, risks are continuously introduced in the ASIC design process, the process from a concept stage to the process of being listed on the market is converted for several times (such as design specification- > code- > comprehensive netlist and the like), no matter which conversion process leads in deviation, the verification work is to reduce the risks existing in the design process as much as possible, the goodness of fit between a chip and the system protocol is ensured, and the error guarantee project development of the design chip in the aspects of concept, function, realization and the like is verified before tape-out. At present, verification is the most time-consuming work in the ASIC design process, which accounts for 50% -70% of the design workload, and becomes one of the most important works in ASIC design, and as more and more real-time data needs to be processed, verification requires that the design can be operated at a frequency close to the actual operating frequency of the chip, which is a challenge to the verification work.

When ASIC design is verified, the verification can be divided into module level verification, component level verification and system level verification according to different sections of the design, in the whole verification process, different verification technologies are required to be used in different verification stages, each verification technology occupies different positions in the verification process, when a behavioral modeling is carried out to a code and the code is carried to a netlist, formal verification is used, at the beginning of design, a software simulation or a hardware simulator and other forms are used, so that the design defect of the design can be conveniently found, sufficient tests are required to be carried out at the end of the basic end of the design, a Field Programmable Gate Array (FPGA) prototype verification should be used, so that the remaining system level errors are found, static timing analysis is carried out after layout and wiring, and the verification methods complement each other to form a multi-level verification system, for large ASIC design, the flexible application of various verification methods to verify the design memorability is a key factor for ensuring the smooth flow of the design.

The traditional simulation technology can not meet the requirement of complex ASIC verification on speed, a software simulator and a formulated software model are very popular, but the traditional simulation technology can not meet the requirement of use, a hardware accelerator has better performance, but is expensive and inconvenient to use, the required performance can not be achieved for some applications with high-speed data processing, such as MPEG video processing and the like, and the traditional simulation technology can not meet the performance requirement of the current ASIC design due to more expensive and complex hardware simulator in the market.

As the front end part of the verification environment of the traditional ASIC design System on chip (SoC), the main way of functional verification is software simulation, one of the problems of various functional verifications is that the amount of data to be collected and stored will greatly slow down the simulation speed if a large number of signals are monitored and the lengthy simulation speed will result in a larger amount of data, the main advantage of software simulation is that the main disadvantage of complete visibility of the design is slow, even if the software simulation is executed on powerful and high-level workstations, the software simulation of the current large-scale SoC design can only reach the simulation speed of a few hertz (namely, the real-time main system frequency period of the design can only be a few times per second), this means that software simulations are usually only applicable to a small part of the design, or to tens of frequency cycles of a full chip design; however, the complete verification of modern SoC designs requires thousands or even millions of frequency cycles, and at this time, some form of hardware-assisted verification is required, so as to solve the problems of simulation speed and tedious problems of building a programming test platform and the like.

If the FPGA design cannot be synthesized or fails to work properly on the development board as expected, it is often difficult to find the source of the failure in thousands of Register-transfer Level (RTL) and routing source files, and many of these files may be written by other designers. Given the iterations and running time extension of FPGA design, designers should find many possible errors at an early stage in the design flow and try to validate the design on the development board. It is also common that the tool optimizes some codes during synthesis, placement and routing, so that the actual circuit does not correspond to the signal in the code. Often, the signal name in the code is used to capture the signal, and in the later stage of layout and wiring, the corresponding circuit signal cannot be found, which may result in that the signal cannot be captured or the layout and wiring fail.

The conventional debugging process is as follows: the FPGA verifier adds keywords into the codes to mark signals to be debugged. The code to which the keyword is added is evaluated and synthesized using a synthesis tool. After the synthesis is completed, an ILA (integrated logic analyzer) debugging core is generated, FPGA (field programmable gate array) verification personnel is required to manually open a Set Up Debug option under design synthesis, a clock signal is generated for the Debug ILA core, the signal to be debugged is manually added, whether the signal is optimized and whether a clock domain is correct or not is judged, then the needed ILA debugging core is generated, then instance and write bitstream are performed, and finally downloading and debugging are performed. Traditional debugging process needs the artificial judgement of verification personnel and waits for to synthesize the realization, and general chip verification design is very big, and the signal that needs to transfer is also many, and the manual work adds the mark and also makes mistakes relatively easily, synthesizes often to need several hours to tens hours's time, and the efficiency that prototype was verified can be influenced in manual watch and manual judgement.

Disclosure of Invention

In order to solve the problems of manual processing and signal optimization judgment in the prior art, the invention provides a processing method, a device, equipment and a medium for an FPGA prototype design file.

According to a first aspect of the present invention, there is provided a method of processing an FPGA prototype design file, the method comprising:

acquiring a design file of an FPGA prototype and a list file of signals to be debugged;

inquiring and marking the signal to be debugged in the list file in the design file by using a first batch script;

updating a preset constraint file based on the signal to be debugged in the list file to generate a first constraint file;

performing design synthesis on the first constraint file and the design file through a synthesis tool to generate a synthesized netlist;

screening the signal to be debugged in the list file by using the comprehensive netlist to obtain the signal to be debugged which is not optimized;

updating the first constraint file based on the screened signal to be debugged which is not optimized to generate a second constraint file;

and executing placement and routing based on the comprehensive netlist and the second constraint file to generate a placement and routing netlist, and generating the FPGA bit stream by using the placement and routing netlist.

In some embodiments, the list file includes the signal name of each signal to be debugged and the path of the module file to which the signal belongs;

the step of querying and marking the signal to be debugged in the list file in the design file by using the first batch script comprises the following steps:

searching signals matched with the names of the signals in the design file based on the paths of the module files of the signals to be debugged in the list file;

an identifier is added to the matched signal that prevents the signal from being optimized out during synthesis.

In some embodiments, the step of screening the signal to be debugged in the list file by using the synthesized netlist to obtain the signal to be debugged which is not optimized includes:

searching signals matched with the names of the signals in the comprehensive netlist based on the paths of the module files of the signals to be debugged in the list files by using a second batch processing script;

in response to finding out the signal matched with each signal name, taking the signal as a signal to be debugged which is not optimized;

in response to the fact that the signal matched with each signal name is not found, the signal is used as the optimized signal to be debugged;

and creating a signal optimization report to record and store all the signals to be debugged which are optimized.

In some embodiments, the method further comprises:

burning the FPGA bit stream into an FPGA;

running a bit stream in the FPGA and adding a trigger condition to at least one signal to be tested which is not optimized according to a test requirement;

and responding to the trigger condition to take effect in the debugging process, and performing problem analysis and positioning based on the waveform corresponding to the trigger condition.

According to a second aspect of the present invention, there is provided apparatus for processing an FPGA prototype design file, the apparatus comprising:

the acquisition module is configured for acquiring a design file of an FPGA prototype and a list file of signals to be debugged;

the marking module is configured to query and mark the signals to be debugged in the list file in the design file by using a first batch script;

the first updating module is configured to update a preset constraint file based on a signal to be debugged in the list file to generate a first constraint file;

the synthesis module is configured to perform design synthesis on the first constraint file and the design file through a synthesis tool to generate a synthesized netlist;

the screening module is configured to screen the signal to be debugged in the list file by using the comprehensive netlist to obtain the signal to be debugged which is not optimized;

the second updating module is configured to update the first constraint file based on the screened signal to be debugged which is not optimized so as to generate a second constraint file;

and the bit stream generation module is configured to execute placement and routing based on the synthesized netlist and the second constraint file to generate a placement and routing netlist, and generate the FPGA bit stream by using the placement and routing netlist.

the tagging module is further configured to:

In some embodiments, the screening module is further configured to:

In some embodiments, the apparatus further comprises:

the burning module is configured to burn the FPGA bit stream into the FPGA;

the adding module is configured to run a bit stream in the FPGA and add a trigger condition to at least one un-optimized signal to be tested according to a test requirement;

and the debugging module is configured to respond to the trigger condition to take effect in the debugging process, and then perform problem analysis and positioning based on the waveform corresponding to the trigger condition.

According to a third aspect of the present invention, there is also provided a computer apparatus comprising:

at least one processor; and

and the storage is used for storing a computer program capable of running on the processor, and the processor executes the processing method of the FPGA prototype design file when executing the program.

According to a fourth aspect of the present invention, there is also provided a computer-readable storage medium storing a computer program which, when executed by a processor, performs the aforementioned processing method of the FPGA prototype design file.

According to the processing method of the FPGA prototype design file, the signals to be debugged are automatically marked, the signals to be debugged are automatically judged and processed, the signals to be optimized in the debugging process are found, the processes of personnel watching and manually judging whether the signals are optimized are omitted, the labor cost is saved, the debugging time can be shortened more efficiently, the verification efficiency of the FPGA prototype can be improved, and the research and development cost is obviously reduced.

In addition, the processing device, the computer device and the computer-readable storage medium for the FPGA prototype design file provided by the present invention can also achieve the above technical effects, and are not described herein again.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by using the drawings without creative efforts.

Fig. 1 is a flowchart illustrating a method 100 for processing an FPGA prototype design file according to an embodiment of the present invention;

fig. 2 is a flowchart illustrating a method 200 for processing an FPGA prototype design file according to another embodiment of the present invention;

FIG. 3 is a flowchart illustrating a signal validity determination according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of a processing apparatus for an FPGA prototype design file according to another embodiment of the present invention;

fig. 5 is an internal structural view of a computer device in another embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the following embodiments of the present invention are described in further detail with reference to the accompanying drawings.

It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are used for distinguishing two entities with the same name but different names or different parameters, and it should be noted that "first" and "second" are merely for convenience of description and should not be construed as limitations of the embodiments of the present invention, and they are not described in any more detail in the following embodiments.

In one embodiment, referring to fig. 1, the present invention provides a method 100 for processing an FPGA prototype design file, the method comprising the following steps:

step 101, acquiring a design file of an FPGA prototype and a list file of signals to be debugged;

in this embodiment, the design file refers to a corresponding code file in a version of the design release. The design will continually iterate over versions as the project runs. The design version needs to be controlled to ensure the quality of the design. The design file of the FPGA prototype may be a design file for implementing various functions, and the design file may be in various formats such as rtl format and the like. Various signals needing debugging are described in a list file, for example, a clock domain signal A and the auxiliary information of the signal, such as the clock domain, the number of the signals, the path of a module file to which the signal belongs, and the like are described in a certain list file. Where the ancillary information of the signal can be used to find and locate from a design file.

102, inquiring and marking a signal to be debugged in the list file in the design file by using a first batch script;

in this embodiment, the first batch script may be written in various programming languages, and the script may automatically open the list file and the design file when running, and may implement the marking function as mentioned above during the running process of the script.

103, updating a preset constraint file based on a signal to be debugged in the list file to generate a first constraint file;

104, carrying out design synthesis on the first constraint file and the design file through a synthesis tool to generate a synthesized netlist;

105, screening the signal to be debugged in the list file by using the comprehensive netlist to obtain the signal to be debugged which is not optimized;

step 106, updating the first constraint file to generate a second constraint file based on the screened signal to be debugged which is not optimized;

and 107, executing layout and routing based on the comprehensive netlist and the second constraint file to generate a layout and routing netlist, and generating the FPGA bit stream by using the layout and routing netlist.

in step 102, querying and marking the signal to be debugged in the list file in the design file by using the first batch script specifically includes:

In some embodiments, the step 105 of screening, by using the synthesized netlist, the signal to be debugged in the list file to obtain a signal to be debugged that is not optimized specifically includes:

in this embodiment, the second batch script may be written in various programming languages, and when running the script, the script can automatically open the list file and synthesize the netlist, and during running the script, the above-mentioned functions of finding and signal matching can be implemented.

In this embodiment, all signals to be debugged that do not exist after synthesis are recorded in the optimization report, and a research and development worker can refer to the report to assist in debugging in a later research, development and debugging process.

In some embodiments, the method further comprises:

burning the FPGA bit stream into an FPGA;

In another embodiment, in order to facilitate understanding of the technical solution of the present invention, the following describes in detail an FPGA prototype debugging process with FPGA prototype verification in a development process as an application background, and please refer to fig. 2, this embodiment provides another processing method 200 for an FPGA prototype design file, and the specific implementation manner is as follows:

step 201, loading a new design file issued by a designer, a list file to be debugged and a file of signal auxiliary information; in the following step 204, a corresponding debug ILA core is generated according to the file. The list file may be in the following format:

clock domain A

Total number of signals N

Signal file path A

Signal 1

Signal 2

…

Clock domain B

Total number of signals N

Signal file path B

Signal 1

Signal 2

…

And step 202, finishing the marking work of the signal needing debugging by using the first script. Here, calling Python script to find out the signal to be observed in the design file issued by the designer and marking, the marking result is exemplified as follows:

(* DONT_TOUCH= “TRUE”*)(* mark_debug=“true” *) input [23:0] din_data,

(* DONT_TOUCH= “TRUE”*) (* mark_debug=“true” *)input din_sop,

(* DONT_TOUCH= “TRUE”*) (* mark_debug=“true” *)input din_eop,

(* DONT_TOUCH= “TRUE”*) (* mark_debug=“true” *)input din_valid,

the specific operation is to add ([ mark _ debug = "TRUE") to the front of the signal to be observed in the code, and simultaneously, to add ([ DONT _ TOUCH = "TRUE") to prevent the signal from being optimized in the synthesis process; completing character string matching and completing mark storage in the script, wherein the process needs to complete marking of files where all signals are located. It should be noted that mark _ debug and don _ TOUCH function are different, where mark _ debug is used for signal marking for debugging, and the parameter is true in lower case; DONT _ TOUCH is a mechanism that prevents the synthesis tool from optimizing the signal during the synthesis process. Is also a kind of identification. Design synthesis first converts HDL code into various logic gate circuits. Secondly, mapping the gate circuit after RTL analysis to the physical structure of the FPGA device (the structure relation of the FPGA with LUT, RAM and the like). After the combination, the 'gate' circuit can not be seen, but the combination of various structures. This process, even if marked don _ TOUCH, may result in the signal desired to be observed not being found after synthesis.

In the implementation process, the code of the first script refers to the following:

import os

a = os

with open (os.path.join (a., "xxxxx/rtl _ release/file a.v.)," r ") as:// get file a under the current path and set the attribute of file a to readable state to file a with a code number f

read lines = f

Close ()// close file A indicates the end of reading the file

w = open (os.path.join (a, "xxxxx/rtl _ release/file a.v"), "w")// open file a is set to a writable state

for line in read_lines:

line_srtip = line.strip()

if line_strip == “input din_sop”

line = line.replace(“input din_sop”,”(* DONT_TOUCH= “TRUE”*) (* mark_debug=“true” *)input din_sop”)

w.write(line)

……

else

w.write(line)

w.close

The purpose of the// for line in read _ lines loop is to compare signals from all lines of the previously read file A, and if the lines need to be identified are found, character replacement is carried out, and if the lines do not match, the original content is kept.

And step 203, carrying out design synthesis by using a synthesis tool, namely starting a vivado command to carry out design synthesis, wherein the synthesis input file of the step is the new design file after the identification obtained in the step two. It should be noted that vivado is development software in the field of FPGA, design synthesis, layout and wiring, bit file generation, downloading and debugging in the example are all performed in the software, and a netlist file with circuit information, i.e. a synthesized netlist, is generated after synthesis.

Step 204: and opening the synthesized netlist generated after synthesis, reading the signal to be debugged and observed through the batch processing script, and effectively judging the signal to generate an optimization report of the signal.

Referring to fig. 3, a process for implementing signal validity determination is as follows:

(1) opening a netlist of the integrated design: open _ run syth _ 1-name syth _ 1;

(2) acquiring a net get _ nets signal A of a clock domain A signal list;

(3) obtaining a return result and judging according to the result;

(4) the current clock domain is circulated and ended;

the principle of the above steps (1) to (4) is to obtain all signals of the clock domain currently required to be processed from the design file of step 201, and then to sequentially synthesize the netlist to find out whether the signals exist. If the signal exists, the constraint file is written according to the appointed mode. If the signal can be found in the netlist then the signal is not optimized, if the execute acquire signal command returns an error then the signal is still optimized by the tool.

Preferably, an optimization report can be generated at the end of the cycle in the specific implementation process, the optimization report is used for recording which signals cannot be debugged and observed due to optimization, and a debugger can refer to the content of the optimization report in the subsequent debugging process.

Step 205, repeating step 204 until the signals of all clock domains are processed, waiting for all signals to be processed to generate a new constraint file, and executing step 205 to obtain an example of the constraint file as follows:

open_run syth_1 –name syth_1

create_debug_core u_ila_0 labtools_ila_v3

set_property ALL_PROBE_SAME_MU true [get_debug_cores u_ila_0]

set_property ALL_PROBE_SAME_MU_CNT 4 [get_debug_cores u_ila_0]

set_property C_ADV_TRIGGER true [get_debug_cores u_ila_0]

set_property C_DATA_DEPTH 1024 [get_debug_cores u_ila_0]

set_property C_EN_STRG_QUAL true [get_debug_cores u_ila_0]

set_property C_INPUT_PIPE_STAGES 0 [get_debug_cores u_ila_0]

set_property C_TRIGIN_EN false [get_debug_cores u_ila_0]

set_property C_TRIGOUT_EN false [get_debug_cores u_ila_0]

set_property port_width 1 [get_debug_ports u_ila_0/clk]

connect_debug_port u_ila_0/clk [get_nets [list clk_IBUF_BUFG]]

set_property port_width 24 [get_debug_ports u_ila_0/probe0]

connect_debug_port u_ila_0/probe0 [get_nets [list {din_data[0]} {din_data[1]} {din_data[2]} {din_data[3]} {din_data[4]} {din_data[5]} {din_data[6]} {din_data[7]} {din_data[8]} {din_data[9]} {din_data[10]} {din_data[11]} {din_data[12]} {din_data[13]} {din_data[14]} {din_data[15]} {din_data[16]} {din_data[17]} {din_data[18]} {din_data[19]} {din_data[20]} {din_data[21]} {din_data[22]} {din_data[23]}]]

set_property C_USER_SCAN_CHAIN 1 [get_debug_cores dbg_hub]

and step 206, performing layout and wiring, wherein design optimization can be completed in the step by calling vivado, and a layout and wiring netlist can be generated after contents such as physical optimization, physical layout and physical wiring are performed. The physical optimization is an important means for improving fan-out and readjusting time sequence through copying and moving registers at the back end so as to optimize the time sequence, and generally runs between physical layout and physical wiring; the physical layout is a process of placing all integrated circuit elements in the FPGA according to the constraint file; physical routing is the process of routing between the various elements after physical placement is completed.

In step 207, a bit file (file) containing the debugging content can be further generated by using the placement and routing netlist in step 206.

And step 208, burning, namely burning the bit file generated in the step 207 into the FPGA.

Step 209, performing verification debugging, for example, a debugging person may set a trigger condition according to a debugging requirement to perform debugging, may observe a waveform of a signal during the debugging process, and observe the waveform to perform problem analysis and positioning after the trigger becomes effective.

The processing method of the FPGA prototype design file at least has the following beneficial technical effects: the method and the device realize automatic completion of marking of debugging signals, automatic judgment and processing of whether the signals needing debugging are optimized or not, thereby finding the signals optimized in the comprehensive process, shortening the time for realizing debugging more efficiently and being beneficial to improving the verification efficiency of the FPAG model.

In another embodiment, referring to fig. 4, the present invention further provides an apparatus 300 for processing an FPGA prototype design file, the apparatus comprising:

an obtaining module 301, configured to obtain a design file of an FPGA prototype and a list file of signals to be debugged;

a marking module 302 configured to query and mark the signal to be debugged in the list file in the design file by using a first batch script;

a first updating module 303, configured to update a preset constraint file based on a signal to be debugged in the list file to generate a first constraint file;

a synthesis module 304 configured to perform design synthesis on the first constraint file and the design file through a synthesis tool to generate a synthesized netlist;

a screening module 305 configured to screen the signal to be debugged in the list file by using the synthesized netlist to obtain a signal to be debugged which is not optimized;

a second updating module 306, configured to update the first constraint file based on the filtered signal to be debugged that is not optimized to generate a second constraint file;

a bitstream generation module 307 configured to perform place and route based on the synthesized netlist and the second constraint file to generate a place and route netlist, and generate an FPGA bitstream using the place and route netlist.

Above-mentioned processing apparatus of FPGA prototype design file has realized the mark of the automatic debugging signal that accomplishes, and the signal that needs the debugging is judged and handled automatically, finds the signal that optimizes among the debugging process, has saved personnel's on duty and has judged the process that whether the signal is optimized manually and has saved the cost of labor, can shorten debugging time more high-efficiently, helps promoting the verification efficiency of FPGA prototype, is showing and reduces the research and development cost.

the tagging module 302 is further configured to:

In some embodiments, the screening module 305 is further configured to:

In some embodiments, the apparatus further comprises:

the burning module is configured to burn the FPGA bit stream into the FPGA;

It should be noted that, for specific limitations of the processing device for the FPGA prototype design file, reference may be made to the above limitations of the processing method for the FPGA prototype design file, and details are not described herein again. The various modules in the processing means of the FPGA prototype design file described above may be implemented in whole or in part by software, hardware, and combinations thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

According to another aspect of the present invention, a computer device is provided, the computer device may be a server, and the internal structure thereof is shown in fig. 5. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements the method of processing the FPGA prototype design file described above.

According to a further aspect of the present invention, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of processing an FPGA prototype design file as described above.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method for processing an FPGA prototype design file, the method comprising:

2. The method according to claim 1, wherein the list file comprises the signal name of each signal to be debugged and the path of the module file to which the signal belongs;

3. The method according to claim 2, wherein the step of screening the signal to be debugged in the list file by using the synthesized netlist to obtain the signal to be debugged which is not optimized comprises:

4. The method of claim 1, further comprising:

burning the FPGA bit stream into an FPGA;

5. An apparatus for processing an FPGA prototype design file, the apparatus comprising:

6. The apparatus of claim 5, wherein the list file comprises a signal name of each signal to be debugged and a path of the module file;

the tagging module is further configured to:

7. The apparatus of claim 6, wherein the screening module is further configured to:

8. The apparatus of claim 5, further comprising:

the burning module is configured to burn the FPGA bit stream into the FPGA;

9. A computer device, comprising:

at least one processor; and

a memory storing a computer program operable in the processor, the processor when executing the program performing the method of any of claims 1-4.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, is adapted to carry out the method of any one of claims 1 to 4.