Implementing and verifying security measures in system design based on security specifications generated according to security requirements

Abstract

A system enhances a system design to include security measures. The system receives a system design for processing through various stages of design using design tools, such as electronic design automation tools for introducing security features in circuit design. The system receives security requirements for the system design, the security requirements specifying security measures for the system design. The system generates security specifications from the security requirements, the security specifications storing a set of commands. The system generates the system design enhanced with the security measures. The enhanced system design is generated for at least a subset of a plurality of tools. The tools process the generated security specifications to implement the security measures in the system design according to the received security requirements.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Patent Application Serial No. 63 / 014857, filed April 24, 2020, the contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the design of automated systems, and more specifically, to security measures such as security mechanisms implemented in systems such as electronic circuits based on security specifications generated according to security requirements. Background Technology

[0004] In the system design flow, users analyze potential faults (e.g., safety hazards) and mitigate them by adding safety measures to the design. Examples of this design flow include automated design flows. Safety measures are documented and tracked in safety requirement management tools. This process requires users to manually add safety measures to the design and ensure they are correctly implemented and verified throughout the design cycle. Typically, several design tools are used throughout the design cycle. For example, in the circuit design cycle, several electronic design automation tools are used, including verification tools, synthesis and placement / routing tools, fault simulators, etc. Consistently implementing safety measures across such a wide range of tools is a lengthy and error-prone process. If safety measures are not implemented correctly or are completely ignored, the resulting loss of diagnostic coverage may not be identified until much later in the design cycle, or may be completely overlooked. This results in a significant waste of effort, as several design processes may have to be repeated with corrected designs. Alternatively, if inconsistencies in the implementation of safety measures are completely ignored, the resulting product may have a flawed design. Summary of the Invention

[0005] The above and other problems are addressed through computer-implemented methods, computer systems, and computer program products for instructions used to enhance system designs to include security measures. A system design is received for processing using design tools throughout the design cycle. For example, the system design may represent a circuit design, which is processed by several EDA tools. The system receives security requirements for the system design. The security requirements specify security measures for the system design. Examples of security measures include a security register having one of the following: three-mode redundancy, two-mode redundancy, or fault tolerance; dual-core lockstep; fault-protected finite state machine or monitor. The system generates a security specification based on the security requirements, which comprises a set of commands. The commands specify (a) security measures for one or more components of the system design, and (b) one or more attributes processed by one or more tools for implementing and verifying the security measures. Based on the security specification, the system generates a system design enhanced with the security measures. The enhanced system design is generated for at least a subset of multiple tools. Each tool from the subset processes the generated security specification to implement and verify the security measures in the system design according to the received security requirements.

[0006] Security measures are implemented in components of the system design. These components can be software components, hardware components, or firmware components.

[0007] In one embodiment, the tools from the subset are synthesis tools, and the security specifications generated by the synthesis tools include: selecting commands to specify security measures, and modifying the representation of the circuit design processed by the synthesis tools to implement the security measures specified by the commands.

[0008] In one embodiment, the tools from the subset are layout and routing tools for circuit design, and the security specifications generated by the synthesis tools include: selecting a security specification command from the specified security measures, and ensuring physical separation between components by the layout and routing tools based on the selected command.

[0009] In one embodiment, the tools from the subset are formal verification tools, and the system uses the formal verification tools to verify that the security measures implemented in the design comply with the received security requirements.

[0010] In one embodiment, the tool from the subset is a fault simulator that performs diagnostic coverage of the circuit design, which leverages safety measures to enhance its performance. The diagnostic coverage conforms to the generated safety specifications.

[0011] In one embodiment, a subset of tools enhanced with security measures perform estimations of power, timing, congestion, area, etc. These tools may be simulation tools, validation planning tools, coverage management tools, etc.

[0012] Although the disclosed embodiments use hardware and circuit designs as examples to illustrate these techniques, the disclosed techniques are applicable to software design.

[0013] The features and advantages described in the present invention and the following detailed description are not exhaustive. Many additional features and advantages will be apparent to those skilled in the art from the accompanying drawings, specification, and claims. Attached Figure Description

[0014] Figure 1A The illustration depicts an overall system environment for incorporating security measures into a system design, according to one embodiment.

[0015] Figure 1B The illustration shows an overall system environment for incorporating security measures into a system design, according to another embodiment.

[0016] Figure 2 The illustration shows the architecture of a system for incorporating security measures in a system design, according to one embodiment.

[0017] Figure 3 A flowchart illustrating a process for enhancing system design to include security measures, according to one embodiment, is shown.

[0018] Figure 4 An example of a design is shown according to one embodiment when a security register is specified using a security specification.

[0019] Figure 5 An example of a system design is shown according to one embodiment when the security core rules are specified by a security specification.

[0020] Figure 6 An example of a design using a fault-protected finite state machine according to one embodiment is shown.

[0021] Figure 7 An example of a system design enhanced with a design monitor, according to one embodiment, is shown.

[0022] Figure 8 Flowcharts depict various processes used during the design and manufacture of integrated circuits according to some embodiments of this disclosure.

