A method and apparatus for establishing a DFT clock architecture, and an electronic device

Abstract

The present disclosure provides a DFT clock architecture establishment method, device and electronic equipment, belonging to the technical field of EDA. The DFT clock architecture establishment method comprises: obtaining a structured data file corresponding to clock planning information of a chip, the structured data file at least comprising an index field for identifying clock uniqueness, a type field for indicating clock type, and a parameter field for indicating clock attribute; generating a corresponding clock information object based on the values of the index field, the type field and the parameter field; generating a first configuration file and a second configuration file based on the clock information object, the first configuration file being used to drive a DFT tool to perform circuit insertion, and the second configuration file being used to drive a synthesis or static timing analysis tool. The problems of configuration ambiguity, floating point error, asynchronous path omission and OCC insertion inconsistency caused by the dispersion, unstructured and manual transmission of DFT clock planning information can be solved.

Description

Technical Field

[0001] This disclosure relates to the field of electronic design automation (EDA) technology, and in particular to a method, apparatus and electronic device for establishing a DFT clock architecture. Background Technology

[0002] In modern Large-Scale Integration (LSI), Very Large-Scale Integration (VLSI), and Ultra Large-Scale Integration (ULSI) chip design, design for test (DFT) is a crucial step in ensuring chip manufacturability, testability, and yield. With the dramatic increase in chip complexity, the number of clock domains on a single chip can reach 50 or even 100. Simultaneously, advanced technologies such as multiple phase-locked loops, dynamic frequency division, power-off, and scan compression are widely used in chip design.

[0003] These complex designs result in an exponential increase in the amount of DFT clock planning information. In these complex, large-scale chips, the ability to complete clock planning rationally and quickly is crucial for subsequent Automatic Test Pattern Generation (ATPG), Memory Built-In Self-Test (MBIST), and the insertion of on-chip clock control (OCC).

[0004] However, due to the dispersed and unstructured storage of DFT clock planning information, such as clock source information scattered in Register Transfer Level (RTL) code comments, documentation, and temporary mailing conventions, information ambiguity, omissions, and inconsistencies arise. These defects can further lead to chip simulation failures, inflated ATPG fault coverage, and ultimately, a decrease in measured yield. Summary of the Invention

[0005] This disclosure provides a method, apparatus, and electronic device for establishing a DFT clock architecture; it can solve technical problems such as configuration ambiguity, floating-point errors, asynchronous path omissions, and inconsistent OCC insertion caused by the dispersed, unstructured, and manually transmitted nature of DFT clock planning information.

[0006] The technical solution disclosed herein is implemented as follows:

[0007] Firstly, this disclosure provides a method for establishing a DFT clock architecture. This method includes: acquiring a structured data file corresponding to the chip's clock planning information; the structured data file includes at least an index field for identifying the uniqueness of the clock, a type field for indicating the clock type, and a parameter field for indicating clock attributes; generating a corresponding clock information object based on the values ​​of the index field, type field, and parameter field; and generating a first configuration file and a second configuration file based on the clock information object. The first configuration file is a script file used to drive the chip's Design for Testability (DFT) tool to perform circuit insertion, and the second configuration file is a timing constraint file used to drive synthesis or static timing analysis tools. By acquiring and parsing a standardized structured data file, the index field, type field, and parameter field of various clocks are extracted to generate corresponding clock information objects. Furthermore, both the first and second configuration files are generated based on the same clock information object in the digital model, fundamentally ensuring strict consistency between the physical implementation script and the timing constraint file in clock definitions (such as name, period, and source port).

[0008] In some embodiments, the DFT clock architecture establishment method further includes: when the establishment time margin of the timing path corresponding to any clock is detected to be less than a preset timing threshold, determining that the value of the OCC insertion flag field of the corresponding clock is true; when the number of OCCs already inserted in a preset layout area is detected to be greater than a preset density threshold, determining that the value of the OCC insertion flag field corresponding to the remaining clocks in the layout area is false; when the clock domain frequency of any clock is detected to be greater than a preset frequency threshold, or the clock tree depth is greater than a preset depth threshold, determining that the value of the OCC insertion flag field of the corresponding clock is true. This disclosure transforms the decision-making process of the OCC insertion flag in the embodiments from human intuition to data-driven, ensuring that the establishment of the DFT architecture meets the requirements of high-quality testing while avoiding excessive intrusion into the chip physical implementation.

[0009] In some embodiments, the parameter field includes an on-chip clock control (OCC) insertion flag field. Based on the clock information object, a first configuration file is generated, including: traversing the values ​​of the OCC insertion flag field of the clock information object; if the OCC insertion flag field is true, generating instructions in the first configuration file for inserting OCC hardware logic on the corresponding clock path; if the OCC insertion flag field is false, generating clock definition instructions in the first configuration file. This embodiment moves the OCC insertion decision forward to a structured data file, making the OCC placement strategy an auditable, quantifiable, and traceable data record. Whether to insert an OCC is controlled by simple Boolean logic through complex script branches. Regardless of the number of clocks in the chip, simply adjusting the flag bits in the table and rerunning the generation steps completes the adjustment of the entire chip's DFT architecture, improving design iteration efficiency.

[0010] In some embodiments, the parameter field includes a shutdown state field; generating a first configuration file based on a clock information object includes: generating constraint instructions in the first configuration file, based on the value of the shutdown state field, for setting the level state of the clock when it is in the shutdown state. This embodiment allows users to flexibly set the level state when the clock is in the shutdown state.

[0011] In some embodiments, the parameter field includes an asynchronous grouping field; based on the clock information object, a second configuration file is generated, including: traversing the clock information objects and grouping clock information objects with the same asynchronous grouping field value into the same clock group; generating asynchronous constraint commands for setting clock groups between different clock groups. This embodiment ensures that as long as the user fills in the grouping label when defining the clock, the clock will be automatically added to the correct asynchronous group, fundamentally eliminating omissions. The generated Synopsys Design Constraints (SDC) file can guide the ATPG tool to correctly shield cross-clock domain paths, ensuring that the generated test vectors are real and effective, thereby guaranteeing mass production yield. By transforming the complex pairwise mutual exclusion logic into a simple operation of entering the asynchronous grouping field in the structured data file, the maintenance threshold of the clock architecture is greatly reduced. Designers do not need to care about the specific SDC syntax details, nor do they need to manually check the pairwise relationships of hundreds or thousands of clocks; they only need to focus on the attributes of each clock itself.

[0012] In some embodiments, the parameter field includes a clock name field; the DFT clock architecture establishment method further includes: before generating asynchronous constraint commands, if the clock information object lacks a value for the asynchronous grouping field, outputting a prompt message including the value of the clock name field, or assigning the clock information object to the default synchronous clock group. This embodiment achieves semantic-level error reporting by explicitly including the value of the clock name field in the prompt message. Engineers can immediately locate the source of the problem upon seeing "vpu_clk" in the error message, significantly shortening troubleshooting time. Furthermore, if the program crashes and exits upon encountering a null value, the user experience is extremely poor. The automatic grouping mechanism in this embodiment ensures that even if the input data is imperfect, the tool can generate a syntactically correct and logically complete timing constraint file, guaranteeing a smooth design process.

