Method and device for generating testability design architecture, equipment and storage medium

Abstract

The invention provides a method, device and equipment for generating a testability design architecture and a storage medium, and belongs to the technical field of testability design, and the method for generating the testability design architecture comprises the steps: obtaining project information in a design plan of a to-be-tested chip; analyzing the project information into testability design DFT architecture planning data of a standard data structure; and from DFT architecture planning data, module data is obtained according to a module hierarchical structure, and a DFT architecture is obtained through planning. According to the method and the device, the required DFT architecture planning data is obtained through analysis according to the project information in the design process of the to-be-tested chip, and then the DFT architecture is automatically planned according to the hierarchical structure of each module without depending on artificial experience, so that the design efficiency is improved, and the error rate is reduced.

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 advancement of manufacturing technology, chip testability design (Design For Test, DFT) is crucial to chip manufacturing and quality assurance. This technology introduces specific logic and structure in the chip design stage to effectively test the chip after chip manufacturing and check the chip manufacturing defects.

[0003] The design of the DFT architecture is crucial to 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 of the chip, whether to plan the on-chip memory built-in self-test in the module, whether to plan the boundary scan test, etc. It is the cornerstone of the entire chip DFT design.

[0004] However, DFT architecture design places very high demands on engineers, and usually requires experienced engineers to develop a reasonable DFT architecture based on 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 testability design architecture; the testability design architecture can be automatically generated.

[0006] The technical solution of the present disclosure is achieved as follows: In a first aspect, the present disclosure provides a method for generating a testability design architecture, the method comprising: Obtain project information in the design plan of the chip to be tested; parse the project information into testability design DFT architecture planning data of a standard data structure; obtain module data from the DFT architecture planning data according to the module hierarchy structure and plan the 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 the DFT architecture is automatically planned according to the hierarchy of each module, without relying on manual experience, thereby improving design efficiency and reducing error rate.

[0007] In some embodiments, the project information is parsed into testability design DFT architecture planning data of 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, the scan block structure is planned in the DFT architecture, and each scan block can be tested separately, which reduces the length of the scan chain and the volume of the test data. In addition, since each scan block can be tested in parallel, a reasonable scan block structure can also improve the test efficiency.

[0008] In some embodiments, the project information is parsed into the testability design DFT architecture planning data of the standard data structure, including: determining the test grouping of the scan block according to the number of universal bidirectional pins at the top level of the chip to be tested and the scan block structure. In this way, while performing synchronous testing on multiple modules, it is ensured that no test errors are caused by insufficient number of top level pins.

[0009] In some embodiments, the project information is parsed into testability design DFT architecture planning data of a standard data structure, including: determining the on-chip memory built-in self-test task of each module according to the memory information in each module. For a module including a memory, it is necessary to plan an MBIST task specifically for memory testing, so as to implement the memory test in a subsequent DFT process.

[0010] In some embodiments, the DFT architecture planning data also includes: boundary scan test tasks; the project information also includes: pin information in each module; the testability design DFT architecture planning data that parses the project information into a standard data structure also includes: determining the boundary scan test tasks of each module based on the pin information in each module. For the pins in each module, it is necessary to plan a boundary scan task specifically for pin testing, so as to implement the testing of the pins in the subsequent DFT process.

[0011] In some embodiments, the method for generating a design for testability 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, the user can clearly view the test tasks for each module layout and the test flow in each test task for each module.

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

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

[0014] In a second aspect, the present disclosure provides a device for generating a design for testability architecture, the device comprising: an acquisition part, a parsing part, and a planning part; the acquisition part is configured to acquire project information in the design plan of a 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 acquire module data from the DFT architecture planning data according to the module hierarchy structure and plan the DFT architecture.

[0015] In some embodiments of the present disclosure, the parsing part is specifically configured to determine the divided scan block structure based on the hierarchy information, layout information and register quantity information.

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

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

[0018] In some embodiments of the present disclosure, the DFT architecture planning data also includes: boundary scan test tasks; the project information also includes: pin information in each module; the parsing part is specifically configured to determine the boundary scan test tasks of each module based on the pin information in each module.

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

[0020] 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.

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

[0022] In a third aspect, the present disclosure provides an electronic device comprising 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 the first aspect.