[0023] Figure 9 A diagram depicts an example computer system in which embodiments of the present disclosure may operate.

[0024] The accompanying drawings use the same reference numerals to identify the same elements. The letter following the reference numeral (such as "310a") indicates that the text specifically refers to the element with that particular reference numeral. Reference numerals without a following letter (such as "310") refer to any or all elements in the drawings that bear that reference numeral (e.g., "310" in the text refers to reference numerals "310a" and / or "310b" in the figures).

[0025] The accompanying drawings (Figures) and the following description relate to preferred embodiments only by way of illustration. It should be noted that, based on the following discussion, alternative embodiments of the structures and methods disclosed herein will readily be considered as feasible alternatives, which may be adopted without departing from the claimed principles.

[0026] Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying drawings. Note that the same or similar reference numerals may be used in the drawings and may indicate the same or similar functions, whenever feasible. The drawings depict embodiments of the disclosed system (or method) for illustrative purposes only. Alternative embodiments of the structures and methods described herein may be employed without departing from the principles described herein. Detailed Implementation

[0027] The system analyzes security requirements and ensures that the correct design and verification of security measures meet the security requirements in the system design. It performs various types of security analyses, including Failure Mode and Effects Analysis (FMEA) and Failure Mode, Effects and Diagnostic Analysis (FMEDA). It can accept additional user input via standard formats (e.g., JSON or XML), specifying additional details about the expected security measures. The system identifies various failure modes of the design and their associated security measures (SMs), such as security mechanisms based on security analysis.

[0028] The system generates security specifications, which include commands to implement security measures to meet security requirements determined based on security analysis. Security specifications are specified using a security specification language that represents the security intent of the design. The system allows users to modify the generated security specifications. For example, users can modify security specifications to add additional security measures, remove some generated security measures, or modify existing security measures.

[0029] Safety specifications generated by various tools throughout the design verification process ensure that these tools comply with safety specifications. For example, for circuit design, safety specifications are used by verification tools, synthesis tools, logic equivalence checks, placement and routing tools, RTL analysis, exploration and optimization tools, and are used for pre-tape-out sign-off verification. These tools adjust the system design to include various safety measures specified by the safety specifications. Safety measures can be implemented in components of the system design, whether software, hardware, or firmware. Using a common safety specification throughout the design and verification process ensures that every design or verification tool uses the same safety measures and meets the same safety requirements. Therefore, there are no inconsistencies among the safety measures implemented by the various tools using the same safety specification.

[0030] A tool refers to a system or application that allows users, such as circuit designers, to use a computing system to perform specific tasks, such as design or verification tasks associated with circuit design. Tools may include user interfaces, such as graphical user interfaces that allow users to provide input to the tool and display output to the user. Tools may use command-line interfaces. Tools may provide output, such as the results of execution, via files.