[0013] In some embodiments, the parameter fields further include a clock name field, a clock frequency field, a clock source field, and a master clock field. Based on the clock information object, a second configuration file is generated, including: when the type field indicates the clock type is the root clock, generating a master clock creation command based on the values ​​of the clock source field, clock name field, and clock frequency field; when the type field indicates the clock type is a derived clock, creating a derived clock definition command based on the value of the clock name field; generating a clock source pin specification command for the derived clock based on the value of the clock source field; and generating a master clock source specification command for the derived clock based on the value of the master clock field. This embodiment eliminates ambiguity and ensures the logical uniqueness of the clock tree topology by mandating the inclusion of a master clock field in the parameter fields. Furthermore, it can automatically distinguish between root clocks and derived clocks and generate different timing constraints.

[0014] In some embodiments, the parameter fields include a multiplication factor field and a division factor field; based on the clock information object, a second configuration file is generated, including: when the type field indicates that the clock type is a derived clock, generating a frequency definition command for the derived clock based on the value of the multiplication factor field or the value of the division factor field in the clock information object. This embodiment, by directly passing the value of the division factor field, enables the DFT tool to perform precise derivation internally using a fractional algorithm, thereby mathematically guaranteeing absolute alignment of the clock edges.

[0015] In some embodiments, the structured data file is a spreadsheet file; before generating the corresponding clock information object based on the values ​​of the index field, type field, and parameter field, the DFT clock architecture establishment method further includes: reading the header row of the spreadsheet file and establishing a mapping table between column names and column indices; traversing the data rows of the spreadsheet file, and for each row of data, extracting the values ​​of the index field, type field, and parameter field by matching column names according to the mapping table.

[0016] In some embodiments, the chip is a target die in a multi-die packaged chip that includes multiple dies; the above-mentioned acquisition of the structured data file corresponding to the chip's clock planning information includes: acquiring the structured data file corresponding to the target die based on the mapping relationship between the die identifier and the structured data file. This embodiment achieves clear management and accurate extraction of complex clock architectures across multiple dies without changing the original two-dimensional structure within the structured data file of a single die.

[0017] Secondly, this disclosure provides a DFT clock architecture establishment apparatus, which includes: an acquisition part and a generation part; the acquisition part is configured to acquire a structured data file corresponding to the clock planning information of a chip, the structured data file including at least an index field for identifying the uniqueness of the clock, a type field for indicating the clock type, and a parameter field for indicating clock attributes; the generation part is configured to generate a corresponding clock information object based on the values ​​of the index field, the type field, and the parameter field; and, based on the clock information object, generate a first configuration file and a second configuration file, the first configuration file being a script file for driving the chip design for testability (DFT) tool to perform circuit insertion, and the second configuration file being a timing constraint file for driving synthesis or static timing analysis tools.

[0018] Thirdly, this disclosure provides an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the DFT clock architecture establishment method as described in the first aspect.

[0019] Fourthly, this disclosure provides a computer-readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the DFT clock architecture establishment method as described in the first aspect.

[0020] Fifthly, this disclosure provides a computer program product, wherein the computer program product includes a computer program or instructions, which, when run on a processor, cause the processor to execute the computer program or instructions to implement the steps of the DFT clock architecture establishment method as described in the first aspect.

[0021] In a sixth aspect, this disclosure provides a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the DFT clock architecture establishment method as described in the first aspect.

[0022] This disclosure provides a method, apparatus, and electronic device for establishing a DFT clock architecture. The method acquires and parses standardized structured data files, extracting index fields, type fields, and parameter fields for various clock types to generate corresponding clock information objects. Both the first and second configuration files are generated based on the same clock information object in the digital model, fundamentally ensuring strict consistency between the physical implementation script and the timing constraint file in clock definitions (such as name, period, and source port). Furthermore, the automatic generation of the first and second configuration files avoids spelling errors, syntax errors, or parameter copying errors that may occur when manually writing scripts. Especially when the chip's clock scheme changes, the user only needs to modify the input structured data file to synchronously update the output DFT script file and SDC file, significantly reducing iteration costs and ensuring the synchronized progress of the DFT design flow and timing analysis flow. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of an application environment for a method for establishing a DFT clock architecture provided in this disclosure.

[0024] Figure 2 This is a flowchart illustrating a method for establishing a DFT clock architecture provided in this disclosure.

[0025] Figure 3 A flowchart illustrating another method for establishing a DFT clock architecture provided in this disclosure.

[0026] Figure 4 This is a flowchart illustrating another method for establishing a DFT clock architecture provided in this disclosure.

[0027] Figure 5 This is a flowchart illustrating another method for establishing a DFT clock architecture provided in this disclosure.

[0028] Figure 6 This is a schematic diagram of a portion of data in an electronic spreadsheet file provided in this disclosure.

[0029] Figure 7 This is a structural block diagram of a DFT clock architecture establishment device provided in this disclosure.

[0030] Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in this disclosure. Detailed Implementation

[0031] The technical solutions in the embodiments of this disclosure will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure are within the scope of protection of this disclosure.

[0032] Driven by Moore's Law, the design scale of integrated circuits has exploded. Modern system-on-chips (SoCs) integrate multiple heterogeneous computing units such as central processing units (CPUs), graphics processing units (GPUs), neural processing units (NPUs), and digital signal processors (DSPs), resulting in an extremely complex clock network within the chip.

[0033] A typical AI chip may contain more than 100 independent clock domains, each with different frequencies, phases, and sources. To screen for manufacturing defects, a large amount of DFT logic must be inserted during the design phase, including scan chains, compression logic, MBIST controllers, and OCCs. The correct operation of this logic depends heavily on the proper configuration of the clock architecture.

[0034] All DFT logic and functional logic must meet setup and hold time requirements. This requires backend engineers to write extremely precise SDC documents to guide synthesis and place-and-route tools.

[0035] Currently, front-end designers are typically responsible for RTL design, DFT engineers are responsible for inserting test logic, and back-end engineers are responsible for timing constraints. This workflow leads to severe data fragmentation: First, design specifications usually describe frequency division relationships in natural language, such as "System Clock is derived from PLL1 output divided by 3". When engineers manually input " / 3" into the tool, it may be written as "333.33ns". This inconsistency in precision, after accumulating multiple times, will cause clock edge alignment deviations, triggering pseudo-timing violations and wasting a lot of iteration time.

[0036] Secondly, asynchronous clock grouping information is typically agreed upon by design team engineers in ad-hoc emails, and then manually translated and written into the `set_clock_groups` command in the SDC file by DFT engineers. This manual transmission method is highly susceptible to information omissions. For example, if a new clock domain is added later in the chip design process, and the engineer forgets to update the email agreement or the SDC file, the new clock domain may not be correctly updated in the `set_clock_groups` command. This can cause the ATPG tool to misclassify cross-clock domain paths that should be asynchronous as synchronous paths, resulting in an inflated fault coverage rate generated by ATPG. During actual testing on automated test equipment (ATE), the lack of coverage of these paths leads to a decrease in the chip's measured yield.

[0037] Finally, the OCC is a key component of the DFT, used to control the clock pulse in test mode. Inserting an OCC increases area and introduces clock delay. In the prior art, OCC insertion often relies on the intuition of the DFT engineer; some engineers tend to insert all OCCs, resulting in wasted area; others tend to insert fewer, resulting in certain modes not being covered.

