Fault-tolerant quantum architecture design method and device, storage medium and electronic equipment

Abstract

The application discloses a fault-tolerant quantum architecture design method, device, storage medium and electronic equipment, wherein the fault-tolerant quantum architecture design method comprises the following steps: obtaining hardware configuration parameters of a target quantum computing architecture, and constructing a fault tree model based on the hardware configuration parameters; performing vulnerability evaluation on the fault tree model, generating a vulnerability quantification index, and determining a candidate component set requiring deployment of a resilience mechanism according to the vulnerability quantification index; configuring a corresponding resilience strategy for each component in the candidate component set, and generating a graceful degradation planning table based on the resilience strategy; inputting the fault tree model, the resilience strategy and the graceful degradation planning table into a formal verification engine to output a reliability certificate; and generating an authenticated resilience architecture netlist through a hardware description language according to the reliability certificate. The application can solve the technical problems that the quantum computing system lacks systematic fault-tolerant design, the fault response capability is insufficient, and the reliability index cannot be verified in the prior art.

Description

Technical Field

[0001] This application relates to the field of quantum computing technology, specifically to a fault-tolerant quantum architecture design method, apparatus, storage medium, and electronic device. Background Technology

[0002] Quantum computing, with its potential to surpass classical computing in solving specific problems, has become a cutting-edge research area in information technology. However, quantum computing systems face severe reliability challenges in practical deployment and operation. As the fundamental carrier of quantum information, qubits have extremely limited coherence time and are highly susceptible to decoherence caused by environmental noise, temperature fluctuations, and electromagnetic interference. Furthermore, the control signals for quantum gate operations suffer from timing jitter, and the measurement process of the readout resonator is prone to readout errors. These hardware-level instabilities collectively result in the overall reliability of quantum computing systems being far lower than that of classical computing systems.

[0003] To address the aforementioned reliability issues, several fault-tolerant quantum computing schemes have been proposed. For example, logical qubits are encoded using quantum error-correcting codes such as surface codes and Steane codes, and redundant physical qubits are used to detect and correct errors. Another approach is to improve operational reliability at the control level through mechanisms such as signal verification and repeated measurements.

[0004] However, current solutions typically employ fragmented and isolated fault-tolerance methods, lacking a systematic approach to overall resilience design at the system architecture level. This results in technical defects in quantum computing systems during actual deployment, such as unreliability, insufficient fault response capabilities, and a lack of verifiable reliability metrics. Summary of the Invention

[0005] This application provides a fault-tolerant quantum architecture design method, device, storage medium, and electronic device, which can solve the technical problems of current quantum computing systems lacking systematic fault-tolerant design, insufficient fault response capability, and inability to verify reliability indicators.

[0006] In a first aspect, embodiments of this application provide a fault-tolerant quantum architecture design method, including: Obtain the hardware configuration parameters of the target quantum computing architecture, and construct a fault tree model based on the hardware configuration parameters; Vulnerability assessment is performed on the fault tree model to generate vulnerability quantification indicators, and a set of candidate components for which resilience mechanisms need to be deployed is determined based on the vulnerability quantification indicators. Configure a corresponding resilience strategy for each component in the candidate component set, and generate a graceful degradation plan table based on the resilience strategy; The fault tree model, the resilience strategy, and the graceful degradation planning table are input into the formal verification engine to output a reliability certificate. Based on the reliability certificate, a certified resilient architecture netlist is generated using a hardware description language.

[0007] In the fault-tolerant quantum architecture design method provided in this application embodiment, the hardware configuration parameters include: the number of qubits, the decoherence time of the qubits, the clock jitter probability density function of the control signal, and the power spectral density of the environmental noise.

[0008] In the fault-tolerant quantum architecture design method provided in this application embodiment, the step of constructing a fault tree model based on the hardware configuration parameters includes: The decoherence time of the quantum bit is converted into a decoherence error probability distribution, the clock jitter probability density function is converted into a control signal timing error probability distribution, and the environmental noise power spectral density is converted into an environmental disturbance error probability distribution for quantum gate operations. Using the fault tree analysis method, with the functional failure of the target quantum computing architecture as the top event, the decoherence error probability distribution, the timing error probability distribution, and the environmental disturbance error probability distribution are respectively assigned as the bottom event probabilities of the fault tree; Based on the topological connection between qubits and control signals, logic gate connections from bottom events to top events are established to generate a fault tree model.

[0009] In the fault-tolerant quantum architecture design method provided in this application embodiment, the vulnerability assessment of the fault tree model and the generation of vulnerability quantification indicators include: A probabilistic model detection engine is used to perform Monte Carlo simulation on the fault tree model to calculate the first probability of occurrence of the fault mode corresponding to each of the bottom events. Based on the logic gate structure of the fault tree model, the second probability of occurrence of each intermediate event and the third probability of occurrence of the top event are calculated by the uppropagation algorithm, and the degree of influence of each bottom event on the occurrence of the top event is determined. Based on the topological connection between the qubits and the control signal, the fault propagation path is identified and the fault propagation path length is calculated; The first occurrence probability, the second occurrence probability, the third occurrence probability, the degree of impact, and the length of the fault propagation path are used as vulnerability quantification indicators.