[0031] Other techniques may require users to manually specify safety measures for each step of the design and verification process. This can be cumbersome and error-prone, leading to inconsistencies in safety measures used across various design tools. The disclosed embodiments use automatically generated safety specifications (which describe the safety measures and the user's intent) based on safety analysis to ensure consistency across various design tools. These tools modify the system design to implement the safety measures. These tools can generate metrics describing the system design that includes the safety measures. The generated metrics include safety metrics, such as Single Point of Failure Metrics (SPFM), Potential Failure Metrics (LFM), and Probability of (Random) Hardware Failure Metrics (PMHF), which are calculated to ensure the design meets safety objectives. Metrics may include other aspects of the system design, such as power, area, timing metrics, etc., and tools modify their estimates of corresponding metrics to accommodate the safety measures. Tools can modify the system design and then determine the metrics, or they can adjust the metric values ​​based on anticipated modifications to the system design according to the safety specifications. For example, tools can adjust estimates of the power, area, timing, and other properties of the system design to account for possible changes in the system design to include the safety measures. Furthermore, the embodiments ensure that no safety measure is neglected across various design tools.

[0032] Figure 1AThe diagram illustrates an overall system environment for incorporating security measures into a system design according to one embodiment. Boxes 110, 120, 115, 125, and 128 represent the security analysis steps of the system being designed. The system receives technical security requirements 110. Various types of security analyses 120 are performed, such as FMEA, FMEDA, hardware security measure identification, etc. The system generates a security specification 130 based on the performed security analyses. The system also receives the system design for processing by various design tools, such as RTL (Register Transfer Level) specifications 135 for circuit design. Various design tools use the security specification 130 to enhance the system design with security measures conforming to the security specification 130, such as design tools 140 such as Design for Testability (DFT) tools, synthesis tools, placement and routing tools, etc., and verification tools 145 such as simulation tools, formal verification tools, simulators, static verification tools, etc. The system provides the system designer with enhanced system diagnostic coverage and various security metrics. The security analysis process includes steps 115 with functional safety measurements and diagnostic coverage measurements 115 and fault simulation. The system design enhanced with safety measures provides additional metrics (e.g., SPFM and LFM metrics) for further safety analysis. As a result of the safety analysis of the enhanced system design, functional safety working product 128 is provided.

[0033] Figure 1B The illustration depicts an overall system environment for incorporating safety measures into a system design, according to another embodiment. A functional safety management system 155 receives safety requirements from a requirement management system 150. The functional safety management system 155 stores a data structure representing the safety requirements. The functional safety management system 155 processes the data structure storing the safety requirements to generate a safety specification, which is stored in a safety specification storage device 170. The safety measures include various commands that specify safety measures for the system design. The generated safety specification can be accessed by a user via a user interface 160, which allows the user to modify the safety specification or enhance it by adding additional safety measures. The generated safety specification can be further analyzed using a safety analysis tool 165.

[0034] The safety specifications are processed by various tools, including design tool 140 and verification tool 145. Design tool 140 and verification tool 145 generate or analyze system designs that implement various safety measures as specified in the safety specifications. The tools perform system analyses with regard to the safety measures. For example, the tools can perform accurate power analysis of the system design by considering any modifications made to introduce safety measures that can affect power consumption. As another example, if a safety measure introduces redundancy in a hardware component, thereby increasing power consumption, design tool 140 adjusts the power estimate accordingly. Similarly, if introducing a safety measure in a component increases the area of ​​the system design, design tool 140 adjusts the area estimate of the system design. As another example, if introducing a safety measure in a component increases the delay along the path of the system design, design tool 140 adjusts the delay estimate of the system design path to account for the safety measures. Therefore, the design tools perform accurate area, timing, power, or other types of analyses on the system design considering safety measures according to the safety specifications. The verification tools perform fault simulations considering the safety measures, thereby providing accurate fault simulations. Because various tools use common security standards, security analysis and system design modifications that incorporate security measures are consistent and compliant with security standards.

[0035] The techniques described herein can be applied to, but are not limited to, automated design flows and can be applied to other design flows, such as any EDA (Electronic Design Automation) flow. Unless otherwise indicated, the term "safety" as used herein refers to "functional safety".

[0036] Figure 2 The illustration shows the architecture of a system for incorporating security measures in a system design, according to one embodiment. Figure 2 The system architecture illustrated in the diagram includes a computer system 200, which comprises a security analysis module 210, a security specification generator 230, a design storage device 250, and a security specification storage device 260. Other embodiments may include... Figure 2 The number of modules indicated in the text is either more or less.

[0037] The design of a storage device 250 storage system includes, for example, circuit design, software design, firmware design, etc. System design may include components that can be software components, hardware components, or firmware components. The design is handled by design tools. For example, the design representing the circuit design is handled by electronic design automation (EDA) tools (such as...). Figure 8 As shown and combined Figure 8 The described tool) is used for processing.

[0038] The security analysis module 210 presents a user interface to the user and receives details of security requirements from the user through this interface. The user interface allows users to perform various types of security analyses, including Failure Mode and Effects Analysis (FMEA), Failure Mode, Effects and Diagnostic Analysis (FMEDA), and other possible security analyses. To simplify the description of the solution, the process involves FMEA / FMEDA analysis; however, the disclosed techniques are applicable to other types of security analyses, such as DFA (Delta Fault Analysis), FTA (Fault Tree Analysis), etc.

[0039] This analysis generates a list of failure modes (FMs) and associated safety measures (SMs) for the design. The system incorporates the identified safety measures into the safety specification. The system can include active or passive safety measures, monitors, isolation schemes, and other safety measures from the safety specification. The safety specification can be generated based on other safety analyses, including related failure analyses (DFAs), which identify common-cause failures (such as clock, reset, and power) or failures unaffected by different parts of the design. The analysis can be performed before the design begins, and the user estimates coverage metrics. As the design process progresses, these analyses can be further refined, allowing for more detailed design analyses.

[0040] The security specification generator 230 receives various inputs describing security requirements and generates a security specification for the design based on these requirements. The security specification storage device 260 stores the generated security specification for the design. Users provide input in one location via a user interface provided by the security analysis module 210. Various design tools consistently verify and implement the design according to the security intent described in the security specification.

[0041] Design and verification tools modify the system design to incorporate security measures. These tools include analysis, exploration, and optimization tools. The added security features conform to security specifications. This paper further describes the details of the process used to enhance the system design by adding security measures.

[0042] As the design begins, Failure Mode and Effects (FMEDA) analyses are performed for different parts of the design by associating failure modes and their corresponding safety measures with specific design blocks and components. Based on this information, various metrics, such as the Single Point of Failure Metric (SPFM), Latent Failure Metric (LFM), and Probability of (Random) Hardware Failure Metric (PMHF), are calculated to ensure the design meets safety objectives. These metrics largely depend on the diagnostic coverage of the safety measures, which constitute the majority of safety measures. Based on this analysis, FMEA and FMEDA reports, as well as DFA and (Possible) Fault Tree Analysis (FTA) reports, are created as evidence of safety.

[0043] Figure 3 A flowchart illustrating a process for enhancing system design to include security measures, according to one embodiment, is shown.

