Method, apparatus, device, and storage medium for generating a testability design architecture

Abstract

The present disclosure provides a method, apparatus, device and storage medium for generating a testability design architecture, belonging to the technical field of testability design. The method for generating a testability design architecture includes: obtaining project information in a design plan of a chip to be tested; parsing the project information into testability design DFT architecture planning data in a standard data structure; and obtaining module data according to a module hierarchical structure from the DFT architecture planning data and planning to obtain a DFT architecture. In the present disclosure, according to the project information in the design process of the chip to be tested, the required DFT architecture planning data is parsed, and then, according to the hierarchical structure of each module, the DFT architecture is automatically planned, without relying on manual experience, thereby improving the design efficiency and reducing the error rate.

Description

Technical Field

[0001] The present disclosure relates to the technical field of design for testability, and in particular, to a method, apparatus, device, and storage medium for generating a design for testability architecture. Background Art

[0002] With the continuous increase in chip scale and the continuous progress of manufacturing processes, design for testability (DFT) of chips is crucial for chip manufacturing and quality assurance. This technology introduces specific logic and structures during the chip design stage to effectively test the chip after manufacturing and check for manufacturing defects of the chip.

[0003] The design of the DFT architecture is crucial for the entire DFT process. The implementation of DFT is based on the definition of the DFT architecture. The DFT architecture plans the scan test grouping of each module in the chip, whether to plan built-in self-test for on-chip memories in the module, whether to plan boundary scan testing, etc., and is the cornerstone of the entire chip DFT design.

[0004] However, the requirements for engineers in DFT architecture design are very high. Usually, experienced engineers are required to formulate a reasonable DFT architecture according to the actual situation of the project. Summary of the Invention

[0005] The present disclosure provides a method, apparatus, device, and storage medium for generating a design for testability architecture; it can automatically generate a design for testability architecture.

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

[0007] In a first aspect, the present disclosure provides a method for generating a design for testability architecture, the method comprising:

[0008] Obtain project information in the design plan of the chip to be tested; parse the project information into design for testability (DFT) architecture planning data in a standard data structure; and obtain module data according to the module hierarchical structure from the DFT architecture planning data and plan to obtain a DFT architecture. In this way, according to the project information in the design process of the chip to be tested, the required DFT architecture planning data is parsed, and then according to the hierarchical structure of each module, the DFT architecture is automatically planned without relying on manual experience, thereby improving the design efficiency and reducing the error rate.

[0009] In some embodiments, the project information is parsed into testability design (DFT) architecture planning data in a standard data structure, including: determining the divided scan block structure according to the hierarchical information, layout information, and the number of registers. In this way, a scan block structure is planned in the DFT architecture. Each scan block can be tested independently, reducing the length of the scan chain and the volume of test data. In addition, since each scan block can be tested in parallel, a reasonable scan block structure can also improve the test efficiency.

[0010] In some embodiments, the project information is parsed into testability design (DFT) architecture planning data in a standard data structure, including: determining the test grouping of the scan blocks according to the number of general-purpose bidirectional pins on the top layer of the chip under test and the scan block structure. In this way, while multiple modules are being tested synchronously, it can be ensured that no test errors occur due to insufficient top-layer pin numbers.

[0011] In some embodiments, the project information is parsed into testability design (DFT) architecture planning data in a standard data structure, including: determining the on-chip memory built-in self-test tasks for each module according to the memory information in each module. For modules including memories, dedicated memory built-in self-test (MBIST) tasks for memory testing need to be planned to facilitate the testing of memories in subsequent DFT processes.

[0012] In some embodiments, the DFT architecture planning data further includes: boundary scan test tasks; the project information further includes: pin information in each module; parsing the project information into testability design (DFT) architecture planning data in a standard data structure further includes: determining the boundary scan test tasks for each module according to the pin information in each module. For the pins in each module, dedicated boundary scan tasks for pin testing need to be planned to facilitate the testing of pins in subsequent DFT processes.

[0013] In some embodiments, the method for generating a testability design architecture further includes: converting the DFT architecture into a task list in a preset format and outputting it. By outputting the DFT architecture in the form of a task list, for each module, the user can clearly view the test tasks for the layout of each module and the test processes in each type of test task.

[0014] In some embodiments, the method for generating a testability design architecture further includes: converting the DFT architecture into a visual architecture diagram and outputting it. Outputting the DFT architecture diagram in the form of an architecture diagram is more intuitive, and the DFT elements included in each layer under the chip under test can be clearly viewed.