[0010] In the fault-tolerant quantum architecture design method provided in this application embodiment, determining the set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification index includes: The first occurrence probability of the underlying event corresponding to each component is compared with a first preset threshold, and the components whose first occurrence probability is greater than the first preset threshold are marked as high failure probability components. The influence of each component on the occurrence of the top event is compared with a second preset threshold, and the components whose influence is greater than the second preset threshold are marked as key influencing components. Components whose fault propagation path length is greater than a third preset threshold are marked as long propagation path components; The union of the high failure probability components, the critical impact components, and the long propagation path components is taken as the candidate component set for which a resilience mechanism needs to be deployed.

[0011] In the fault-tolerant quantum architecture design method provided in this application embodiment, configuring a corresponding resilience strategy for each component in the candidate component set and generating a graceful degradation planning table based on the resilience strategy includes: For each component in the candidate component set, a corresponding elastic strategy is matched from a preset elastic strategy library based on the component type and vulnerability quantification index of the component. Configure the elastic strategy to the corresponding component; Based on the configured elasticity policy, multiple degradation levels are generated, and corresponding function reduction methods and degradation trigger conditions are defined for each degradation level. According to the degradation levels from low to high, the function reduction methods, degradation triggering conditions, and elastic strategy execution status of each component under the corresponding degradation level are structured and arranged to generate an elegant degradation planning table.

[0012] In the fault-tolerant quantum architecture design method provided in this application embodiment, the step of inputting the fault tree model, the resilience strategy, and the graceful degradation planning table into the formal verification engine to output a reliability certificate includes: The fault tree model is converted into a formal model of a probabilistic automaton or Markov decision process, the resilient strategy is converted into a state transition rule, and the graceful degradation planning table is converted into a jump condition between degradation states. The formal model, the state transition rules, and the jump conditions are input into the formal verification engine, which uses probabilistic computation tree logic or continuous random logic to define the elastic properties to be verified. The formal model is searched in state space using a model checking algorithm to verify whether the elasticity property holds and to calculate the reliability index value when the elasticity property is satisfied. The verified resilience attributes and their corresponding reliability index values ​​are packaged into structured data to generate a reliability certificate.

[0013] Secondly, embodiments of this application provide a fault-tolerant quantum architecture design device, comprising: An acquisition unit is used to acquire the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters. An evaluation unit is used to perform vulnerability assessment on the fault tree model, generate vulnerability quantification indicators, and determine a set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators. A configuration unit is used to configure a corresponding elasticity strategy for each component in the candidate component set, and generate a graceful degradation planning table based on the elasticity strategy; The output unit is used to input the fault tree model, the resilience strategy, and the graceful degradation planning table into the formal verification engine to output a reliability certificate. The generation unit is used to generate a certified resilient architecture netlist using a hardware description language based on the reliability certificate.

[0014] Thirdly, this application provides a storage medium storing a plurality of instructions adapted for loading by a processor to execute the fault-tolerant quantum architecture design method described in any of the preceding claims.

[0015] Fourthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the fault-tolerant quantum architecture design method described in any of the preceding claims when executing the computer program.

[0016] In summary, the fault-tolerant quantum architecture design method provided in this application includes obtaining the hardware configuration parameters of the target quantum computing architecture and constructing a fault tree model based on the hardware configuration parameters; performing vulnerability assessment on the fault tree model, generating vulnerability quantification indicators, and determining a set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators; configuring corresponding resilience strategies for each component in the candidate component set, and generating a graceful degradation planning table based on the resilience strategies; inputting the fault tree model, the resilience strategies, and the graceful degradation planning table into a formal verification engine to output a reliability certificate; and generating a certified resilience architecture netlist based on the reliability certificate using a hardware description language. This application embodiment can systematically perform fault modeling and vulnerability assessment on quantum computing architectures, automatically configure resilience strategies and generate graceful degradation planning tables, and output a certified architecture netlist with reliability guarantees through formal verification, thereby solving the technical problems of existing quantum computing systems lacking systematic fault-tolerant design, insufficient fault response capabilities, and unverifiable reliability indicators. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of the fault-tolerant quantum architecture design method provided in the embodiments of this application.

[0019] Figure 2 This is a flowchart illustrating the fault-tolerant quantum architecture design method provided in the embodiments of this application.

[0020] Figure 3 This is a schematic diagram of the fault-tolerant quantum architecture design device provided in the embodiments of this application.

[0021] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0024] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0025] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0026] In the description of this application, it should be noted that the terms "upper," "lower," "left," "right," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. In addition, terms such as "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] This application provides a fault-tolerant quantum architecture design method, apparatus, storage medium, and electronic device. Specifically, the fault-tolerant quantum architecture design apparatus can be integrated into an electronic device, which can be a server or a terminal, etc. The terminal can include mobile phones, wearable smart devices, tablets, laptops, and personal computers (PCs) and other computers and auxiliary devices. The server can be a single server or a server cluster composed of multiple servers, and can be a physical server or a virtual server.

[0028] For example, such as Figure 1 As shown, the electronic device can acquire the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters; perform vulnerability assessment on the fault tree model, generate vulnerability quantification indicators, and determine the candidate component set for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators; configure corresponding resilience policies for each component in the candidate component set, and generate a graceful degradation planning table based on the resilience policies; input the fault tree model, resilience policies, and graceful degradation planning table into a formal verification engine to output a reliability certificate; and generate a certified resilience architecture netlist based on the reliability certificate using a hardware description language.