[0044] For example, system receiver 310 of computing system 200 contains a system design for processing using multiple design tools at various stages of the design process. System receiver 320 contains security requirements for the system design. These security requirements specify security measures for the system design. These security measures represent the system designer's intent to implement security measures using various design tools.

[0045] The system generates a 330 security specification based on security requirements. The security specification includes a set of commands from the received security requirements. Each command specifies (a) security measures for one or more components of the system design and (b) one or more attributes processed by design tools for analyzing, implementing, and verifying these security measures. The system allows users to further modify the security specification, such as by adding new commands, deleting some automatically generated commands, or modifying existing commands to adjust some parameters specified in the commands.

[0046] The system receives a system design for processing by various design tools. The system generates a system design enhanced with various security measures, for example, by modifying the system design to implement one or more security measures specified in the generated security specification. One or more design tools process the generated security specification to implement the security measures in the system design according to the received security requirements. The design tools read the security specification and process each command within it. The design tools identify components in the system design that need to be modified to conform to the security specification. Components modified to implement security measures can be software components, hardware components, or firmware components.

[0047] If the security specification includes instructions that specify a particular component type requires a specific security measure to be implemented, the design tool identifies all components of that component type and modifies their designs to include the security measure. As an example, if the security specification specifies that certain types of registers should implement three-mode redundancy, the tool (1) identifies the register R that needs to be modified, (2) modifies the system design to include an additional copy of the register, (3) adds a majority voter component, (4) connects the input of register R to the input of each copy of the register, (5) connects the output of the copy of the register to the input of the majority voter component, and (6) connects the output of the majority voter component to the component that received the output of register R.

[0048] During the design process, the same safety specifications are used by multiple tools. For example, if a circuit design is handled by multiple EDA tools, the same safety specifications are used by verification tools, placement and routing tools, fault simulation tools, etc. Tools can modify the design to include safety measures or perform analyses that take safety measures into account, for example, by scaling various parameters without explicitly modifying the system design.

[0049] The system can specify security registers to implement one of the following security measures: (1) Triple Module Redundancy (TMR), (2) Dual Module Redundancy (DMR), or (3) Fault Tolerance (FT). The security measure specifies the number of copies of the registers in the security measure, for example, two copies of the registers according to the DMR security specification, or three copies according to the TMR security specification. The security specification includes commands for creating security registers. Commands for creating security registers can accept arguments, including the type of security measure (TMR, DMR, or FT), the minimum distance between registers in the layout, the pin types for which separate routing is required for the copied registers, etc. Verification tools verify that the design tools comply with the security specifications.

[0050] Commands used to create security registers do not bind security measures to any specific register or other design element; instead, they specify the intent behind the security measure. Therefore, the command specifies the parameters and construct used to implement the security measure, independent of the specific environment in which the security measure is contained. This allows security measures to be included at various stages of the design and verification process. Separate commands are used to bind registers to the security register rules described by the command to create the security register. Various tools modify system designs to achieve, for example... Figure 4 The security register shown in the diagram.

[0051] Figure 4 An example design is shown according to one embodiment when a security register is specified using a security specification. For example... Figure 4 As shown, the safety specification stipulates three-module redundancy. Therefore, the tool enhances the circuit design to include three copies of the register, shown as flip-flops FF1, FF2, and FF3. Inputs to the three flip-flops FF1, FF2, and FF3 are received from component 410 of the circuit. The outputs of flip-flops FF1, FF2, and FF3 are provided as inputs to a majority voter component, which determines its output based on a majority of the matching input values.

[0052] Tools can handle security register commands in security specifications by modifying the system design to add additional registers and majority voters according to the command. Tools for estimating the power of a circuit design can adjust power requirements to account for the additional power consumed by the additional registers and majority voters. Tools for estimating the area of ​​a circuit design can scale the area estimate to account for the potential increase in area due to the addition of additional registers and majority voters. Tools for estimating delays along various path lengths can adjust the delay using a scaling factor based on the delay added by additional components introduced in the path (e.g., majority voters).

[0053] In one embodiment, the security specification includes a multi-core lockstep command that specifies the intent of the safety-critical module that needs to be replicated. This command ensures that, at a specific step, the result generated by that step is compared to a redundant copy of the component. The command used to create the security core specifies the number of cores for the component. If the specification specifies that two copies of the component are included, the security measure is called a dual-core lockstep (DCLS) security measure. Typically, the security specification may specify a multi-core lockstep (MCLS) security measure.

[0054] If two cores are specified, the tool modifies the design to include two copies of the component and adds comparison logic at each output of the component. If three cores are specified, the tool modifies the design to include three copies of the component and adds voting logic at each output. If the command specifies a replication factor greater than three, the user must provide the HDL (Hardware Description Language) module name for selecting the winning value if all cores do not reach a consensus on a single value of the output. Various tools modify system designs to achieve, for example... Figure 5 The multiple cores shown.

[0055] Figure 5 An example of a system design is shown according to one embodiment when the security core rules are specified by a security specification. For example... Figure 5 As shown, the Create Security Core command is used to specify the security intent of using two cores. The tool is designed to use two cores, including a primary core 510 and a secondary core 530, and uses a comparator 520 to compare the outputs of the two cores 510 and 530.

