An optimization method and device of a DFT flow, electronic equipment and storage medium

Abstract

The present disclosure provides a DFT flow optimization method, device, electronic equipment and storage medium, belonging to the technical field of design for testability. The DFT flow optimization method comprises: obtaining configuration data of a design for testability DFT flow of a preset data mode; checking the configuration data before generating a DFT script for the DFT flow; and generating the DFT script based on the configuration data that passes the check. In this way, by checking the configuration data, potential errors are located in real time, and data defects are intercepted before script generation.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of design for test (DFT), and particularly relates to a DFT flow optimization method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the increasing complexity of chip design, the importance of design for test (DFT) in the chip development process is increasingly prominent. In the development process of a chip integrated with DFT design, engineers need to configure and generate corresponding test scripts for electronic design automation (EDA) tools to execute, so as to implement DFT logic on the chip, such as inserting scan chains, memory built-in self-test (MBIST), etc.

[0003] However, the traditional DFT flow faces many challenges in practice. In the early stage of the project, DFT engineers usually need to manually collect a large amount of project information and chip parameters, such as process nodes, module quantities, power domains, clock frequencies, etc. In addition, engineers also need to manually write various test scripts based on the collected information and personal experience.

[0004] These errors introduced in the early stage of data collection and script writing are often not discovered until the subsequent verification stage. Once the problem is discovered, the engineer needs to return to the early stage to modify the parameters or scripts, resulting in multiple iterations, which not only occupies valuable engineering resources, but also seriously prolongs the entire project cycle. Therefore, how to improve the information collection and verification efficiency and accuracy in the early stage of the DFT flow, and reduce human errors, has become a technical problem to be solved in the field. SUMMARY

[0005] The present disclosure provides a DFT flow optimization method, device, electronic equipment and storage medium, which can intercept data defects before script generation, avoiding invalid DFT flow due to incorrect configuration data.

[0006] The technical solution of the present disclosure is implemented as follows:

[0007] In a first aspect, the present disclosure provides a DFT flow optimization method, which comprises: obtaining configuration data of a design for test (DFT) flow of a preset data pattern; verifying the configuration data before generating a DFT script for the DFT flow; and generating the DFT script based on the configuration data that passes the verification. In this way, by verifying the configuration data, potential errors are located in real time, and data defects are intercepted before script generation.

[0008] In some embodiments, the checking comprises at least one of the following: integrity checking, consistency checking, reasonableness checking, or conflict checking. The multi-dimensional checking is performed on the configuration data, thereby ensuring the accuracy of the data from multiple perspectives.

[0009] In some embodiments, the checking comprises consistency checking, and the checking is performed on the configuration data before generating the DFT script for the DFT process, comprising:

[0010] Before generating the DFT script for the DFT process, it is checked whether the information of the associated parameters in the configuration data is consistent. Thus, the problem of missing key parameters in the manual input process is solved, and the checking algorithm traverses all the key fields in the standardized table to ensure that there is no missing (i.e., non-empty) and the format conforms to the preset specification.

[0011] In some embodiments, the checking comprises integrity checking, and the checking is performed on the configuration data before generating the DFT script for the DFT process, comprising:

[0012] Before generating the DFT script for the DFT process, it is detected whether the preset key fields in the configuration data meet the corresponding preset rules. Thus, the logical contradictions that may exist between different data sources, which are easily ignored in manual checking, are solved, and the checking algorithm performs logical relationship judgment across tables or fields.

[0013] In some embodiments, the checking comprises reasonableness checking, and the checking is performed on the configuration data before generating the DFT script for the DFT process, comprising:

[0014] Before generating the DFT script for the DFT process, a machine learning model trained based on historical DFT project data is used to detect whether the plurality of parameters of the configuration data are within a reasonable range. Thus, whether the data is "reasonable" is judged by using the technical conventions, physical and logical limits in the field, to find errors that although the format is correct but the numerical value is obviously abnormal.

[0015] In some embodiments, the checking comprises conflict checking, and the checking is performed on the configuration data before generating the DFT script for the DFT process, comprising:

[0016] Before generating the DFT script for the DFT process, the plurality of parameters and their associated relationships in the configuration data are constructed into a knowledge graph; and according to the knowledge graph, it is detected whether there is a semantic logical conflict in the configuration data. Thus, it is ensured that the key parameters that need to be unique are not repeatedly defined or used, or there is a deeper logical conflict.