[0029] The technical solutions shown in this application will be described in detail below through specific embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0030] Please see Figure 2 , Figure 2 This is a flowchart illustrating the fault-tolerant quantum architecture design method provided in this application embodiment. The specific flow of the fault-tolerant quantum architecture design method can be as follows: 101. Obtain the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters.

[0031] In the embodiments of this application, the target quantum computing architecture can be a quantum computing system based on superconducting qubits, or a quantum computing system based on ion traps, photons, or silicon-based quantum dots. Different quantum computing architectures have different hardware characteristics and fault characteristics, but all can be designed with fault tolerance using the methods provided in the embodiments of this application.

[0032] The hardware configuration parameters include the number of qubits, qubit decoherence time, clock jitter probability density function of the control signal, and power spectral density of ambient noise. The qubit decoherence time can be comprised of the transverse relaxation time T1 and the phase relaxation time T2, which together determine the qubit's coherence preservation capability in the absence of error correction. The clock jitter probability density function of the control signal describes the random deviation distribution of the timing of the output pulses from the control signal generator, which directly affects the accuracy of quantum gate operations. The power spectral density of ambient noise reflects the frequency distribution characteristics of external disturbances such as electromagnetic interference and temperature fluctuations in the environment in which the quantum chip operates.

[0033] In some embodiments, the step "constructing a fault tree model based on hardware configuration parameters" may include the following steps: 1011. Convert the decoherence time of a quantum bit into a decoherence error probability distribution, convert the clock jitter probability density function into a control signal timing error probability distribution, and convert the ambient noise power spectral density into an ambient disturbance error probability distribution for quantum gate operations.

[0034] For example, for a superconducting qubit with a decoherence time T2 = 50 microseconds, the error probability caused by decoherence during a quantum gate operation time of 10 microseconds is approximately 1 - e^(-10 / 50) ≈ 18.1%.

[0035] For example, when the standard deviation of clock jitter is 1 nanosecond, the probability of timing exceeding the gate operation tolerance can be calculated by combining the time window width of quantum gate operations.

[0036] For example, the probability that noise causes the gate operation to deviate from the ideal state can be calculated based on the ratio of noise spectral density to quantum gate amplitude.

[0037] 1012. Using the fault tree analysis method, with the functional failure of the target quantum computing architecture as the top event, the probability distributions of decoherence error, timing error, and environmental disturbance error are assigned as the bottom event probabilities of the fault tree.

[0038] Functional failure can be defined according to the specific application scenario. For example, for quantum chemical simulation tasks, functional failure can be defined as the fidelity of the final measurement result being less than 0.9; for quantum random number generation tasks, it can be defined as the output sequence failing the randomness statistical test.

[0039] 1013. Based on the topological connection between the qubits and the control signals, establish logic gate connections from bottom events to top events to generate a fault tree model.

[0040] In quantum computing, the qubit is the fundamental physical unit that carries quantum information within the target quantum computing architecture. In superconducting quantum computing architectures, qubits are typically implemented using a nonlinear resonator composed of a Josephson junction and a capacitor; in ion trap architectures, qubits are implemented using hyperfine levels of ions or electronic levels. The physical properties of the qubit (such as decoherence times T1 and T2) directly determine the fundamental coherence performance of the architecture.

[0041] The control signal is the physical driving source for manipulating the state of qubits in the target quantum computing architecture. In superconducting architectures, the control signal manifests as microwave pulses, coupled to the qubits through transmission lines to achieve single-qubit gate operations such as X-gates and Y-gates. In ion trap architectures, the control signal manifests as laser pulses or microwave fields, achieving quantum gate operations through Raman transitions or direct driving. The timing accuracy and amplitude stability of the control signal directly affect the fidelity of quantum gate operations.

[0042] For example, in a 5-qubit linear chain architecture, each qubit is connected to an independent control signal generator while sharing a common cooling environment. In this case, a decoherence error in any qubit will be propagated to system malfunction via an OR gate, while environmental noise disturbances will affect all qubits via an AND gate.

[0043] In one application example, a quantum computing company is designing a 64-qubit chip for quantum machine learning tasks. The designers input the chip's qubit decoherence time T2 = 100 microseconds, control signal clock jitter standard deviation of 0.5 nanoseconds, and the measured 1 / f noise power spectral density as hardware configuration parameters into the system. The system automatically constructs a fault tree model containing 64 decoherence error base events, 64 timing error base events, and 1 common environmental disturbance base event. The top event is defined as "the classification accuracy of the quantum machine learning task result is lower than 85%".

[0044] 102. Perform vulnerability assessment on the fault tree model, generate vulnerability quantification indicators, and determine the set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators.

[0045] First, a vulnerability assessment can be performed on the fault tree model to generate a quantitative vulnerability index. Specifically, this can include the following steps: 1021a. Use a probabilistic model detection engine to perform Monte Carlo simulation on the fault tree model and calculate the first probability of occurrence of the fault mode corresponding to each bottom event.

[0046] Understandably, the number of samples in a Monte Carlo simulation can be set to 10^6 to ensure that the confidence interval for the probability estimate is narrow enough. For example, for a qubit with a decoherence error probability of approximately 18.1%, after 10^6 simulations, the estimated first occurrence probability will converge to around 18.1%.