[0015] In some embodiments, the method for generating a design for testability (DFT) architecture further includes: modifying the DFT architecture according to the modification information input by the user. This design that allows user modification is user-friendly. The user can modify project information, architecture diagrams, task lists, etc. as needed. Moreover, when one of the architecture diagram and the task list is modified, the other is updated synchronously, ensuring the consistency between the architecture diagram and the task list.

[0016] In a second aspect, the present disclosure provides an apparatus for generating a design for testability (DFT) architecture. The apparatus includes: an acquisition part, an analysis part, and a planning part. The acquisition part is configured to acquire project information in the design plan of the chip to be tested. The analysis part is configured to parse the project information into DFT architecture planning data in a standard data structure. The planning part is configured to obtain module data according to the module hierarchical structure from the DFT architecture planning data and plan to obtain the DFT architecture.

[0017] In some embodiments of the present disclosure, the analysis part is specifically configured to determine the divided scan block structure according to the hierarchical information, layout information, and the number of register information.

[0018] In some embodiments of the present disclosure, the analysis part is specifically configured to determine the test grouping of the scan blocks according to the number of general-purpose bidirectional pins at the top layer of the chip to be tested and the scan block structure.

[0019] In some embodiments of the present disclosure, the analysis part is specifically configured to determine the on-chip memory built-in self-test task for each module according to the memory information in each module.

[0020] In some embodiments of the present disclosure, the DFT architecture planning data further includes: boundary scan test tasks; the project information further includes: pin information in each module; the analysis part is specifically configured to determine the boundary scan test task for each module according to the pin information in each module.

[0021] In some embodiments of the present disclosure, the apparatus for generating a design for testability (DFT) architecture further includes: a conversion and output part; the conversion and output part is configured to convert the DFT architecture into a task list in a preset format and output it.

[0022] In some embodiments of the present disclosure, the conversion and output part is further configured to convert the DFT architecture into a visual architecture diagram and output it.

[0023] In some embodiments of the present disclosure, the apparatus for generating a design for testability (DFT) architecture further includes: a modification part; the modification part is configured to modify the DFT architecture according to the modification information input by the user.

[0024] In a third aspect, the present 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 method for generating a testability design architecture as described in the first aspect are implemented.

[0025] In a fourth aspect, the present disclosure provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method for generating a testability design architecture as described in the first aspect are implemented.

[0026] In a fifth aspect, the present disclosure provides a computer program product, where the computer program product includes a computer program or instruction. When the computer program product runs on a processor, the processor is caused to execute the computer program or instruction to implement the steps of the method for generating a testability design architecture as described in the first aspect.

[0027] In a sixth aspect, the present disclosure provides a chip under test, which includes a processor and a communication interface. The communication interface is coupled to the processor, and the processor is configured to run a program or instruction to implement the method for generating a testability design architecture as described in the first aspect.

[0028] The present disclosure provides a method for generating a testability design architecture. The method includes: obtaining project information in a design plan of a chip under test; parsing the project information into testability design DFT architecture planning data in a standard data structure; and obtaining module data from the DFT architecture planning data according to a module hierarchical structure and planning to obtain a DFT architecture. In this way, according to the project information in the design process of the chip under test, the required DFT architecture planning data is parsed, and then according to the hierarchical structure of each module, the DFT architecture is automatically planned without relying on manual experience, thereby improving the design efficiency and reducing the error rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 is one of the flow diagrams of the method for generating a testability design architecture provided by the present disclosure;

[0030] Figure 2 is one of the exemplary DFT architecture diagrams provided by the present disclosure;

[0031] Figure 3 is another flow diagram of the method for generating a testability design architecture provided by the present disclosure;

[0032] Figure 4 is another exemplary DFT architecture diagram provided by the present disclosure;

[0033] Figure 5Block diagram of an apparatus for generating a testability design architecture provided by the present disclosure;

[0034] Figure 6 Schematic diagram of the hardware structure of an electronic device provided by the present disclosure. Specific embodiments

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

[0036] A method for generating a testability design architecture provided by the present disclosure will be described in detail below with reference to the accompanying drawings through specific embodiments.

[0037] As Figure 1 shown, the method for generating a testability design architecture may include the following steps S101 to S103.

[0038] In step S101, project information in the design plan of the chip to be tested is obtained.

[0039] Among them, the project information is the design file in the design process of the chip to be tested, and the project information includes: the hierarchical information of the modules in the chip to be tested, the clock information of the modules in the chip to be tested, the number of registers of the modules in the chip to be tested, the general-purpose bidirectional pin (General Purpose Input / Output, GPIO) information available for DFT in the chip to be tested, the power domain information of the chip to be tested, the layout planning information of the chip to be tested, the pin information of the chip to be tested, and other information. The present disclosure provides a visual user interface, and the project information may be input by the user in the user interface.