[0017] In some embodiments, the preset data mode includes a standardized form for collecting at least one of the following configuration data: project basic configuration information, chip design parameters and test requirements, library file list, or electronic design automation (EDA) tool configuration list. This preset data mode structures and standardizes the data required by the DFT flow, which is a technical prerequisite for subsequent verification and script generation.

[0018] In a second aspect, the disclosure provides a DFT flow optimization device, which includes an acquisition part, a verification part, and a generation part. The acquisition part is configured to acquire configuration data of a design for test (DFT) flow of a preset data mode. The verification part is configured to verify the configuration data before generating a DFT script for the DFT flow. The generation part is configured to generate the DFT script based on the verified configuration data.

[0019] In a third aspect, the disclosure provides an electronic device, which includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, the steps of the DFT flow optimization method according to the first aspect are implemented.

[0020] In a fourth aspect, the disclosure provides a computer-readable storage medium, which stores a program or instruction. When the program or instruction is executed by a processor, the steps of the DFT flow optimization method according to the first aspect are implemented.

[0021] In a fifth aspect, the disclosure provides a computer program product, which includes a computer program or instruction. When the computer program product is executed on a processor, the processor executes the computer program or instruction to implement the steps of the DFT flow optimization method according to the first aspect.

[0022] In a sixth aspect, the disclosure provides a chip, which includes a processor and a communication interface coupled to the processor. The processor is configured to execute a program or instruction to implement the DFT flow optimization method according to the first aspect.

[0023] The disclosure provides a DFT flow optimization method. By using a preset data mode to structurally acquire configuration data required by a DFT flow, such as using a standardized form, and performing a multi-dimensional verification of the configuration data before generating a DFT script, potential errors are immediately located, and data defects are intercepted before script generation, thereby avoiding invalid DFT flows caused by incorrect configuration data. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1An application environment schematic diagram of a DFT flow optimization method provided by the present disclosure.

[0025] Figure 2 A flowchart schematic diagram of a DFT flow optimization method provided by the present disclosure.

[0026] Figure 3 A flowchart schematic diagram of another DFT flow optimization method provided by the present disclosure.

[0027] Figure 4 A schematic diagram of a knowledge graph provided by the present disclosure.

[0028] Figure 5 A structural block diagram of a DFT flow optimization device provided by the present disclosure.

[0029] Figure 6 A hardware structure schematic diagram of an electronic device provided by the present disclosure. DETAILED DESCRIPTION

[0030] The technical solutions in the embodiments of the present disclosure will be described in detail below with reference to the drawings in the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art belong to the scope of protection of the present disclosure.

[0031] The technical solutions of the embodiments of the present disclosure aim to optimize the DFT flow in integrated circuit design. The DFT flow usually involves complex configuration, script writing and use of expensive EDA tools.

[0032] Please refer to Figure 1 , Figure 1 An application environment schematic diagram of a DFT flow optimization method provided by the present embodiment, which can include a DFT management system 100 and one or more EDA tool systems 120 (only one is shown in the figure). Figure 1

[0033] The DFT management system 100 can be a server, workstation or personal computer, on which a DFT full flow management software tool 110 is installed and run. The DFT full flow management software tool 110 is the main execution carrier of the DFT flow optimization method described in the embodiments of the present disclosure, which is responsible for centralized collection and automatic verification of all necessary configuration data in the early stage of the DFT flow, i.e. before calling the EDA tool system 120 to perform the main DFT tasks such as logic synthesis and test insertion.

[0034] ​EDA tool system 120 represents the industry standard DFT implementation and verification tools, which are responsible for executing the DFT scripts generated by DFT management system 100 to complete specific DFT implementation and verification tasks such as boundary scan configuration, MBIST insertion, scan chain insertion, etc.

[0035] In the embodiments of the present disclosure, DFT full-process management software tool 110 ensures the quality of the data and scripts delivered to EDA tool system 120 through standardized data input and pre-processed automatic verification, thereby avoiding execution failure and rework due to low-level data errors such as parameter omission, path error, and configuration conflict in the expensive EDA tool execution phase, and solving the problem of returning to modify after discovering problems in the traditional DFT process.

[0036] Based on the above application environment, the embodiments of the present disclosure provide a DFT process optimization method, which is integrated in DFT full-process management software tool 110 of DFT management system 100 and executed.