[0056] The tool can handle multi-core lockstep commands in security specifications by modifying the system design to add multi-core login based on the command. The tool for estimating the power of the circuit design can adjust the power requirements to account for the additional power consumed by the secondary cores and comparators. The tool for estimating the area of ​​the circuit design can scale the area estimate to account for the potential increase in area due to the addition of secondary cores and comparators.

[0057] In one embodiment, the safety specification includes a command specifying the intent for a fault-protected finite state machine (FSM). This command specifies that the FSM needs to be designed to prevent deadlocks caused by single event flip-flops (SEUs). If any SEU places the FSM in a corrupted state, the design includes mechanisms coded in the FSM to restore it to a recoverable state, thereby preventing the system from entering a suspended state.

[0058] Figure 6 An example of a design using a fault-protected finite state machine according to one embodiment is shown. Figure 6 The finite state machine 600 shown in the diagram transitions through various states, including states 000, 001, 010, 011, and 100. State 010 is designated as a safe state. If a fault occurs in state 000, the system transitions to safe state 010 and skips state 001.

[0059] Verification tools ensure that these FSMs are implemented to comply with safety specifications. Design tools modify the system design to add transitions from illegal to legal states. In one embodiment, the tools automatically insert error detection and error correction circuitry using Hamming codes hamming2 and hamming3, respectively. For example, error detection / correction circuitry can be inserted into a netlist representing the circuit design using synthesis tools.

[0060] Tools such as RTL verification tools and simulators / emulators model the error detection / correction functionality. This allows users to inject faults into the FSM registers to create error detection scenarios that cause the FSM to reset to its default state. This verifies the downstream logic from the FSM so that it can correctly handle scenarios where the FSM is reset mid-operation due to a SEU. RTL-level fault simulation also considers this modified functionality. RTL-level fault simulation requires knowledge that faults on individual flip-flops of the FSM are detected and corrected. Users can perform RTL simulation / emulation by injecting faults using force / deposit and ensure that the fault does not propagate downstream. The modified system design corrects the error.

[0061] In one embodiment, the safety specification includes commands to add a design monitor to the system design. A monitor is a component that receives signals from a specific point in the system design and can perform actions based on those signals, such as monitoring certain activities and reporting or generating another signal. For example, a monitor might detect whether a signal exceeds a threshold and generate an interrupt if the signal exceeds the threshold. The monitoring command specifies the monitor's inputs and outputs, as well as parameters, such as the threshold, which the monitor uses to compare signals. Another example of a monitor is a temperature monitor, which detects whether the temperature is above or below permissible operating conditions.

[0062] Figure 7 An example of a system design 700 enhanced using a design monitor according to one embodiment is shown. The system receives the system design 700 and enhances it using a monitor. The monitor 720 receives input and output signals from component 710. Based on the values ​​of the input and output signals, the monitor 720 generates an error value. Therefore, the monitor can perform constraint checks based on the inputs and outputs of component 710.

[0063] Tools can handle monitoring commands in safety specifications by modifying the system design to add monitoring logic associated with components identified by the safety specifications. Tools for estimating the power consumption of the circuit design can adjust the power consumption estimate to account for the additional power consumed by the monitors. Tools for estimating the area of ​​the circuit design can scale the area estimate to account for the potential increase in area due to the addition of monitors.

[0064] The examples of commands in the security language used in security specifications are provided above for illustrative purposes. Various other types of security measures, such as error-correcting codes (ECC), error-detecting codes (EDC), parity checks, and cyclic redundancy checks, can be implemented using the techniques disclosed herein. Furthermore, security specifications can be represented in any format or representation and are not limited to any particular syntax, format, or language. Various tools are described herein for illustrative purposes. However, other tools not mentioned herein can be used to implement these techniques. Additionally, the security measures specified in the security specifications can be implemented in system designs using hardware, software, or firmware.

[0065] Figure 8 Flowcharts depict various processes used during the design and manufacture of integrated circuits according to some embodiments of this disclosure. Figure 8The illustration shows an example set of processes 800 used during the design, verification, and manufacturing of articles such as integrated circuits to transform and verify design data and instructions representing integrated circuits. Each of these processes can be constructed and enabled as multiple modules or operations. The term "EDA" stands for "Electronic Design Automation." These processes begin with the creation of a product concept 810 using information provided by the designer, which is then transformed to create an article of art using a set of EDA processes 812. When the design is complete, it is tape-out 834, which occurs when the original pattern (e.g., geometric pattern) of the integrated circuit is sent to a manufacturing plant to create a mask set, which is then used to manufacture the integrated circuit. After tape-out, semiconductor dies are manufactured 836, and packaging and assembly processes 838 are performed to produce a finished integrated circuit 840.