[0040] The hierarchical information of the modules in the chip under test refers to the organizational structure of different modules inside the chip under test, and how the modules are interconnected and cooperate with each other; the clock information of the modules in the chip under test refers to the clock signals of each module, including clock frequency, clock domain, clock tree structure, etc.; the number of registers of the modules in the chip under test refers to the total number of registers used to store data and control signals in the module; the GPIO information available for DFT in the chip under test refers to the general-purpose input / output ports that can be used for testing purposes; the power domain information refers to the collection of modules that share the same power switch logic within the same voltage domain; the layout planning information is the layout planning in the backend design, which defines the size and shape of the chip under test, as well as the positions and layouts of various modules, hard cores, inputs / outputs, etc. within the chip under test; the pin information refers to the pads or bumps on the chip under test, which are the physical connection points between the chip and the external world; other information such as the process technology, performance indicators, package type, interface specifications, etc. of the chip under test are optional information.

[0041] The project information obtained is usually in a fixed format. In practical applications, since JSON (JavaScript Object Notation) is easy to read and write, and is also easy for machines to parse and generate, the project information is usually stored in JSON format.

[0042] In step S102, the project information is parsed into testability design DFT architecture planning data in a standard data structure.

[0043] Specifically, the modules included in the chip under test are determined from the project information according to the layout information of the chip under test; according to the hierarchical information of the modules, it is determined whether the module is an independent module (referring to a module with an independent function in chip design) or a hierarchical module (referring to a functional module composed of multiple modules). If the module is an independent module or the top-level module in the hierarchical module (the outermost layer in the hierarchical module, integrating all the sub-modules in the hierarchical module), then the module is determined as an independent physical module (tested independently), and the memory information, pin information, etc. of the module included in the project information are parsed, and the DFT architecture planning data of the module is obtained under this module; if the module is a non-top-level module in the hierarchical module, then the upper module where the module is located is determined, and the module is determined as a sub-module of the upper module (not tested independently), and the memory information, pin information, etc. of the module included in the project information are parsed, and the DFT architecture planning data of the module is obtained under this module.

[0044] The finally parsed DFT architecture planning data is used to characterize: each module included in the chip under test is an independent module or a sub-module of a certain module, the memory information and pin information included in each module, whether on-chip memory built-in self-test is planned for each module, whether boundary scan test is planned, which modules can be grouped for testing, and which modules can be tested synchronously.

[0045] The standard data structure is a custom data structure in the present disclosure. The standard data structure is composed of multiple structures. One structure corresponds to a set of data. A set of data can be chip data, module data, DFT process data, DFT architecture data, DFT execution data, etc. For example, the module data includes the clock data, GPIO data, memory data, register quantity data, etc. of the module. This set of data can be boolean variables, strings, arrays, integers, etc.

[0046] The following shows converting all the tools required in the DFT process from the project information into a structure named "flowTool". The set of data included in this structure records the tools used in the DFT process:

[0047] struct flowTool {

[0048] / / dft flow tool info

[0049] QString dftToolName = "tessent";

[0050] QString dftToolModule;

[0051] QString formalToolName = "formality";

[0052] QString formalToolModule;

[0053] QString synToolName = "dc";

[0054] QString synToolModule;

[0055] QString scanToolName = "tessent";

[0056] QString simToolName = "vcs";

[0057] QString simToolModule;

[0058] flowTool(){};

[0059] ~flowTool(){};

[0060] };

[0061] For some members in the structure, default values will be defined. In the case where the members with default values are not assigned in the project information, the default values defined in the structure will be used as the default values of these members. For example, in the "flowTool" structure, if the member "dftToolName" is not assigned in the project information, it will be named "tessent" according to the definition of "dftToolName" in "flowTool"; if the project information includes the value of "dftToolName", it will be named according to the corresponding assignment of "dftToolName" included in the project information.

[0062] The purpose of the custom standard data structure in this disclosure is to be able to efficiently call the project information in the program. In practical applications, different standard data structures can be designed, which is not limited in this disclosure.

[0063] In step S103, from the DFT architecture planning data, module data is obtained according to the module hierarchical structure and the DFT architecture is planned.

[0064] According to the hierarchical structure of the modules, the DFT architecture planning data of each module is obtained layer by layer and the final overall DFT architecture is planned.