[0023] In a fourth aspect, the present disclosure provides a computer-readable storage medium storing a program or instruction, which, when executed by a processor, implements the steps of the method for generating a testability design architecture as described in the first aspect.

[0024] In a fifth aspect, the present disclosure provides a computer program product, wherein the computer program product includes a computer program or instructions, and when the computer program product runs on a processor, the processor executes the computer program or instructions to implement the steps of the method for generating a testability design architecture as described in the first aspect.

[0025] In a sixth aspect, the present disclosure provides a chip to be tested, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method for generating a testability design architecture as described in the first aspect.

[0026] The present disclosure provides a method for generating a design for testability architecture, the method comprising: obtaining project information in the design plan of a chip to be tested; parsing the project information into design for testability DFT architecture planning data of a standard data structure; obtaining module data from the DFT architecture planning data according to the module hierarchy structure and planning to obtain the 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 hierarchy structure of each module, the DFT architecture is automatically planned without relying on manual experience, thereby improving design efficiency and reducing error rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 One of the flowcharts of a method for generating a testability design architecture provided by the present disclosure; Figure 2 One of the exemplary DFT architecture diagrams provided in the present disclosure; Figure 3 A second flowchart of a method for generating a design for testability architecture provided by the present disclosure; Figure 4 The second exemplary DFT architecture diagram provided by the present disclosure; Figure 5 A structural block diagram of a device for generating a design for testability architecture provided by the present disclosure; Figure 6A schematic diagram of the hardware structure of an electronic device provided by the present invention. DETAILED DESCRIPTION

[0028] The following will be combined with the drawings in the present disclosure to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of the present application.

[0029] In conjunction with the accompanying drawings, a method for generating a design for testability architecture provided by the present disclosure is described in detail below through specific embodiments.

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

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

[0032] The project information is the design file in the design process of the chip under test, and the project information includes: the hierarchical information of the modules in the chip under test, the clock information of the modules in the chip under test, the number of registers of the modules in the chip under test, the general purpose input / output (GPIO) information of the chip under test that can be used by DFT, the power domain information of the chip under test, the layout planning information of the chip under test, the pin information of the chip under test and other information. The present disclosure provides a visual user interaction interface, and the project information can be input by the user in the user interaction interface.

[0033] 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 connected and collaborated 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 input and 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 in the same voltage domain; the layout planning information is the layout planning in the back-end design, which defines the size, shape, and location and layout of various modules, hard cores, input / output, etc. in the chip under test; the pin information refers to the pads or bumps on the chip under test, which are the points where the chip is physically connected to the outside world; other information such as the process technology, performance indicators, packaging type, interface specifications, etc. of the chip under test is optional information.

[0034] The acquired project information is usually in a fixed format. For example, in practical applications, since json (JavaScript Object Notation) is easy to read and write, and is also easy for machines to parse and generate, project information is usually stored in json format.

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

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

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

[0038] The standard data structure is a customized 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 module's clock data, GPIO data, memory data, register quantity data, etc. This set of data can be a Boolean variable, a string, an array, an integer, etc.

[0039] The following shows how all the tools required in the DFT process are converted from the project information into a structure named "flowTool". The structure includes a set of data that records the tools used in the DFT process: struct flowTool { / / dft flow tool info QString dftToolName="tessent"; QString dftToolModule; QString formalToolName="formality"; QString formalToolModule; QString synToolName = "dc"; QString synToolModule; QString scanToolName="tessent"; QString simToolName = "vcs"; QString simToolModule; flowTool(){}; ~flowTool(){}; }; For some members in the structure, default values ​​are defined. If the member with default value is not assigned in the project information, the default value defined in the structure is used as the default value of the member. For example, in the "flowTool" structure, if the member dftToolName is assigned in the project information, it is named according to the "tessent" corresponding to the "dftToolName" defined in the "flowTool"; if the project information includes the value of "dftToolName", it is named according to the assigned value corresponding to the "dftToolName" included in the project information.

[0040] The purpose of the customized standard data structure in the present disclosure is to be able to efficiently call the project information in the program. In actual applications, different standard data structures can be designed, and the present disclosure does not limit this.