[0037] Referring to Figure 2 , Figure 2 is a flowchart of a DFT process optimization method provided by the embodiments of the present disclosure. The DFT process optimization method can include the following steps S201 to S203.

[0038] In step S201, configuration data of a DFT process of a preset data mode is obtained.

[0039] The configuration data is various design parameters required in a chip design project, which can include project basic configuration information, chip design parameters, library file list, or tool configuration list, etc.

[0040] In order to solve the problem of information collection confusion and easy omission in the traditional process, the embodiments of the present disclosure first define a preset data mode. The preset data mode converts the original unstructured experience scattered in different stages or different documents into machine-readable, structured data fields, data types, and constraint relationships. In some implementable manners, the preset data mode can be embodied in a series of standardized table templates in form, which cover all project information and chip parameters required by the DFT process. The preset data mode can also be implemented by JSON, XML, or Web form, and the specific form of the preset data mode is not limited in the present disclosure.

[0041] In some implementable manners, the preset data mode is a standardized table for collecting at least one of item basic configuration information, chip design parameters and test requirements, library file list, or electronic design automation (EDA) tool configuration list, the configuration data is collected by using four standardized tables, and a DFT engineer fills in all the configuration data required by a DFT project according to the defined standardized tables. Then, when the DFT full-process management software tool 110 is executed, the standardized tables are first read and imported as inputs for subsequent verification and script generation.

[0042] The item basic configuration information, as shown in Table 1, includes a project name, a chip type, a chip quantity, and the like.

[0043] Table 1: Item basic configuration information

[0044]

[0045] The exemplary item basic configuration information shown in Table 1 includes three columns, namely, an entry, content, and a description. The entry lists various parameters included in the item basic configuration information, the content lists corresponding values of the parameters, and the description indicates meanings of the parameters.

[0046] The chip design parameters and test requirements, as shown in Table 2, include a chip name, a process node, a chip area, a module quantity, a general input / output quantity, a register quantity, whether multiple chips, and the like.

[0047] Table 2: Chip design parameters and test requirements

[0048]

[0049] The exemplary chip design parameters and test requirements shown in Table 2 include three columns, namely, an entry, content, and a description. The entry lists various parameters included in the chip design parameters and test requirements, the content lists corresponding values of the parameters, and the description indicates meanings of the parameters. The table covers key data such as process information, design size, test complexity, coverage target, and milestone.

[0050] The library file list includes view types, paths, and corresponding files of various types of standard cell libraries, memory libraries, input / output libraries, analog intellectual property core libraries, and the like, and provides required library file indexes for subsequent EDA tools (such as synthesis, layout and routing, simulation, and test insertion). As exemplarily shown in Table 3, the library file list includes library names of memory libraries, input / output libraries, analog intellectual property core libraries, and the like, corresponding view types, paths, and corresponding files.

[0051] Table 3: Library file list

[0052]

[0053] The EDA tool configuration list, as shown in Table 4, includes various types of EDA tools and related information thereof.

[0054] Table 4 EDA tool configuration list

[0055]

[0056] The exemplary EDA tool configuration list shown in Table 4 contains five columns, namely entry, content, module, path and information, and records various types of EDA tools to be used in the project and related information thereof, which provides basic data for subsequent automatic script generation, tool call chain configuration and environment deployment.

[0057] It should be noted that the above-mentioned standardized table is only an example of a preset data mode. In other embodiments, the preset data mode can also be implemented by other structured data formats, such as an extensible markup language (XML) file, a JavaScript object notation (JSON) file, or a specific data table in a database. In actual applications, it can also be other standardized and machine-readable data structures, which are not limited in the present disclosure.

[0058] In step S202, the configuration data is checked before generating the DFT script for the DFT flow.

[0059] In the embodiment of the present disclosure, after obtaining the configuration data, the script is not immediately generated, but the internally integrated verification algorithm is first called to automatically verify the configuration data in multiple dimensions. The verification dimensions can include integrity verification, consistency verification, reasonableness verification and conflict verification.