[0065] Exemplarily, an array for storing the sub-module information included in the current module is set in the structure corresponding to each module. If there are no sub-modules, this array is empty. The following shows the obtained project information. "usb", "cpu", and "starsp" are listed according to the modules, but after being parsed into DFT architecture planning data, in the DFT architecture planning data, "usb" and "cpu" will be determined as a single physical module (the physical module is tested as an independent module, and a scan package will be inserted during the scan test for testing); while "starsp" is determined as a sub-module of "usb" and "cpu" (the sub-module will not be tested separately and there is no need to insert a scan package). In the structures corresponding to the two modules of "usb" and "cpu", it is determined that the array for storing sub-module information includes "starsp".

[0066] In this way, according to the hierarchical structure of the modules, "usb" and "cpu" are planned first, and then "starsp" is planned, and finally the DFT architecture is obtained.

[0067] {

[0068] "design_type":"standard",

[0069] "designs":{

[0070] "usb":{

[0071] "instance":

[0072] "usb_subsys"

[0073] ,

[0074] "isLayout":"true",

[0075] "FFcount":101000,

[0076] "hasMemory":"true",

[0077] "GPIO_info":"",

[0078] "clock_info"

[0079] },

[0080] "cpu":{

[0081] "instance":

[0082] "cpu_subsys"

[0083] ,

[0084] "isLayout":"true",

[0085] "FFcount":500365,

[0086] "hasMemory":"true",

[0087] "GPI0 info"

[0088] "clock_info":

[0089] },

[0090] "starsp":{

[0091] "instance":

[0092] "cpu_subsys / starsp_inst"

[0093] It should be noted that there seems to be a typo in the original text where "GPI0 info" should probably be "GPIO_info". This has been corrected in the translation."usb_subsys / core_inst / starsp_inst"

[0094] ,

[0095] "isLayout":"false",

[0096] "FFcount":5000,

[0097] "hasMemory":"true",

[0098] "GPIO_info":"",

[0099] "clock_info":""

[0100] },

[0101] }

[0102] }

[0103] Exemplarily, after parsing the above information into DFT architecture planning data, according to the DFT architecture planning data, the obtained DFT architecture diagram is as Figure 2 shown. The black rounded rectangle filled box in the figure is an element included in the DFT architecture, and the remaining white rectangle boxes are the original modules in the chip under test. The central processing unit (CPU) and the universal serial bus (USB) included in the chip under test are regarded as an independent physical module, and the star processor (starsp) is regarded as a sub-module of the CPU and the USB. According to the memory 1 included in the CPU, the memory built-in self-test (MBIST) MBIST 1 for testing the memory 1 and the test control unit 1 for controlling the test process of the CPU are planned; according to the memory 2 included in the starsp, the MBIST 2 for testing the memory 2 and the test control unit 2 for controlling the test process of the starsp are planned. According to the memory 3 included in the USB, the MBIST 3 for testing the memory 3 and the test control unit 3 for controlling the test process of the USB are planned.

[0104] In the present disclosure, according to the project information in the design process of the chip under test, the required DFT architecture planning data is parsed, and then the DFT architecture is automatically planned according to the hierarchical structure of each module, without relying on manual experience, thereby improving the design efficiency and reducing the error rate.

[0105] In some embodiments of the present disclosure, the DFT architecture planning data includes: a scan block structure; the project information includes: the hierarchical information of each module in the chip under test, the layout information of each module, and the number information of registers in each module; in step S102 above, the project information is parsed into testability design DFT architecture planning data in a standard data structure, including: determining the divided scan block structure according to the hierarchical information, layout information, and the number information of registers.

[0106] Specifically, according to the hierarchical information of the module, it can be determined whether the planned module is an independent physical module or a sub-module; according to the layout information of the module (such as the size of the module), it is split or merged as a scan module, and each scan module needs to perform scan insertion, including inserting Embedded Deterministic Testing (edt), On Chip Clock Controller (occ), scan wrapper, etc.; according to the number of registers in the module, the module size can be determined. According to the preset splitting strategy, for an over-large module, it needs to be split for scan testing, and for relatively small modules, multiple modules can be merged for scan testing. Therefore, according to the number of registers in the module, it can be determined whether to split or merge the module.

[0107] Specifically, according to the hierarchical information of the module, it can be determined whether the planned module is an independent physical module or a sub-module; according to the number of registers in the module, the module size can be determined. According to the preset splitting strategy, for an over-large module, it needs to be split for scan testing, and for relatively small modules, multiple modules can be merged for scan testing. Finally, the scan modules are determined. Each scan module needs to perform scan insertion, including inserting Embedded Deterministic Testing (edt), On Chip Clock Controller (occ), scan wrapper, etc.; testing each module individually will consume a long time, so some scan modules can be merged for testing. At this time, according to the layout information of the module, the scan block structure of the scan module is determined, that is, which scan modules can be tested together.