[0047] 1022a. A logic gate structure based on a fault tree model is used to calculate the second probability of occurrence of each intermediate event and the third probability of occurrence of the top event through an upward propagation algorithm, and to determine the degree of influence of each bottom event on the occurrence of the top event.

[0048] It should be noted that the degree of impact can be measured using "importance" metrics, such as structural importance, probabilistic importance, and critical importance. Probabilistic importance is defined as the partial derivative of the probability of the top event with respect to the probability of the bottom event, reflecting the sensitivity of the system to changes in the probability of the bottom event.

[0049] 1023a. Based on the topological connection between the qubits and the control signal, identify the fault propagation path and calculate the fault propagation path length.

[0050] The fault propagation path length can be quantified as the number of logic gates traversed from the bottom event to the top event. For example, a decoherent error bottom event is directly connected to the top event through an OR gate, and its propagation path length is 1; while an environmental disturbance bottom event must pass through an AND gate and then an OR gate to reach the top event, and its propagation path length is 2.

[0051] 1024a. The first occurrence probability, the second occurrence probability, the third occurrence probability, the degree of impact, and the length of the fault propagation path are used as vulnerability quantification indicators.

[0052] Understandably, these vulnerability quantification indicators characterize the vulnerability of a system from different dimensions: the first probability of occurrence reflects the failure tendency of the component itself, the second and third probabilities of occurrence reflect the failure risk at the system level, the degree of impact reflects the contribution of the component to the system failure, and the propagation path length reflects the ease or difficulty of the failure propagation.

[0053] Next, based on vulnerability quantification metrics, a set of candidate components for which resilience mechanisms need to be deployed is determined. Specifically, this may include the following steps: 1021b. Compare the first occurrence probability of the underlying event corresponding to each component with a first preset threshold, and mark the component with the first occurrence probability greater than the first preset threshold as a high failure probability component.

[0054] For example, if the first preset threshold is set to 10%, then qubits with a probability of occurrence greater than 10% will be marked.

[0055] 1022b. Compare the degree of influence of each component on the occurrence of the top event with the second preset threshold, and mark the components whose degree of influence is greater than the second preset threshold as key influencing components.

[0056] For example, if the second preset threshold is set to 0.05, components with an impact level greater than 0.05 will be marked.

[0057] 1023b. Components whose fault propagation path length is greater than the third preset threshold are marked as long propagation path components.

[0058] For example, if the third preset threshold is set to 3, components with a fault propagation path length greater than 3 will be marked.

[0059] 1024b. The union of high failure probability components, critical impact components, and long propagation path components is taken as the candidate set of components for which resilience mechanisms need to be deployed.

[0060] Understandably, this multi-indicator fusion screening method can comprehensively identify vulnerable links in the system and avoid omissions caused by a single indicator.

[0061] In one application example, vulnerability assessment of the fault tree model for the aforementioned 64-qubit chip revealed that: the 12 qubits located at the chip edge, due to stronger environmental noise, had a first occurrence probability as high as 15%, exceeding the first preset threshold of 10%, and were thus marked as high-probability fault components; the 8 key qubits located on the feature extraction path of the quantum machine learning model had an influence level exceeding 0.08, and were marked as key influencing components; while the 3 qubits located at the chip center with a complex connection topology had a fault propagation path length of 4, exceeding the third preset threshold of 3, and were marked as long propagation path components. Ultimately, the candidate component set included these 23 qubits and their corresponding control signal generators, with some components simultaneously satisfying multiple marking conditions.

[0062] 103. Configure a corresponding elasticity strategy for each component in the candidate component set, and generate a graceful degradation plan table based on the elasticity strategy.

[0063] In some embodiments, step 103 may include the following steps: 1031. For each component in the candidate component set, match the corresponding elasticity strategy from the preset elasticity strategy library based on the component type and vulnerability quantification index.

[0064] In this embodiment of the application, the resilient strategy library predefines the mapping relationship between various component types and resilient strategies. For example, for qubit components, the optional resilient strategies include double redundancy (configuring 2 spare physical qubits), triple redundancy (configuring 3 qubits for majority voting), and dynamic remapping (migrating logical qubits to healthy physical qubits when an error is detected).

[0065] For the control signal generator component, optional flexible strategies include dual-machine hot standby (two generators work simultaneously, triggering an alarm when the outputs are inconsistent), signal verification redundancy (each control pulse is accompanied by a check bit), and readback verification (measurement and verification are performed immediately after the gate operation is executed); for the read resonator component, optional flexible strategies include repeated measurement (multiple measurements are taken in the same state and the majority result is taken) and error detection code (verification information is embedded in the measurement sequence).

[0066] 1032. Configure the elasticity strategy to the corresponding component.

[0067] For example, for edge qubits marked as high-failure-probability components, the system employs a double redundancy strategy, meaning each edge qubit corresponds to two backup physical qubits. When the error rate of the main qubit exceeds the limit, the system automatically switches to the backup qubits. For qubits marked as critical impact components on the feature extraction path, the system employs a triple-modulus redundancy strategy to ensure the reliability of these critical qubits.

[0068] 1033. Based on the configured elasticity policy, generate multiple degradation levels, and define the corresponding function reduction method and degradation trigger conditions for each degradation level.