[0038] In summary, existing technologies lack machine-level correlation and consistency verification between information carriers (such as Word documents, emails, RTL comments, and design specifications), which makes DFT clock planning information prone to errors, omissions, and ambiguities during transmission.

[0039] Based on the above description, the present disclosure aims to provide a method for establishing a chip DFT clock architecture to solve the above-mentioned technical problems such as configuration ambiguity, floating-point error, asynchronous path omission and OCC insertion inconsistency caused by the scattered, unstructured and manually transmitted DFT clock planning information.

[0040] First, refer to Figure 1 , Figure 1 This is a schematic diagram of an application environment for a DFT clock architecture establishment method provided in an embodiment of this application. The application environment may include an electronic device 110, a structured data file 120, and a downstream EDA tool 130.

[0041] In this embodiment of the disclosure, the electronic device 110 can be any computing device capable of performing computational and processing tasks, such as an EDA workstation, server, personal computer, etc. The method proposed in this embodiment can be stored as a software program in the memory of the electronic device 110 and executed by its processor.

[0042] Structured data file 120 is the single data source proposed in this embodiment of the disclosure. It contains chip project clock information filled in by a DFT engineer or design engineer, and can be stored in the memory of electronic device 110 or in a cloud database.

[0043] EDA Tools 130 is an existing EDA toolchain. These tools are used to perform specific tasks in the DFT process, such as MBIST insertion tools like Tessent MBIST, OCC insertion tools like Tessent OCC, or time series synthesis and analysis tools, etc.

[0044] In this embodiment of the disclosure, electronic device 110 captures the full design intent regarding the DFT clock by acquiring a structured data file 120 populated by an engineer. This design intent is automatically (without human intervention) parsed and compiled to generate a configuration file that EDA tool 130 can recognize and execute.

[0045] Configuration files may include, for example, MBIST clock scripts for the Tessent MBIST process, OCC clock scripts for the Tessent OCC process, and SDC files for timing synthesis and analysis.

[0046] In this way, the electronic device 110 and the method executed by it in this embodiment of the present disclosure transform the design intent expressed in a structured data file into a configuration file executable by the EDA tool 130, thereby solving the problems caused by manual translation and information dispersion in the prior art.

[0047] The method for establishing the DFT clock architecture provided in this disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0048] like Figure 2 As shown, this disclosure provides a method for establishing a DFT clock architecture. The following example, using an electronic device as the execution subject, provides an illustrative description of the DFT clock architecture establishment method provided in this disclosure. This method may include the following steps S201 to S203.

[0049] In step S201, the structured data file corresponding to the chip's clock planning information is obtained.

[0050] Structured data files include at least index fields, type fields, and parameter fields.

[0051] The index field, in a structured data file, is a data field used to uniquely identify a specific clock entry; it is a globally unique identifier for the clock object. The type field indicates the type or hierarchy of the clock, determining whether it exists as an independent source or is derived from other clocks. The parameter field is a set of data fields indicating the physical or logical attributes of the clock; these parameters define the clock's specific specifications.

[0052] Specifically, the structured data file can be based on a predefined template, such as an Excel spreadsheet or a comma-separated values ​​(CSV) file. Users enter complete clock planning information required for chip design into the predefined template. For example, each line describes a clock node; the input index field assigns a unique ID to each clock, such as 1, 2, 3…; the input type field specifies whether the clock is a root clock ("ROOT") or a derived clock ("GENERATED"); and the input parameter field allows users to fill in the physical pin location of the clock, the desired frequency or period, and the clock name, etc.

[0053] For a single-die chip, relevant clock planning information can be extracted from the structured data file using the module name and clock name. The chip in this embodiment can also be a target die in a multi-die package chip, which stores multiple structured data files, each corresponding to one die, with the mapping relationship between die identifiers and structured files predetermined.

[0054] When generating clock information objects, the target die identifier is first determined. Based on the mapping relationship, the structured data file corresponding to the target die identifier is located, thus narrowing the search scope from the entire package to a single die. After determining the structured data file corresponding to the target die, relevant clock planning information is extracted from the corresponding structured data file using the module name and clock name. This embodiment achieves clear management and accurate extraction of complex clock architectures across multiple dies without altering the original two-dimensional structure within the structured data file of a single die.

[0055] In step S202, a corresponding clock information object is generated based on the values ​​of the index field, type field, and parameter field.

[0056] A clock information object refers to a data structure or class instance instantiated in the memory of a computer program to carry clock planning information. It is a memory mapping of structured data files and serves as a single trusted source for the subsequent generation of various configuration files.

[0057] Specifically, the structured data file is read line by line. For each line, the columns or labels containing the index field, type field, and parameter field are identified according to preset rules. A clock information object is created for each line, such as an instance of the ClockInfo class. The value of the index field, such as 1, is assigned to the ID member variable of the clock information object, serving as the lookup key in memory. The value of the type field, such as ROOT, is assigned to the Type member variable of the clock information object for subsequent decision-making logic. The values ​​of the parameter fields, such as 10ns and pin_A, are assigned to the Period and Source member variables of the clock information object, respectively. This ensures that all clock planning information in the structured data file is completely mapped to a list of objects or a hash table in memory, forming a digital model of the chip clock architecture.

[0058] In step S203, a first configuration file and a second configuration file are generated based on the clock information object.

[0059] The first configuration file refers to the script file used to drive the DFT tool to perform circuit insertion or configuration. For example, a Tcl format script file containing commands such as `add_clock` and `set_context` is used to guide the DFT tool to identify the clock and insert the corresponding test logic into the circuit. The first configuration file can include clock-related scripts in the Embedded Deterministic Test (EDT) insertion process, the OCC insertion process, and the MBIST insertion process, etc. The second configuration file refers to the timing constraint file used to drive synthesis tools or static timing analysis tools to perform timing constraints, such as an SDC file containing commands such as `create_clock` and `create_generated_clock`.

[0060] Specifically, the process iterates through the list of clock information objects generated for each clock node. For each clock information object, it extracts information such as clock name, clock period, and clock source from its parameter fields. Following the syntax rules of DFT tools (such as Tessent), this information is formatted into corresponding configuration commands and written to the first configuration file. For example, extracting the clock information objects "clock_source" and "clock_name" generates the command "add_clocks 0 pin_A -label clk_sys" and writes it to the first configuration file. For the same clock information object, its type field and parameter field information are extracted again. Following the syntax rules of the SDC standard, this information is formatted into timing constraint commands and written to the second configuration file. For example, if the type field of the clock information object is ROOT, its period (10ns) and port pin_A are extracted, generating the command create_clock -name clk_sys -period 10 [get_ports pin_A] and writing it to the second configuration file.

[0061] The data in both the first and second configuration files in this process comes directly from the same clock information object, without any intermediate manual transcription or independent secondary definition.

[0062] This embodiment acquires and parses standardized structured data files, extracting index, type, and parameter fields for various clocks to generate corresponding clock information objects. Both the first and second configuration files are generated based on the same clock information object from the digital model, fundamentally ensuring strict consistency between the physical implementation script and the timing constraint file in clock definitions (such as name, period, and source port). Furthermore, the automatic generation of the first and second configuration files avoids spelling errors, syntax errors, or parameter copying errors that may occur when manually writing scripts. Especially when the chip's clock scheme changes, users only need to modify the input structured data file to synchronously update the output DFT script file and SDC file, significantly reducing iteration costs and ensuring the synchronized progress of the DFT design flow and timing analysis flow.

