Chip and its design method and failure analysis method
By introducing a combination of volatile configuration registers and nonvolatile memory in integrated circuits, the problem of lack of system configuration information in integrated circuit failure analysis is solved, and efficient fault reconstruction and analysis is achieved.
Patent Information
- Application Number
- CN202110973645.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-08-27
- Filing Date
- 2021-08-24
- Publication Date
- 2025-08-15
- Estimated Expiration
- 2041-08-24
AI Technical Summary
In the prior art, failure analysis of integrated circuits is difficult to be performed in the absence of system configuration information, especially when a failure occurs in a customer system, the lack of specific configuration information of the chip within a wide working configuration range, resulting in difficulty in rebuilding the fault.
A chip is designed to include a volatile configuration temporary storage and a nonvolatile memory. The contents of the configuration temporary storage are stored in the nonvolatile memory through the writing unit, and the chip configuration is reconstructed using this information during fault analysis, including retaining memory locations on the chip to save the contents of the configuration temporary storage, and failure reconstruction is carried out using the nonvolatile memory.
By saving chip configuration information, the fault analysis process is simplified, the time and cost of fault reconstruction is reduced, and the efficiency of fault identification and repair is improved.
Smart Images

Figure CN114121133B_ABST
Abstract
Description
Technical Field
[0001] In general, the present application relates to hardware; in particular, the present application relates to a semiconductor device, and more particularly to a chip, a design method thereof, and a failure analysis method thereof. Background Art
[0002] Various persistent storage methods for storing configurations are known, whether implemented as non-volatile memory (NVM) or older complementary metal oxide semiconductor (CMOS) memory.
[0003] The following links: https: / / www.tech-faq.com / cmos-ram.html A method is described for saving system configuration settings in the field of personal computers (PCs).
[0004] Other prior arts related to capture system configuration include: US5497490A (IBM, 1991); US5768568A (IBM, 1997); US20100037042A1 (Foxconn, 2008); US6601190B1 (HP, 1999); US20130111275A1 and US20140325286A1 (Dell, 2011); and US20060168471A1 (Tandberg Storage ASA, 2005).
[0005] The disclosures of all publications and patent documents mentioned in this specification, as well as the disclosures of publications and patent documents directly or indirectly cited in such publications and patent documents, are hereby incorporated by reference, except where disclaimed or otherwise disclaimed. If such incorporated content is inconsistent with the present application, it should be interpreted as if the present application describes certain embodiments while the incorporated content describes other embodiments. Definitions of terms in such incorporated content should be considered as one possible definition of the term. Summary of the Invention
[0006] The following terms may be interpreted according to any definitions appearing in prior art documents, or according to the definitions in this specification, or include the following definitions within their respective scopes:
[0007] The term "write transaction" or "write operation" is intended to include any operation in which a processor or other type of master issues a target address and data to be written, resulting in the data being placed at the target pointed to by the address. The target may be any suitable target, including but not limited to a register, an input / output port (IO port), or a memory address. A write transaction may include a request message or a logical combination of control signals indicating that the operation to be performed is a "write."
[0008] The terms "chip," "device," and "integrated circuit" are used interchangeably.
[0009] The terms "programming a register" and "writing to a register" are used interchangeably.
[0010] "Configuration register" is intended to include any register that stores a value that affects the function of a device, such as changing the operating frequency of the device, changing the input / output function of the device, or turning certain device functions on or off.
[0011] According to some embodiments, bits or values in a configuration register are applied to an integrated circuit, resulting in multiple configurations of the integrated circuit.
[0012] Certain embodiments attempt to facilitate reconstruction of a failure (e.g., a failed chip) by providing (typically non-volatile) information within the chip that supports chip failure analysis, as failure analysis typically only needs to be performed based on information available from the chip itself without requiring the acquisition of additional information.
[0013] Chips have a wide range of possible operating configurations, making traditional fault reconstruction difficult. However, embodiments of the present invention exploit the fact that the application system writes all necessary settings into the chip's configuration registers, effectively selecting a specific operating configuration for the chip from a wide range of possible operating configurations. This configuration is stored in the chip for eventual retrieval later in a fault analysis scenario (if any), resulting in a highly advantageous fault analysis shortcut.
[0014] Certain embodiments seek to provide an improved integrated circuit, for example, designed to facilitate any of the functions described herein, in the manner described herein.
[0015] Some embodiments provide a chip or integrated circuit comprising all or any subset of the following components: NVM, configuration registers, an NVM writer (such as those described herein), an indicator that inhibits the NVM writer from being operated again after it has been operated once, and a trigger signal for the NVM writer. The chip can be embedded in an application system, and the application system can store the chip's settings in the chip's configuration registers.
[0016] Certain embodiments contemplate a method in which a chip is designed (generally, for at least one configuration register, including identifying a NVM in which the configuration stored in the register is to be stored in non-volatile form) and / or a processor is built that, when the processor configures the device (chip), sets the configuration in the NVM and / or records in the chip documentation which configurations are stored in those NVMs.
[0017] Certain embodiments contemplate providing an NVM write operation flow that includes all or any subset of the following operations, performed in a suitable order (e.g., the following order):
[0018] Operation 1: Provide a non-volatile indicator (eg, one bit, or more bits for safety) to complete the configuration save.
[0019] Operation 2: After exiting reset, if the indicator indicates "completed," NVM writes remain disabled (disabled) and no action is performed. Otherwise, the following events occur.
[0020] Operation: 3 After a trigger (e.g., the “storage register setting” trigger in the figure), the NVM writer performs the following actions:
[0021] Read the specified storage address.
[0022] Is the value the default value (erased)?
[0023] If it is a preset value, then the register value is written to the designated location.
[0024] Otherwise, the write action is skipped since it is presumed that the value has already been stored in the previous configuration sequence.
[0025] Operation 4: After completing the device configuration, the firmware code will set the non-volatile indicator to indicate "Done".
[0026] Operation 5: During the subsequent power-on or reset cycle, perform Operation 2.
[0027] If, for some reason, such as user interruption or system failure, the configuration cannot be completed in one sequence, the subsequent sequence will complete the configuration using the above operations.
[0028] Therefore, there are at least the following embodiments:
[0029] Example 1: A chip, also known as an integrated circuit, comprising
[0030] Volatile configuration registers; and / or
[0031] at least one on-chip non-volatile memory m, typically including at least one reserved memory location reserved for storing the contents of at least one volatile configuration register r among the volatile configuration registers; and / or
[0032] The write unit is configured to store values at least once, wherein the values indicate the content of at least one volatile configuration register r among the registers, generally stored in the at least one reserved memory location of the on-chip non-volatile memory m.
[0033] The writing unit may include an NVM writer and may also receive a trigger signal as described elsewhere in this specification.
[0034] Generally speaking, the at least one location (which may include a plurality of such locations) includes at least one complete space, segment or region, and the complete space, segment or region includes a plurality of locations and is located in the non-volatile memory m.
[0035] The at least one memory location is "reserved" so that neither the firmware nor the hardware on the chip is configured to use the reserved memory location for its own purposes (i.e., for purposes other than storing the contents provided by the write unit). This configuration ensures that the space used for this embodiment is safe within the total available space of the chip.
[0036] The at least one reserved memory location may include allocations of storage space for one or more registers, each of which is typically a number of bytes wide. The number of registers allocated for storage space is determined based on size and cost constraints, as well as the configuration complexity of a given chip.
[0037] Embodiment 2: A chip as in any of the preceding embodiments, wherein the writing unit comprises hardware located within the chip.
[0038] Embodiment 3: A chip as in any of the preceding embodiments, wherein the writing unit comprises firmware located within the chip.
[0039] One advantage of implementing the write unit in hardware, for example, entirely in hardware rather than entirely in firmware, or partially in hardware and partially in firmware, is that storing the register value does not interrupt the normal execution and function of the chip, so the operation of the write unit is transparent to the application system. However, in some use cases, the chip can afford the time it takes for the firmware to store a copy of the register value in the NVM.
[0040] Embodiment 4: A chip design method, comprising:
[0041] At least one chip is designed using electronic design automation (EDA) software. The at least one chip generally includes non-volatile memory (NVM) and / or volatile configuration registers located within the chip. The design generally includes providing the at least one chip NVM write function, the function being configured to write at least one setting to the non-volatile memory at least once. The at least one setting is generally stored by the application system in the at least one volatile configuration register of the chip.
[0042] Embodiment 5: A chip as in any of the preceding embodiments, wherein the write unit (also referred to as a "NVM writer") receives an address of the at least one volatile configuration register r when writing to the at least one volatile configuration register r, receives at least a portion of the data to be written to the at least one volatile configuration register r, and stores the data in the at least one reserved memory location.
[0043] Embodiment 6: The chip of any of the above embodiments, wherein the write unit is triggered by a trigger signal, and wherein the trigger signal is generated at least once when identifying a write to the register r.
[0044] The identification of a write-once operation may depend on the designer's definition of the mechanism or which configuration registers the NVM writer should involve.
[0045] Generally speaking, the NVM writer is triggered when a write transaction is performed on each register in a predetermined register range, such as register contents or values to be stored in the non-volatile memory within the chip.
[0046] The NVM writer (such as shown) or mechanism, when triggered, issues a write transaction to the NVM space allocated to store the register value. The data in the write transaction is the same as the aforementioned transmission.
[0047] Example 7: A chip as in any of the aforementioned embodiments, wherein the write unit is configured to store the contents in the memory m only when the application system in which the chip is located is powered on for the first time, and not to store the contents in the memory m each time the application system is powered on subsequently.
[0048] Embodiment 8: A chip as in any of the above embodiments, wherein after the write unit stores the contents of the at least one register r in the on-chip non-volatile memory m, it is inhibited (or disabled) from storing the contents of the at least one register r in the on-chip non-volatile memory m at least once.
[0049] Generally speaking, the write unit is permanently (or fixedly, constantly) inhibited, so that after storing the content of the at least one register r in the on-chip non-volatile memory m, the write unit is inhibited and no longer stores the content of the at least one register r in the on-chip non-volatile memory m.
[0050] Embodiment 9: A chip as in any of the above embodiments, wherein after the write unit stores the content of the at least one register r in the on-chip non-volatile memory m, it is inhibited from no longer storing the content of the at least one register r in the on-chip non-volatile memory m.
[0051] Embodiment 10: A chip as in any of the preceding embodiments, wherein the write unit receives a trigger signal, the logic structure of the trigger signal ensuring that the write unit does not store the write data in the at least one reserved memory location of the non-volatile memory m when subsequently writing to the register r.
[0052] A particular advantage of embodiments 7 to 10 is that the process of storing the contents of the volatile configuration register on the chip is not repeated each time the system is booted up. Such repetition is unnecessary and would result in the non-volatile memory being subjected to multiple writes to the same location.
[0053] Example 11: A fault analysis method, comprising:
[0054] At least one faulty chip is provided. The faulty chip generally includes:
[0055] Non-volatile memory (NVM), and / or
[0056] Volatile configuration registers; and / or
[0057] NVM write functionality, typically configured to write at least once a bit representing at least one setting stored in at least one volatile configuration register of the chip, typically to the non-volatile memory; and / or
[0058] The bits are received and the chip is configured according to the bits when reconstructing the failure of the chip.
[0059] The chip's configuration generally includes all settings stored in all configuration registers of the chip.
[0060] Typically (but not necessarily), the bits written to the NVM are all or part of the bits stored in all or part of the chip's configuration register. Alternatively, the bits written to the NVM can be derived by reversibly inferring the bits stored in the chip's volatile configuration register, such that some or all of the bits stored in the chip's volatile configuration register can be derived by retrieving the bits actually stored in the chip's NVM during fault analysis. For example, if for some reason the bits written to the NVM are known to be the inverse of the bits stored in the configuration registers (e.g., for every "1" stored in the configuration registers, a "0" is written to the NVM; and vice versa, for every "0" stored in the configuration registers, a "1" is written to the NVM), then during fault analysis, one can invert the bits read from the NVM and deduce the values that were loaded into the chip's configuration registers at the time.
[0061] When reconstructing a chip failure, the chip is configured based on the extracted bits: when the chip is operating (and presumably when the chip failed), if all bits loaded into all configuration registers of the chip are stored in the chip's NVM or can be derived from the chip's NVM, then all such bits are loaded into the chip's configuration registers and the failure reconstruction process continues. If not all bits loaded into all configuration registers of the chip are stored in the chip's NVM or can be derived from the chip's NVM, then all available bits are loaded into the chip's configuration registers and the failure reconstruction process continues by "scanning" all configuration options compatible with the available bits (and bits stored in the NVM). For example, if only five configuration registers of the chip are stored in the chip's NVM, then the chip is configured based on these configuration registers and the chip is operated with each possible configuration of the five remaining registers until the failure is reconstructed with one of the configurations.
[0062] The aforementioned embodiments, as well as other embodiments, will be described in detail in the “Implementation Methods” section.
[0063] Any trademarks appearing in this specification and drawings are the property of their respective owners and are used in this specification only to explain or illustrate the implementation of one embodiment of the present invention.
[0064] Unless otherwise stated, it should be apparent from the following that throughout this specification, the terms "process," "calculate," "estimate," "select," "rank," "rank," "calculate," "determine," "generate," "re-evaluate," "classify," "produce," "stereo-matching," "log," "detect," "correlate," "superimpose," "acquire," or similar terms refer to the actions and / or procedures of at least one computer or computing system, or processor, or similar electronic computing device, to manipulate and / or convert data represented as physical (e.g., electronic) quantities in the registers and / or storage of the computing system into other data represented as physical quantities in a similar form in the memory, registers, or other such information storage, transmission, or display device of the computing system. The term "computer" should be broadly interpreted to include any electronic device with data processing capabilities, including but not limited to personal computers, servers, embedded cores, computing systems, communication devices, processors (e.g., digital signal processors (DSPs), microcontrollers, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.), and other electronic computing devices.
[0065] Elements listed separately in this specification are not necessarily different components and can be the same structure. The statement "an element or feature may be present" is intended to include (a) embodiments in which the element or feature is present; (b) embodiments in which the element or feature is absent; and (c) embodiments in which the presence or absence of the element or feature is optional, for example, the user can configure or select the presence or absence of the element or feature. BRIEF DESCRIPTION OF THE DRAWINGS
[0066] Certain embodiments of the present invention are illustrated in the following drawings;
[0067] Figure 1 is a simplified block diagram illustrating a chip system according to one embodiment, including all or any subset of all the blocks in the diagram, generally all located in a single chip.
[0068] Figure 2 A decoder is shown in FIG. 1 , which can be used to implement Figure 1 The decoder in .
[0069] Figure 3 A NVM writer is shown in FIG. 1 , which can be used to implement Figure 1 NVM writer in .
[0070] Figure Number:
[0071] NVM: Non-volatile memory DETAILED DESCRIPTION
[0072] Methods and systems encompassed within the scope of the present invention may include, for example, some (eg, any suitable subset) or all of the functional blocks shown in the explicitly illustrated implementations, arranged in any suitable order (eg, as shown).
[0073] The operations, functions, or logic components described or illustrated in this specification may be implemented in a variety of forms, such as hardware circuits (such as, but not limited to, customized VLSI circuits, logic gate arrays, or programmable hardware devices (such as, but not limited to, FPGAs)), or software code stored on at least one tangible or intangible computer-readable medium and executed by at least one processor, or any suitable combination of the foregoing. A particular functional component may be formed by a specific sequence or software code, or by a plurality of such specific programs or software codes, wherein the programs or software codes collectively operate in the manner described in this specification for the functional component. For example, the component may be distributed across multiple code sequences, such as, but not limited to, objects, procedures, functions, routines, and programs, and may be derived from multiple computer files that generally operate in conjunction with each other.
[0074] Any logical functions described in this specification may be implemented in real-time applications as appropriate and may use any suitable architecture options, such as, but not limited to, ASICs or DSPs, or any suitable combination of the aforementioned architectures. Any hardware components mentioned in this specification may actually include one or more hardware devices (e.g., chips), which may be located in the same location or remotely located.
[0075] Devices manufactured by IC (integrated circuit) manufacturers have a variety of configuration options, provided to provide IC flexibility and / or to tailor device functionality to system-specific and application-specific requirements. IC configurations are typically set using registers. The registers used to set the IC configuration (or "configuration registers") are typically volatile, so non-default configuration settings are lost when power is removed. This is not a problem for the system itself, as the device is internal to the system and the system also has software or firmware code that configures the device according to the exact, specific configuration required for that particular system. Generally, each time the system is powered on, the software or firmware code reprograms the configuration registers by replacing certain default IC configuration settings stored in the configuration registers with non-default settings stored in the software or firmware code. This action may also be performed based on some table that may be referenced or accessed based on some external (to the chip) input (eg, an indication of a system model) that determines which of a set of configuration options should be applied by the firmware code.
[0076] Unfortunately, the volatility of IC configuration registers presents a problem for IC manufacturers' failure analysis engineers. In many cases, IC manufacturers ship devices to customers, which are then returned. Because the configuration settings are volatile, failure analysis engineers lack information about the exact configuration of the failed device in the customer's system. Failure analysis engineers do not have access to the customer's specific system, and it is unrealistic to assume access to every failing customer system. Consequently, current failure analysis of returned chips often must be performed completely out of context. In some cases, failure analysis engineers do not even know the system model from which the returned device was removed.
[0077] Certain embodiments enable failure analysis engineers to more easily debug and identify the problem that caused the device failure by providing them with information about the device configuration and operation at the time the problem occurred.
[0078] Understanding how the chip operates within the system is extremely helpful in this type of failure analysis. For example, the failure may only occur under certain conditions. In this case, knowing how the chip operates and / or in what system it operates can help determine the conditions under which the device failed, while another device may not fail because it was not exposed to those exact conditions. It should be noted that the device manufacturer may then modify the device design (even at this late stage), require the device to be tested to ensure that it does not fail in the same way, or simply discard the device, or take any other appropriate action.
[0079] The customer may return the device during the system development phase or later (for example, during the system mass production phase). The device is typically installed in a larger customer system. The system in which the device is installed is powered on and verified after installation. The system may fail during operation or verification. In such cases, using, for example, a known debugging process, the customer may conclude that the device may be the cause of the failure. The customer may then desolder the device and send it to the device manufacturer for analysis. If this situation occurs during the system development phase rather than the system mass production phase, there may be a customer development team that can informally provide the device engineer with system information, as well as device configuration information and system usage at the time of the failure. However, if the system has entered the mass production phase, there is no such customer development team, and it becomes very difficult for the device manufacturer to obtain any correct information (device configuration and usage at the time of the failure). Certain embodiments attempt to provide a failure analysis method, including:
[0080] A plurality of integrated circuit chip systems are provided, wherein each integrated circuit chip includes a volatile configuration register, at least one non-volatile memory M reserved for storing the contents of at least one register R among the volatile configuration registers; and a write unit for storing a copy of the contents of the at least one register R into the non-volatile memory M; and
[0081] When an individual chip system in the batch of integrated circuit chip systems is returned due to failure, a failure analysis is performed on the individual chip system, including retrieving the contents of register R from memory M, and then retrieving the configuration characteristics of the individual chip system at the time of failure, and configuring the individual chip system based on the characteristics to reconstruct the failure.
[0082] Some embodiments attempt to preserve IC configuration records, including recording all or at least critical hardware and / or firmware configurations within the IC, for future reference when failure analysis is required.
[0083] Certain embodiments include a chip system comprising (e.g. Figure 1 (as shown) all or a partial subset of the following (generally all located on a single chip);
[0084] Volatile configuration register, programmed by firmware;
[0085] (Generally speaking, the firmware is located in a memory available or accessible to a processor that configures the device. The processor and the memory may be located inside or outside the device, and the configuration of the device is what we wish to preserve);
[0086] Non-volatile memory (or NVM), located within the chip; and
[0087] The writing unit is used to record the contents of at least part of the registers in the NVM.
[0088] The information stored in the NVM may include all or a subset of the following:
[0089] A set of preset register configuration values: clock, pin multiplexing configuration, etc.
[0090] A set of default firmware configuration and operating mode settings: such as the number of temperature sensors, the number and pins of fans, and other specific parameters.
[0091] A preset OEM (Original Equipment Manufacturer) defined parameter set.
[0092] It should be noted that the above list is merely an example of possible purposes (or contents) for configuring registers and is not intended to be limiting. The write unit for recording content can be implemented in hardware or firmware. If implemented in hardware, the write unit for recording content generally includes write-back hardware; wherein each time the firmware programs any register in at least a predetermined subset of the registers to define a configuration to be applied to the chip, the hardware stores configuration data representing the chip configuration in the NVM (generally automatically, generally without any user or firmware intervention), thereby ensuring that the configuration to be applied to the chip is persistently preserved. Generally, the configuration data includes the exact bits in the register.
[0093] The default register subset can be the set of all configuration registers, in which case all contents of all configuration registers will be stored. Alternatively, if the NVM capacity required to store all configuration registers is too large, a critical register subset can be defined and only the contents of this critical subset can be stored, while the contents of configuration registers outside of this critical subset are not stored.
[0094] Typically, during the architecture definition phase of a future IC that will store at least some of the configuration register contents, the IC developers will decide which subset of registers are important enough to be recorded for future debugging purposes. Typically, this decision is then defined as part of the architecture of the future IC and implemented.
[0095] Generally speaking, each time the firmware writes a value into at least one of the registers, the hardware receives the value and stores it in a predetermined location in the NVM.
[0096] Re-"preset": Any pre-set information can be recorded in enterprise documents. For example, the internal or external specifications of the device (which are natural language documents) may include instructions such as "The values of registers A, B, and C of module X can be obtained from NVM addresses D, E, and F respectively. The values of registers H, I, and J of module Y can be obtained from NVM addresses K, L, and M."
[0097] Typically, when a manufacturer receives a device returned from the field and performs fault analysis on it, the contents of the primary NVM area are dumped, accessed, or downloaded (e.g., as a computer file), and the configuration information is made available. The fault analyst then has access to all of this information, facilitating analysis and testing of the device; they can focus on the specific configuration used by the chip in the specific system in which it is used. The following example illustrates how time-consuming fault analysis can be, necessitating focused analysis: A device has 77 user-selectable clock options. The device is returned by a customer, and no engineer is available to contact the customer team to identify which clock option the device was using when it failed. According to conventional techniques, this situation would force the fault analyst to analyze or verify the device under all 77 clock options. However, if the actual clock setting used in the system is accessible to the fault analyst (e.g., as described in this specification), the device only needs to be verified under this single clock setting, significantly saving debugging time and enabling faster problem identification.
[0098] According to conventional technology, when returned devices arrive at the device manufacturer for failure analysis, the failure analysis engineer may not even know in which system model the failed devices were disassembled.
[0099] The system model can be recorded in the device, for example, by programming code that programs certain system identifiers into the NVM (if the code has this information). However, generally speaking, having the configuration information described in this specification means that the fault analysis engineer no longer needs to know the system model.
[0100] As it is particularly applicable to firmware implementations, it should be noted that according to conventional techniques, the chip has two operating states:
[0101] State 1: Pre-operation (the state in which the device wakes up after being powered on);
[0102] State 2: Fully configured and operational (the state where the device is fully configured).
[0103] Generally speaking, the writing unit for recording content includes firmware program code, which operates in the device, wherein when a chip is in the latter state (fully configured operating state), the device adopts a default configuration parameter subset (reads and then writes these parameters to a "default" space in the NVM), for example to record at least the configuration parameter subset in the NVM.
[0104] An operating method, including all or any subset of the following operations, performed in a suitable order (eg, in the following order), can be provided as, for example, an extension or trigger signal of the NVM writer, causing the writer to operate only once.
[0105] Operation 1a: During the chip design phase, configuration register content to be stored is selected from the configuration register of the chip.
[0106] Operation 1b: Reserve sufficient NVM space within the total available space of the chip to store the contents selected in Operation 1a by ensuring that the firmware and hardware on the chip are configured to use a reserved memory location for a dedicated purpose (i.e., for purposes other than storing the contents of the configuration registers provided by the NVM writer).
[0107] Operation 1c: In addition to the NVM space reserved for storing the contents of the configuration registers, NVM bits are allocated in the chip to store a non-volatile indication or indicator to allow / trigger or prevent / inhibit the NVM writer (e.g., by ignoring), generally depending on whether the contents of the configuration registers have not been written to the NVM or have been written to the NVM. The non-volatile indicator can include a single bit (completed / incomplete) or more than one bit for safety reasons.
[0108] Operation 1d: According to one embodiment, when generating the application firmware code specifically responsible for configuring the chip, a logic operation is added to set the non-volatile indicator to, for example, "completed" or "incomplete" after the device configuration is completed (for example, when the contents of the configuration registers have not yet been written to the NVM).
[0109] The "application firmware code" is generally the firmware code for the device (or chip) that performs whatever primary application the device (e.g., the chip) is built for. Generally, one of the first operations performed by the application firmware is to configure the device or chip on which the firmware operates. This configuration is generally performed by a sequence of firmware instructions that executes a corresponding sequence of writes to registers. If this sequence (which takes some time) completes successfully, the end result is that all necessary values are stored in the chip's configuration registers. However, sometimes the sequence cannot complete successfully, in which case not all necessary configuration values are stored in the NVM.
[0110] Therefore, the mechanism or NVM writer is responsible for repeating the aforementioned process until, for example, the firmware code marks the configuration as complete.
[0111] Operation 2a: Each time the system (the application system in which the chip is embedded) leaves reset (eg, any power-on or reset cycle), if the indicator indicates "completed," the NVM writer remains closed, and thus no action is performed, and the process ends.
[0112] Operation 2b: If no (if the indicator indicates that the configuration has not been saved yet, or has not been written to the NVM), a decoder (e.g. Figure 1 ) provides a trigger signal (eg, "store register set" in the figure) to the NVM writer. The decoder generally recognizes the writing to the configuration register and the fact that the register is one of the registers selected in operation 1a.
[0113] The decoder's example decoding logic is shown in Figure 2 Among them Figure 2 The memory mapping information shown corresponds to Figure 1 Write information to the temporary register.
[0114] Operation 3: responding to the trigger signal;
[0115] Operation 3a: The NVM writer reads the designated memory address (e.g., an address in the on-chip memory that has been reserved to save the configuration)
[0116] Operation 3b: If the value in the designated storage address is a preset value (erased), the NVM writer writes the register value to the designated location (designated storage address).
[0117] Otherwise (eg, if the value in the designated memory address is not the default value (not erased)), the NVM writer skips the write operation 3b because the register value can be inferred to have been stored in the previous configuration sequence.
[0118] Operation 4: When the chip configuration is completed, the application firmware program code responsible for the chip configuration (which can definitely know that the chip configuration is completed) sets the indicator to, for example, “not completed”.
[0119] The example interface logic of the NVM writer is shown in Figure 3 The NVM writer writes data to the NVM through the NVM interface. Figure 3 The memory mapping information shown corresponds to Figure 1 Write information to the temporary register.
[0120] Therefore, if configuration is not completed in one sequence (eg, due to user interruption or system failure), subsequent sequences of application firmware instructions executing register writes will complete the configuration, and write operation 3b will be performed in those subsequent sequences.
[0121] It should be noted that the embodiments described herein help support analysis of failures caused by manufacturing defects and also help discover design defects that were not discovered in previous stages.
[0122] According to some embodiments, a method is provided, comprising all or a subset of the following operations, performed in a suitable order (e.g., in the following order):
[0123] Chip manufacturers design a chip architecture that includes:
[0124] Volatile configuration register;
[0125] at least one non-volatile memory M reserved for storing the contents of at least one register R among the volatile configuration registers; and
[0126] Hardware or firmware configured to store at least a copy of the contents of register R in the non-volatile memory M;
[0127] The chip manufacturer generates product documentation including a human-readable description of the non-volatile memory retained to store the contents of at least one of the volatile configuration registers;
[0128] A chip manufacturer makes a batch of chips;
[0129] Chip manufacturers perform production testing to identify defective chips, such as chips with manufacturing defects. However, production testing may be limited by unknown "testing coverage pinholes" that may cause defective chips to occasionally go undetected. So, for example, if 95% of chips can be perfectly manufactured and tested, then 5% of chips have manufacturing defects. Of these defective chips, the majority (perhaps greater than 4.9%) are successfully screened out or detected by existing production testing, but for example, at a given moment, a very small percentage (e.g., a few DPPM (defective chips per million)) of chips have manufacturing defects but are not detected, thereby defining a hole in the test coverage;
[0130] Chip manufacturers provide customers with chips after production testing, which may include defective chips. The chips are in a pre-operational state; customers install the chips in their systems (or "application systems").
[0131] Each time the application system is powered on, the system's processor, software, or firmware code configures the chip, including replacing the contents of register R (e.g., a default value or "reset value") with the system-selected configuration value; and the hardware or firmware triggered by the replacement of the contents of register R copies the system-selected configuration value(s) to the non-volatile memory M on the chip (i.e., located within the chip).
[0132] It should be noted that the aforementioned operation e pertains to an abnormal chip among a large batch of chips that have passed production testing. This chip has a manufacturing defect due to a vulnerability, unlike other chips produced in the same batch. These other chips generally do not have defects, so the aforementioned operation e is not applicable to these other chips.
[0133] Typically, the application system eventually fails; the customer desolders the chip and returns the desoldered chip (which is attributed to the cause of the failure) to the chip manufacturer's failure analysis engineer. Typically, the customer provides the engineer with only vague information or no information about the failure (e.g., "the system won't boot" or "the system displays a black screen continuously").
[0134] The chip manufacturer's failure analysis engineer dumps the chip's non-volatile memory M and then consults the product documentation to identify the contents of the volatile configuration registers, thereby at least partially understanding the chip's configuration at the time of the failure.
[0135] The more complete the understanding of the chip configuration at the time of the failure, the easier and faster the chip manufacturer's failure analysis engineers can achieve the goal of reproducing or recreating the failure (making the customer's reported failure actually occur again). The time required to recreate the failure is reduced because the number of chip configurations that need to be tested to recreate the customer's reported failure is reduced, generally by the same factor.
[0136] Example: A chip design has two clock domains (i.e., two logic domains), each with a clock of a different frequency. A chip with this design has a defect. The defect causes a failure only when there is a certain relationship between the two clocks in use, for example, only when the first clock is exactly twice the second clock. According to the prior art, there is little or no information available about the actual configuration of the chip when it fails. Therefore, engineers must analyze the operating state of the chip multiple times to reconstruct the failure reported by the customer (all frequency combinations of the two clocks must be analyzed) until one frequency combination just causes the failure reported by the customer. From a statistical point of view, this situation may only occur after laboriously checking, for example, half of the frequency combinations one by one. However, according to one embodiment of the present invention, the set frequency pairing is recorded in a location specified in the product documentation. The advantage of this configuration is that the failure analysis engineer only needs to test the chip under this specific clock setting (to verify that the reported failure actually occurs), which can shorten the time required to identify the root cause of the failure;
[0137] The failure analysis engineer identifies a gap in test coverage that allowed the previously described failure to be successfully reconstructed. When failure reconstruction is facilitated by identifying the operational configuration of the chip at the time of the failure, any known method, such as determining which specific function in the chip caused the overall failure, can be used to identify the coverage gap. For example, the gap may be caused by the chip's existing test process failing to detect a clock generator generating an erroneous clock frequency, an address decoder preventing a register access, or a specific flip-flop failure, where the clock generator (or address decoder, or flip-flop) is the cause of the overall failure;
[0138] The failure analysis engineer implements a test patch that closes the test coverage gap. For example, the failure analysis engineer designs a test to add to the existing test flow to check whether the omitted clock generator generates the correct clock frequency, or whether the omitted address decoder no longer prevents register access, or whether the omitted flip-flop operates properly, and so on.
[0139] Therefore, engineers can perform more efficient fault analysis because the chip's configuration at the time of the fault is at least partially known. It should be noted that fault reconstruction facilitated by the methods described herein is often the most challenging part of the fault analysis process.
[0140] It should be noted that, more generally, when failure reconstruction is facilitated by identifying the operational configuration of the chip at the time of the failure, any known method can be used to identify where the coverage hole is.
[0141] It should be noted that a device may still be operational even when it fails, because the failure may be partial (perhaps only a specific function or only a specific signal fails or is damaged) and does not necessarily mean that the device is completely dead. Therefore, the device may still be operational, allowing the failure to be observed to obtain information for debugging and fault analysis.
[0142] It should be noted that a variety of implementations are possible, depending particularly on the microarchitecture of each given chip, and the specific memory being used.
[0143] A particular advantage of certain embodiments is that volatile registers cannot generally be replaced entirely with non-volatile registers due to the fact that the memory (whether volatile or non-volatile) does not have external access or contact channels to each bit, which is generally required to configure the registers. One can store a configuration in NVM and then have the firmware copy (i.e., store a copy) the configuration, and the embodiments described herein can achieve this automatically without requiring, for example, user intervention in the device to complete the process.
[0144] The mechanism or NVM writer described in this specification may be implemented as a (finite) state machine in the chip; any suitable hardware implementation of the state machine may be used using known techniques, such as https: / / mitpress.mit.edu / books / finite-state-machines-hardware Generally, the state machine acquires address information and data and generates an NVM write transaction. Firmware used to implement certain embodiments of this specification may be stored in non-volatile memory, such as flash memory or read-only memory (ROM).
[0145] Alternatively, some embodiments described herein may be implemented partially or solely (ie, without firmware) in hardware, in which case some or all of the variables, parameters, sequential operations, and calculations described herein may be implemented in hardware.
[0146] It should be noted that words such as "essential", "must", and "required" are used for clarity of description to refer to implementation choices made in the specific implementation or application scenarios described in this specification, and are not intended to be limiting, as the same elements may be defined as non-essential or even removed altogether in alternative implementations.
[0147] The features (including operations) of the present invention that are described in the context of multiple separate embodiments may also be implemented in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding program embodiment, and vice versa. The features may also be combined with features known in the art to which the present invention belongs, in particular (but not limited to) the known features described in the "Prior Art" section and the public documents mentioned in that section. Conversely, the features (including operations) of the present invention that are described in the context of a single embodiment or in a certain order for the sake of brevity of description may also be implemented separately or in any suitable subcombination, including features known in the art to which the present invention belongs (in particular (but not limited to) the known features described in the "Prior Art" section and the public documents mentioned in that section), or in a different order. The word "for example" is intended to be a non-limiting example. Each method may include some or all of the operations shown or described, performed in a suitable order, for example, in the order shown or described in this specification.
Claims
1. A chip, characterized in that: include: Multiple volatile configuration registers; an on-chip non-volatile memory comprising at least one reserved memory location for storing the contents of at least one of the volatile configuration registers; as well as a writing unit configured to store a value in the at least one reserved memory location of the on-chip non-volatile memory, the value indicating the content of at least one of the volatile configuration registers; The writing unit is inhibited from storing the content in the on-chip non-volatile memory at least once after storing the content in the on-chip non-volatile memory.
2. The chip according to claim 1, characterized in that The writing unit includes hardware located within the chip.
3. The chip according to claim 1, characterized in that The writing unit includes firmware located within the chip.
4. The chip according to claim 1, wherein: When writing to the at least one volatile configuration register, the write unit receives an address of the at least one volatile configuration register, receives at least a portion of data to be written to the at least one volatile configuration register, and stores the data in the at least one reserved memory location.
5. The chip according to claim 1, characterized in that The write unit is triggered by a trigger signal, and the trigger signal is generated at least once when a write to the register is recognized.
6. The chip according to claim 1, characterized in that The write unit is configured to store the content in the non-volatile memory on the chip only when the application system where the chip is located is powered on for the first time, and not to store the content in the non-volatile memory on the chip each time the application system is powered on subsequently.
7. The chip according to claim 1, characterized in that After storing the content in the on-chip non-volatile memory, the write unit is permanently inhibited from storing the content in the on-chip non-volatile memory.
8. The chip according to claim 1, characterized in that The write unit receives a trigger signal, and a logic operation of the trigger signal ensures that the write unit does not store the data written to the register in the at least one reserved memory location in a subsequent write operation to the register.
9. A chip design method, characterized in that: include: Using electronic design automation software to design at least one chip, the chip including a non-volatile memory and a volatile configuration register; The design includes providing a non-volatile memory write function to the at least one chip, wherein the non-volatile memory write function is configured to write at least one setting to the non-volatile memory, wherein the setting is the content stored in at least one volatile configuration register of the chip; The non-volatile memory write function is inhibited from storing the content in the on-chip non-volatile memory at least once after storing the content in the on-chip non-volatile memory.
10. A fault analysis method, characterized in that: include: At least one faulty chip is provided, wherein the faulty chip comprises: Non-volatile memory; Volatile configuration registers; and a non-volatile memory write function configured to write a bit to the non-volatile memory at least once, the bit being used to indicate at least one setting stored in at least one volatile configuration register of the chip; and Retrieving the bits and configuring the chip according to the bits when reconstructing a failure of the chip; The non-volatile memory write function is inhibited from storing the content in the on-chip non-volatile memory at least once after storing the content in the on-chip non-volatile memory.
Citation Information
Patent Citations
Automatically triggered snapshot data dump for storage unit with embedded system
US20060168471A1
System for switching BIOS set-values
US20100037042A1
Troubleshooting system using device snapshots
US20130111275A1
Troubleshooting system using device snapshots
US20140325286A1
Automatic reconfiguration of alterable systems
US5497490A