[0069] In this application embodiment, the degradation level is typically set from high to low according to the system functional integrity, for example: Downgrade level 0 (normal operation): All elastic policies are activated, and the system operates in full-featured state.

[0070] Degradation Level 1 (Mild Degradation): When the cumulative number of faulty components reaches 5, some of the spare qubits in the double redundancy strategy are shut down, but the effectiveness of the triple redundancy strategy on the critical path is still maintained.

[0071] Degradation Level 2 (Moderate Degradation): When the cumulative number of faulty components reaches 10, all double redundancy strategies are turned off, and only the triple redundancy strategy on the critical path is retained. The system can only run shorter quantum circuits.

[0072] Degradation Level 3 (Severe Degradation): When the cumulative number of faulty components reaches 15, all quantum gate operations are stopped, and only classical diagnostic programs are run to save and report the system status.

[0073] Degradation Level 4 (Safe Shutdown): When the cumulative number of faulty components reaches 20, execute the system safe shutdown procedure and release all control resources.

[0074] 1034. Arrange the function reduction methods, degradation trigger conditions, and elastic strategy execution status of each component in the corresponding degradation level in a structured manner according to the degradation level from low to high, and generate a graceful degradation planning table.

[0075] It should be noted that, in this embodiment of the application, the graceful degradation planning table is organized in tabular form, which facilitates the system to make quick decisions based on the real-time monitored fault counter during operation.

[0076] In a practical application example, the candidate component set in the aforementioned 64-qubit chip design includes 23 components. After matching a resilience strategy to each component, the system generates a graceful degradation planning table with five degradation levels. This graceful degradation planning table is integrated into the chip's microcontroller firmware, enabling the system to automatically degrade to an appropriate functional mode during actual operation as qubits fail one by one, rather than suddenly failing completely. For example, in one operation, three qubits at the chip's edge failed successively due to temperature fluctuations, the fault counter reached 3, and no degradation was triggered; when the fourth qubit failed, the fault counter reached 4, and the system automatically shut down some non-critical redundant backups, but the core computing tasks could still continue to run; when the cumulative faults reached 10, the system switched to a moderate degradation mode. Although it could not execute the original 64-qubit quantum machine learning task, it could still run a small-scale verification algorithm with 16 qubits.

[0077] 104. Input the fault tree model, resilience strategy, and graceful degradation planning table into the formal verification engine to output a reliability certificate.

[0078] Specifically, step 104 may include the following steps: 1041. Convert the fault tree model into a formal model of a probabilistic automaton or Markov decision process, convert the resilient strategy into a state transition rule, and convert the graceful degradation planning table into a transition condition between degraded states.

[0079] Understandably, the purpose of formal transformation is to convert engineering designs into models that can be processed by mathematical reasoning tools. For example, an "OR gate" in a fault tree model can be transformed into a parallel combination of multiple fault states in a probabilistic automaton, and an "AND gate" can be transformed into a sequential combination of multiple fault states.

[0080] In some embodiments, the redundancy switching logic in the resilient strategy can be converted into state transition rules. For example, when the primary component is in a "fault" state and the backup component is in a "healthy" state, the system state transitions from "redundancy mode" to "fault recovery mode".

[0081] In some embodiments, the triggering conditions in the graceful degradation planning table can be converted into transition conditions between degradation states. For example, when the fault counter is greater than or equal to the threshold N, the system state transitions from "degradation level k" to "degradation level k+1".

[0082] 1042. Input the formal model, state transition rules and jump conditions into the formal verification engine. The formal verification engine uses probabilistic computation tree logic or continuous random logic to define the elastic properties to be verified.

[0083] In practical applications, common elastic properties include the following three: "Under the failure of any single component, the system retains at least 90% of its logical qubits available." This property is expressed by the probability calculation tree logic formula as: P ≥ 0.9 [ G (number of failures = 1 → number of available qubits / total number of qubits ≥ 0.9)].

[0084] "The system recovery time between any three consecutive failure events does not exceed 100 microseconds". This property can be expressed by the continuous random logic formula as: P≤0.01 [F_{≤100μs} (recovery complete)].

[0085] "In downgrade level 2 mode, critical security functions continue to operate", this attribute can be represented as: P=1 [ G (downgrade level=2 → critical functions operating)].

[0086] 1043. Use a model checking algorithm to perform state space search on the formal model, verify whether the elasticity property holds, and calculate the reliability index value when the elasticity property is satisfied.

[0087] The model checking algorithm (such as the symbolic model checking in the PRISM tool) traverses all possible states of the system, checking whether the resilience properties are satisfied in each state. If the resilience properties are satisfied, the algorithm will also calculate the corresponding reliability metrics, such as the Mean Time To Failure (MTTF), Recovery Time Objective (RTO), and performance retention guarantee (e.g., "the system performance is not less than 80% of the design specifications for 95% of the runtime").

[0088] 1044. Package the verified elasticity attributes and corresponding reliability index values ​​into structured data and generate a reliability certificate.

[0089] In this embodiment of the application, the reliability certificate can be encoded in Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format, and includes the following fields: certificate number, generation time, target architecture identifier, list of verified resilience attributes, corresponding reliability index value, hash value of formal proof script (for subsequent verification), and digital signature (for tamper-proof).