[0063] In some embodiments, such as Figure 3 As shown, the DFT clock architecture establishment method generates a first configuration file, specifically including the following steps S301 to S305.

[0064] In step S301, the structured data file corresponding to the chip's clock planning information is obtained.

[0065] In step S302, a corresponding clock information object is generated based on the values ​​of the index field, type field, and parameter field.

[0066] The parameter fields include the OCC insertion flag field.

[0067] In step S303, the values ​​of the OCC insertion flag field of the clock information object are traversed. If the value of the OCC insertion flag field is true, an instruction for inserting OCC hardware logic on the corresponding clock path is generated in the first configuration file.

[0068] In step S304, if the value of the OCC insertion flag field is false, a clock definition instruction is generated in the first configuration file.

[0069] An OCC (Optical Clock Control) is a dedicated hardware logic module used for the DFT (Distributed Flow Test) of integrated circuits. It typically includes circuitry such as clock gating, multiplexers, and counters. In scan test mode, the OCC is responsible for chopping or controlling the high-speed functional clock to generate precise capture pulses for at-speed testing, while keeping the clock controlled during the shift phase.

[0070] The OCC Insertion Flag field is a Boolean parameter in the clock information object that indicates whether OCC hardware logic needs to be physically inserted into the clock path. It is a control switch connecting the clock planning intent and the physical circuit implementation. The value of the OCC Insertion Flag field determines whether the DFT tool only recognizes the clock or needs to modify the clock path.

[0071] OCC hardware logic refers to the actual instantiated OCC circuit structure and its connection relationships in the chip netlist.

[0072] In some embodiments, the value of the OCC insertion flag field is determined based on a quantization determination mechanism using multidimensional parameters.

[0073] Specifically, the setup time margin of the clock path is analyzed. The setup time margin refers to the time difference between the actual arrival time of the signal and the required arrival time. If the setup time margin of a timing path is less than a preset timing threshold, the value of the OCC insertion flag field of that clock is true.

[0074] For example, if the preset timing threshold is 0.5ns, and the clock path setup time margin within the clk_vpu clock domain is detected to be only 0.2ns, this indicates that the timing of this clock path is very tight. For such paths, an OCC (Optical Characteristic) must be inserted to support high-precision full-speed testing, thereby accurately screening for minute delay faults. Therefore, the value of the OCC insertion flag field corresponding to clk_vpu is set to true, forcing the insertion of OCC hardware logic.

[0075] The density parameter is set within a preset layout area on the monitor chip layout. The density parameter refers to the number of planned or instantiated OCC modules per unit physical area. For example, if a preset layout area on a physical layout is defined as a rectangular area R, and the number of inserted OCCs in R is greater than a preset density threshold, then the value of the OCC insertion flag field for the remaining unprocessed clocks in R is set to false.

[0076] For example, the preset density threshold is 5. In Area_A at the bottom left of the physical layout, 5 OCC modules have already been inserted. Since the OCC modules themselves contain multiplexers and clock gating, they occupy a large area and have complex routing. If more OCCs are inserted into this congested area, it will cause localized routing blockage, leading to a serious physical design violation. Therefore, for other clocks subsequently scanned within Area_A, the value of their OCC insertion flag field is set to false.

[0077] In addition, the value of the OCC insertion flag field can be determined based on the inherent properties of the clock itself. These inherent properties include clock frequency and clock tree depth. Clock tree depth refers to the number of buffer stages traversed from the clock source to the final flip-flop. If the clock frequency is greater than a preset frequency threshold, or the clock tree depth is greater than a preset depth threshold, then the value of its OCC insertion flag field is set to true.

[0078] For example, with a clock frequency of 125MHz and a clock tree depth of 10 levels, the core clock of a certain AI accelerator, npu_core_clk, has a frequency of 800MHz. High-frequency signals are extremely sensitive to jitter and duty cycle. Traditional external low-speed testing cannot cover signal integrity issues at high frequencies; therefore, it is determined that an OCC must be inserted for full-speed testing. A certain bus clock, sys_bus_clk, although not high in frequency, has a huge fan-out and a clock tree depth of 15 levels. Deep clock trees are prone to clock skew mismatches between different branches during manufacturing. To flexibly adjust the timing relationship of pulse transmission and capture in test mode to compensate for clock skew, it is determined that an OCC must be inserted, thereby utilizing the programmable characteristics of the OCC to manage the complex clock tree.

[0079] This disclosure transforms the decision-making process for the OCC insertion flag in the embodiments from human intuition to data-driven, ensuring that the establishment of the DFT architecture meets the requirements of high-quality testing while avoiding excessive intrusion into the chip's physical implementation.

[0080] The clock definition command is a command in the script file of the DFT tool used to declare a signal as a clock. This command only informs the tool of the existence and properties of the clock, without triggering any modification or insertion of hardware circuitry.

[0081] Read the currently processed clock information object (e.g., clock information object Clk_A) and access its member variable OCC insertion flag field. When the OCC insertion flag field is true, it indicates that the clock is being tested and controlled at full speed in the chip design. Therefore, it is not only necessary to define the clock in the script file, but also to generate a series of complex instructions to instruct the EDA tool to insert the OCC module in the netlist.

[0082] When the OCC insertion flag field is false, it indicates that the clock does not require complex test control. This could be a statically configured clock that does not require full-speed test control testing, or a slow clock directly from an external automated test device. Therefore, only the most basic definition code is generated, such as writing only one line of instruction in the first configuration file: `add_clocks 0 pad_ref_clk -label clk_ref`. This instruction only serves to let the DFT tool know that the port is a clock so that it can be correctly identified during design rule checks, but it does not insert any additional gates or control logic into this path.

[0083] In existing technologies, OCC insertion often relies on engineers' personal experience or ad-hoc decisions when writing scripts, which can easily lead to inconsistent insertion standards between different modules. This embodiment, however, moves the OCC insertion decision forward to a structured data file, making the OCC layout strategy an auditable, quantifiable, and traceable data record. Whether to insert an OCC is controlled by simple Boolean logic through complex script branches. Regardless of the number of clocks in the chip, simply adjusting the flags in the table and rerunning the generation steps completes the adjustment of the entire chip's DFT architecture, improving design iteration efficiency.

[0084] In step S305, based on the value of the shutdown state field, a constraint instruction for setting the level state of the clock when it is in the shutdown state is generated in the first configuration file.

[0085] The parameter fields include a shutdown state field. The shutdown state field is a parameter field in the clock information object used to specify a fixed level value that the clock signal source should be forced to maintain when the clock is turned off.

[0086] Specifically, the currently processed clock information object (such as the clock information object Clk_HighSpeed_PLL) is read, and its member variable OffState field is accessed. The value of this variable is checked; 0 indicates that the clock remains low in the off state, and 1 indicates that the clock remains high in the off state. Based on the read value, a constraint instruction for the clock source pin input is generated and written to the first configuration file. This constraint instruction is used to indicate the control of the clock source in the off state. Through the constraint instruction, the clock level state maintained when the clock is off can be flexibly selected.