[0060] The integrity verification aims to solve the problem that key parameters are easily missed in the manual input process. The verification algorithm will traverse all the key fields in the standardized table to ensure that there is no missing, i.e., the key field is not empty, and its format conforms to the preset specification. The consistency verification aims to solve the logical contradictions that may exist between different data sources, which is easily ignored in manual checking. The verification algorithm will perform logical relationship judgment across tables or fields. The reasonableness verification aims to judge whether the data is "reasonable" by using the technical convention in the field, physical and logical limitations, to find errors that although the format is correct but the values are obviously abnormal. The conflict verification aims to ensure that the key parameters that need to be kept unique are not repeatedly defined or used, or there is a deeper logical conflict.

[0061] In step S203, the DFT script is generated based on the configuration data that passes the verification.

[0062] The timing of the verification of the configuration data can be before the graphical user interface (GUI) of the DFT full flow management software tool 110 is opened. If the verification fails, then no subsequent operation based on the configuration data is allowed to be performed on the GUI interface, and a verification report is outputted, which explicitly marks the error items and provides corresponding modification suggestions. The report can be a text file (.log), an HTML file, or a printout in the console.

[0063] Exemplarily, the outputted report is as follows:

[0064] Logical consistency check failed:

[0065] Error item: parameter 'isMultiChip' (in 'chip_info.xlsx');

[0066] Error value: 'Yes';

[0067] Conflict item: parameter 'chip number' (in 'project_info.xlsx');

[0068] Conflict value: '1';

[0069] Modification suggestion: please confirm whether the project is a single-chip design. If so, please change 'isMultiChip' to 'No'.

[0070] Data rationality check failed:

[0071] Error item: 'total register number' (in 'chip_info.xlsx');

[0072] Error value: '50000';

[0073] Verification value (sum of each module): '45000';

[0074] Modification suggestion: please check whether the total register number or the register number of each module is filled in incorrectly.

[0075] After the check passes, the structured configuration data that passes the check is used as input, such as a standardized table, to automatically generate a DFT script required for subsequent EDA tool system 120 execution. The automatically generated DFT script includes at least one of the following: a boundary scan configuration script, an MBIST insertion script, or a scan chain insertion script. The boundary scan configuration script can automatically generate a configuration script of boundary scan logic (for example, a BSDL file) that conforms to the Joint Test Action Group (JTAG) standard according to information such as the number of GPIOs, input / output library types, and the like in the standardized table. The MBIST insertion script can automatically generate a Tool Command Language (Tcl) script for inserting an MBIST controller in an EDA tool according to information such as the memory ratio, module information, and memory library information (for example,.lib,.v file paths) in the standardized table. The scan chain insertion script can automatically generate a configuration script for performing scan chain insertion and compression in an EDA tool according to information such as the number of registers, clock frequency, number of power domains, test coverage requirements, and the like in the standardized table.

[0076] Because these scripts are generated based on strictly checked data, for example, library file paths are guaranteed to be valid, power domain configurations are guaranteed to be conflict-free, and the number of registers is guaranteed to be reasonable, the quality of the scripts is much higher than that of scripts written manually, and the scripts can be directly imported into an EDA tool for execution, thereby significantly reducing the number of iterations in which errors are found during EDA tool execution and returned for modification, thereby shortening the project cycle.

[0077] Embodiments of the present disclosure structurally obtain configuration data required for a DFT flow by using a preset data mode, and perform multidimensional pre-checking on the configuration data before generating a DFT script, thereby immediately locating potential errors and intercepting data defects before script generation, and avoiding invalid DFT flows caused by erroneous configuration data.

[0078] In some embodiments, as shown in FIG. 3, Figure 3 The optimization method for the DFT flow provided by the present disclosure includes the following steps S301 to S307.

[0079] In step S301, configuration data of a DFT flow of a preset data mode is obtained.

[0080] In step S302, before a DFT script for the DFT flow is generated, it is checked whether information of associated parameters in the configuration data is consistent.

[0081] The process is to perform consistency check in the verification, and the consistency check corresponds to a verification algorithm performing logical relationship judgment across standardized tables or across fields. In a specific example, the consistency check includes checking whether the “multi-chip” parameter in the configuration data is consistent with the chip quantity information, specifically, the algorithm reads the value of the “chip quantity” field in Table 1, if the value is “1”, indicating a single-chip project, the algorithm will cross-check whether the “multi-chip” parameter in Table 2 is correctly set to “No”, if the two are inconsistent, for example, the chip quantity is 1, but the “multi-chip” is “Yes”, the verification will fail. In other examples, the consistency check can also include checking whether the declared “used tools” are all defined in the “tool configuration list”; checking whether the declared “library files” all exist in the “library list”; checking whether the number of design projects in different tables is consistent (for example, the total number of design projects in Table 1 is 10, but Table 2 fills in 11, which is inconsistent); checking whether the chip names in different tables are consistent, etc. In the consistency check process, the verification algorithm is a static rule set according to the content included in the standardized table.