[0090] In a practical application, the development team of a space-based quantum computing payload needed to perform reliability certification on the aforementioned 64-qubit chip to meet the reliability requirements of the space mission. They input a fault tree model, resilience strategies, and graceful degradation planning tables into a formal verification engine (using the PRISM model checking tool), defining three key resilience attributes: single-point fault tolerance, fault recovery time not exceeding 50 microseconds, and continued operation of core functions in degradation mode. The model checking run took approximately 2 hours, with the state space search covering approximately 10^8 states. The final verification results are as follows: the single-point fault tolerance attribute is valid, and the proportion of usable logical qubits in the system under a single-point fault is 94.2%; the fault recovery time attribute is valid, with a worst-case recovery time of 48 microseconds; and the attribute of continued operation of core functions in degradation mode is valid. Based on this, the system generated an XML-formatted reliability certificate, which can be submitted to the space project review committee along with the chip design documents as a basis for passing the reliability review.

[0091] 105. Generate a certified resilient architecture netlist using a hardware description language based on the reliability certificate.

[0092] First, the reliability certificate can be parsed to extract the resilience strategy parameters and verified resilience attribute constraints contained therein.

[0093] Among them, the elastic strategy parameters include hardware redundancy values ​​(such as double redundancy, triple redundancy), error correction code type and code distance parameters (such as surface code code distance d=3, Steane code coding rate), and degradation state transition conditions in the graceful degradation planning table (such as degradation threshold values).

[0094] Then, the elasticity policy parameters are converted into hardware description language code structures.

[0095] The hardware description language can be Verilog, VHDL, or SystemVerilog. Specific conversion methods may include: A. Convert the hardware redundancy value into instantiation statements for redundant qubits and gate-level descriptions of majority voting logic.

[0096] For example, for a double redundancy strategy, three physical qubits (one main qubit and two spare qubits) are instantiated in the hardware description language, and a majority voter module is added. This module receives the measurement results of the three qubits and outputs the result of the majority decision.

[0097] B. Convert the error correction code type and code distance parameters into register transfer level descriptions for the error correction encoder and decoder.

[0098] For example, for a surface code distance d=3, it is necessary to generate encoder logic containing 17 physical qubits (9 data bits and 8 measurement bits), as well as accompanying measurement and decoder logic.

[0099] C. Convert the degradation state transition conditions into a state transition logic description of a finite state machine.

[0100] For example, design a status register to store the current degradation level (0-4), a counter to accumulate the number of fault events, and a comparator to compare the counter with each degradation threshold. When the comparison result meets the jump condition, the state machine updates the status register to the new degradation level.

[0101] Next, the elastic property constraints are converted into hardware assertion statements, which are used to detect whether the elastic properties are satisfied during simulation or runtime.

[0102] For example, for the resilience property that "the proportion of available qubits under a single point of failure is not less than 90%", a SystemVerilog assertion can be generated: assert property (@(posedge clk) (fault_count == 1) |->(available_qubits>= total_qubits * 0.9)); these assertions can be checked in real time during simulation or used in FPGA prototyping or post-silicon verification after chip fabrication.

[0103] Finally, by combining the hardware description language code structure and hardware assertion statements, a certified resilient architecture netlist is generated.

[0104] Understandably, this resilient architecture netlist is a gate-level or transistor-level connectivity description that can be directly used for subsequent placement and routing, timing analysis, and tape-out manufacturing. The generated netlist includes a hash of a reliability certificate as a watermark to allow for traceability of authentication results in subsequent processes.

[0105] In some embodiments, a chip design company used the method of this application to design a 64-qubit fault-tolerant quantum chip. In step 105, after parsing the reliability certificate, the system automatically generated approximately 100,000 lines of SystemVerilog code, including redundant qubit instantiation statements, surface code encoder / decoder modules, graceful degradation state machines, and over 100 hardware assertion statements. This code was synthesized using Synopsys Design Compiler to generate a gate-level netlist containing approximately 2 million standard cells. This netlist was then submitted to a semiconductor foundry for tape-out manufacturing. The manufactured chip exhibited the expected resilience characteristics in laboratory testing: when a single qubit fault was introduced, the system automatically switched to a backup qubit without interruption; when the accumulated faults reached a preset threshold, the system automatically degraded to the corresponding functional mode, effectively preventing complete failure.

[0106] In summary, the fault-tolerant quantum architecture design method provided in this application includes obtaining the hardware configuration parameters of the target quantum computing architecture and constructing a fault tree model based on the hardware configuration parameters; performing vulnerability assessment on the fault tree model, generating vulnerability quantification indicators, and determining a set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators; configuring corresponding resilience policies for each component in the candidate component set, and generating a graceful degradation planning table based on the resilience policies; inputting the fault tree model, resilience policies, and graceful degradation planning table into a formal verification engine to output a reliability certificate; and generating a certified resilience architecture netlist based on the reliability certificate using a hardware description language. This application, through the systematic process of steps 101 to 105, achieves end-to-end design automation from hardware configuration parameter input to the output of a certified resilience architecture netlist. This application embodiment can systematically perform fault modeling and vulnerability assessment on quantum computing architectures, automatically configure resilience policies and generate graceful degradation planning tables, and output a certified architecture netlist with reliability guarantees through formal verification, thereby solving the technical problems of existing quantum computing systems lacking systematic fault-tolerant design, insufficient fault response capabilities, and unverifiable reliability indicators.