[0108] The finally divided scan block structure describes: which modules are independently scanned and tested, which modules are divided into multiple partitions and each partition is independently scanned and tested, and which modules are merged into a group for scan testing.

[0109] In this embodiment, a scan block structure is planned in the DFT architecture. Each scan block can be tested independently, reducing the length of the scan chain and the volume of test data. In addition, since each scan block can be tested in parallel, a reasonable scan block structure can also improve the test efficiency.

[0110] In some embodiments, the DFT architecture planning data further includes: the test grouping of the scan blocks; the project information further includes: the number of general-purpose bidirectional pins on the top layer of the chip under test; the step S102 parses the project information into the testable design DFT architecture planning data in the standard data structure, including: determining the test grouping of the scan blocks according to the number of general-purpose bidirectional pins on the top layer of the chip under test and the scan block structure.

[0111] Although each scan block can be tested in parallel simultaneously, limited by the number of GPIO on the top layer of the chip under test, when any multiple scan blocks are tested in parallel, test errors may occur due to insufficient GIPO on the top layer of the chip under test. Therefore, it is necessary to determine the test grouping of the scan blocks according to the number of GIPO on the top layer of the chip under test and the scan block structure, and the scan blocks in the same group can be tested in parallel.

[0112] Determine the test grouping of the scan blocks according to the number of GIPO on the top layer of the chip under test and the scan block structure. Specifically, a grouping strategy can be preset. For example, the preset grouping strategy is that the physical line is the shortest and the number of GIPO required for each group of tests is less than the number of GIPO on the top layer of the chip under test. The specific grouping strategy is not limited in this disclosure.

[0113] In some embodiments of this disclosure, the DFT architecture planning data further includes: the built-in self-test task of the on-chip memory; the project information further includes: the memory information in each module; the step S102 parses the project information into the testable design DFT architecture planning data in the standard data structure, including: determining the built-in self-test task of the on-chip memory for each module according to the memory information in each module.

[0114] MBIST is an automatic test technology for detecting memories. Specifically, after the test control module receives the instruction to start the test, it will switch the input and output of the memory to the test mode and start the hardware vector generation module to start generating and giving test stimuli. Therefore, for modules including memories, it is necessary to plan MBIST tasks specifically for memory testing in order to implement memory testing in the subsequent DFT process.

[0115] In some embodiments of the present disclosure, the DFT architecture planning data further includes: boundary scan tasks; the project information further includes: pin information in each module; in step S102 above, parsing the project information into testability design DFT architecture planning data in a standard data structure includes: determining the boundary scan test tasks for each module according to the pin information in each module.

[0116] Boundary scan testing places shift registers between the internal logic of an integrated circuit and the pins of each module. Each shift register is called a cell, and these cells allow the control and observation of the state of each input / output pin. The principle of boundary scan is to add a register at both the input and output ports of the core logic circuit. By connecting the registers on these inputs and outputs, data can be serially input into the unit under test and serially read out from the corresponding ports.

[0117] Therefore, for the pins in each module, it is necessary to plan boundary scan tasks specifically for pin testing to facilitate the testing of pins in the subsequent DFT process.

[0118] In some embodiments of the present disclosure, in combination with Figure 1 , as Figure 3 shown, after step S103 above obtains the module data according to the module hierarchical structure from the DFT architecture planning data and plans the DFT architecture, the method for generating a testability design architecture further includes the following step S104, and / or, the following step S105.

[0119] In step S104, convert the DFT architecture into a task list in a preset format and output it.

[0120] Specifically, present the DFT architecture as a visual task list. Since JSON is easy to understand and read, the DFT architecture can be converted into JSON format and output.

[0121] Exemplarily, the following shows the DFT architecture output in JSON format by a certain module. As can be seen from the following task list, this module plans boundary scan (BSCAN) tasks and MBIST tasks. In the BSCAN tasks, the data included is the pin information corresponding to the Joint Test Action Group (JTAG) protocol interface, which ports of the top-level modules do not need to insert data such as BSCAN. These data are used to automatically generate DFT insertion tool scripts during the DFT execution phase to implement the insertion of BSCAN; in the MBIST task data, test requests and repair requests are included. These data are used to automatically generate DFT insertion tool scripts during the DFT execution phase to implement the insertion of MBIST and Memory Built In Self Repair (MBISR) logic; and the "MBIST_C*_PORT_LIST" stores which port pins need to be constrained to fixed values when the tool performs design specification checks.