[0082] In step S303, before generating the DFT script for the DFT flow, it is detected whether the preset key fields in the configuration data meet the corresponding preset rules.

[0083] The process is to perform integrity check in the verification, and the integrity check corresponds to a verification algorithm that traverses all key fields in the standardized table to ensure that they are not missing and their format conforms to the preset specification. In a specific example, the integrity check rule includes that only letters, numbers and underscores are allowed in the milestone name, so whether the milestone name only contains letters, numbers and underscores, then the integrity check passes, otherwise it does not pass. The check rule is only an example, and more check rules can be included, which will not be described here.

[0084] In step S304, a machine learning model trained based on historical DFT project data is used to detect whether the plurality of parameters of the configuration data are within a reasonable range.

[0085] The process is to perform reasonableness check in the verification, and the reasonableness check corresponds to a verification algorithm that can be a static rule, such as an exemplary static rule including checking whether the register quantity of a single module in the configuration data is consistent with the total register quantity, by traversing the “register quantity of a single module” in the standardized table and summing them up, and then comparing the sum with the total register quantity field, if the two are inconsistent, it means that the data entry has an error, and the verification will fail. The verification of this kind of static rule depends on the threshold or logic set by the engineer in advance.

[0086] Since the rationality check based on static rules cannot capture the hidden, non-obvious inter-relationships among multiple variables. For example, a static rule can allow the range of "power domain number" to be 1 to 12, however, this static threshold cannot determine whether a specific value is "reasonable" in a specific context.

[0087] Therefore, a machine learning model trained based on historical DFT project data detects whether multiple parameters of the configuration data are within a reasonable range. The historical DFT project data is the configuration data corresponding to a plurality of successfully taped-out DFT projects in the past, which is stored in a database during actual project operation, i.e., the historical table 1 to table 4.

[0088] The machine learning model can be an anomaly detection model, such as an isolation forest or a variational autoencoder. The machine learning model learns the complex, nonlinear relationships among the historical DFT project data in the training phase, such as process node, chip area, memory ratio, power domain number, etc.

[0089] In the execution of the rationality check, the configuration data of the current project is extracted as a feature vector, and input into the pre-trained machine learning model, and the machine learning model calculates an anomaly score.

[0090] A specific example is as follows: suppose the configuration data includes the following parameters: process node: 7nm, chip area: X, memory ratio: Y, power domain number: 10, and suppose the static rule corresponding to the rationality check is to allow "power domain number" to be 1 to 12. Therefore, the value of 10 passes the static rule check.

[0091] However, after analyzing the historical DFT project data, the machine learning model can learn a hidden pattern: "under the 7nm process, when the chip area is X and the memory ratio is Y, the reasonable range of 'power domain number' of all historical successful projects is between 3 and 5".

[0092] Therefore, the machine learning model will identify that the value of "10" deviates significantly from the data distribution of successful projects learned from the historical DFT project data. Therefore, the machine learning model outputs a high anomaly score. The high anomaly score indicates that the check fails, and the report output marks this item as a high-risk anomaly and prompts "power domain number is 10, deviates from the historical projects (range 3-5) with similar configurations (7nm, X, Y), please confirm whether the configuration is required by the design".

[0093] This dynamic rationality check based on machine learning models is no longer a simple static rule, but learns deeper logical relationships between data from historical data, thus making the rationality check results more accurate.

[0094] In step S305, before generating the DFT script for the DFT process, multiple parameters in the configuration data and their relationships are constructed into a knowledge graph.

[0095] In step S306, based on the knowledge graph, it is detected whether there are semantic and logical conflicts in the configuration data.

[0096] This process involves conflict checking during the validation process. The validation algorithm for this conflict checking can be a static rule. For example, an exemplary static rule might include checking whether the design identifier in the configuration data is unique. This is a simple database query-based validation used to prevent low-level naming conflicts. However, this static rule approach cannot validate cross-domain logical conflicts. For instance, a parameter may be valid on its own, but its combination with other parameters might be logically contradictory in the DFT design.