[0107] To facilitate better implementation of the fault-tolerant quantum architecture design method provided in this application, this application also provides a fault-tolerant quantum architecture design device. The meanings of the terms used are the same as in the fault-tolerant quantum architecture design method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0108] Please see Figure 3 , Figure 3 This is a schematic diagram of the fault-tolerant quantum architecture design device provided in an embodiment of this application. The fault-tolerant quantum architecture design device may include an acquisition unit 201, an evaluation unit 202, a configuration unit 203, an output unit 204, and a generation unit 205. Acquisition unit 201 is used to acquire the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters; Evaluation unit 202 is used to perform vulnerability assessment on the fault tree model, generate vulnerability quantification indicators, and determine the set of candidate components that need to be deployed with resilience mechanisms based on the vulnerability quantification indicators. Configuration unit 203 is used to configure a corresponding elasticity strategy for each component in the candidate component set, and generate an elegant degradation plan table based on the elasticity strategy; Output unit 204 is used to input the fault tree model, resilience strategy and graceful degradation planning table into the formal verification engine to output a reliability certificate; The generation unit 205 is used to generate a certified resilient architecture netlist using a hardware description language based on the reliability certificate.

[0109] For specific implementation methods of each of the above units, please refer to the embodiments of the fault-tolerant quantum architecture design method described above, which will not be repeated here.

[0110] In summary, the fault-tolerant quantum architecture design device provided in this application embodiment can acquire the hardware configuration parameters of the target quantum computing architecture through the acquisition unit 201 and construct a fault tree model based on the hardware configuration parameters; the evaluation unit 202 performs vulnerability assessment on the fault tree model, generates vulnerability quantification indicators, and determines a set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators; the configuration unit 203 configures corresponding resilience strategies for each component in the candidate component set and generates a graceful degradation planning table based on the resilience strategies; the output unit 204 inputs the fault tree model, resilience strategies, and graceful degradation planning table into a formal verification engine to output a reliability certificate; and the generation unit 205 generates a certified resilience architecture netlist based on the reliability certificate using a hardware description language. This application embodiment can systematically perform fault modeling and vulnerability assessment on quantum computing architectures, automatically configure resilience strategies and generate graceful degradation planning tables, and output a certified architecture netlist with reliability guarantees through formal verification, thereby solving the technical problems of lack of systematic fault-tolerant design, insufficient fault response capability, and inability to verify reliability indicators in existing quantum computing systems.

[0111] This application also provides an electronic device that may integrate the fault-tolerant quantum architecture design device of this application, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores and a memory 302 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 4The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs stored in the memory 302 and / or this application, and by calling data stored in the memory 302, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operation of the storage medium, user interface, and application programs, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0112] The memory 302 can be used to store software programs and this application. The processor 301 executes various functional applications and data processing by running the software programs and this application stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store applications required for operating the storage medium and at least one function; the data storage area may store data created based on the use of the electronic device. In addition, the memory 302 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0113] Although not shown, the electronic device may also include a display unit, an input unit, and a power supply, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more application programs into the memory 302 according to the following instructions, and the processor 301 runs the application programs stored in the memory 302 to realize various functions, as follows: Obtain the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters; Vulnerability assessment is performed on the fault tree model to generate vulnerability quantification indicators, and a set of candidate components for which resilience mechanisms need to be deployed is determined based on the vulnerability quantification indicators; Configure a corresponding resilience strategy for each component in the candidate component set, and generate a graceful degradation plan table based on the resilience strategy; Input the fault tree model, resilience strategy, and graceful degradation planning table into the formal verification engine to output a reliability certificate; A certified resilient architecture netlist is generated using a hardware description language based on the reliability certificate.

[0114] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0115] Therefore, embodiments of this application provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the methods provided in embodiments of this application. For example, the instructions can execute the following steps: Obtain the hardware configuration parameters of the target quantum computing architecture and construct a fault tree model based on the hardware configuration parameters; Vulnerability assessment is performed on the fault tree model to generate vulnerability quantification indicators, and a set of candidate components for which resilience mechanisms need to be deployed is determined based on the vulnerability quantification indicators; Configure a corresponding resilience strategy for each component in the candidate component set, and generate a graceful degradation plan table based on the resilience strategy; Input the fault tree model, resilience strategy, and graceful degradation planning table into the formal verification engine to output a reliability certificate; A certified resilient architecture netlist is generated using a hardware description language based on the reliability certificate.

[0116] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0117] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0118] Since the instructions stored in the storage medium can execute the steps of any method provided in the embodiments of this application, the beneficial effects that any method provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0119] The foregoing has provided a detailed description of the fault-tolerant quantum architecture design method, apparatus, storage medium, and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A fault-tolerant quantum architecture design method, characterized in that, include: Obtain the hardware configuration parameters of the target quantum computing architecture, and construct a fault tree model based on the hardware configuration parameters; Vulnerability assessment is performed on the fault tree model to generate vulnerability quantification indicators, and a set of candidate components for which resilience mechanisms need to be deployed is determined based on the vulnerability quantification indicators. Configure a corresponding resilience strategy for each component in the candidate component set, and generate a graceful degradation plan table based on the resilience strategy; The fault tree model, the resilience strategy, and the graceful degradation planning table are input into the formal verification engine to output a reliability certificate. Based on the reliability certificate, a certified resilient architecture netlist is generated using a hardware description language.