[0066] The specification of a circuit or electronic structure can range from low-level transistor material placement to high-level description languages. High-level representations can be used to design circuits and systems using hardware description languages ​​(“HDLs”) such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVera. HDL descriptions can be transformed into logic-level register-transfer-level (“RTL”) descriptions, gate-level descriptions, placement-level descriptions, or mask-level descriptions. Each lower level, as a more specific description, adds more useful details to the design description, for example, more details about the modules included in the description. Lower-level representations as more specific descriptions can be computer-generated, exported from a design library, or created by another design automation process. An example of a lower-level specification language used to specify a more detailed representation language is SPICE (a simulation program focused on integrated circuits), which is used for detailed descriptions of circuits with many simulated components. The description at each representation level is made usable by the corresponding tool at that layer (e.g., a formal verification tool). The design process can use… Figure 8 The sequence described herein. The described process is implemented using EDA products (or tools).

[0067] During system design phase 814, the functionality of the integrated circuit to be manufactured is specified. The design can be optimized for desired characteristics such as power consumption, performance, area (physical and / or lines of code), and cost reduction. Dividing the design into different types of modules or components can occur at this stage.

[0068] During logic design and functional verification 816, modules or components in a circuit are specified in one or more description languages, and the functional accuracy of the specifications is checked. For example, components of a circuit can be verified to generate outputs that match the requirements of the specifications for the designed circuit or system. Functional verification can use simulators and other programs, such as test bench generators, static HDL checkers, and formal checkers. In some embodiments, a special system of components referred to as a “simulator” or “prototype system” is used to accelerate functional verification.

[0069] During synthesis and design for testing the 818, HDL code is converted into a netlist. In some embodiments, the netlist can be a graphical structure, where the edges of the graphical structure represent components of the circuit, and the nodes of the graphical structure represent how the components are interconnected. Both HDL code and netlist are hierarchical products that can be used by EDA products to verify that the integrated circuit performs according to a specified design when manufactured. The netlist can be optimized for a target semiconductor manufacturing technology. Additionally, the completed integrated circuit can be tested to verify that the integrated circuit meets specification requirements.

[0070] During netlist verification 820, the netlist is checked to ensure it meets timing constraints and conforms to the HDL code. During design planning 822, the overall planar layout of the integrated circuit is constructed and analyzed for timing and top-level routing.

[0071] During the layout or physical implementation of 824, physical placement (positioning of circuit components such as transistors or capacitors) and wiring (connecting circuit components via multiple conductors) occur, and cells can be selected from a library to implement a specific logic function. As used herein, the term "cell" can specify a collection of transistors, other components, and interconnections that provide Boolean logic functions (e.g., AND, OR, NOT, XOR) or storage functions (e.g., flip-flops or latches). As used herein, a circuit "block" can refer to two or more cells. Both cells and circuit blocks can be referred to as modules or components and are enabled for both physical structure and simulation. Parameters (such as size) are specified for the selected cells (based on "standard cells"), and these parameters are made accessible in a database for use in EDA products.

[0072] During analysis and extraction (826), circuit functionality is verified at the placement level, allowing for improvements to the placement design. During physical verification (828), the placement design is checked to ensure that manufacturing constraints (such as DRC constraints, electrical constraints, and lithographic constraints) are correct and that the circuit functionality matches the HDL design specification. During resolution enhancement (830), the geometry of the placement is transformed to improve how the circuit design is manufactured.

[0073] During the tape-out process, data is created for the production of photomasks (if appropriate, after the application of photolithography enhancement). During mask data preparation 832, the "tape-out" data is used to generate photomasks, which are then used to produce the finished integrated circuit.

[0074] The storage subsystem of a computer system can be used to store programs and data structures used by some or all of the EDA products described herein, and by products used for the development of units for libraries and for the physical and logical design of using libraries.

[0075] Figure 9 A diagram depicts an example computer system in which embodiments of the present disclosure may operate. Figure 9 An example machine of computer system 900 is illustrated, in which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate with the capabilities of a server or client machine in a client-server network environment, as a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0076] A machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a web device, a server, a network router, a switch, or a bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) specifying actions to be taken by that machine. Furthermore, although a single machine is shown, the term "machine" should also be considered to include any set of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any or more of the methods discussed herein.

[0077] Example computer system 900 includes processing device 902, main memory 904 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), static memory 906 (e.g., flash memory, static random access memory (SRAM) etc.)) and data storage device 918, which communicate with each other via bus 930.

[0078] Processing device 902 represents one or more processors, such as microprocessors, central processing units, etc. More specifically, processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processing device 902 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 902 may be configured to execute instructions 926 for performing the operations and steps described herein.

[0079] The computer system 900 may also include a network interface device 908 for communication via a network 920. The computer system 900 may also include a video display unit 910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 912 (e.g., a keyboard), a cursor control device 914 (e.g., a mouse), a graphics processing unit 922, a signal generation device 916 (e.g., a speaker), a graphics processing unit 922, a video processing unit 928, and an audio processing unit 932.

[0080] Data storage device 918 may include machine-readable storage medium 924 (also known as non-transitory computer-readable medium) storing a set of one or more instructions 926 embodying any one or more of the methods or functions described herein. Instructions 926 may also reside wholly or at least partially within main memory 904 and / or processing device 902 during execution by computer system 900, which also constitute machine-readable storage media.