[0097] To address this issue, in some embodiments, the conflict verification can also be a semantic verification. Specifically, multiple parameters in the configuration data and their relationships are constructed into a knowledge graph. After the configuration data is imported, the knowledge graph is dynamically constructed in memory at the start of the verification. The configuration data is parsed, and key parameters, such as clock, power domain, scan chain, library files, tools, etc., are created as nodes in the knowledge graph. The relationships between them, such as "belongs to", "uses", "type", etc., are created as edges in the graph.

[0098] By querying the knowledge graph to identify semantic and logical conflicts in the configuration data, queries can be implemented using graph database query languages ​​(such as SPARQL or Cypher) or custom graph traversal algorithms.

[0099] Specific examples are as follows, such as Figure 4 As shown, this diagram is an example of a knowledge graph used for semantic logic conflict verification in an embodiment of this disclosure. This knowledge graph consists of nodes ( Figure 4 (represented by rectangles in the text), relationships ( Figure 4 (indicated by arrows) and attributes ( Figure 4 The system is composed of ellipses and is determined from the configuration data. The nodes include: clock A, clock B, power domain 1, power domain 2, and scan chain A. The relationships include: clock used, belonging to, and type. The attributes include: synchronous and asynchronous.

[0100] according to Figure 4It can be seen that clock A belongs to power domain 1, clock B belongs to power domain 2, and power domain 1 and power domain 2 are both asynchronous, that is, they are asynchronous power domains, the type of scan chain A is configured as synchronous, and clock A and clock B are used at the same time.

[0101] A preset semantic rule query is performed on the knowledge graph, for example, a reasoning task, the preset semantic rule is defined as: “a synchronous type of scan chain must use all clocks from the same synchronous clock domain”, by traversing the path in Figure 4 , it is found that scan chain A (synchronous) uses clock A, clock A belongs to power domain 1, power domain 1 (asynchronous); scan chain A (synchronous) uses clock B, clock B belongs to power domain 2, power domain 2 (asynchronous); it is determined that there is a high-order semantic logic conflict: a scan chain defined as “synchronous” incorrectly uses two clocks from different “asynchronous” power domains. This logic error in the DFT design level cannot be found by any static rule-based check, because it needs to comprehensively reason about multiple parameters (clock, power domain, scan chain) and their mutual relationships (belongs to, uses, type). The semantic checking based on the knowledge graph can find deeper semantic logic errors, so that the checking result is more accurate.

[0102] Exemplarily, the output report is:

[0103] Machine learning rationality check failed (high risk):

[0104] Abnormal item: parameter 'number of power domains' (located in 'chip_info.xlsx');

[0105] Abnormal value: '10';

[0106] Related configuration: 'process node = 7nm', 'chip area = X', 'Memory ratio = Y';

[0107] Modification suggestion: detected as a high-risk abnormal value, according to historical data, the reasonable range of the number of power domains under this configuration is (3-5).

[0108] Knowledge graph conflict check failed (serious):

[0109] Conflict item:'scan chain A';

[0110] Conflict reason: semantic logic conflict;

[0111] Details:'scan chain A' (type = synchronous) incorrectly uses a clock from an asynchronous power domain;

[0112] 'clock A' (used for'scan chain A') is located in 'power domain 1' (type = asynchronous);

[0113] Clock B (for scan chain A) is located in Power Domain 2 (type = asynchronous);

[0114] Modification suggestion: Please check the clock configuration of'scan chain A' or the power domain type of 'power domain 1' or 'power domain 2'.

[0115] In step S307, based on the configuration data passed the verification, a DFT script is generated.

[0116] It should be noted that the description of steps S301 and S307 refers to the description of steps S201 and S203 described above, and will not be repeated here.

[0117] Figure 5 The structure block diagram of an optimization device for a DFT flow shown in the present disclosure is as shown in Figure 5 The structure block diagram of an optimization device for a DFT flow shown in the present disclosure is as shown in

[0118] In some embodiments, the verification includes at least one of the following: integrity verification, consistency verification, rationality verification, or conflict verification.

[0119] In some embodiments, the verification part 502 is configured to check whether the information of the associated parameters in the configuration data is consistent before generating the DFT script for the DFT flow.

[0120] In some embodiments, the verification part 502 is configured to detect whether the preset key fields in the configuration data meet the corresponding preset rules before generating the DFT script for the DFT flow.

[0121] In some embodiments, the verification part 502 is configured to detect whether the plurality of parameters of the configuration data are within a reasonable range by using a machine learning model trained based on historical DFT project data before generating the DFT script for the DFT flow.

[0122] In some embodiments, the verification part 502 is configured to construct a plurality of parameters and their associated relationships in the configuration data into a knowledge graph before generating the DFT script for the DFT flow; and according to the knowledge graph, detect whether there is a semantic logic conflict in the configuration data.

[0123] In some embodiments, the preset data mode includes a standardized form for collecting configuration data of at least one of the following: project basic configuration information, chip design parameters and test requirements, library file list, or electronic design automation (EDA) tool configuration list.

[0124] In the embodiments of the present disclosure, each part can implement the optimization method of the DFT flow provided by the above-mentioned method embodiments, and achieve the same technical effects. To avoid repetition, it will not be described here.

[0125] Reference Figure 6 The embodiments of the present disclosure also provide an electronic device, which can be Figure 6 The DFT management system 100 shown in the specific implementation, for example, a server, workstation, personal computer (PC), notebook computer or any other device capable of performing computing tasks.

[0126] Reference Figure 6 , Figure 6 is a hardware structure block diagram of an electronic device provided by the embodiments of the present disclosure. The electronic device can include one or more processors 610, such as a central processing unit (CPU), a graphics processing unit (GPU), or an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). The processor 610 is responsible for executing instructions stored in the memory 620.

[0127] A memory 620, such as a read-only memory (ROM), a random access memory (RAM), a hard disk drive (HDD), or a solid state drive (SSD).

[0128] A communication interface 630 for communicating with other devices (e.g. Figure 1 The EDA tool system 120) through, for example, Ethernet, Wi-Fi, etc.

[0129] An input / output interface 640 for interacting with a user, such as connecting a keyboard, mouse, display, etc.

[0130] In the memory 620, there is a computer program (e.g., DFT full flow management software tool 110). When the processor 610 is configured to execute the computer program, the electronic device is configured to implement steps such as the DFT flow optimization method.

[0131] For example, the processor 610 implements the functions of the various parts shown in the drawings when executing a computer program. Figure 5

[0132] The function of the obtaining part 501 is implemented by the communication interface 630, and configuration data is obtained based on a preset data mode (for example, a standardized table stored in the memory 620).

[0133] The function of the checking part 502 is implemented by calling a checking algorithm (including the static rules, machine learning model and knowledge graph reasoning of the method embodiments described above) to automatically check the obtained configuration data before the GUI is opened.

[0134] The function of the generating part 503 is implemented based on the configuration data that passes the check, and a DFT script is automatically generated.

[0135] In addition, those skilled in the art can understand that the structure of the electronic device shown in the above drawings does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than shown, or combine certain components, or different component arrangements. For example, the electronic device also includes a display screen, a camera assembly, a microphone, a speaker, a radio frequency circuit, an input unit, a sensor such as an acceleration sensor, an angular velocity sensor, a light sensor, etc., an audio circuit, a Wi-Fi module, a power supply, a Bluetooth module, and the like. Components are not described here.

[0136] The present disclosure also provides a computer-readable storage medium storing at least one instruction for being executed by a processor to implement the optimization method of the DFT process according to the various embodiments described above.

[0137] The present disclosure also provides a computer program product including computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the electronic device to perform the optimization method of the DFT process according to the various embodiments described above.

[0138] The present disclosure also provides a chip including a processor and a communication interface, the communication interface and the processor being coupled, the processor being configured to run a program or instructions to implement the various processes of the optimization method of the DFT process according to the embodiments described above, and achieve the same technical effects. To avoid repetition, details are not described here.

[0139] It should be understood that the chip mentioned in the embodiments of the present disclosure can also be referred to as a system-level chip, a system chip, a chip system, or a system-on-chip, etc.

[0140] ​In several embodiments provided by the present disclosure, it should be understood that the disclosed system, device, server and method can be implemented in other manners. For example, the described device embodiments are merely illustrative. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different units, can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0141] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0142] In addition, each functional unit in the various embodiments of the present disclosure can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0143] The integrated unit, if implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present disclosure essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, and various media that can store program codes.