2. The fault-tolerant quantum architecture design method as described in claim 1, characterized in that, The hardware configuration parameters include: the number of qubits, the decoherence time of the qubits, the clock jitter probability density function of the control signal, and the power spectral density of the ambient noise.

3. The fault-tolerant quantum architecture design method as described in claim 2, characterized in that, The construction of the fault tree model based on the hardware configuration parameters includes: The decoherence time of the quantum bit is converted into a decoherence error probability distribution, the clock jitter probability density function is converted into a control signal timing error probability distribution, and the environmental noise power spectral density is converted into an environmental disturbance error probability distribution for quantum gate operations. Using the fault tree analysis method, with the functional failure of the target quantum computing architecture as the top event, the decoherence error probability distribution, the timing error probability distribution, and the environmental disturbance error probability distribution are respectively assigned as the bottom event probabilities of the fault tree; Based on the topological connection between qubits and control signals, logic gate connections from bottom events to top events are established to generate a fault tree model.

4. The fault-tolerant quantum architecture design method as described in claim 3, characterized in that, The vulnerability assessment of the fault tree model, generating a vulnerability quantification index, includes: A probabilistic model detection engine is used to perform Monte Carlo simulation on the fault tree model to calculate the first probability of occurrence of the fault mode corresponding to each of the bottom events. Based on the logic gate structure of the fault tree model, the second probability of occurrence of each intermediate event and the third probability of occurrence of the top event are calculated by the uppropagation algorithm, and the degree of influence of each bottom event on the occurrence of the top event is determined. Based on the topological connection between the qubits and the control signal, the fault propagation path is identified and the fault propagation path length is calculated; The first occurrence probability, the second occurrence probability, the third occurrence probability, the degree of impact, and the length of the fault propagation path are used as vulnerability quantification indicators.

5. The fault-tolerant quantum architecture design method as described in claim 4, characterized in that, The step of determining the set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification index includes: The first occurrence probability of the underlying event corresponding to each component is compared with a first preset threshold, and the components whose first occurrence probability is greater than the first preset threshold are marked as high failure probability components. The influence of each component on the occurrence of the top event is compared with a second preset threshold, and the components whose influence is greater than the second preset threshold are marked as key influencing components. Components whose fault propagation path length is greater than a third preset threshold are marked as long propagation path components; The union of the high failure probability components, the critical impact components, and the long propagation path components is taken as the candidate component set for which a resilience mechanism needs to be deployed.

6. The fault-tolerant quantum architecture design method as described in claim 1, characterized in that, The step of configuring a corresponding resilience strategy for each component in the candidate component set and generating a graceful degradation plan table based on the resilience strategy includes: For each component in the candidate component set, a corresponding elastic strategy is matched from a preset elastic strategy library based on the component type and vulnerability quantification index of the component. Configure the elastic strategy to the corresponding component; Based on the configured elasticity policy, multiple degradation levels are generated, and corresponding function reduction methods and degradation trigger conditions are defined for each degradation level. According to the degradation levels from low to high, the function reduction methods, degradation triggering conditions, and elastic strategy execution status of each component under the corresponding degradation level are structured and arranged to generate an elegant degradation planning table.

7. The fault-tolerant quantum architecture design method as described in claim 1, characterized in that, The step of inputting the fault tree model, the resilience strategy, and the graceful degradation planning table into the formal verification engine to output a reliability certificate includes: The fault tree model is converted into a formal model of a probabilistic automaton or Markov decision process, the resilient strategy is converted into a state transition rule, and the graceful degradation planning table is converted into a jump condition between degradation states. The formal model, the state transition rules, and the jump conditions are input into the formal verification engine, which uses probabilistic computation tree logic or continuous random logic to define the elastic properties to be verified. The formal model is searched in state space using a model checking algorithm to verify whether the elasticity property holds and to calculate the reliability index value when the elasticity property is satisfied. The verified resilience attributes and their corresponding reliability index values ​​are packaged into structured data to generate a reliability certificate.

8. A fault-tolerant quantum architecture design device, characterized in that, include: The acquisition unit acquires the hardware configuration parameters of the target quantum computing architecture and constructs a fault tree model based on the hardware configuration parameters. An evaluation unit is used to perform vulnerability assessment on the fault tree model, generate vulnerability quantification indicators, and determine a set of candidate components for which resilience mechanisms need to be deployed based on the vulnerability quantification indicators. A configuration unit is used to configure a corresponding elasticity strategy for each component in the candidate component set, and generate a graceful degradation planning table based on the elasticity strategy; The output unit is used to input the fault tree model, the resilience strategy, and the graceful degradation planning table into the formal verification engine to output a reliability certificate. The generation unit is used to generate a certified resilient architecture netlist using a hardware description language based on the reliability certificate.

9. A storage medium, characterized in that, The storage medium stores multiple instructions, which are adapted for loading by a processor to execute the fault-tolerant quantum architecture design method according to any one of claims 1-7.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the fault-tolerant quantum architecture design method as described in any one of claims 1-7.

Images