[0041] In step S103, module data is acquired from the DFT architecture planning data according to the module hierarchy structure and the DFT architecture is planned.

[0042] 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.

[0043] Exemplarily, an array for storing submodule information contained in the current module is set in the structure corresponding to each module. If no submodule is contained, the array is empty. The acquired project information is shown below. "usb", "cpu" and "starsp" are all listed as modules, but after being parsed into DFT architecture planning data, the DFT architecture planning data will determine "usb" and "cpu" as a separate physical module (the physical module is tested as an independent module, and a scanning package will be inserted to wrap it for testing during the scan test); and "starsp" is determined as a submodule of "usb" and "cpu" (the submodule will not be tested separately, and there is no need to insert a scanning package). In the structures corresponding to the two modules "usb" and "cpu", it is determined that the array for storing submodule information includes "starsp".

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

[0045] { "design_type":"standard", "designs":{ "USB":{ "instance":[ "usb_subsys" ], "isLayout":"true", "FFcount":101000, "hasMemory":"true", "GPIO_info"_:"", "clock_info" }, "cpu":{ "instance":[ "cpu_subsys" ], "isLayout":"true", "FFcount":500365, "hasMemory":"true", "GPI0 info" "clock_info": }, "starsp":{ "instance":[ "cpu_subsys / starsp_inst" "usb_subsys / core_inst / starsp_inst" ], "isLayout":"false", "FFcount":5000, "hasMemory":"true", "GPIO_info":"", "clock_info": "" }, } } Exemplarily, after parsing the above information into DFT architecture planning data, the DFT architecture diagram obtained according to the DFT architecture planning data is as follows: Figure 2 As shown in the figure, the black rounded rectangular filled boxes are the elements included in the DFT architecture, and the other white rectangular boxes are the original modules in the chip to be tested. The central processing unit (CPU) and the universal serial bus (USB) included in the chip to be tested are taken as an independent physical module, and the stars processor (STARSP) is taken as a submodule of the CPU and the USB. According to the memory 1 included in the CPU, the on-chip 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.

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

[0047] In some embodiments of the present disclosure, DFT architecture planning data includes: a scan block structure; project information includes: hierarchical information of each module in the chip to be tested, layout information of each module, and number information of registers in each module; the above step S102 parses the project information into testability design DFT architecture planning data with a standard data structure, including: determining the divided scan block structure based on the hierarchical information, layout information and number information of registers.

