Verification method and device for performance of FPGA comprehensive tool and readable storage medium
By obtaining the test device resources, a collection of test cases is generated and a comprehensive process of different conditions is implemented, the problem of cumbersome verification of the performance of FPGA comprehensive tools in the existing technology is solved, and the performance of FPGA comprehensive tools is achieved quickly and conveniently verification.
Patent Information
- Application Number
- CN202411310460.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-19
- Publication Date
- 2024-12-31
AI Technical Summary
In the prior art, verifying the performance of FPGA comprehensive tools requires the introduction of additional superior performance reference FPGA comprehensive tools, which are cumbersome and inconvenient.
By obtaining the resource situation of the test device, a collection of test cases is generated, and a comprehensive process of different memory limitations, different levels and different methods is performed on the test device to verify the operation stability, resource optimization, timing processing of the FPGA comprehensive tool to be tested and Resource balance performance.
It realizes simple and fast verification of the performance of FPGA comprehensive tools, avoids the introduction of additional FPGA comprehensive tools, provides a variety of verification methods, and improves verification efficiency and accuracy.
Smart Images

Figure CN119226163A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to FPGA technology, and more particularly to a method, device and readable storage medium for verifying the performance of an FPGA synthesis tool. Background Art
[0002] The design process of Field Programmable Gate Array (FPGA) mainly includes design input, synthesis optimization, layout and routing, among which the synthesis step is crucial. Therefore, high-quality FPGA synthesis tools play an indispensable and important role in ensuring the promotion and application of FPGA and market competitiveness. Correspondingly, how to verify the performance of FPGA synthesis tools becomes very important.
[0003] In the related art, to verify the performance of an FPGA synthesis tool, it is often necessary to introduce a reference FPGA synthesis tool with superior performance, and then use the performance of the reference FPGA synthesis tool to verify the performance of the FPGA synthesis tool.
[0004] However, this method requires the introduction of new FPGA synthesis tools, so the operation is limited and very cumbersome. Summary of the invention
[0005] The present application provides a method, device and readable storage medium for verifying the performance of an FPGA synthesis tool, which can simply and quickly verify the performance of the FPGA synthesis tool.
[0006] In a first aspect, the present application provides a method for verifying the performance of an FPGA synthesis tool. The verification method comprises: Acquiring the ownership status of resources in the test device, and acquiring test cases according to the ownership status of the resources to obtain a test case set; Perform at least one of the following verifications on the FPGA synthesis tool to be tested on the test device based on the test cases in the test case set: Execute the synthesis process on the test case under different memory constraints to verify the running stability performance of the FPGA synthesis tool to be tested; execute the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested; execute the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested; execute the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested.
[0007] In a second aspect, the present application provides a device for verifying the performance of an FPGA synthesis tool, comprising: a memory and a processor, wherein the memory is used to store an executable program; The processor is used to read and execute the executable program to implement the FPGA synthesis tool performance verification method as described above.
[0008] In a third aspect, the present application provides a method for verifying the performance of an FPGA synthesis tool, wherein the computer-readable storage medium stores computer executable commands, and the computer executable commands are used to execute the method for verifying the performance of an FPGA synthesis tool as described above.
[0009] Compared with the related art, the embodiment of the present application obtains the ownership of resources in the test device, and obtains test cases according to the ownership of the resources to obtain a test case set; based on the test cases in the test case set, at least one of the following verifications is performed on the test device for the FPGA synthesis tool to be tested: executing the synthesis process on the test case under different memory restrictions to verify the running stability performance of the FPGA synthesis tool to be tested; executing the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested; executing the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested; executing the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested. The embodiment of the present application provides different verification methods for verifying the FPGA synthesis tool starting from the performance of the FPGA synthesis tool, avoiding the introduction of additional FPGA synthesis tools, thereby realizing the verification of the performance of the FPGA synthesis tool in a simple and fast way.
[0010] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by implementing the present application. Other advantages of the present application can be realized and obtained by the schemes described in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The accompanying drawings are used to provide an understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.
[0012] Figure 1 A flowchart of a method for verifying the performance of an FPGA synthesis tool according to an embodiment of the present application; Figure 2 A flowchart of another FPGA synthesis tool performance verification method according to an embodiment of the present application; Figure 3 A flowchart of another FPGA synthesis tool performance verification method according to an embodiment of the present application; Figure 4A flowchart of another FPGA synthesis tool performance verification method according to an embodiment of the present application; Figure 5 A flowchart of another FPGA synthesis tool performance verification method according to an embodiment of the present application; Figure 6 A schematic diagram of the structure of a verification platform for the performance of an FPGA synthesis tool according to an embodiment of the present application; Figure 7 A schematic diagram of a case generation process of a case library module in an embodiment of the present application; Figure 8 A schematic diagram of a verification process of a memory limit module according to an embodiment of the present application; Fig. 9 A schematic diagram of the verification process of a balance verification module according to an embodiment of the present application. DETAILED DESCRIPTION
[0013] The present application describes multiple embodiments, but the description is exemplary rather than restrictive, and it is obvious to those skilled in the art that there may be more embodiments and implementations within the scope of the embodiments described in the present application. Although many possible feature combinations are shown in the drawings and discussed in the specific embodiments, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with any other feature or element in any other embodiment, or may replace any other feature or element in any other embodiment.
[0014] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in the present application may also be combined with any conventional features or elements to form a unique invention scheme defined by the claims. Any features or elements of any embodiment may also be combined with features or elements from other invention schemes to form another unique invention scheme defined by the claims. Therefore, it should be understood that any feature shown and / or discussed in the present application may be implemented individually or in any appropriate combination. Therefore, except for the limitations made according to the attached claims and their equivalents, the embodiments are not subject to other restrictions. In addition, various modifications and changes may be made within the scope of protection of the attached claims.
[0015] In addition, when describing representative embodiments, the specification may have presented the method and / or process as a specific sequence of steps. However, to the extent that the method or process does not rely on the specific order of the steps described herein, the method or process should not be limited to the steps of the specific order described. As will be understood by those of ordinary skill in the art, other sequences of steps are also possible. Therefore, the specific sequence of the steps set forth in the specification should not be interpreted as a limitation for the claims. In addition, the claims for the method and / or process should not be limited to the steps of performing them in the order written, and those skilled in the art can easily understand that these sequences can be changed and still remain within the spirit and scope of the embodiments of the present application.
[0016] In recent years, with the rapid development of integrated circuit technology, FPGA has been widely used in the fields of Internet of Things, aerospace, artificial intelligence, etc. through the design and implementation of supporting electronic design automation (EDA) software due to its rich logic resources, high integration, and flexible design. The design process of FPGA mainly includes design input, comprehensive optimization, layout and routing, among which the synthesis step is crucial. Synthesis is the process of converting register transfer level RTL (Register-Transfer Level) circuits (circuits described by hardware language) to gate-level circuits, providing netlist input for layout and routing, which directly affects the difficulty of layout and routing. High-quality synthesis tools play an indispensable and important role in ensuring the promotion and application of FPGA and its market competitiveness. Therefore, ensuring the quality of synthesis tools has become a technical problem that needs to be solved urgently by technicians in this field.
[0017] In the related art, to verify the performance of an FPGA synthesis tool, it is often necessary to introduce a reference FPGA synthesis tool with superior performance, and then use the performance of the reference FPGA synthesis tool to verify the performance of the FPGA synthesis tool.
[0018] To this end, the present application embodiment provides a method for verifying the performance of an FPGA synthesis tool, such as Figure 1 As shown, the verification method includes: Step 101: Acquire the ownership status of resources in the test device, and acquire test cases according to the ownership status of the resources to obtain a test case set; Step 102: Based on the test cases in the test case set, at least one of the following verifications is performed on the test device for the FPGA synthesis tool to be tested: executing the synthesis process on the test case under different memory constraints to verify the running stability performance of the FPGA synthesis tool to be tested; executing the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested; executing the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested; executing the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested.
[0019] When executing the synthesis process on the test device, it is necessary to consider the resource ownership of the test device itself, otherwise it is easy to cause the test case to occupy too many resources and fail to complete the synthesis process execution. The resource ownership of the test device can refer to the ownership of the digital signal processor (DSP) resources, block static random access memory (BSRAM) resources, logic resources, and register resources in the test device. Acquiring test cases based on the ownership of the resources may refer to test cases in which DSP resources do not exceed the DSP resource upper limit of the test device, BSRAM resources do not exceed the BSRAM resource upper limit of the test device, logic resources do not exceed the logic resource upper limit of the test device, and register resources do not exceed the register resource upper limit of the test device; it may also refer to test cases in which DSP resources exceed the DSP resource upper limit of the test device, BSRAM resources do not exceed the BSRAM resource upper limit of the test device, but do not exceed the total resource upper limit of the test device after executing the comprehensive process; it may also refer to test cases in which DSP resources do not exceed the DSP resource upper limit of the test device, BSRAM resources exceed the BSRAM resource upper limit of the test device, but do not exceed the total resource upper limit of the test device after executing the comprehensive process; it may also refer to test cases in which DSP resources exceed the DSP resource upper limit of the test device, BSRAM resources exceed the BSRAM resource upper limit of the test device, but do not exceed the total resource upper limit of the test device after executing the comprehensive process.
[0020] For example, assuming that the test device is a 4K test device, including: 4 DSP resources, 8 BSRAM resources, 4000 logic resources and 4000 register resources, the test case includes: 5 DSP resources, 8 BSRAM resources, 1000 logic resources and 2000 register resources. The DSP resources in the test case exceed the DSP resource upper limit of the test device, but the excess DSP resources will be converted into logic resources during execution and flow. Therefore, as long as the converted logic resources do not exceed the logic resource upper limit of the test device, the test case can be obtained as one of the test case collections.
[0021] The verification performed on the FPGA synthesis tool to be tested may be any one of all the verification types mentioned above, or any several of all the verification types mentioned above, or all the verification types mentioned above. When one or more of the verification types mentioned above are performed on the FPGA synthesis tool to be tested, the performance verification corresponding to the selected verification type can be achieved, and when all the verification types mentioned above are performed on the FPGA synthesis tool to be tested, the comprehensive performance can be achieved, that is, the test of the running stability performance, resource optimization performance, timing processing performance and resource balance performance.
[0022] The method for verifying the performance of an FPGA synthesis tool provided in an embodiment of the present application obtains the ownership of resources in a test device, and obtains test cases based on the ownership of the resources to obtain a test case set; based on the test cases in the test case set, at least one of the following verifications is performed on the test device for the FPGA synthesis tool to be tested: executing a synthesis process on the test case under different memory restrictions to verify the running stability performance of the FPGA synthesis tool to be tested; executing a synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested; executing a synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested; executing a synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested. The embodiment of the present application provides different verification methods for verifying the FPGA synthesis tool starting from the performance of the FPGA synthesis tool, avoiding the introduction of additional FPGA synthesis tools, thereby realizing the verification of the performance of the FPGA synthesis tool in a simple and quick way.
[0023] In an exemplary embodiment, when the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested, such as Figure 2 As shown, the step of verifying the content may include: Step 201: Utilize the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtain first test case information of the test case after executing the synthesis process; Step 202: Determine the type and number of primitives to be balanced in the test case according to the number of each primitive required in the test case and the upper limit of the number of each primitive in the test device; Step 203: traverse and select primitives that match the type and number of the primitives to be balanced in the test case to obtain different primitive balancing schemes, and determine the priority of all primitive balancing schemes according to the size of resources required for balancing; Step 204: Use the FPGA synthesis tool to execute the synthesis process for the test cases under the primitive balancing schemes with priorities from high to low in turn, obtain the second use case information of the test cases after each execution of the synthesis process, and verify the resource balancing performance of the FPGA synthesis tool to be tested based on the comparison between the second use case information of the test cases after each execution of the synthesis process and the first use case information.
[0024] For example, assuming that the test device is a 4K test device, including: 4 DSP resources, 8 BSRAM resources, 4000 logic resources and 4000 register resources, and the test case includes: 5 DSP resources, 8 BSRAM resources, 1000 logic resources and 2000 register resources, then it can be seen that there is 1 DSP primitive that needs to be balanced, that is, the type of primitive to be balanced is DSP, and the number is 1.
[0025] For example, assuming that the test device is a 4K test device, including: 4 DSP resources, 8 BSRAM resources, 4000 logic resources and 4000 register resources, and the test case includes: 3 DSP resources, 10 BSRAM resources, 1000 logic resources and 2000 register resources, then it can be seen that there are 2 BSRAM primitives that need to be balanced, that is, the type of primitive to be balanced is BSRAM, and the number is 2.
[0026] Since the primitives to be balanced are only a part of the primitives in the test case, different primitive balancing schemes can be obtained by traversing and selecting primitives that match the types and numbers of the primitives to be balanced in the test case.
[0027] For example, assuming that the primitives to be balanced in the test case are DSP primitives, and the number is 2, and there are 4 DSP primitives in the test case (represented as DSP primitive 1, DSP primitive 2, DSP primitive 3 and DSP primitive 4 respectively), the following primitive balancing schemes can be obtained: Primitive balancing scheme 1, balance DSP primitive 1 and DSP primitive 2, balancing scheme 2, balance DSP primitive 1 and DSP primitive 3, balancing scheme 3, balance DSP primitive 1 and DSP primitive 4, balancing scheme 4, balance DSP primitive 2 and DSP primitive 3, balancing scheme 5, balance DSP primitive 2 and DSP primitive 4, balancing scheme 6, balance DSP primitive 3 and DSP primitive 4.
[0028] For another example, suppose that the primitives to be balanced in the test case are DSP primitives and BSRAM primitives, with the numbers being 2 and 1 respectively. There are 4 DSP primitives in the test case (represented as DSP primitive 1, DSP primitive 2, DSP primitive 3 and DSP primitive 4 respectively), and 2 BSRAM primitives (represented as BSRAM primitive 1 and BSRAM primitive 2 respectively). Therefore, the following primitive balancing schemes can be obtained: Primitive balancing scheme 1, balance DSP primitive 1, DSP primitive 2, and BSRAM primitive 1; balancing scheme 2, balance DSP primitive 1, DSP primitive 3, and BSRAM primitive 1; balancing scheme 3, balance DSP primitive 1, DSP primitive 4, and BSRAM primitive 1; balancing scheme 4, balance DSP primitive 2, DSP primitive 3, and BSRAM primitive 1 Balance, balancing plan five, balance DSP primitive 2, DSP primitive 4, and BSRAM primitive 1, balancing plan six, balance DSP primitive 3, DSP primitive 4, and BSRAM primitive 1, primitive balancing plan seven, balance DSP primitive 1, DSP primitive 2, and BSRAM primitive 2, balancing plan eight, balance DSP primitive 1, DSP primitive 3, and BSRAM primitive 2, balancing plan nine, balance DSP primitive 1, DSP primitive 4, and BSRAM primitive 2, balancing plan ten, balance DSP primitive 2, DSP primitive 3, and BSRAM primitive 2, balancing plan eleven, balance DSP primitive 2, DSP primitive 4, and BSRAM primitive 2, balancing plan twelve, balance DSP primitive 3, DSP primitive 4, and BSRAM primitive 2.
[0029] Determining the priorities of all primitive balancing solutions according to the size of resources required for balancing in step 203 may refer to determining the priorities of all primitive balancing solutions from high to low according to the size of resources required for balancing. The balancing principles followed in the process of determining the priorities are as follows:
[0030] The balancing principles for DSP primitives are as follows: Principle 1: When a test case needs to balance a DSP primitive, and the DSP primitives in the test case include 9X9 type DSP primitives and 18X18 type primitives, the 9X9 type DSP is balanced first; Principle 2: When a DSP primitive needs to be balanced in a test case, and the DSP primitives in the test case are of the same type but different bit widths, for example, they are all 9X9 type DSP primitives, one type of DSP primitive is 6-bit width x 8-bit width, and the other type of DSP primitive is 8-bit width x 8-bit width, then the 6-bit width x 8-bit width DSP primitive shall be balanced first.
[0031] The balancing principles for BSRAM primitives are as follows: Principle 1: When a BSRAM primitive needs to be balanced in a test case, and the BSRAM primitives in the test case are ROM type primitives and single-port BSRAM, the ROM type primitives are prioritized for balancing; Principle 2: When a test case needs to balance one BSRAM primitive, and the BSRAM resources in the test case are single-port BSRAMs with different bit widths, one type of BSRAM has a bit width of 8 and the other type of BSRAM has a bit width of 16, the BSRAM with a bit width of 8 is prioritized for balancing.
[0032] That is, in the balancing principle involving BSRAM primitives, ROM type primitives are prioritized, followed by single-port or pseudo-dual-port, and then BSRAM primitives of the same type are balanced for small bit width primitives.
[0033] In an exemplary embodiment, the test case includes: a top-level module and at least one sub-module, and the first test case information includes: module belonging information of each primitive in the test case.
[0034] Step 204 includes: Step 204a, taking the primitive balancing scheme with the highest priority as the current primitive balancing scheme, and performing the following verification operation: adding attribute constraints to the module to which the primitive selected by the current primitive balancing scheme belongs, using the FPGA synthesis tool to execute the synthesis process for the test case under the current primitive balancing scheme to which the attribute constraints have been added, and obtaining the second use case information of the test case that has completed the execution of the synthesis process; using the comparison rule to compare the obtained second use case information with the first use case information to obtain the resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing the synthesis process for the test case under the current primitive balancing scheme, and updating the comparison rule based on the obtained resource balancing performance evaluation result; taking the next primitive balancing scheme as the new current primitive balancing scheme and performing the verification operation until the verification operation is completed for the primitive balancing scheme with the lowest priority; Step 204b: Determine the resource balancing performance of the FPGA synthesis tool to be tested according to the update status of the comparison rule.
[0035] Exemplarily, if it is determined that there is no update based on the update status of the comparison rule, it is determined that the resource balancing performance of the FPGA synthesis tool to be tested is good; if it is determined that there is an update (one update or multiple updates) based on the update status of the comparison rule, it is determined that the resource balancing performance of the FPGA synthesis tool to be tested is poor.
[0036] In an exemplary embodiment, the first use case information further includes: resource information source1 and timing information fmax1; the second use case information includes: resource information source2 and timing information fmax2; The comparison rule includes: comparing whether (source2-source1) / source1 is greater than a first preset threshold, and when (source2-source1) / source1 is not greater than the first preset threshold, comparing whether (fmax2-fmax1) / fmax1 is greater than a second preset threshold.
[0037] In an exemplary embodiment, the comparison of the obtained second use case information and the first use case information using a comparison rule to obtain a resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing a synthesis process on the test case under the current primitive balancing scheme, and updating the comparison rule based on the obtained resource balancing performance evaluation result, includes: When (source2-source1) / source1 is greater than the first preset threshold, determining that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested for executing the synthesis process for the test case under the current primitive balancing scheme is good resource balancing performance, and maintaining the comparison rule based on the resource balancing performance evaluation result with good resource balancing performance; When (fmax2-fmax1) / fmax1 is greater than the second preset threshold, it is determined that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested for executing the synthesis process for the test case under the current primitive balancing scheme is poor resource balancing performance, and the value of fmax2 is assigned to fmax1 to update the comparison rule; When (fmax2-fmax1) / fmax1 is not greater than the second preset threshold, it is determined that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing the synthesis process for the test case under the current primitive balancing scheme is good.
[0038] In an exemplary embodiment, when the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process on the test case under different memory constraints to verify the running stability performance of the FPGA synthesis tool to be tested, such as Figure 3 As shown, the step of verifying the content may include: Step 301, limiting the running memory of the FPGA synthesis tool to be tested to different memory resources respectively, and executing the synthesis process for multiple instances of the test case; Step 302: Determine whether the FPGA synthesis tool to be tested crashes during multiple executions of the synthesis flow, and whether the netlist and log file are changed, so as to verify the operational stability of the FPGA synthesis tool to be tested.
[0039] For example, different memory resources can include 1G, 2G, and 4G memory. The running memory resources of the FPGA synthesis tool are limited to 1G, 2G, 4G and other resource scenarios, and the synthesis process is executed for multiple times for the same case to check whether the FPGA synthesis tool will crash or whether the netlist and log files are different. If a crash occurs, or the netlist or log files are different, it means that the FPGA synthesis tool has defects; if there is no crash and the netlist and log files are the same after multiple executions, it means that the FPGA synthesis tool is stable.
[0040] In an exemplary embodiment, when the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested, such as Figure 4 As shown, the step of verifying the content may include: Step 401: Use the FPGA synthesis tool to be tested to execute the synthesis process on each submodule of the test case respectively, and obtain the resource information of each submodule after the synthesis process is completed; Step 402: Utilize the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtain resource information of each submodule in the test case after the synthesis process is completed; Step 403: for each submodule, respectively compare the differences between the resource information after the submodule has completed two comprehensive process executions; Step 404: determine whether the difference between the resource information of all sub-modules after the synthesis process is executed twice exceeds the resource optimization threshold corresponding to the corresponding sub-module, so as to verify the resource optimization performance of the FPGA synthesis tool to be tested.
[0041] Before synthesizing a test case, first execute the synthesis process on its submodules and record the resource information of the submodules after the synthesis process is completed (assuming there are two submodules, the information resources of the two submodules, such as information values, are represented as S1 and S2 respectively); then execute the synthesis process on the test case and record the resource information of each submodule after the synthesis process is completed (the information resources of the two submodules, such as information values, are represented as top_S1 and top_S2 respectively). Determine whether the difference between the resource information of submodule 1 after the two synthesis process executions, that is, S1 and top_S1, exceeds the resource optimization threshold corresponding to submodule 1, and determine whether the difference between the resource information of submodule 2 after the two synthesis process executions, that is, S2 and top_S2, exceeds the resource optimization threshold corresponding to submodule 2.
[0042] The difference between the resource information after two comprehensive processes of the sub-module are executed can be determined by whether the difference between the two is greater than the corresponding resource optimization threshold.
[0043] For example, the test case (fpag_test) has 3 sub-modules (a, b, c). The synthesis tool first executes the synthesis process for sub-modules a, b, and c respectively and records the resource information after the synthesis process is completed as module a, logic: 1020, BSRAM: 1, DSP: 1; module b, logic: 3000; module c: DSP: 1). Then the synthesis process is executed on the test case and the resource information of each sub-module is parsed as module a: logic 500, BSRAM: 1, DSP: 1; module b: logic: 2000; module c: 1DSP). By comparing the resource information of sub-modules a, b, and c of fpga_test with the resource information of separate synthesis sub-modules a, b, and c, it is found that the resources of each module have not increased after the execution of the fpga_test synthesis process, indicating that the comprehensive resource optimization test has passed; if the resource information after the execution of the fpga_test synthesis process is module a: logic 500, BSRAM: 1, DSP: 1; module b: logic: 4000; module c: logic: 1000). By comparison, it is found that the resources of module b are much larger than those when synthesized separately, and there is a problem of resource optimization. The types of resources in module c are different, and feedback analysis of DSP inference problems is required.
[0044] The difference between resource information after two synthesis process executions of the sub-module can also be determined by using the formula (top_Si-Si) / Si, that is, when (top_S1-S1) / S1 exceeds the resource optimization threshold corresponding to sub-module 1, or when (top_S2-S2) / S2 exceeds the resource optimization threshold corresponding to sub-module 2, it indicates that there is a problem with the resource optimization performance of the FPGA synthesis tool; when (top_S1-S1) / S1 does not exceed the resource optimization threshold corresponding to sub-module 1 and (top_S2-S2) / S2 exceeds the resource optimization threshold corresponding to sub-module 2, it indicates that there is no problem with the resource optimization performance of the FPGA synthesis tool.
[0045] In an exemplary embodiment, when the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested, such as Figure 5 As shown, the step of verifying the content may include: Step 501: Use the FPGA synthesis tool to be tested to execute the synthesis process on each submodule of the test case, obtain the timing information of each submodule after the synthesis process is completed, and obtain the maximum timing information Max_fmax; Step 502: Utilize the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtain the timing information of each submodule in the test case after the synthesis process is completed, and obtain the maximum timing information top_fmax therein; Step 503: Compare Max_fmax and top_fmax, and verify the timing processing performance of the FPGA synthesis tool to be tested according to the comparison result.
[0046] Exemplarily, if (top_fmax-Max_fmax) / Max_fmax is in the domain value range (derived from empirical values such as between -5% and 5%), it means that the synthesis timing passes; if (top_fmax-Max_fmax) / Max_fmax is not in the domain value range, if top_fmax < Max_fmax, it means that the timing processing performance of the FPGA synthesis tool to be tested is poor, and feedback indicates that there is a timing optimization problem in the synthesis tool; if top_fmax > Max_fmax, then perform equivalence verification of the netlist and the rtl project. If the verification is equivalent, it means that the timing processing performance of the FPGA synthesis tool to be tested is good and the synthesis timing passes. If they are not equivalent, it means that the timing processing performance of the FPGA synthesis tool to be tested is poor, and feedback indicates a synthesis equivalence problem.
[0047] The present application also provides a platform for verifying the performance of an FPGA synthesis tool. Figure 6As shown, it includes: a case library module 61 , a memory restriction module 62 , a resource verification module 63 , a timing verification module 64 and a balance verification module 65 .
[0048] 1. Case library module 61 provides case support for memory limitation module 62, resource verification module 63, timing verification module 64, and balance verification module 65. This module contains cases and stimulus files for various device resources. Test cases can be added / deleted at any time according to needs. It is easy to operate and highly portable. At the same time, this module contains all attribute constraints supported by the synthesis tool. Attribute constraints can be added to test cases according to verification requirements to form new test cases. For example, if the verification requirement is to verify the support of the synthesis tool for the attribute constraint dsp_style, and the attribute constraint value includes dsp and logic, the module will create two attribute files to record these two attribute options, copy the test case at the same time, and place the attribute constraint file in the test case to form a new attribute constraint test case.
[0049] For example, taking the configuration of the attribute value dsp,logic of dspstyle as an example, the case generation process of the case library module can be as follows: Figure 7 As shown, including: Step 701, verify the dspstyle attribute value dsp, logic; Step 702, the attribute constraint file is configured as dspstyle=dsp; Step 703: Place the attribute constraint file into each test case of the regression case module to form a new test case; Step 704: The attribute constraint file is configured as dspstyle=logic; Step 705: Place the attribute constraint file into each test case of the regression case module to form a new test case.
[0050] 2. Memory restriction module 62, by limiting the memory resources when the synthesis tool is running, to check whether the synthesis tool crashes and compare whether the netlists after synthesis are the same. At the same time, this module can be used to simulate the customer's memory operating environment.
[0051] Exemplarily, the memory limit module 62 verification process can be as follows: Figure 8 As shown, including: Step 801, using an FPGA synthesis tool to perform a synthesis process on the test case; Step 802, determine whether the FPGA synthesis tool crashes, if not, execute step 803; Step 803, save the integrated netlist; The synthesized netlist can be saved as normal.vg.
[0052] Step 804, setting the comprehensive tool running memory according to the requirements; Step 805, determine whether the FPGA synthesis tool crashes, if not, execute step 806; Step 806, save the integrated netlist; The synthesized netlist can be saved as case_1.vg.
[0053] Step 807: determine whether the second saved integrated netlists are the same. If they are the same, it indicates that the FPGA synthesis tool runs stably. If they are not the same, it indicates that there are defects in the FPGA synthesis tool.
[0054] 3. Resource verification module 63 is used to assist in providing feedback on the quality of integrated resources. The test cases of this module must meet the requirement that when the top-level submodule is called, there is no parameter passing and no attribute constraint passing. Before integrating a test case, this module first integrates its submodules and saves the resource information of the submodules; then it executes the integration process on the test case and records the resource information of each submodule. Analyze and compare the resource information of each submodule after integration with the resource information of each submodule after separate integration. If the comparison value exceeds the set domain (which can be an empirical value, such as 5%), it means that there is a resource optimization problem in the integration; if it does not exceed the set domain, it means that the integrated resource test has passed.
[0055] 4. Timing verification module 64 is used to assist in providing feedback on the comprehensive timing quality. The test cases of this module must meet the requirement that when the top-level submodule is called, there is no parameter passing and no attribute constraint passing. Before synthesizing a test case, the resource verification module will first execute the synthesis process on its sub-modules, save the timing fmax value of each sub-module, and obtain the maximum value of fmax Max_fmax; then the synthesis process is executed on the test case to obtain the maximum value top_fmax of the timing after the synthesis process is completed. If (top_fmax-Max_fmax) / Max_fmax is in the domain value range (which can be an empirical value, such as between -5% and 5%), it means that the synthesis timing passes; if (top_fmax-Max_fmax) / Max_fmax is not in the domain value range, and top_fmax< Max_fmax, then the feedback is that there is a timing optimization problem in the synthesis tool; if (top_fmax-Max_fmax) / Max_fmax is not in the domain value range, and top_fmax > Max_fmax, then the equivalence verification of the netlist and the rtl project is performed. If they are equivalent, it means that the synthesis timing passes. If they are not equivalent, the synthesis equivalence problem is fed back.
[0056] 5. The verification process of the balance verification module 65 includes the following steps: 1. Case screening: Screen cases where DSP and BSRAM resources are exceeded, but the total number of resources does not exceed the limit after comprehensive balancing.
[0057] 2. Resource record of normal synthesis: Use the synthesis tool to synthesize the case, record the current resource information (source1), timing information (fmax1) and the module where the balancing primitives (DSP, BSRAM) are located.
[0058] 3. Obtain the types and numbers of primitives that need to be balanced through internal commands: Synthesize the design again and add internal commands to the project so that the synthesis tool does not perform balancing and resource checks. Record the types of balanced primitives (DSP, BSRAM) and the modules they are in. At the same time, based on the device resource upper limit, determine the types of primitives that need to be balanced and calculate the number of primitives that need to be balanced.
[0059] 4. Balanced primitive analysis comparison: Analyze primitive types and prioritize them according to primitive types.
[0060] 5. According to the balancing priority, add attribute constraints to the modules or statements corresponding to the primitives, execute the synthesis process, and record the current resource information (source2) and timing information (fmax2).
[0061] 6. Compare source2 with source1, fmax2 with fmax1, as follows: Scenario 1: If (source2-source1) / source1 is greater than the set value (e.g. 5%), it means that the comprehensive tool has a good balancing effect, and step 5 is repeated according to the priority ranking; Scenario 2: If (source2-source1) / source1 is less than or equal to the set value (such as 5%), and (fmax2-fmax1) / fmax1 is greater than the set value (such as 5%), it means that the attribute constraint effect is better than the default balance effect of the synthesis tool. Assign the value of fmax2 to fmax1, record the configuration of the attribute constraint, and repeat step 5 according to the priority sorting; Scenario 3: If (source2-source1) / source1 is less than or equal to the set value (such as 5%), and (fmax2-fmax1) / fmax1 is less than or equal to the set value (such as 5%), it means that the comprehensive tool has a good balancing effect, and step 5 is repeated according to the priority sorting.
[0062] 7. Determine whether the balancing scheme of the comprehensive tool needs to be optimized based on the records of whether there is attribute constraint configuration. If there is attribute constraint configuration, feedback indicates that the balancing function of the comprehensive tool needs to be further optimized; if there is no attribute constraint configuration, it indicates that the balancing function of the comprehensive tool is good.
[0063] Exemplarily, the balance verification module 65 verification process can be as follows: Fig. 9 As shown, including: Step 901, using an FPGA synthesis tool to perform a synthesis process on the test case; Step 902, record the current resource information (source1), timing information (fmax1), the type of primitive to be balanced, and the module where it is located; Step 903: Determine the type and number of primitives to be balanced according to the upper limit of device resources; Step 904: Determine a balancing scheme and a balancing scheme priority according to the type and number of primitives to be balanced; Step 905: Add attribute constraints to the module where the primitive to be balanced in the balancing scheme is located according to the balancing scheme priority; Step 906: Execute the synthesis process for the test case and record the current resource information (source2) and timing information (fmax2); Step 907, determine whether (source2-source1) / source1 is greater than the first set value, if it is greater than the first set value, return to step 905, if it is not greater than the first set value, execute step 908; Step 908, determine whether (fmax2-fmax1) / fmax1 is greater than the second set value, if it is greater than the second set value, execute step 909, if it is not greater than the second set value, return to execute step 905; Step 909, assign fmax2 to fmax1; Step 910: record the attribute constraint configuration and return to execute step 905.
[0064] The FPGA synthesis tool performance verification platform provided in the embodiment of the present application has the advantages of convenience, high efficiency, and easy portability. The synthesis tool is tested through system consistency, functional consistency, resource consistency, etc., to provide guarantees for the functional stability and functional consistency of the synthesis tool and improve the quality of the synthesis tool.
[0065] The embodiment of the present application provides a device for verifying the performance of an FPGA synthesis tool, including: a memory and a processor, wherein the memory is used to store an executable program; The processor is used to read and execute the executable program to implement the method for verifying the performance of the FPGA synthesis tool as described in any of the above embodiments.
[0066] An embodiment of the present application further provides a readable storage medium, on which computer executable commands are stored, and the computer executable commands are used to execute the method for verifying the performance of an FPGA synthesis tool as described in any of the above embodiments.
[0067] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.
Claims
1. A method for verifying the performance of an FPGA synthesis tool, characterized in that: The verification method comprises: Acquiring the ownership status of resources in the test device, and acquiring test cases according to the ownership status of the resources to obtain a test case set; Based on the test cases in the test case set, at least one of the following checks is performed on the test device for the FPGA synthesis tool to be tested: Execute the synthesis process on the test case under different memory constraints to verify the running stability performance of the FPGA synthesis tool to be tested; execute the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested; execute the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested; execute the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested.
2. The verification method according to claim 1, characterized in that: When the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested, the executing the synthesis process on the test case in different ways to verify the resource balancing performance of the FPGA synthesis tool to be tested includes: Utilizing the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtaining first case information of the test case after executing the synthesis process; Determining the type and number of primitives to be balanced in the test case according to the number of each primitive required in the test case and the upper limit of the number of each primitive in the test device; traversing and selecting primitives that match the type and number of the primitives to be balanced in the test case to obtain different primitive balancing schemes, and determining the priority of all primitive balancing schemes according to the size of resources required for balancing; An FPGA synthesis tool is used to execute a synthesis process on test cases under primitive balancing schemes with priorities from high to low in sequence, and second use case information of the test cases after each execution of the synthesis process is obtained. Based on a comparison between the second use case information of the test cases after each execution of the synthesis process and the first use case information, the resource balancing performance of the FPGA synthesis tool to be tested is verified.
3. The verification method according to claim 2, characterized in that: The test case includes: a top-level module and at least one sub-module, and the first test case information includes: module belonging information of each primitive in the test case; The method uses the FPGA synthesis tool to sequentially execute the synthesis process for the test cases under the primitive balancing scheme with the priority from high to low, obtains the second use case information of the test case after each execution of the synthesis process, and verifies the resource balancing performance of the FPGA synthesis tool to be tested based on the comparison between the second use case information of the test case after each execution of the synthesis process and the first use case information, including: The primitive balancing scheme with the highest priority is used as the current primitive balancing scheme, and the following verification operation is performed: attribute constraints are added to the module to which the primitive selected by the current primitive balancing scheme belongs, and the FPGA synthesis tool is used to execute the synthesis process for the test case under the current primitive balancing scheme to which the attribute constraints have been added, and the second use case information of the test case that has completed the execution of the synthesis process is obtained; the obtained second use case information is compared with the first use case information by using a comparison rule to obtain a resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing the synthesis process for the test case under the current primitive balancing scheme, and the comparison rule is updated based on the obtained resource balancing performance evaluation result; the next primitive balancing scheme is used as the new current primitive balancing scheme and the verification operation is performed until the verification operation is completed for the primitive balancing scheme with the lowest priority; The resource balancing performance of the FPGA synthesis tool to be tested is determined according to the update status of the comparison rule.
4. The verification method according to claim 3, characterized in that: The first use case information further includes: resource information source1 and timing information fmax1; the second use case information includes: resource information source2 and timing information fmax2; The comparison rule includes: comparing whether (source2-source1) / source1 is greater than a first preset threshold, and when (source2-source1) / source1 is not greater than the first preset threshold, comparing whether (fmax2-fmax1) / fmax1 is greater than a second preset threshold.
5. The verification method according to claim 4, characterized in that: The method of comparing the obtained second use case information and the obtained first use case information by using a comparison rule to obtain a resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing a synthesis process on the test case under the current primitive balancing scheme, and updating the comparison rule based on the obtained resource balancing performance evaluation result, includes: When (source2-source1) / source1 is greater than the first preset threshold, determining that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested for executing the synthesis process for the test case under the current primitive balancing scheme is good resource balancing performance, and maintaining the comparison rule based on the resource balancing performance evaluation result with good resource balancing performance; When (fmax2-fmax1) / fmax1 is greater than the second preset threshold, it is determined that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested for executing the synthesis process for the test case under the current primitive balancing scheme is poor resource balancing performance, and the value of fmax2 is assigned to fmax1 to update the comparison rule; When (fmax2-fmax1) / fmax1 is not greater than the second preset threshold, it is determined that the resource balancing performance evaluation result of the FPGA synthesis tool to be tested executing the synthesis process for the test case under the current primitive balancing scheme is good.
6. The verification method according to claim 1, characterized in that: When the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process on the test case under different memory restrictions to verify the running stability performance of the FPGA synthesis tool to be tested, the executing the synthesis process on the test case under different memory restrictions to verify the running stability performance of the FPGA synthesis tool to be tested includes: Limiting the running memory of the FPGA synthesis tool to be tested to different memory resources respectively, and executing the synthesis process for multiple instances of the test case; It is determined whether the FPGA synthesis tool to be tested crashes during multiple executions of the synthesis flow, and whether the netlist and log file are changed, so as to verify the running stability performance of the FPGA synthesis tool to be tested.
7. The verification method according to claim 1, characterized in that: When the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested, the executing the synthesis process from different levels of the test case to verify the resource optimization performance of the FPGA synthesis tool to be tested includes: Utilizing the FPGA synthesis tool to be tested to execute the synthesis process on each submodule of the test case respectively, and obtaining the resource information of each submodule after the execution of the synthesis process is completed; Utilizing the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtaining resource information of each submodule in the test case after the synthesis process is completed; For each submodule, the difference between the resource information after the two comprehensive flow executions of the submodule are completed is compared; It is determined whether the difference between the resource information of all sub-modules after the two synthesis processes are executed exceeds the resource optimization threshold corresponding to the corresponding sub-module, so as to verify the resource optimization performance of the FPGA synthesis tool to be tested.
8. The verification method according to claim 1, characterized in that: When the verification of the FPGA synthesis tool to be tested includes: executing the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested, the executing the synthesis process from different levels of the test case to verify the timing processing performance of the FPGA synthesis tool to be tested includes: Utilize the FPGA synthesis tool to be tested to respectively execute the synthesis process on each submodule of the test case, obtain the timing information of each submodule after the execution of the synthesis process is completed, and obtain the maximum timing information Max_fmax therein; Utilize the FPGA synthesis tool to be tested to execute a synthesis process on the test case, and obtain the timing information of each submodule in the test case after the synthesis process is completed, and obtain the maximum timing information top_fmax therein; Max_fmax and top_fmax are compared, and the timing processing performance of the FPGA synthesis tool to be tested is verified according to the comparison result.
9. A device for verifying the performance of an FPGA synthesis tool, characterized in that: include: A memory and a processor, wherein the memory is used to store an executable program; The processor is used to read and execute the executable program to implement the method for verifying the performance of the FPGA synthesis tool as described in any one of claims 1 to 8.
10. A readable storage medium, characterized in that: The readable storage medium stores computer executable commands, and the computer executable commands are used to execute the method for verifying the performance of an FPGA synthesis tool as described in any one of claims 1 to 8.