[0144] Those skilled in the art should realize that the functions described in the one or more examples described above can be implemented in hardware, software, firmware or any combination thereof. When implemented in software, the functions can be stored in a computer readable medium or transmitted as one or more instructions or codes on a computer readable medium. The computer readable medium includes computer storage medium and communication medium, wherein the communication medium includes any medium that facilitates the transfer of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

[0145] It should be noted that the technical solutions disclosed in the present disclosure can be combined arbitrarily without conflict.

[0146] The above merely describes a specific implementation of the present disclosure, but the protection scope of the present disclosure is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the present disclosure, which should be covered within the protection scope of the present disclosure.

Claims

1. A method for optimization of a DFT procedure, characterized in that, The optimization method of the DFT flow comprises: obtaining configuration data of a design for test DFT flow of a preset data mode; checking the configuration data before generating a DFT script for the DFT flow; generating the DFT script based on the configuration data that passes the check; wherein the checking of the configuration data comprises: constructing a plurality of parameters and their associated relationships in the configuration data into a knowledge graph, wherein nodes of the knowledge graph at least include clock nodes, power domain nodes and scan chain nodes, and edges of the knowledge graph at least include belonging relationships and usage relationships; detecting whether there is a semantic logic conflict in the configuration data according to the knowledge graph; the detection of whether there is a semantic logic conflict in the configuration data according to the knowledge graph comprises: traversing the knowledge graph to locate a scan chain node configured as a synchronous attribute; tracking clock nodes used by the scan chain node configured as the synchronous attribute based on the usage relationships, and tracking power domain nodes to which the clock nodes belong based on the belonging relationships; if it is determined that a plurality of clock nodes used by the scan chain node configured as the synchronous attribute belong to different power domain nodes configured as asynchronous attributes, it is determined that there is a semantic logic conflict in the configuration data.