[0048] Specifically, based on the module's hierarchical information, it can be determined whether the planned module is an independent physical module or a sub-module; based on the module's layout information (such as the module's size), it can be split or merged as a scan module. Each scan module needs to be scan-inserted, including inserting embedded deterministic testing (edt), on-chip clock controller (occ), scan wrapper, etc.; based on the number of module registers, the module size can be determined. According to the preset splitting strategy, overly large modules need to be split for scan testing, and smaller modules can be merged for scan testing. Therefore, based on the number of module registers, it can be determined whether the module needs to be split or merged.

[0049] Specifically, based on the module's hierarchical information, it can be determined whether the planned module is an independent physical module or a sub-module; based on the number of registers in the module, the module size can be determined. According to the preset splitting strategy, overly large modules need to be split for scan testing, and smaller modules can be merged for scan testing. Finally, the scan module is determined, and each scan module needs to be scan-inserted, including inserting embedded deterministic testing (Embedded Deterministic Testing, EDT), on-chip clock controller (On Chip Clock Controller, OCC), scan wrapper, etc.; testing each module separately will take a long time, so some scan modules can be merged for testing. At this time, the scan block structure of the scan module is determined according to the module's layout information, that is, which scan modules can be tested together.

[0050] The scan block structure finally obtained by division 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.

[0051] In this embodiment, a scan block structure is planned in the DFT architecture, and each scan block can be tested individually, which reduces 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 test efficiency.

[0052] In some embodiments, the DFT architecture planning data also includes: test grouping of scan blocks; the project information also includes: the number of general bidirectional pins at the top level of the chip to be tested; the above step S102 parses the project information into testability design DFT architecture planning data with a standard data structure, including: determining the test grouping of the scan block based on the number of general bidirectional pins at the top level of the chip to be tested and the scan block structure.

[0053] Although each scan block can be tested in parallel at the same time, it is limited by the number of GPIOs on the top layer of the chip to be tested. When any multiple scan blocks are tested in parallel, the test may fail due to insufficient number of GIPOs on the top layer of the chip to be tested. Therefore, it is necessary to determine the test grouping of the scan blocks according to the number of GIPOs on the top layer of the chip to be tested and the structure of the scan blocks. Scan blocks in the same group can be tested in parallel.

[0054] According to the number of GIPOs at the top of the chip to be tested and the structure of the scan block, the test grouping of the scan block is determined. Specifically, a grouping strategy can be preset, such as: the preset grouping strategy is that the physical line is the shortest and the number of GIPOs required for each group of tests is less than the number of GIPOs at the top of the chip to be tested. The specific grouping strategy is not limited in this disclosure.

[0055] In some embodiments of the present disclosure, the DFT architecture planning data also includes: on-chip memory built-in self-test tasks; the project information also includes: memory information in each module; the above step S102 parses the project information into testability design DFT architecture planning data with a standard data structure, including: determining the on-chip memory built-in self-test tasks of each module based on the memory information in each module.

[0056] MBIST is an automatic test technology for detecting memory. 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 the module including the memory, it is necessary to plan the MBIST task specifically for performing the memory test, so as to realize the test of the memory in the subsequent DFT process.

[0057] In some embodiments of the present disclosure, the DFT architecture planning data also includes: boundary scan tasks; the project information also includes: pin information in each module; the above step S102 parses the project information into testability design DFT architecture planning data with a standard data structure, including: determining the boundary scan test tasks of each module based on the pin information in each module.

[0058] Boundary scan testing is done by placing shift registers between the internal logic of the integrated circuit and the pins of each module. Each shift register is called a unit, which allows the state of each input / output pin to be controlled and observed. The principle of boundary scan is to add a register to the input and output ports of the core logic circuit. By connecting the registers on these input / output, data can be serially input into the unit under test and serially read out from the corresponding port.

[0059] Therefore, for the pins in each module, it is necessary to plan a boundary scan task specifically for pin testing, so as to facilitate the testing of the pins in the subsequent DFT process.

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

[0061] In step S104, the DFT framework is converted into a task list in a preset format and outputted.

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

[0063] For example, the DFT architecture of a module is output in json format as shown below. It can be seen from the task list below that the module plans the boundary scan (BSCAN) task and the MBIST task. In the BSCAN task, the data included are the pin information corresponding to the Joint Test Action Group (JTAG) protocol interface, which top-level module ports do not need to insert BSCAN and other data. These data are used to automatically generate DFT insertion tool scripts in the DFT execution phase to implement BSCAN insertion; in the MBIST task data, test requests and repair requests are included. These data are used to automatically generate DFT insertion tool scripts in the DFT execution phase to implement MBIST and memory built-in self-repair (MBISR) logic insertion; and "MBIST_C*_PORT_LIST" stores which port pins need to be constrained to fixed values ​​when the tool is doing design specification checks.

[0064] "BSCAN":{ "REQUIREMENT":true, "TAP_PORT_PIN":{ "PAD":{ "TMS":"tms_p", "TCK":"tck_p", "TDI":"tdi_p", "TDO"_:"tdo_p", "TRST":"trst_p" }, "INTERNALPINS":{ "TMS":" ", "TCK":" ", "TDI":" ", "TDO":" ", "TRST":" ", "TD0 EN":" ", "TD0 EN POLARITY":" " }, "ISINTERNAL":false }, "CHIP_BSCAN_DONT_ToUCH_LIST":["clk*ramclk_p"] , "SUB_BSCAN_TCD_FILE_LIST":[], "PIN_ORDER_FILE":"," "AUXILIARY_PIN_MUX_OUTPUT_PORT_LIST":["portbout_p"], "AUXILIARY_PIN_MUX_INPUT_PORT_LIST":["portain_p"], "IO_PAD_LIST":[] }, "MBIST":{ "REQUIREMENT":true, "REPAIRE_REQUIREMENT":true, "MBIST_C1_PORT_PIN_LIST":[], "MBIST_Co_PORT_PIN_LIST":[] } In step S105 , the DFT architecture is converted into a visual architecture diagram and output.

[0065] In order to display the DFT architecture more clearly, the architecture diagram can be output in graphical form, such as Figure 4 As shown, it is an exemplary DFT architecture diagram, in which the black filled boxes are elements in the DFT architecture, and the others are the original elements on the chip to be tested. The DFT architecture plans a test control unit 40 for controlling the test process of the entire chip to be tested, a BSCAN 41 for boundary scan testing of GPIO or pins, a test control unit 42 for testing and controlling the input / output (IO) controller, which controls the functional module 50 during the test process, a remote test data register 43 for testing the system controller, which controls the phase-locked loop 51 during the test process, 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.

[0066] By outputting the DFT architecture in the form of a task list, users can clearly view the test tasks for each module layout and the test flow in each test task for each module; and outputting the DFT architecture diagram in the form of an architecture diagram is more intuitive, and users can clearly view the DFT elements included in each layer under the chip to be tested.

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

[0068] After the DFT architecture is generated, if the user needs to modify it, he can modify the project information and regenerate the DFT architecture; he can also make changes in the architecture diagram by adding, deleting, and changing operations. After the architecture diagram is modified and saved, the corresponding task list will be updated synchronously; the user can also modify the task list, and the corresponding architecture diagram will be updated synchronously. This design is user-friendly. Users can modify project information, architecture diagrams, or task lists as needed, 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.

[0069] Based on the same concept as the above method for generating a testability design architecture, the present disclosure also provides a device for generating a testability design architecture. Figure 5 The structural block diagram of the device for generating the testability design architecture is shown as follows: Figure 5 As shown, it includes: an acquisition part 501, a parsing 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 parsing part 502 is configured to parse the project information into testability design DFT architecture planning data of a standard data structure; the planning part 503 is configured to acquire module data from the DFT architecture planning data according to the module hierarchy structure and plan to obtain the DFT architecture.

[0070] In some embodiments of the present disclosure, the parsing part 502 is specifically configured to determine the structure of the divided scan blocks according to the level information, the layout information and the number information of the registers.

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

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

[0073] In some embodiments of the present disclosure, the DFT architecture planning data also includes: boundary scan test tasks; the project information also includes: pin information in each module; the parsing part 502 is specifically configured to determine the boundary scan test tasks of each module based on the pin information in each module.

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

[0075] 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.

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

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

[0078] 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 a smart phone, a smart watch, a desktop computer, a laptop, a virtual reality terminal, an augmented reality terminal, a wireless terminal, and a laptop 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 a plurality of terminals, and those skilled in the art may know that the number of the above terminals may be more or less. It can be understood that the electronic device undertakes the calculation and processing work of the technical solution of the present disclosure, and the present disclosure does not limit this.

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

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

[0081] The memory 620 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 620 includes a non-transitory computer-readable storage medium. The memory 620 may 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, wherein 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 the above various method embodiments, etc.; the data storage area may store data created according to the use of the electronic device, etc.

[0082] 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 may include more or fewer components than shown, or combine certain components, or arrange the components differently. 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 WiFi module, a power supply, a Bluetooth module and other components, which will not be described in detail here.

[0083] The present disclosure also provides a computer-readable storage medium storing at least one instruction, wherein the at least one instruction is used to be executed by a processor to implement the method for generating a design for testability architecture as described in the above embodiments.

[0084] The present disclosure also provides a computer program product, which includes 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, so that the electronic device executes to implement the method of generating a testability design architecture described in the above-mentioned embodiments.

[0085] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned method embodiment for generating a testability design architecture, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0086] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0087] In the several embodiments provided in 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 only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

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

[0090] If the 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 this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

[0091] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the present disclosure can be implemented using 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. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. Storage media can be any available media that can be accessed by a general or special-purpose computer.

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

[0093] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by 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 the DFT architecture is planned.

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 structure of the divided scanning blocks is determined 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.

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: 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.

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 memory information in each module, the on-chip memory built-in self-test task of each module is determined.

5. The method according to claim 4, 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.

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

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

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

9. 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.

10. An electronic device, characterized in that: The method 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 8.

11. 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 8 are implemented.

Images