[0081] In some embodiments, instruction 926 includes instructions for implementing functions corresponding to this disclosure. While machine-readable storage medium 924 is shown as a single medium in the example implementation, the term "machine-readable storage medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding sets of instructions for execution by a machine and to cause the machine and processing device 902 to perform any one or more methods of this disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0082] Some parts of the foregoing detailed description have been presented based on the algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively communicate the substance of their work to others skilled in the art. An algorithm can be a sequence of operations that leads to a desired result. An operation is an operation that requires physical manipulation of a physical quantity. Such a quantity can take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Such signals can be referred to as bits, values, elements, symbols, characters, items, numbers, etc.

[0083] However, it should be remembered that all these and similar terms will be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise stated, as is apparent from this disclosure, it should be understood that throughout the specification, certain terms refer to the actions and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities within the registers and memories of the computer system into other data similarly represented as physical quantities within the computer system's memory or registers or other such information storage devices.

[0084] This disclosure also relates to means for performing the operations described herein. Such means may be specifically configured for the intended purpose, or may comprise a computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0085] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used with the programs based on the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods. Furthermore, this disclosure is described without reference to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using various programming languages.

[0086] This disclosure can be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media include any mechanism for storing information in a machine-readable (e.g., computer-readable) form. For example, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory devices, etc.

[0087] In the foregoing disclosure, implementations of this disclosure have been described with reference to specific example implementations. It will be apparent that various modifications may be made without departing from the broader spirit and scope of the embodiments of this disclosure as set forth in the appended claims. Where elements are referred to in the singular in this disclosure, more than one element may be depicted in the drawings, and the same elements are labeled with the same reference numerals. Therefore, this disclosure and the drawings should be considered illustrative rather than restrictive.

[0088] Alternative embodiments

[0089] Given low power considerations, the embodiments disclosed herein can be used for connectivity verification of circuits. Although SOC I / O loop connectivity is presented as an example of a circuit type for which formal verification is performed, the embodiments can be used for formal verification of any other type of circuit. Furthermore, the assertions used for formal verification are not limited to assertions specifying the connectivity of a circuit, but can be any other type of assertion describing the circuit.

[0090] Some of the descriptions above describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the art of data processing to effectively communicate the substance of their work to others skilled in the art. While these operations are described functionally, computationally, or logically, they should be understood as being implemented by a computer program, including instructions, microcode, etc., for execution by a processor or equivalent circuitry. Furthermore, without loss of generality, it has sometimes proven convenient to refer to the arrangement of these functional operations as modules. The described operations and their associated modules can be embodied in software, firmware, hardware, or any combination thereof.

[0091] As used herein, any reference to "an embodiment" or "embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The phrase "in an embodiment" appearing in various places in the specification does not necessarily refer to the same embodiment.

[0092] Some embodiments may be described using the terms “coupled” and “connected” along with their derivatives. It should be understood that these terms are not intended to be synonyms. For example, the term “connected” may be used to describe some embodiments to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, the term “coupled” may be used to describe some embodiments to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. Embodiments are not limited to this context.

[0093] As used herein, the terms “comprising,” “including,” “having,” “possessing,” or any other variation thereof are intended to cover non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, “or” refers to inclusive or, not exclusive, or. For example, condition A or B is satisfied by any of the following: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0094] Furthermore, the terms "a" or "an" are used to describe the elements and components of the embodiments herein. This is done merely for convenience and to give the general meaning of this disclosure. The description should be understood to include one or at least one, and the singular includes the plural, unless it is obvious that it means otherwise. Upon reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for systems and processes used for the formal verification of circuits with low power considerations. Therefore, while specific embodiments and applications have been illustrated and described, it should be understood that the invention is not limited to the precise structures and components disclosed herein, and various modifications, alterations, and variations that will be apparent to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined by the appended claims.

Claims

1. A computer-implemented method of executing instructions for enhancing a system design to include security measures, the method comprising: receiving the system design for processing through various stages of design and verification using a plurality of tools; receiving security requirements for the system design, the security requirements specifying security measures for the system design; generating a security specification comprising one or more security measures in accordance with the received security requirements; performing an analysis of the system design, the analysis determining a metric based on one or more of: a power requirement, an area, or a delay of the system design; scaling the metric to account for possible changes to the system design for implementing security measures, the scaling determining an impact of including the security measures in the system design without modifying the system design; and creating one or more security reports for the system design based on the metric.

2. The computer-implemented method of claim 1, wherein the security specification comprises a set of commands, each command specifying: (a) a particular security measure for one or more components of the system design, and (b) one or more attributes to be processed by one or more tools for implementing the particular security measure.

3. The computer-implemented method of claim 1, wherein a security measure is implemented in a component of the system design, wherein the component is one of: a software component, a hardware component, or a firmware component.

4. The computer-implemented method of claim 1, wherein the system design represents a circuit design and the plurality of tools represent electronic design automation (EDA) tools, the method further comprising: modifying the system design to implement one or more security measures for a tool of the plurality of tools.