[0087] In some embodiments, such as Figure 4 As shown, the DFT clock architecture establishment method generates a second configuration file, specifically including the following steps S401 to S410.

[0088] In step S401, the structured data file corresponding to the chip's clock planning information is obtained.

[0089] In step S402, a corresponding clock information object is generated based on the values ​​of the index field, type field, and parameter field.

[0090] The parameter fields include clock name, clock frequency, clock source, master clock, multiplication factor, and division factor fields.

[0091] In step S403, if the type field indicates that the clock type is the root clock, a master clock creation command is generated based on the values ​​of the clock source field, the clock name field, and the clock frequency field.

[0092] In step S404, if the type field indicates that the clock type is a derived clock, a derived clock definition command is created based on the value of the clock name field.

[0093] In step S405, a clock source pin specification command for the derived clock is generated based on the value of the clock source field.

[0094] In step S406, a master clock source specification command for the derived clock is generated based on the value of the master clock field.

[0095] The root clock refers to the source of the chip's clock tree, which usually comes directly from an external crystal oscillator or the input pin of an automated test device, and has no internal parent clock.

[0096] A derived clock refers to a clock signal that is not directly generated by an external crystal oscillator or clock source, but is generated by processing other clock signals (i.e., the master clock) inside the chip through certain logic circuits (such as frequency dividers, frequency multipliers, and phase-locked loops). Its frequency and phase have a definite mathematical relationship with the master clock.

[0097] The clock source field is a string parameter in the clock information object that indicates the specific location where the clock signal is generated or injected in the physical netlist, used to locate the physical anchor point of the clock. For the root clock, the clock source field is the top-level input / output port; for derived clocks, the clock source field is the output pin of an internal register or combinational logic.

[0098] The master clock field is a parameter field in the clock information object used to specify the parent clock from which the current derived clock is derived. In complex clock networks, multiple different clock signals may propagate simultaneously on a single physical pin. This master clock field is used to logically eliminate ambiguity so that the DFT tool knows which parent clock waveform the currently defined clock is derived from.

[0099] The clock name field is a string parameter in the clock information object used to store the clock's identifier, which is readable in the design. In error reports or logs, simply providing the clock index is often not intuitive enough; providing the clock name allows engineers to quickly locate the specific circuit module.

[0100] The clock frequency field is the period or frequency of the clock information object.

[0101] Specifically, when the type field indicates that the clock type is the root clock, the clock source field is identified as pointing to the physical port (i.e., the value of this field). Then, this port is declared in the timing constraint file, and the clock waveform is defined. Example of timing constraint file code: Taking ClockName="clk_xtal", ClockPeriod="40", and ClockSource="PAD_XTAL_IN" as an example, the generated master clock creation command is: create_clock -name clk_xtal -period 40 [get_ports PAD_XTAL_IN]. Here, create_clock refers to the master clock creation command, which is the source of the zero point. The DFT tool will use this as a basis to calculate the setup and hold times of all subsequent flip-flops. -name clk_xtal indicates that this clock object is given a logical name, clk_xtal, which is the value of the clock name field. -period 40 represents the clock period, i.e., the value of the clock frequency field; the default unit is usually nanoseconds (ns). The `[get_ports PAD_XTAL_IN]` directive specifies the physical source of the clock. `get_ports` retrieves the top-level input / output ports from the design database, and `PAD_XTAL_IN` is the specific pin name of the top-level module, representing the value of the clock source field. This code physically binds a defined 40ns period ideal waveform to the chip's `PAD_XTAL_IN` pin. All signal paths entering the chip from this pin will be constrained by this clock.

[0102] When the type field indicates that the clock type is a derived clock, for example, the currently defined derived clock is a frequency-divided clock selected by a multiplexer with two input master clocks. If the master clock is not specified, the EDA tool cannot know which master clock the frequency-divided derived clock originates from. Therefore, the source of the frequency-divided derived clock is determined based on the value of the master clock field, generating the following timing constraint file:

[0103] create_generated_clock -name mux_clkA\

[0104] -source [get_pins u_mux / I0]\

[0105] -master_clock clk_A [get_pins u_mux / Z]

[0106] create_generated_clock -name mux_clkB\

[0107] -source [get_pins u_mux / I1]\

[0108] -master_clock clk_B [get_pins u_mux / Z] ​​-add

[0109] `create_generated_clock -name mux_clkA` means to create a derived clock and name it `mux_clkA`.

[0110] -source [get_pins u_mux / I0] specifies the clock source pin of the derived clock as u_mux / I0, which is the output pin of the multiplexer. The DFT tool will start from u_mux / I0 and trace back along the circuit netlist until it finds a master clock that has been defined.

[0111] The command `-master_clock clk_A[get_pins u_mux / Z]` specifies that the parent clock of this derived clock is clk_A. The DFT tool can trace back in reverse to find clk_A.

[0112] [get_pins u_mux / Z] ​​refers to the clock object of the command, which indicates that the newly defined clk_mux_out clock field of the DFT tool originates from the u_mux / Z pin and propagates downstream from there.

[0113] For an explanation of how to create the mux_clkB script, please refer to mux_clkA; it will not be repeated here.

[0114] In modern chip design, clock networks often contain numerous multiplexers and switches. Multiple logic clock waveforms are often superimposed at a single physical point. If the script file does not specify a master clock, synthesis tools may randomly select a source clock or report an error, leading to uncontrollable timing analysis results. This embodiment eliminates this ambiguity by mandating the inclusion of a master clock field in the parameter fields, ensuring the logical uniqueness of the clock tree topology. Furthermore, it can automatically distinguish between the root clock and derived clocks and generate different timing constraints.

[0115] In step S407, a frequency definition command for the derived clock is generated based on the value of the multiplication factor field or the division factor field in the clock information object.

[0116] The multiplication factor field is a numerical parameter in the clock information object used to store the clock frequency amplification factor, indicating how many times the clock frequency is a multiple of its master clock frequency. The division factor field is a numerical parameter in the clock information object used to store the clock frequency reduction factor, indicating what fraction of its master clock frequency is.

[0117] The frequency definition command is used to indicate the division factor or multiplication factor of the derived clock.

[0118] Specifically, read the member variable type field of the current clock information object. If the clock is a derived clock, read the value of the multiplication factor field or the division factor field from the clock information object. For the value of the division factor field, the original integer or fraction is read here, rather than the result after floating-point operation (such as 0.3333...).

[0119] For example, in a frequency division scenario, taking the value DivBy = 3 read from the frequency division coefficient field as an example, the generated frequency definition command would be:

[0120] -divide_by 3 [get_pins div_reg / Q]

[0121] In a frequency multiplication scenario, taking the value MultiBy = 2 read from the frequency multiplication coefficient field as an example, the generated frequency definition command is:

[0122] -multiply_by 2 [get_pins pll / out]

[0123] In this process, instead of dividing the period of the derived clock by the division factor according to the period of the master clock, the value of the division factor field is passed to the DFT tool as a parameter.

[0124] Based on the example of the derived clock creation command above, the complete code generated for a derived clock is as follows:

[0125] create_generated_clock -name mux_clkA \

[0126] -source [get_pins u_mux / I0]\

[0127] -master_clock clk_A [get_pins u_mux / Z]\

[0128] -divide_by 2 [get_pins u_mux / Z]