[0122] "BSCAN":{

[0123] "REQUIREMENT":true,

[0124] "TAP_PORT_PIN":{

[0125] "PAD":{

[0126] "TMS":"tms_p",

[0127] "TCK":"tck_p",

[0128] "TDI":"tdi_p",

[0129] "TDO"_:"tdo_p",

[0130] "TRST":"trst_p"

[0131] },

[0132] "INTERNALPINS":{

[0133] "TMS":" ",

[0134] "TCK":" ",

[0135] "TDI":" ",

[0136] "TDO":" ",

[0137] "TRST":" ",

[0138] "TD0 EN": " ",

[0139] "TD0 EN POLARITY": " "

[0140] },

[0141] "ISINTERNAL": false

[0142] },

[0143] "CHIP_BSCAN_DONT_ToUCH_LIST": ["clk*ramclk_p"],

[0144] "SUB_BSCAN_TCD_FILE_LIST": [],

[0145] "PIN_ORDER_FILE": ","

[0146] "AUXILIARY_PIN_MUX_OUTPUT_PORT_LIST": ["portbout_p"],

[0147] "AUXILIARY_PIN_MUX_INPUT_PORT_LIST": ["portain_p"],

[0148] "IO_PAD_LIST": []

[0149] },

[0150] "MBIST": {

[0151] "REQUIREMENT": true,

[0152] "REPAIRE_REQUIREMENT": true,

[0153] "MBIST_C1_PORT_PIN_LIST": [],

[0154] "MBIST_Co_PORT_PIN_LIST": []

[0155] }

[0156] In step S105, the DFT architecture is converted into a visual architecture diagram and output.

[0157] To more clearly display the DFT architecture, the architecture diagram can be output in the form of a graph, such as Figure 4As shown, it is an exemplary DFT architecture diagram. The black-filled boxes in the figure are the elements in the DFT architecture, and the others are the original elements on the chip under test. In the DFT architecture, a test control unit 40 is planned to control the test process of the entire chip under test, a BSCAN 41 for boundary scan testing of GPIO or pins, a test control unit 42 for test control of the input / output (IO) controller, which will control the functional module 50 during the test, a remote test data register 43 for testing the system controller, which will control the phase-locked loop 51 during the test, a test control unit 44 for controlling the test process of subsystem 1, a test control unit 45 for controlling the test process of module 1, an MBIST 46 for testing the memory in module 1, a scan test control unit 47 for testing the logic in module 1, a test control unit 48 for controlling the test process of module 2 in subsystem 2, and an MBIST 49 for testing the memory in module 2.

[0158] The DFT architecture is output in the form of a task list. For each module, the user can clearly view the test tasks for the layout of each module and the test process in each test task; while outputting the DFT architecture diagram in the form of an architecture diagram is more intuitive, and the DFT elements included in each layer under the chip under test can be clearly viewed.

[0159] In some embodiments, after the above step S103 obtains the module data according to the module hierarchical structure from the DFT architecture planning data and plans to obtain the DFT architecture, the method for generating a testable design architecture further includes: modifying the DFT architecture according to the modification information input by the user.

[0160] After generating the DFT architecture, if the user needs to modify, the project information can be modified and the DFT architecture can be regenerated; or changes can be made through addition, deletion, and modification operations in the architecture diagram. After the architecture diagram is modified and saved, the corresponding task list will also be updated synchronously; it can also be that the user modifies the task list, and the corresponding architecture diagram will also be updated synchronously. This design is user-friendly. The user can modify the project information, architecture diagram, or task list according to needs, and when one of the architecture diagram and task list is modified, the other is updated synchronously, ensuring the consistency between the architecture diagram and the task list.

[0161] Based on the same concept as the above method for generating a testable design architecture, the present disclosure also provides a device for generating a testable design architecture. Figure 5 The structural block diagram of the device for generating a testable design architecture is shown, as Figure 5As shown in the figure, it includes: an acquisition part 501, an analysis part 502, and a planning part 503; the acquisition part 501 is configured to acquire project information in the design plan of the chip to be tested; the analysis part 502 is configured to parse the project information into testability design DFT architecture planning data in a standard data structure; the planning part 503 is configured to obtain module data according to the module hierarchical structure from the DFT architecture planning data and plan to obtain the DFT architecture.

[0162] In some embodiments of the present disclosure, the analysis part 502 is specifically configured to determine the divided scan block structure according to the hierarchical information, layout information, and the number of registers.

[0163] In some embodiments of the present disclosure, the analysis part 502 is specifically configured to determine the test grouping of the scan block according to the number of general bidirectional pins at the top layer of the chip to be tested and the scan block structure.