5. The computer-implemented method of claim 4, wherein the modifying comprises, for each tool of at least a subset of the plurality of tools: processing the security specification generated by the tool to implement one or more security measures.

6. The computer-implemented method of claim 4, wherein the tool is a synthesis tool, wherein the security specification generated by the synthesis tool comprises: selecting a command of the security specification generated, the command specifying a security measure; and modifying a representation of the circuit design processed by the synthesis tool to implement the security measure specified by the command.

7. The computer-implemented method of claim 4, wherein the tool is a place and route tool, wherein the security specification generated by the place and route tool comprises: selecting a command of the security specification generated, the command specifying a security measure; and ensuring, by the place and route tool, physical separation between components in accordance with the selected command of the security specification generated.

8. The computer-implemented method of claim 1, wherein a security measure comprises one or more of: a secure register having one of: triple-mode redundancy, dual-mode redundancy, or fault tolerance; dual-core lockstep, ​ ​ ​ fault protection finite state machine, monitor, error correction code (ECC), error detection code (EDC), parity, or cyclic redundancy check.

9. The computer-implemented method of claim 1, wherein a tool of the plurality of tools is a formal verification tool, the method further comprising: verifying, by the formal verification tool, that the safety measures implemented in the system design comply with the received safety requirements.

10. The computer-implemented method of claim 1, wherein a tool of the plurality of tools is a fault simulator, the method further comprising: performing, by the fault simulator, diagnostic coverage of the system design augmented with safety measures, the diagnostic coverage complying with the generated safety specification.

11. The computer-implemented method of claim 1, wherein a tool of the plurality of tools is a power estimation tool, the method further comprising: estimating, by the power estimation tool, power consumption of the system design augmented with safety measures.

12. The computer-implemented method of claim 1, further comprising: providing, in response to receiving a safety signoff for the system design augmented with the safety measures, a representation of the system design augmented with the safety measures for manufacturing of the system.

13. A non-transitory computer-readable storage medium storing executable computer program instructions, the instructions being executable by a computer processor and causing the computer processor to perform steps comprising: receiving a system design for processing through various stages of design and verification using a plurality of tools; receiving safety requirements for the system design, the safety requirements specifying safety measures for the system design; generating, in accordance with the received safety requirements, a safety specification, the safety specification comprising one or more safety measures; performing an analysis of the system design, the analysis determining a metric based on one or more of: a power requirement, an area, or a delay of the system design; scaling the metric to account for possible changes to the system design for implementing safety measures, the scaling determining an impact of including the safety measures in the system design without modifying the system design; and creating one or more safety reports for the system design based on the metric.

14. The non-transitory computer-readable storage medium of claim 13, wherein a safety measure is implemented in a component of the system design, wherein the component is one of: a software component, a hardware component, or a firmware component.

15. The non-transitory computer-readable storage medium of claim 13, wherein the system design represents a circuit design and the plurality of tools represent electronic design automation (EDA) tools.

16. The non-transitory computer-readable storage medium of claim 15, wherein a tool of the plurality of tools is a synthesis tool, wherein the instructions for processing the generated safety specification by the synthesis tool cause the computer processor to perform steps comprising: selecting a command of the generated safety specification, the command specifying a safety measure; and ​ modifying a representation of the circuit design processed by the synthesis tool to implement the safety measures specified by the commands.

17. The non-transitory computer readable storage medium of claim 15, wherein a tool of the plurality of tools is a place and route tool, wherein the instructions for processing the generated safety specification by the place and route tool cause the computer processor to perform steps comprising: selecting a command of the generated safety specification, the command specifying a safety measure; hardware ensuring, by the place and route tool, physical separation between components according to the selected command of the generated safety specification.

18. The non-transitory computer readable storage medium of claim 13, wherein a safety measure comprises one or more of: a safety register having one of: triple mode redundancy, dual mode redundancy, or fault tolerance; dual core lockstep, fault protection finite state machine, monitor, error correction code (ECC), error detection code (EDC), parity, or cyclic redundancy check.

19. The non-transitory computer readable storage medium of claim 13, wherein a tool of the plurality of tools is a formal verification tool, wherein the instructions further cause the computer processor to perform steps comprising: verifying, by the formal verification tool, that the safety measures implemented in the system design comply with the received safety requirements.

20. A computer system comprising: a computer processor; and a non-transitory computer readable storage medium storing executable computer program instructions, the instructions being executable by the computer processor and causing the computer processor to perform steps comprising: receiving a system design for processing through various stages of design and verification using a plurality of tools; receiving safety requirements for the system design, the safety requirements specifying safety measures for the system design; generating a safety specification comprising one or more safety measures according to the received safety requirements; performing an analysis of the system design, the analysis determining a metric based on one or more of: a power requirement, an area, or a delay of the system design; scaling the metric to account for possible changes to the system design for implementing safety measures, the scaling determining an impact of including the safety measures in the system design without modifying the system design; and creating one or more safety reports for the system design based on the metric. ​ ​

Images