[0129] The explanations for the remaining lines of code are as described above and will not be repeated here. -divide_by 2 [get_pins u_mux / Z] ​​defines the frequency conversion relationship, indicating that the frequency of the generated clk_mux_out is 1 / 2 of the main clock clk_A, that is, the period is doubled.

[0130] In existing technologies, if the master clock period is 10ns, the period after a 3-division rule is 3.333…ns. If an engineer manually calculates and writes 3.33 in the script, it introduces an error of 0.003…ns. After multiple levels of clock tree propagation and frequency multiplication, this tiny accumulated error may be amplified, causing clock edge alignment checks to fail and resulting in pseudo-timing violations. This embodiment, however, directly transmits the value of the division coefficient field, allowing the DFT tool to perform precise derivation using a fractional algorithm internally, thus mathematically guaranteeing absolute clock edge alignment.

[0131] In step S408, if the value of the asynchronous grouping field of the clock information object is empty, a prompt message including the value of the clock name field is output, or the clock information object is assigned to the default synchronous clock group.

[0132] The parameter fields include the asynchronous grouping field. The asynchronous grouping field is a tag string in the clock information object used to identify the logical synchronization domain to which the clock belongs. This field abstracts the complex circuit phase relationship into a simple set relationship. Clocks with the same tag value are considered to belong to the same synchronization group, and the tool will check the timing between them; clocks with different tag values ​​are considered to be asynchronous to each other, and the tool will ignore the timing path between them.

[0133] This embodiment further addresses the issue of missing information that may exist in structured data. Especially in large-scale chip design, users may omit filling in certain asynchronous grouping fields for clocks. If a second configuration file is generated directly, it may cause timing analysis tools to report errors or produce unpredictable timing check behavior.

[0134] Iterate through each clock information object in memory, read the value of its asynchronous grouping field member variable, and check whether the variable is an empty string, a null pointer, or a specific invalid placeholder. When a clock information object is found to be missing asynchronous grouping field information, output a prompt message including the value of the clock name field to inform the user that a clock is missing a value for an asynchronous grouping member field.

[0135] For example, the value of the clock name field, vpu_clk, can be extracted from clock information object A. The value of the index field, 205, can also be extracted. A formatted log string can be constructed: "Warning: Clock object vpu_clk (index: 205) was not configured for asynchronous grouping." This string is written to the error log file or displayed in a message window in the user interface. This ensures that engineers can quickly locate the corresponding clock in the structured data file based on the name "vpu_clk" for correction.

[0136] Alternatively, the clock information object can be assigned to the default synchronous clock group. The default synchronous clock group has a special clock group container that stores all clock objects that do not have an explicitly specified asynchronous relationship.

[0137] To ensure that the subsequent generation process is not interrupted, the repair strategy is to force it to be classified into a safe default group.

[0138] For example, if the asynchronous grouping field of clock information object A is empty, the value of the asynchronous grouping field will be dynamically modified in memory to a preset value, such as "default_sync_grp". When generating asynchronous constraint commands subsequently, clock information object A will be automatically included in the "default_sync_grp" list.

[0139] In existing technologies, if script generation fails, it often only reports a vague syntax error, making it difficult for engineers to pinpoint which clock parameter is missing. This embodiment achieves semantic-level error reporting by explicitly including the clock name field value in the error message. Engineers can immediately locate the source of the problem upon seeing "vpu_clk" in the error message, significantly reducing troubleshooting time. Furthermore, if the program crashes upon encountering a null value, the user experience is extremely poor. The automatic grouping mechanism in this embodiment ensures that even with imperfect input data, the tool can generate a syntactically correct and logically complete timing constraint file, guaranteeing a smooth design process.

[0140] In step S409, if the value of the asynchronous grouping field of the clock information object is not empty, clock information objects with the same value of the asynchronous grouping field are grouped into the same clock group.

[0141] A clock group refers to a container or list dynamically constructed in memory to store all clock information objects with the same asynchronous grouping field value.

[0142] In step S410, asynchronous constraint commands for setting clock groups are generated between different clock groups.

[0143] The asynchronous constraint command is used to explicitly inform timing analysis tools or synthesis tools that there is no defined phase relationship between the specified multiple clock groups, so setup and hold time checks are not required.

[0144] For each clock information object, read the value of its member variable asynchronous grouping field. If the value is empty, it is either assigned to the default group or skipped according to a preset strategy. If the value is not empty, those with the same non-empty value are grouped into the same clock group.

[0145] For example, the asynchronous constraint commands generated by the SDC file are as follows:

[0146] set_clock_groups -asynchronous

[0147] -group [get_clocks {clk_core_0 clk_core_1 clk_axi_main}]

[0148] -group [get_clocks {clk_ddr_phy clk_ddr_ctrl}]

[0149] -group [get_clocks {clk_usb_48m}]

[0150] The physical meaning of this asynchronous constraint command is: group represents a group, and the clocks within the same group are synchronized (interoperable), but the three groups are asynchronous to each other.

[0151] In existing technologies, engineers need to manually maintain complex `set_clock_groups` scripts. Whenever a new clock domain is added to the design, if the engineer forgets to add it to the correct location in the script, that clock will default to synchronizing with all other clocks on the chip. This causes DFT tools to attempt to create physically impossible paths (such as a direct path from the CPU domain to the USB domain), resulting in significant logic redundancy and timing violations. For ATPG tools, proper asynchronous constraints are crucial. Without asynchronous definitions, ATPG tools may mistakenly assume that two asynchronous clocks can capture data simultaneously, generating invalid test vectors. These vectors might pass in simulation, but will fail on the actual chip due to clock drift, thus misclassifying good products as defective.

[0152] This embodiment ensures that as long as the user fills in the group label when defining the clock, the clock will be automatically added to the correct asynchronous group, fundamentally eliminating omissions. The generated SDC file can guide the ATPG tool to correctly shield cross-clock domain paths, ensuring that the generated test vectors are real and effective, thereby guaranteeing mass production yield. By transforming the complex pairwise mutual exclusion logic into a simple operation of entering asynchronous group fields in a structured data file, the maintenance threshold of the clock architecture is greatly reduced. Designers do not need to care about the specific SDC syntax details, nor do they need to manually check the pairwise relationships of hundreds or thousands of clocks; they only need to focus on the attributes of each clock itself.

[0153] In some embodiments, the structured data file is a spreadsheet file; such as Figure 5 As shown, the DFT clock architecture establishment method includes the following steps S501 to S505.

[0154] In step S501, the structured data file corresponding to the chip's clock planning information is obtained.

[0155] In step S502, the header row of the spreadsheet file is read, and a mapping table between column names and column indices is established.

[0156] A spreadsheet file is a computer file that organizes data in a two-dimensional grid format, typically consisting of rows and columns, with each cell storing text, numbers, or formulas.

[0157] The header row is a specific row in a spreadsheet file used to define the meaning of each column of data. It is located in the first row of the table and is predetermined in a predefined template.