[0164] In some embodiments of the present disclosure, the analysis part 502 is specifically configured to determine the on-chip memory built-in self-test task for each module according to the memory information in each module.

[0165] In some embodiments of the present disclosure, the DFT architecture planning data further includes: boundary scan test tasks; the project information further includes: pin information in each module; the analysis part 502 is specifically configured to determine the boundary scan test task for each module according to the pin information in each module.

[0166] In some embodiments of the present disclosure, the device for generating the testability design architecture further includes: a conversion and output part; the conversion and output part is configured to convert the DFT architecture into a task list in a preset format and output it.

[0167] In some embodiments of the present disclosure, the conversion and output part is further configured to convert the DFT architecture into a visual architecture diagram and output it.

[0168] In some embodiments of the present disclosure, the device for generating the testability design architecture further includes: a modification part; the modification part is configured to modify the DFT architecture according to the modification information input by the user.

[0169] In the embodiments of the present application, each module can implement the method for generating the testability design architecture provided in the above method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be elaborated here.

[0170] Please refer to Figure 6, which shows a schematic diagram of the hardware structure of an electronic device provided by an exemplary embodiment of the present disclosure. In some examples, the electronic device may be at least one of devices such as a smart phone, a smart watch, a desktop computer, a laptop computer, a virtual reality terminal, an augmented reality terminal, a wireless terminal, and a laptop portable computer. The electronic device has a communication function and can access a wired network or a wireless network. The electronic device may generally refer to one of multiple terminals, and those skilled in the art can know that the number of the above terminals may be more or less. It can be understood that the electronic device undertakes the computing and processing work of the technical solution of the present disclosure, and the present disclosure does not limit this.

[0171] As Figure 6 shown, the electronic device in the present disclosure may include one or more of the following components: a processor 610 and a memory 620.

[0172] Optionally, the processor 610 is connected to various parts within the entire electronic device through various interfaces and lines, and by running or executing instructions, programs, code sets, or instruction sets stored in the memory 620, and by calling data stored in the memory 620, it executes various functions of the electronic device and processes data. Optionally, the processor 610 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 610 may integrate one or a combination of several of a central processing unit (CPU), a graphics processing unit (GPU), a neural-network processing unit (NPU), and a baseband chip, etc. Among them, the CPU mainly processes the operating system, user interface, and application programs, etc.; the GPU is responsible for rendering and drawing the content required to be displayed on the touch display screen; the NPU is used to implement artificial intelligence (AI) functions; the baseband chip is used to process wireless communication. It can be understood that the above baseband chip may not be integrated into the processor 610 and may be implemented separately by a single chip.

[0173] The memory 620 may include a Random Access Memory (RAM), or may also include a Read-Only Memory (ROM). Optionally, the memory 620 includes a non-transitory computer-readable storage medium. The memory 620 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 620 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing each of the above method embodiments, etc.; the data storage area may store data created according to the use of the electronic device, etc.

[0174] 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. The electronic device may include more or fewer components than shown in the drawings, or combine some components, or have different component arrangements. For example, the electronic device also includes components such as a display screen, a camera component, a microphone, a speaker, a radio frequency circuit, an input unit, sensors (such as an acceleration sensor, an angular velocity sensor, a light sensor, etc.), an audio circuit, a WiFi module, a power supply, a Bluetooth module, etc., which will not be elaborated here.

[0175] The present disclosure also provides a computer-readable storage medium storing at least one instruction for being executed by a processor to implement the method for generating a testability design architecture as described in each of the above embodiments.

[0176] 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 enable the electronic device to execute to implement the method for generating a testability design architecture as described in each of the above embodiments.

[0177] Another embodiment of the present application provides a chip including a processor and a communication interface, the communication interface is coupled to the processor, and the processor is configured to run programs or instructions to implement each process of the method embodiment for generating a testability design architecture as described above, and can achieve the same technical effect. To avoid repetition, it will not be elaborated here.

[0178] It should be understood that the chip mentioned in the embodiments of the present application may also be referred to as a system-on-chip, system chip, chip system or system-on-chip, etc.

[0179] In several embodiments provided by the present disclosure, it should be understood that the disclosed systems, devices, servers, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0180] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0181] In addition, in each embodiment of the present disclosure, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0182] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several 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 each embodiment of this application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0183] Those skilled in the art should be able to realize that in one or more of the above examples, the functions described in the present disclosure can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these 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 media and communication media, where the communication media includes any medium that facilitates the transmission of a computer program from one place to another. The storage media can be any available medium accessible by a general-purpose or special-purpose computer.