2. The method of claim 1, wherein, The check comprises at least one of integrity check, consistency check, rationality check or conflict check.

3. The method of claim 2, wherein, The check comprises consistency check, and the checking of the configuration data before generating the DFT script for the DFT flow comprises: checking whether information of associated parameters in the configuration data is consistent before generating the DFT script for the DFT flow.

4. The method of Claim 2, wherein, The check comprises integrity check, and the checking of the configuration data before generating the DFT script for the DFT flow comprises: detecting whether preset key fields in the configuration data meet corresponding preset rules before generating the DFT script for the DFT flow.

5. The method of Claim 2, wherein, The check comprises rationality check, and the checking of the configuration data before generating the DFT script for the DFT flow comprises: detecting whether a plurality of parameters of the configuration data are within a reasonable range by using a machine learning model trained based on historical DFT project data before generating the DFT script for the DFT flow.

6. The method of Claim 1, wherein, The preset data mode comprises a standardized table for collecting at least one of the following configuration data: project basic configuration information, chip design parameters and test requirements, library file list or electronic design automation EDA tool configuration list.

7. An apparatus for optimization of a DFT flow, characterized by The optimization device of the DFT flow comprises an obtaining part, a checking part and a generating part; the obtaining part is configured to obtain configuration data of a design for test DFT flow of a preset data mode; the checking part is configured to check the configuration data before generating a DFT script for the DFT flow; the generating part is configured to generate the DFT script based on the configuration data that passes the check; wherein the checking of the configuration data comprises: A plurality of parameters in the configuration data and their associated relationships are constructed into a knowledge graph, nodes of the knowledge graph at least include clock nodes, power domain nodes and scan chain nodes, edges of the knowledge graph at least include belonging-to relationships and using relationships; According to the knowledge graph, it is detected whether there is a semantic logic conflict in the configuration data; The detection of whether there is a semantic logic conflict in the configuration data according to the knowledge graph comprises: Traversing the knowledge graph, a scan chain node configured as a synchronous attribute is located; Based on the using relationship, a clock node used by the scan chain node is tracked, and based on the belonging-to relationship, a power domain node to which the clock node belongs is tracked; If it is determined that a plurality of clock nodes used by the scan chain node configured as the synchronous attribute respectively belong to different power domain nodes configured as asynchronous attributes, it is determined that there is a semantic logic conflict in the configuration data.

8. An electronic device, comprising: The computer readable storage medium stores programs or instructions, which are executed by the processor to implement the steps of the optimization method of the DFT flow as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores programs or instructions, which are executed by the processor to implement the steps of the optimization method of the DFT flow as claimed in any one of claims 1 to 6.

Images