[0158] For example, such as Figure 6 The image shows a portion of the data in the spreadsheet file provided in this disclosure. The header rows in the predefined template include: an index field; a block name field (block_name), a parameter field used to describe the name of the module to which the clock belongs; a clock type field (clock_type); a clock name field (clock_name), used to define the logical name of the clock signal; a clock source field (clock_source); a clock reference field (clock_reference), a parameter field mainly used in the Tessent process. When clock_type is a derived clock, this field is used to specify the derived clock referenced by its add_clock command; a master clock field (clock_master); a multiplication factor field (multi_by); a division factor field (div_by); a clock period field (clock_period); a period unit field (clock_unit), a parameter field used to define the value unit of the clock period field, such as ns; an off state field (off_state); an asynchronous group field (clock_group); and an OCC insertion flag field (is_occ). The columns in this predefined template are merely examples, and additional columns can be added as needed, which is not limited in this disclosure.

[0159] The mapping table between column names and column indexes is a key-value pair data structure built in memory. The key is the string name of the column, and the value is the physical index (integer) of that column in the table.

[0160] In step S503, the data rows of the spreadsheet file are traversed, and for each row of data, the values ​​of the index field, type field, and parameter field are extracted by matching column names according to the mapping table.

[0161] Column name matching refers to a data extraction strategy that first obtains the column number by looking up the mapping table, and then reads the data based on the column number.

[0162] Specifically, the header row of the spreadsheet file, i.e., all cell contents of Row 0, is read. The strings in each cell are standardized and their physical locations are recorded to build a memory mapping table.

[0163] For example, initialize an empty hash table `HeaderMap`, loop through the column index `col_index` from 0 to N, extract the current column name string, and perform normalization processing, such as removing leading and trailing spaces and converting it to all lowercase. Store the processed column name and the current loop variable `col_index` into the hash table, resulting in `HeaderMap["index"] = 0`, `HeaderMap["block_name"] = 1`, ..., `HeaderMap["clock_type"] = N`.

[0164] Starting from the next row after the header row, i.e., Row1, scan downwards row by row until you encounter the end-of-file character or a blank line.

[0165] For example, a loop variable `row_index` is set up and increments from 1. Each loop reads the entire row of data (`RowData`). For each row, the field values ​​are extracted by matching column names according to the mapping table. That is, when processing each row of data to construct the clock information object, the program no longer uses hard-coded numeric indices (such as `RowData`), but instead dynamically obtains the indices by querying the `HeaderMap`.

[0166] Specifically, when retrieving an index field, query `idx=HeaderMap["index"]`. If the key exists in the table, return 0 and read `Value=RowData`. When retrieving a type field, query `idx=HeaderMap["clock_type"]`. If the key exists in the table, return N and read `Value = RowData[N]`.

[0167] Using the extracted discrete data values, the constructor is called to instantiate each clock information object (ClockInfo) in memory, thus completing the conversion from spreadsheet file to in-memory digital model.

[0168] In step S504, a corresponding clock information object is generated based on the values ​​of the index field, type field, and parameter field.

[0169] In step S505, a first configuration file and a second configuration file are generated based on the clock information object.

[0170] In practical engineering, different design teams or engineers may have slightly different preferences for preset templates, such as inserting a notes column in the preset template. Traditional hard-coded parsers will misalign all subsequent data once a user inserts a column, leading to parsing failures or data errors. This solution establishes a mapping table that recognizes only column names, not their positions. Regardless of how the user swaps the column order or inserts numerous irrelevant notes, as long as the key column names exist, the tool can accurately extract the data, greatly reducing the barrier to entry and maintenance costs. When new clock attributes (such as "voltage domain") need to be added in the future, the user only needs to add a new column in Excel, and the tool code only needs to add a key-value lookup to the mapping logic, without modifying the underlying loop logic or index constants.

[0171] Figure 7 This disclosure presents a structural block diagram of a DFT clock architecture establishment device, such as... Figure 7 As shown, it includes: an acquisition section 701 and a generation section 702; the acquisition section 701 is configured to acquire a structured data file corresponding to the clock planning information of the chip, the structured data file including at least an index field for identifying the uniqueness of the clock, a type field for indicating the clock type, and a parameter field for indicating the clock attributes; the generation section 702 is configured to generate a corresponding clock information object based on the values ​​of the index field, the type field, and the parameter field; and, based on the clock information object, generate a first configuration file and a second configuration file, the first configuration file being a script file for driving the chip design for testability (DFT) tool to perform circuit insertion, and the second configuration file being a timing constraint file for driving synthesis or static timing analysis tools.

[0172] In some embodiments, the parameter field includes an on-chip clock control OCC insertion flag field; the generation section 702 is configured to traverse the value of the OCC insertion flag field of the clock information object, and if the value of the OCC insertion flag field is true, generate an instruction in the first configuration file for inserting OCC hardware logic on the corresponding clock path; if the value of the OCC insertion flag field is false, generate a clock definition instruction in the first configuration file.

[0173] In some embodiments, the DFT clock architecture establishment apparatus further includes: a determining portion, configured to determine that when the establishment time margin of the timing path corresponding to any clock is less than a preset timing threshold, the value of the OCC insertion flag field of the corresponding clock is true; when the number of OCCs already inserted in a preset layout area is greater than a preset density threshold, the value of the OCC insertion flag field corresponding to the remaining clocks in the layout area is false; and when the clock domain frequency of any clock is greater than a preset frequency threshold, or the clock tree depth is greater than a preset depth threshold, the value of the OCC insertion flag field of the corresponding clock is true.

[0174] In some embodiments, the parameter field includes a shutdown state field; the generation section 702 is configured to generate, in a first configuration file, constraint instructions for setting the level state of the clock when it is in the shutdown state, based on the value of the shutdown state field.

[0175] In some embodiments, the parameter field includes an asynchronous grouping field; the generation section 702 is configured to traverse clock information objects, group clock information objects with the same value in the asynchronous grouping field into the same clock group; and generate asynchronous constraint commands for setting clock groups between different clock groups.

[0176] In some embodiments, the parameter field includes a clock name field; the DFT clock architecture establishment apparatus further includes an output and allocation section configured to, before generating an asynchronous constraint command, output a prompt message including the value of the clock name field if the clock information object lacks a value for the asynchronous grouping field, or allocate the clock information object to a default synchronous clock group.

[0177] In some embodiments, the parameter fields further include a clock name field, a clock frequency field, a clock source field, and a master clock field; the generation section 702 is configured to generate a master clock creation command based on the values ​​of the clock source field, the clock name field, and the clock frequency field when the type field indicates that the clock type is a root clock; to generate a derived clock definition command based on the value of the clock name field when the type field indicates that the clock type is a derived clock; to generate a clock source pin specification command for the derived clock based on the value of the clock source field; and to generate a master clock source specification command for the derived clock based on the value of the master clock field.

[0178] In some embodiments, the parameter fields include a multiplication factor field and a division factor field; the generation section 702 is configured to generate a frequency definition command for a derived clock based on the value of the multiplication factor field or the value of the division factor field in the clock information object when the type field indicates that the clock type is a derived clock.

[0179] In some embodiments, the structured data file is a spreadsheet file; before generating the corresponding clock information object based on the values ​​of the index field, type field, and parameter field, the DFT clock architecture building apparatus further includes: a reading part and an extraction part; the reading part is configured to read the header row of the spreadsheet file and establish a mapping table between column names and column indices; the extraction part is configured to traverse the data rows of the spreadsheet file and, for each row of data, extract the values ​​of the index field, type field, and parameter field by matching column names according to the mapping table.