[0184] It should be noted that: among the technical solutions recorded in the present disclosure, they can be combined arbitrarily without conflict.

[0185] As described above, it is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered within the protection scope of the present invention.

Claims

1. A method for generating a testability design architecture, characterized in that: The method comprises: Obtain project information in the design plan of the chip to be tested; Parsing the project information into testability design DFT architecture planning data of a standard data structure; From the DFT architecture planning data, module data is acquired according to the module hierarchy structure and a DFT architecture is planned; The project information includes: the hierarchical information of each module in the chip under test, the layout information of each module, and the number of registers in each module; the hierarchical information of the modules in the chip under test refers to the organizational structure of different modules inside the chip under test, and how the modules are interconnected and collaborated; the DFT architecture planning data includes: the scan block structure; The step of parsing the project information into testability design DFT architecture planning data of a standard data structure includes: Determine the divided scanning block structure according to the hierarchical information of each module in the chip to be tested, the layout information of each module and the number information of the registers in each module; The step of determining the divided scanning block structure according to the hierarchical information of each module in the chip to be tested, the layout information of each module and the number information of the registers in each module comprises: According to the module's hierarchical information, it is determined whether the planned module is an independent physical module or a submodule. Independent physical modules are tested separately, while submodules are not tested separately. Determine the module size based on the module's register quantity information; According to the preset splitting strategy, overly large modules are split for scan testing, and smaller modules are combined for scan testing. The scan modules are determined, and each scan module needs to be scan-inserted, including inserting embedded deterministic tests, on-chip clock controllers, and scan packaging. According to the layout information of the module, the scanning block structure of the scanning module is determined, and the scanning block structure describes: which modules are scanned and tested independently, which modules are divided into multiple partitions, each partition is scanned and tested independently, and which modules are combined into one group for scan testing.

2. The method according to claim 1, characterized in that The step of parsing the project information into testability design DFT architecture planning data of a standard data structure includes: The test grouping of the scan block is determined according to the number of universal bidirectional pins on the top layer of the chip to be tested and the scan block structure.

3. The method according to claim 2, characterized in that The step of parsing the project information into testability design DFT architecture planning data of a standard data structure includes: According to the memory information in each module, the on-chip memory built-in self-test task of each module is determined.

4. The method according to claim 3, characterized in that The step of parsing the project information into testability design DFT architecture planning data of a standard data structure includes: According to the pin information in each module, the boundary scan test task of each module is determined.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The DFT architecture is converted into a task list in a preset format and outputted.

6. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The DFT architecture is converted into a visual architecture diagram and output.

7. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The DFT architecture is modified according to the modification information input by the user.

8. A device for generating a testability design architecture, characterized in that: The device comprises: an acquisition part, a parsing part, and a planning part; The acquisition part is configured to acquire project information in the design plan of the chip to be tested; The parsing part is configured to parse the project information into design for testability DFT architecture planning data of a standard data structure; The planning part is configured to obtain module data from the DFT architecture planning data according to the module hierarchy structure and plan to obtain the DFT architecture; The project information includes: the hierarchical information of each module in the chip under test, the layout information of each module, and the number of registers in each module; the hierarchical information of the modules in the chip under test refers to the organizational structure of different modules inside the chip under test, and how the modules are interconnected and collaborated; the DFT architecture planning data includes: the scan block structure; The step of parsing the project information into testability design DFT architecture planning data of a standard data structure includes: Determine the divided scanning block structure according to the hierarchical information of each module in the chip to be tested, the layout information of each module and the number information of the registers in each module; The step of determining the divided scanning block structure according to the hierarchical information of each module in the chip to be tested, the layout information of each module and the number information of the registers in each module comprises: According to the module's hierarchical information, it is determined whether the planned module is an independent physical module or a submodule. Independent physical modules are tested separately, while submodules are not tested separately. Determine the module size based on the module's register quantity information; According to the preset splitting strategy, overly large modules are split for scan testing, and smaller modules are combined for scan testing. The scan modules are determined, and each scan module needs to be scan-inserted, including inserting embedded deterministic tests, on-chip clock controllers, and scan packaging. According to the layout information of the module, the scanning block structure of the scanning module is determined, and the scanning block structure describes: which modules are scanned and tested independently, which modules are divided into multiple partitions, each partition is scanned and tested independently, and which modules are combined into one group for scan testing.

9. An electronic device, characterized in that: The invention comprises a processor, a memory and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the method for generating a testability design architecture as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the steps of the method for generating a design for testability architecture according to any one of claims 1 to 7 are implemented.

Images