[0180] In some embodiments, the chip is a target die in a multi-die package chip that includes multiple dies; the acquisition section 701 is configured to acquire the structured data file corresponding to the target die based on the mapping relationship between the die identifier and the structured data file.

[0181] It should be noted that the above-mentioned DFT clock architecture establishment device can be the electronic device in the above method embodiment of this disclosure, or it can be a functional module and / or functional entity in the electronic device that can realize the function of the device embodiment. This disclosure does not limit it.

[0182] In this embodiment, each part can implement the DFT clock architecture establishment device method provided in the above method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0183] Please refer to Figure 8 This illustration shows a schematic diagram of the hardware structure of an electronic device provided in an exemplary embodiment of this disclosure. The electronic device may be a server, an EDA workstation, a personal computer, a laptop computer, or any other computing device capable of performing the methods of the embodiments of this application.

[0184] The electronic device includes a processor 810 and a memory 820; the processor 810 may be a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any combination thereof. The processor 810 is responsible for performing computational and logical operations.

[0185] The memory 820 can be volatile memory, non-volatile memory, or any combination thereof. The memory 820 stores computer programs (or software instructions).

[0186] When processor 810 is configured (or used) to execute a computer program stored in memory 820, it implements the steps of the method embodiments of this disclosure.

[0187] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include a display screen, camera assembly, microphone, speaker, radio frequency circuit, input unit, sensors (such as accelerometer, angular velocity sensor, light sensor, etc.), audio circuit, WiFi module, power supply, Bluetooth module, etc., which will not be described in detail here.

[0188] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the DFT clock architecture establishment method as described in the above embodiments.

[0189] This 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 executes the computer instructions, causing the electronic device to perform the DFT clock architecture establishment method described in the above embodiments.

[0190] This disclosure also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described DFT clock architecture establishment method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

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

[0192] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, servers, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0194] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0195] If the integrated unit is implemented as 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 this disclosure, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, non-volatile memory, volatile memory, magnetic disks, or optical disks.

[0196] Those skilled in the art will recognize that the functions described in this disclosure in one or more of the examples above can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0197] It should be noted that the technical solutions described in this disclosure can be combined arbitrarily as long as they do not conflict.

[0198] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method of DFT clock architecture establishment, characterized in that, The method for establishing the DFT clock architecture includes: Obtain the structured data file corresponding to the chip's clock planning information. The structured data file includes at least an index field for identifying the uniqueness of the clock, a type field for indicating the clock type, and a parameter field for indicating clock attributes. Based on the values ​​of the index field, the type field, and the parameter field, a corresponding clock information object is generated; Based on the clock information object, a first configuration file and a second configuration file are generated. The first configuration file is a script file used to drive the design for testability (DFT) tool to perform circuit insertion, and the second configuration file is a timing constraint file used to drive synthesis or static timing analysis tools.

2. The DFT clock architecture establishment method of claim 1, wherein, The parameter fields include the on-chip clock control OCC insertion flag field; Based on the clock information object, a first configuration file is generated, including: Iterate through the values ​​of the OCC insertion flag field of the clock information object. If the value of the OCC insertion flag field is true, generate an instruction in the first configuration file for inserting OCC hardware logic on the corresponding clock path. If the value of the OCC insertion flag field is false, a clock definition instruction is generated in the first configuration file.

3. The DFT clock architecture establishment method of claim 2, wherein, The method for establishing the DFT clock architecture also includes: When the setup time margin of any timing path corresponding to a clock is less than the preset timing threshold, the value of the OCC insertion flag field of the corresponding clock is determined to be true. When the number of OCCs already inserted in a preset layout area is detected to be greater than a preset density threshold, the value of the OCC insertion flag field corresponding to the remaining clocks in the layout area is determined to be false. When the clock domain frequency of any clock is detected to be greater than a preset frequency threshold, or the clock tree depth is greater than a preset depth threshold, the value of the OCC insertion flag field of the corresponding clock is determined to be true.

4. The DFT clock architecture establishment method of claim 1, wherein, The parameter fields include a shutdown status field; Based on the clock information object, a first configuration file is generated, including: Based on the value of the shutdown state field, constraint instructions are generated in the first configuration file to set the level state of the clock when it is in the shutdown state.

5. The DFT clock architecture establishment method of claim 1, wherein, The parameter fields include an asynchronous grouping field; Based on the clock information object, a second configuration file is generated, including: Iterate through the clock information objects and group clock information objects with the same value in the asynchronous grouping field into the same clock group; Generate asynchronous constraint commands for setting clock groups across different clock groups.

6. The DFT clock architecture building method of claim 5, wherein, The parameter fields include a clock name field; The method for establishing the DFT clock architecture also includes: Before generating the asynchronous constraint command, if the clock information object lacks a value for the asynchronous grouping field, a prompt message including the value of the clock name field is output, or the clock information object is assigned to the default synchronous clock group.

7. The DFT clock architecture establishment method of claim 1, wherein, The parameter fields also include a clock name field, a clock frequency field, a clock source field, and a master clock field; Based on the clock information object, a second configuration file is generated, including: If the type field indicates that the clock type is root clock, a master clock creation command is generated based on the values ​​of the clock source field, the clock name field, and the clock frequency field. If the type field indicates that the clock type is a derived clock, a derived clock definition command is created based on the value of the clock name field; Based on the value of the clock source field, generate the clock source pin specification command for the derived clock; Based on the value of the master clock field, generate the master clock source specification command for the derived clock.

8. The DFT clock architecture building method of claim 7, wherein, The parameter fields include a frequency multiplication coefficient field and a frequency division coefficient field; Based on the clock information object, a second configuration file is generated, including: When the type field indicates that the clock type is a derived clock, a frequency definition command for the derived clock is generated based on the value of the multiplication factor field or the division factor field in the clock information object.

9. The DFT clock architecture establishment method of claim 1, wherein, The structured data file is a spreadsheet file; Before generating the corresponding clock information object based on the values ​​of the index field, the type field, and the parameter field, the DFT clock architecture establishment method further includes: Read the header row of the spreadsheet file and establish a mapping table between column names and column indexes; Traverse the data rows of the spreadsheet file, and for each row, extract the values ​​of the index field, the type field, and the parameter field by matching column names according to the mapping table.

10. The DFT clock architecture establishment method of claim 1, wherein, The chip is a target die in a multi-die packaged chip that includes multiple dies; The structured data file corresponding to the obtained chip clock planning information includes: Based on the mapping relationship between the die identifier and the structured data file, the structured data file corresponding to the target die is obtained.

11. A DFT clock architecture establishment apparatus, characterized in that, The DFT clock architecture establishment device includes: an acquisition part and a generation part; The acquisition section is configured to acquire a structured data file corresponding to the chip's clock planning information. The structured data file includes at least an index field for identifying the uniqueness of the clock, a type field for indicating the clock type, and a parameter field for indicating clock attributes. The generation section is configured to generate a corresponding clock information object based on the values ​​of the index field, the type field, and the parameter field; and, Based on the clock information object, a first configuration file and a second configuration file are generated. The first configuration file is a script file used to drive the design for testability (DFT) tool to perform circuit insertion, and the second configuration file is a timing constraint file used to drive synthesis or static timing analysis tools.

12. An electronic device, comprising: It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the DFT clock architecture establishment method as described in any one of claims 1 to 10.

Images