CIRCUIT DESIGN VALIDATION TOOL FOR RADIATION-HARDENED DESIGN
One example includes a method for validating a circuit design. The method includes providing a set of coded rules. Each of the coded rules can define conditions for circuit cells to qualify the circuit design as being radiation-hardened. The method also includes accessing a circuit design netlist associated with the circuit design from a circuit design database. The method also includes evaluating each of the circuit cells in the circuit design netlist with respect to each of the coded rules. The method further includes providing a circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
This application claims priority to U.S. Provisional Patent Application No. 63/143,212, filed 29 Jan. 2021, which is incorporated herein by reference in its entirety.
TECHNICAL FIELDThis description relates generally to software systems, and more particularly to a circuit design validation tool for radiation-hardened design.
BACKGROUNDCircuit design software-implemented tools can assist users to design circuits based on providing inputs corresponding to circuit components, desired behavior, and constraints in an interactive or batch manner. Such design tools can be implemented to design very complicated circuits that can ultimately be fabricated into integrated circuits that can be packaged into chips. Such integrated circuits can be implemented in a variety of different applications. Some circuit designs require particular constraints that can require additional componentry, connections, or other considerations that can add considerable complexity to a given circuit. As one example, a circuit that is designed to be radiation-hardened can include additional constraints that facilitate operation of the circuit in certain environmental conditions (e.g., in aerospace applications). For example, one requirement of radiation-hardened circuits is that circuit components be triple-redundant to mitigate damage and/or errors resulting from high-energy particles. Such additional constraints can provide significant additional complexity to circuit design, and can sometimes require costly and time-consuming testing protocols.
SUMMARYOne example includes a method for validating a circuit design. The method includes providing a set of coded rules. Each of the coded rules can define conditions for circuit cells to qualify the circuit design as being radiation-hardened. The method also includes accessing a circuit design netlist associated with the circuit design from a circuit design database. The method also includes evaluating each of the circuit cells in the circuit design netlist with respect to each of the coded rules. The method further includes providing a circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
Another example described herein includes a circuit validation system. The system includes a user interface configured to facilitate input of a set of coded rules. Each of the coded rules can define conditions for circuit cells to qualify the circuit design as being radiation-hardened. The system also includes a circuit database application programming interface (API) configured to provide access to a circuit design netlist associated with the circuit design from a circuit design database. The system further includes a circuit design validation tool configured to access the circuit design netlist via the circuit database API and to evaluate each of the circuit cells in the circuit design netlist with respect to each of the coded rules and to provide a circuit evaluation report to a validation database on the user interface. The circuit evaluation report can include an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
Another example described herein includes a circuit design validation tool. The circuit design validation tool is configured to receive a set of coded rules. Each of the coded rules can define conditions for circuit cells to qualify the circuit design as being radiation-hardened. The circuit design validation tool can also be configured to access a circuit design netlist associated with the circuit design via a circuit database API associated with a circuit design database. The circuit design validation tool can also be configured to evaluate each of the circuit cells in the circuit design netlist with respect to each of the coded rules. The circuit design validation tool can further be configured to provide a circuit evaluation report to a validation database on the user interface, the circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
This description relates generally to software systems, and more particularly to a circuit design validation tool for radiation-hardened design. The circuit design validation tool can be implemented in a circuit design validation system that is configured to validate a circuit design based on a set of coded rules. The coded rules can be created to satisfy a set of criteria and/or constraints associated with the circuit design. As described herein, the term “coded rules” refers to a set of defined rules that can be provided as software files, data elements (e.g., in a database), or any other type of data for use by the circuit design validation tool. For example, the coded rules are used to ensure that a circuit design meets the criteria for satisfying a radiation-hardened design. As described herein, the term “radiation-hardened” refers to design considerations that render a resultant fabricated circuit as resistant to damage or malfunction caused by high levels of ionizing radiation (e.g., particle radiation and/or high-energy electromagnetic radiation), such as for circuit applications in space. Therefore, the circuit design validation tool can evaluate the circuit design based on the coded rules to determine if the circuit design meets the criteria defined by the coded rules.
The circuit design validation system, which includes the circuit design validation tool, can also include a user interface to enable inputs to program the coded rules for use by the circuit design validation tool. As an example, the coded rules are provided as software files or routines accessible and implemented by the software program associated with the circuit design validation tool 102. The user interface can also include a validation database to which the circuit design validation tool can provide a circuit evaluation report that indicates failure of circuit cells with respect to the evaluation of the circuit design based on one or more of the coded rules. As described herein, the term “circuit cell” describes a functional block of one or more circuit components that collectively implement a circuit function within the circuit design. As described herein, at a lowest level of hierarchical layers, a circuit cell can correspond to a single circuit element (e.g., a transistor, resistor, capacitor, etc.), and at higher levels of hierarchical layers, can correspond to a set of smaller circuit cells that can each collectively correspond to a very large quantity of circuit elements. As described herein, the circuit cells can be evaluated by the circuit design validation tool with respect to the coded rules to determine if the circuit cells pass the coded rules or fail the coded rules.
The circuit design validation tool can be configured to access a circuit design netlist associated with the circuit design from a circuit design database (e.g., associated with a circuit design tool) via a circuit database application programming interface (API). The circuit design validation tool can thus evaluate each of the circuit cells based on a sequential application of the coded rules. As an example, circuit design validation tool is configured to evaluate the hierarchical layers of the circuit design in a sequence. Upon evaluation of the entire circuit design, the circuit design validation tool can provide the circuit evaluation report to indicate a list of circuit cells that failed specific coded rules. For example, the user interface includes a evaluate failure input that can provide correction of the respective failed circuit cells (e.g., based on a user input). For example, the evaluate failure input modifies a circuit cell in the circuit design netlist that was indicated as failed in the circuit evaluation report to change the respective circuit cell to allow the circuit cell to pass the respective coded rule.
The coded rules can be associated with a variety of operational, structural, and/or behavioral characteristics of the circuit cells. As a first example, the circuit design validation tool is configured evaluate each instance of a circuit cell corresponding to each of a plurality of circuit cell templates stored in a circuit design library with respect to one or more of the coded rules. In this example, the circuit cell templates can include cell definitions that define operational, structural, and intended behavioral characteristics of the type of the circuit cells. Therefore, the coded rules can correspond to rules defining consistency between a respective one of the circuit cell templates and each instance of the respective circuit cell with respect to the cell definitions. As a second example, the circuit design validation tool is configured to evaluate each of the instances of each of the circuit cell types with respect one or more additional coded rules. In this example, the instances can include a unique instance name, net names associated with input and output wire couplings associated with the respective instances, and connections of the wire couplings to other instances of other circuit cells. Therefore, the coded rules can define standards associated with the instance name, the net names, and the connections for each of the instances of the given cell type.
The circuit design validation tool can thus be implemented to provide a high degree of scrutiny of a circuit design to satisfy the desired criteria as established by the coded rules. Such a validation process can provide a significantly more accurate and more rapid review of a circuit design relative to manual review by a circuit designer. Thus, the circuit design validation tool can mitigate human error that can result from time consuming and tedious manual review. Furthermore, in some examples, the circuit design validation tool can obviate the need for manual circuit validation that simulates environmental conditions. For example, for validation of a radiation-hardened circuit design, the circuit design validation tool can provide sufficient validation of the radiation-hardened design instead of providing particle accelerator testing that can be costly and not readily accessible.
The circuit design validation system 100 includes a user interface 104 that can facilitate inputs from and outputs to a user. The user interface 104 can be configured to program a set of coded rules that are provided to the circuit design validation tool 102, demonstrated in the example of
In the example of
The circuit design validation tool 102 can evaluate the circuit design netlist 112 to determine if circuit cells associated with the circuit design satisfy the coded rules 106. The circuit design validation tool 102 can thus determine if each of a plurality of circuit cells in each of a plurality of hierarchical layers of the circuit design satisfy the predetermined criteria and/or constraints defined by the coded rules 106, thereby passing the respective coded rules, or if any of the circuit cells in the circuit design do not satisfy the predetermined criteria and/or constraints, thereby failing one or more of the coded rules. As an example, the predetermined criteria and/or constraints can be associated with a particular operating characteristic or environment in which the circuit end-product corresponding to the circuit design is to operate.
As an example, the circuit design validation tool 102 can evaluate each of the circuit cells of the circuit design netlist 112 based on a sequential application of the coded rules 106. As an example, the evaluation can be based on evaluation of the hierarchical layers of the circuit design netlist 112 in a sequence. In response to completion of the evaluation of the circuit design netlist 112, the circuit design validation tool 102 can provide a circuit evaluation report, demonstrated as validation report data, shown as “VRPT” in the example of
The coded rules 106 can be associated with a variety of operational, structural, and/or behavioral characteristics of the circuit cells of the circuit design netlist 112. As an example, the circuit design validation tool 102 can evaluate each instance of a circuit cell corresponding to each of a plurality of circuit cell templates stored in a circuit design library with respect to one or more of the coded rules 106. The circuit design library can be stored in the circuit design database 108, for example. As described in greater detail herein, the circuit cell templates in the circuit design library can include cell definitions that define operational, structural, and intended behavioral characteristics of the type of the circuit cells. Therefore, the coded rules 106 can correspond to rules defining consistency between a respective one of the circuit cell templates and each instance of the respective circuit cell with respect to the cell definitions.
As another example, the circuit design validation tool 102 can evaluate each of the instances of each of the circuit cell types with respect one or more additional coded rules. The instances of the circuit cells can each include a unique instance name, net names associated with input and output wire couplings associated with the respective instance, and connections of the wire couplings to other instances of other circuit cells. Therefore, the coded rules 106 can define standards associated with the instance name, the net names, and the connections for each of the instances of the given cell type. The circuit design validation tool 102 can thus determine which of the circuit cells satisfy the coded rules 106 and which of the circuit cells fail the coded rules 106 based on the characteristics of the circuit cells relative to the criteria defined by the coded rules 106.
For example, the user interface 104 can include a evaluate failure input for each of the logged coded rule failures of respective circuit cells. The evaluate failure input can provide a means for correction of the respective failed circuit cells, such as based on user inputs. For example, the correction of the failed circuit cell can occur based on correction data, shown as correction data feedback “CDFBK” in
As an example, the user can provide the evaluate failure input associated with a specific failed circuit cell via the user interface 104 to immediately view the failed circuit cell in a graphical representation of the circuit design. Therefore, the user can provide manual inputs via the user interface 104 to correct the failed circuit cell to a passing condition that satisfies the respective one of the coded rules 106. As another example, the circuit design validation tool 102, upon indicating failure of circuit cell with respect to a given one of the coded rules 106, can provide a suggestion to the user via the evaluate failure input as to how the failed circuit cell can be corrected to a passing condition that satisfies the respective one of the coded rules 106. As yet another example, the evaluate failure input can activate an automatic correction feature of the circuit design validation tool 102, such that the circuit design validation tool 102 can automatically correct the circuit cell to a passing condition that satisfies the respective one of the coded rules 106 based on context associated with surrounding or similar circuit cells that satisfied the respective one of the coded rules 106.
The circuit design validation tool 102 can thus be implemented to provide a high degree of scrutiny of the circuit design to satisfy the desired criteria as established by the coded rules 106. Such a validation process can provide a significantly more accurate and more rapid review of a circuit design relative to manual review by a circuit designer. Thus, the circuit design validation tool 102 can mitigate human error that can result from time consuming and tedious manual review. Furthermore, in some examples, the circuit design validation tool 102 can obviate the need for manual circuit validation that simulates environmental conditions. For example, for validation of a radiation-hardened circuit design, the circuit design validation tool 102 can provide sufficient validation of the radiation-hardened design instead of providing particle accelerator testing that can be costly and not readily accessible.
The circuit design netlist 200 includes a circuit design library 202 and a circuit layout 204. The circuit design library 202 includes a plurality of circuit cell templates that each correspond to types of circuit cells that can be implemented in the circuit design. In the example of
The circuit layout 204 can correspond to a text-based representation of the circuit topography of the circuit design. In the example of
In the example of
As described herein, alphabetic designations are not necessarily intended to be consistent with respect to quantity from one figure to another figure. Therefore, multiple instances of “N”, “X”, “Y”, “Z”, etc. are not necessarily denoting the same quantity or the same componentry in the description herein.
Each of the circuit cell instances 212 through 214 includes a unique instance name (“INSTANCE NAME”) 216 corresponding to nomenclature of the circuit cell in the circuit design netlist 200, net names 218 corresponding to unique labels of the wires that connect as inputs and outputs to the respective circuit cell in the circuit design netlist 200, and connections 220 corresponding to the quantity, location, and other characteristics (e.g., gauge) of the wires that connect as inputs and outputs to the respective circuit cell in the circuit design netlist 200. The text-based representation of the circuit design netlist 200 based on the circuit cell instances 212 through 214, with the corresponding respective unique instance names 216, net names 218, and connections 220, as well as the circuit cell definitions 210 in the corresponding circuit cell templates 206 through 208, can thus correspond to the circuit design that is stored in the circuit design database 108.
As described above and as described in greater detail herein, the circuit design validation tool 102 can evaluate the circuit cell instances 212 through 214 with respect to the coded rules 106 to determine if the circuit cell instances 212 through 214 satisfy the predetermined criteria defined by the coded rules 106. As also described above, the predetermined criteria defined by the coded rules 106 can relate to requiring triple-redundancy for circuit components in the circuit design, with the triple-redundancy requiring a majority vote for the function of the respective circuit components.
As a first example, the circuit design validation tool 102 can evaluate the circuit cell instances 212 through 214 with respect to a first set of coded rules 106 to determine if each of the circuit cell instances 212 and 214 is provided in the circuit layout 204 consistent with the circuit cell definitions 210 of the corresponding respective circuit cell templates 206 through 208. For example, the circuit design validation tool 102 can determine if each of the circuit cell A instances 212 satisfy the circuit cell definitions 210 of the circuit cell A template 206, such as with respect to nomenclature standards, wire connectivity standards of input and output wires (e.g., quantity, type of connection to other circuit cell instances, etc.), and behavioral standards (providing the function in the circuit layout 204 that the circuit cell A template 206 is intended to provide) as set forth in the first set of coded rules 106. If a given one or more of the circuit cell A instances 212 are not consistent with the circuit cell definitions 210 of the circuit cell A template 206, as defined by the first set of coded rules 106, then the circuit design validation tool 102 marks the respective one or more of the circuit cell A instances 212 as having failed the specific respective coded rules 106 in the circuit evaluation report VRPT.
As a second example, the circuit design validation tool 102 can evaluate the circuit cell instances 212 through 214 with respect to a second set of coded rules 106 to determine if each of the circuit cell instances 212 and 214 is provided in the circuit layout 204 satisfy criteria defined by the second set of coded rules 106 with respect to the unique instance names 216, the net names 218, and the connections 220. For example, the circuit design validation tool 102 can determine if each of the circuit cell A instances 212 have unique instance names 216 that satisfy the definitions set forth in the second set of coded rules 106. The circuit design validation tool 102 can also determine if each of the circuit cell A instances 212 have net names 218 that satisfy the definitions set forth in the second set of coded rules 106. The circuit design validation tool 102 can further determine if the connections 220 between the circuit cell A instances 212 and other circuit cell instances satisfy a set of rules (e.g., connection between devices, ground connections, triplicate connection for triple-redundancy, etc.) defined by the second set of coded rules 106. If a given one or more of the circuit cell A instances 212 do not satisfy the rules defined by the second set of coded rules 106 with respect to the unique instance names 216, the net names 218, and the connections 220, then the circuit design validation tool 102 marks the respective one or more of the circuit cell A instances 212 as having failed the specific respective coded rules 106 in the circuit evaluation report VRPT.
Referring back to the example of
In the example of
In the example of
The circuit design validation tool 102 can be configured to evaluate the layers of the hierarchical arrangement of the circuit design individually, collectively, or sequentially. As an example, each of the coded rules 106 can be programmed to apply to one or more of the layers specifically, or can include details as to how to evaluate the circuit design netlist 112 across multiple layers. As an example, the evaluation of layers in a sequence can be necessary to gain context of surrounding portions of the circuit design for purposes of evaluating a given one circuit cell based on a specific one of the coded rules 106.
For example, in evaluating LAYER 3 based on a given one of the coded rules 106, the circuit design validation tool 102 may not be able to determine if a given one of the third circuit cells 306 (e.g., CELL 1_1_1) passes or fails the given one of the coded rules 106 without more information. Therefore, the circuit design validation tool 102 can store the unresolved evaluation regarding the respective third circuit cell 306 with respect to the one of the coded rules 106 in a buffer to be determined at a later time. Thus, in order to ascertain additional context or information that can provide the determination of the unresolved evaluation, the circuit design validation tool 102 can evaluate the respective one of the second circuit cells 304 that subsumes the respective third circuit cell 306 in the next higher layer (e.g., CELL 1_1) based on the respective one of the coded rules 106 or based on a different one of the coded rules 106 to gain additional information. If the additional information is sufficient, the circuit design validation tool 102 can thus provide re-evaluation of the respective one of the third circuit cells 306 with respect to the one of the coded rules 106 based on the additional information to determine if the respective one of the third circuit cells 306 passes or fails the conditions defined by the respective one of the coded rules 106.
In the example provided above, the additional information to re-evaluate an unresolved evaluation of a circuit cell can be gathered in a variety of ways. The circuit design validation tool 102 can gather the additional information based on evaluating surrounding circuit cells (e.g., as determined by the connections 220) based on the same or a different one of the coded rules 106, based on evaluating the circuit cell of a next higher layer or circuit cells of a next lower layer of the hierarchical arrangement of the circuit design, or based on obtaining information in a certain order that is different from the order of applying the coded rules 106 in evaluating the circuit design netlist 112. As another example, one or more of the coded rules 106 can be directed to consistency in the characteristics of the circuit cells across one or more of the layers of the hierarchical arrangement of the circuit design. For example, one or more of the coded rules 106 can be directed to consistency in the unique instance names 216, the net names 218, and the connections 220 of the first circuit cell 302 relative to the second circuit cells 304, and/or the third circuit cells 306.
Each of the coded rules 402 can include a rule definition 404, a layer resolver 406, and one or more rule prerequisites 408. The rule definition 404 can correspond to the definition of the rule, as applied to one or more of the circuit cells, to determine if the respective circuit cell(s) pass or fail the conditions set forth by the definition. The layer resolver 406 can correspond to the behavior or manner of evaluation of the coded rule 402 with respect to the hierarchical structure of the circuit design. As an example, the layer resolver 406 can define that the coded rule 402 operates on only a specific one or more of the layers of the circuit design. As another example, the layer resolver 406 can determine how the circuit design validation tool 102 should apply the coded rule 402 in response to an unresolved evaluation of a given circuit cell on a given layer. For example, as described above in the example of
The rule prerequisite(s) 408 can correspond to one or more conditions as to when the apply the respective coded rule 402, conditions that trigger application of the respective coded rule 402, an order of application of the respective coded rule 402, or any of a variety of factors that dictate when and how the respective coded rule 402 should be applied to the respective circuit cells. For example, the rule prerequisite(s) 408 can determine when or what additional information may be needed for resolving the respective coded rule 402, such that the rule prerequisite(s) 408 can dictate the conditions that the unresolved evaluation of a given circuit cell should be stored in a buffer for re-evaluation at a later time based on additional information or context provided by the evaluation of other circuit cells in the circuit design. The rule prerequisite(s) 408 can also dictate what information specifically may be required for resolving the respective coded rule 402 in evaluating a given circuit cell, such that the required information requirements can be stored in a memory. Therefore, upon the circuit design validation tool 102 gathering the required information either before or after evaluating the circuit cells based on the respective coded rule 402, the circuit design validation tool 102 can flag the rule prerequisite(s) 408 as being met to subsequently evaluate circuit cells with respect to the specific coded rule 402, or to re-evaluate a circuit cell that had been previously buffered as having an unresolved evaluation based on incomplete information at an initial time of evaluation.
Below are several examples of coded rules 402 that are collectively associated with ensuring that the circuit design is radiation-hardened.
As a first example, one of the coded rules 402 can correspond to floating nets for triple-redundancy. The coded rule 402 can check that if triple-redundancy nets are produced then they are all used. Using a single leg of a triple-redundancy net can cause a variety of issues. The coded rule 402 can generate a derivative rule to check connections at higher levels for nets that connect to module terminals (ports). Thus, the coded rule 402 can ensure that the nets connect at an input/output port of the circuit cell. The coded rule 402 can check at a higher level for nets that connect up via a port.
As a second example, one of the coded rules 402 can correspond to ensuring that all input nets on an instance of a circuit cell are or are not triple-redundant. The coded rule 402 can exclude power and ground nets. If an input net is triple-redundant, then the coded rule 402 ensures that all input nets are triple-redundant. An exception can be established for majority voted or majority voted filtered nets. If all nets of a circuit cell are triple-redundant or majority voted, or a filtered net, the coded rule 402 passes. When all nets of a circuit cell are non-triple-redundant, the coded rule 402 passes. If a circuit cell includes both triple-redundant and non-triple-redundant nets, the coded rule 402 fails. Net inputs that are not labeled triple-redundant, majority voted, or filtered, and are hooked to a module port, the coded rule 402 will facilitate checking at a next higher level of the circuit design.
As a third example, one of the coded rules 402 can define that majority vote instances of circuit cells should have majority vote output nets. If the instance of a circuit cell has a majority vote suffix, then the outputs of the circuit cell should have a majority vote suffix. If the instance of the circuit cell has a majority vote filtered suffix, then the outputs of the circuit cell should have a majority vote filtered suffix.
As a fourth example, one of the coded rules 402 can define that filtered instances of circuit cells are required to not have triple-redundant fast input nets. If the instance of the circuit cell has a filtered or majority vote filtered suffix, then the inputs of the circuit cell should not be indicated with a triple redundant fast suffix.
As a fifth example, one of the coded rules 402 can define that triple-redundant net numbers/order match triple-redundant instance numbers.
As a sixth example, one of the coded rules 402 can define that a triple-redundant instance of a circuit cell should have an index indicator that is either an array or a scalar number.
As a seventh example, one of the coded rules 402 can define that triple-redundant nets should have the same number of load connections.
As an eighth example, one of the coded rules 402 can define that triple-redundant nets should be in groups of three. Other quantities of triple-redundant labeled nets will be flagged as failing.
As a ninth example, one of the coded rules 402 can define that memory elements should have majority voted inputs.
As a tenth example, one of the coded rules 402 can define that instances of circuit cells that appear to be triple redundant should have the triple-redundant naming convention. The coded rule 402 identifies such instances of circuit cells by finding circuit cell templates that are instantiated exactly three times in a schematic and have all of the respective ports connected to net names with the same name or the same root name.
As an eleventh example, one of the coded rules 402 can define that nets that appear to be triple redundant should have the triple-redundant naming convention. The coded rule 402 identifies the nets by finding nets with a common root name (e.g., with net array index removed) that are three in quantity in a schematic and are connected to the same combination of ports of the same instances of a circuit cell template.
As a twelfth example, one of the coded rules 402 can define that instances of circuit cells that have been named with a memory suffix should appear in the configuration file for defined circuit cell templates of valid memory cells.
As a thirteenth example, one of the coded rules 402 can define that instances of circuit cells that have been named with memory filtered suffix should appear in the configuration file for defined circuit cell templates of valid memory cells with embedded filters.
As a fourteenth example, one of the coded rules 402 can define that instances of circuit cells should match the defined circuit cell template for memory cells, but do not have a memory cell naming suffix.
As a fifteenth example, one of the coded rules 402 can define that instances of circuit cells that match to the defined circuit cell template for memory cells with embedded filters should a memory cell with filter naming suffix.
As a sixteenth example, one of the coded rules 402 can define that comparators that are not named with a safe (e.g., triple-redundant, majority vote, and/or filtered) extension that are not in a triple-redundant cell and which have loads do not go to a safe port/instance. The coded rule 402 will flag failure if the instance of the circuit cell is not named with a safe suffix and the loads and parent cell are also not named with a safe suffix.
As a seventeenth example, one of the coded rules 402 can define that nets should not have name changes between triple-redundant and triple-redundant fast throughout the hierarchy of the circuit design.
As an eighteenth example, one of the coded rules 402 can check for instances of circuit cells of level shifters as defined in a configuration file. If the level-shifter circuit cells have safe extensions, then the level-shifter circuit cells should have safe inputs. If a safe level shifter instance of a circuit cell is found, the inputs are checked to make sure the input nets are safe. If an input net is not labeled as safe, and is a port, the nets in the layer above are checked.
As a nineteenth example, one of the coded rules 402 can checks that the body terminal of isolated transistor devices (e.g., ISO NMOS devices) are tied to a ground net.
As a twentieth example, one of the coded rules 402 can check that the body terminal of transistor devices (e.g., PMOS devices) are tied to a supply net.
As a twenty-first example, one of the coded rules 402 can check that the bottom plate of high-density capacitors is tied to a supply or ground net.
As a twenty-second example, one of the coded rules 402 can check that one of the terminals of capacitors (e.g., the BN terminal of multi-layer polysilicon capacitors) are tied to a supply or ground net.
As a twenty-third example, one of the coded rules 402 can check that the body terminal of a 20V laterally-diffused transistor (LDMOS) is tied to the source terminal.
As a twenty-fourth example, one of the coded rules 402 can identify simple NAND or NOR based SR latches which are not contained inside a defined memory cell. The topology recognition of the coded rule 402 can see through any resistors that may be part of RC filters. If such devices are found, the latch is checked to determine if it is inside a defined MEM hierarchy so that all the other triple redundant rule checking can be performed.
As a twenty-fifth example, one of the coded rules 402 can identify NMOS spares that are tied off to a supply net.
As a twenty-sixth example, one of the coded rules 402 can provide a general analog linting check not specifically related to triple-redundant circuits. The coded rule 402 attempts to identify places where a bias current net output was shared between two or more blocks.
Additional examples of coded rules 402 can be implemented to ensure that the circuit design is radiation-hardened. Therefore, the coded rules 402 are not limited to the examples described herein.
The circuit cell template 500 includes corresponding circuit cell definitions 502. Similar to as described above, the circuit cell definitions 502 can define operational, structural, and/or intended behavioral characteristics (e.g., requiring a triple redundancy and/or majority vote topology or other radiation-hardened design considerations) of the type of the circuit cells represented by the circuit cell template 500. The circuit cell definitions 502 can thus define nomenclature standards, connectivity standards of input and output wires, and behavioral standards corresponding to an intended use of the circuit cells corresponding to the circuit cell template 500.
In addition, in the example of
As an example, the circuit cell rule 506 can be provided to a set of coded rules 508 that can correspond to the coded rules 400 in the example of
In the example of
In the example of
As another example, in response to providing the evaluate failure input 610, the circuit design validation tool 102 can provide a suggestion to the user via the user interface 104 as to how the failed circuit cell can be corrected to a passing condition that satisfies the respective one of the coded rules 106. For example, the circuit design validation tool 102 can generate the suggested modification to the circuit cell based on contextual information regarding surrounding circuit cells and/or nets connected to the respective circuit cell, such as based on the evaluation of the respective circuit cell and/or surrounding circuit cells. The user can thus accept the suggestion, resulting in an automatic correction of the failed circuit cell, override the suggestion with manual inputs to correct the failed circuit cell, or ignore the failure and mark the respective circuit cell as passing via the user interface 104. As yet another example, the evaluate failure input 610 can be initiated by the user to activate an automatic correction feature of the circuit design validation tool 102. Therefore, similar to the suggested modification described above, the circuit design validation tool 102 can automatically correct the circuit cell to a passing condition that satisfies the respective one of the coded rules 106 based on context associated with surrounding or similar circuit cells that satisfied the respective one of the coded rules 106. Accordingly, the circuit design can be corrected in a variety of ways by the evaluate failure input 610 to satisfy the requirements of a radiation-hardened design.
As described herein, the circuit design validation tool 102 can provide a rapid solution to validating a circuit design to ensure radiation-hardened design considerations. As a result, significant time in manual review and validation can be saved, and the potential for human error resulting from such time-consuming and menial review can be greatly mitigated. Furthermore, the use of the circuit design validation tool 102 can mitigate the need for manual testing protocols to ensure a properly functioning radiation-hardened design. For example, the circuit design validation tool 102 can obviate the need to use a particle accelerator to test actual hardware fabrications of a circuit design. The use of such a particle accelerator is extremely expensive and very difficult to access. Therefore, eliminating such a requirement can result in significant time and cost reduction.
In view of the foregoing structural and functional features described above, a methodology in accordance with various aspects of the present invention will be better appreciated with reference to
In this description, the term “couple” may cover connections, communications, or signal paths that enable a functional relationship consistent with this description. For example, if device A generates a signal to control device B to perform an action, then: (a) in a first example, device A is directly coupled to device B; or (b) in a second example, device A is indirectly coupled to device B through intervening component C if intervening component C does not substantially alter the functional relationship between device A and device B, so device B is controlled by device A via the control signal generated by device A.
Also, in this description, a device that is “configured to” perform a task or function may be configured (e.g., programmed and/or hardwired) at a time of manufacturing by a manufacturer to perform the function and/or may be configurable (or reconfigurable) by a user after manufacturing to perform the function and/or other additional or alternative functions. The configuring may be through firmware and/or software programming of the device, through a construction and/or layout of hardware components and interconnections of the device, or a combination thereof. Furthermore, a circuit or device described herein as including certain components may instead be configured to couple to those components to form the described circuitry or device. For example, a structure described as including one or more semiconductor elements (such as transistors), one or more passive elements (such as resistors, capacitors, and/or inductors), and/or one or more sources (such as voltage and/or current sources) may instead include only the semiconductor elements within a single physical device (e.g., a semiconductor wafer and/or integrated circuit (IC) package) and may be configured to couple to at least some of the passive elements and/or the sources to form the described structure, either at a time of manufacture or after a time of manufacture, such as by an end user and/or a third party.
Modifications are possible in the described embodiments, and other embodiments are possible, within the scope of the claims.
Claims
1. A method for validating a circuit design, the method comprising:
- providing a set of coded rules, each of the coded rules defining conditions for circuit cells to qualify the circuit design as being radiation-hardened;
- accessing a circuit design netlist associated with the circuit design from a circuit design database;
- evaluating each of the circuit cells in the circuit design netlist with respect to each of the coded rules; and
- publishing a circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
2. The method of claim 1, wherein publishing the circuit evaluation report comprises publishing the circuit evaluation report to a validation database on a user interface, the method further comprising providing a evaluate failure input on the validation database to correct a failure of each of the set of circuit cells in the circuit evaluation report.
3. The method of claim 2, wherein the evaluate failure input is configured to modify a respective one of the set of circuit cells in the circuit design netlist indicated as failed in the circuit evaluation report to change the respective one of the set of circuit cells as passing in the circuit evaluation report.
4. The method of claim 1, wherein accessing the circuit design netlist comprises accessing the circuit design netlist from a circuit database application programming interface (API) associated with the circuit design database.
5. The method of claim 1, wherein evaluating each of the circuit cells comprises evaluating each instance of a circuit cell corresponding to each of a plurality of circuit cell templates stored in a circuit design library with respect to at least one of the coded rules,
- wherein each of the circuit cell templates comprises cell definitions that define operational, structural, and intended behavioral characteristics of the respective type of the circuit cells, and
- wherein the at least one of the coded rules corresponds to consistency between a respective one of the circuit cell templates and each instance of the respective circuit cell with respect to the cell definitions.
6. The method of claim 5, further comprising storing a configuration file in one of the circuit cell templates, the configuration file comprising a respective first one of the coded rules of the respective one of the circuit cell templates, wherein storing the set of coded rules comprises storing the respective coded rule from the configuration file in response to evaluating an instance of a respective circuit cell corresponding to the respective one of the circuit cell templates with respect to a second one of the coded rules, and wherein evaluating each of the circuit cells further comprises evaluating each instance of the one of the circuit cell templates with respect to the first one of the coded rules.
7. The method of claim 1, wherein evaluating each of the circuit cells comprises evaluating each of a plurality of instances of each of a plurality of circuit cell types with respect to at least one of the coded rules, wherein each of the instances comprises a unique instance name, net names associated with input and output wire couplings associated with the respective instances, and connections of the input and output wire couplings to other respective instances of circuit cells, wherein the at least one of the coded rules corresponds to defining a standard associated with the instance name, the net names, and the connections for each of the instances.
8. The method of claim 1, wherein evaluating each of the circuit cells further comprises:
- storing an unresolved evaluation a first one of the circuit cells in response to a determination of incomplete information associated with evaluation of the first one of the circuit cells with respect to a first one of the coded rules;
- evaluating at least one other of the circuit cells with respect to at least one of the first one of the coded rules and another one of the coded rules to determine additional evaluation information; and
- re-evaluating the first one of the circuit cells with respect to the first one of the coded rules based on the additional evaluation information.
9. The method of claim 1, wherein evaluating each of the circuit cells comprises evaluating each of a plurality of hierarchical layers of the circuit cells with respect to at least one of the coded rules, the hierarchical layers comprising a top layer, at least one intermediate layer, and a bottom layer, wherein each of the top layer and the at least one intermediate layer comprises at least one higher level circuit cell that comprises a plurality of lower level circuit layers associated with a next lower layer of the hierarchical layers, wherein the at least one of the coded rules corresponds to at least one of name and connection consistency between the at least one higher level circuit cell and the lower level circuit layers.
10. The method of claim 9, wherein evaluating each of the circuit cells further comprises:
- evaluating a respective one of the at least one higher level circuit cell in response to a determination of incomplete information associated with evaluation of the lower level circuit cells with respect to the at least one of the coded rules; and
- re-evaluating the lower level circuit cells with respect to the at least one of the coded rules based on the evaluation of the at least one higher level circuit cell.
11. The method of claim 9, wherein, for each of the coded rules, storing the coded rules comprises:
- storing a rule definition defining passage and failure conditions for the circuit cells for the respective one of the coded rules;
- storing at least one prerequisite for the respective one of the coded rules associated with an order of evaluating the respective one of the coded rules with respect to at least one other coded rule; and
- storing a layer resolver for the respective one of the coded rules that defines a manner of the evaluation of the respective one of the coded rules with respect to the hierarchical layers.
12. The method of claim 1, wherein evaluating each of the circuit cells comprises evaluating each of the circuit cells in the circuit design netlist with respect to each of the coded rules associated with providing triple-redundancy majority voter design considerations for the circuit design to qualify as radiation-hardened.
13. A circuit validation system comprising:
- a user interface configured to facilitate input of a set of coded rules, each of the coded rules defining conditions for circuit cells to qualify the circuit design as being radiation-hardened;
- a circuit database application programming interface (API) configured to provide access to a circuit design netlist associated with the circuit design from a circuit design database; and
- a circuit design validation tool configured to access the circuit design netlist via the circuit database API and to evaluate each of the circuit cells in the circuit design netlist with respect to each of the coded rules and to provide a circuit evaluation report to a validation database on the user interface, the circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
14. The system of claim 13, wherein the user interface comprises a evaluate failure input on the validation database, the evaluate failure input being configured to modify a respective one of the set of circuit cells in the circuit design netlist indicated as failed in the circuit evaluation report to correct a failure of the respective one of the set of circuit cells to change the respective one of the set of circuit cells as passing in the circuit evaluation report.
15. The system of claim 13, wherein the circuit design validation tool is configured to evaluate each instance of a circuit cell corresponding to each of a plurality of circuit cell templates stored in a circuit design library with respect to at least one of the coded rules, wherein each of the circuit cell templates comprises cell definitions that define operational, structural, and intended behavioral characteristics of the type of the circuit cells, wherein the at least one of the coded rules corresponds to consistency between a respective one of the circuit cell templates and each instance of the respective circuit cell with respect to the cell definitions.
16. The system of claim 13, wherein the circuit design validation tool is configured to each of a plurality of instances of each of a plurality of circuit cell types with respect to at least one of the coded rules, wherein each of the instances comprises a unique instance name, net names associated with input and output wire couplings associated with the respective instances, and connections of the input and output wire couplings to other respective instances of circuit cells, wherein the at least one of the coded rules corresponds to defining a standard associated with the instance name, the net names, and the connections for each of the instances.
17. The system of claim 13, wherein the circuit design validation tool is configured to:
- store an unresolved evaluation a first one of the circuit cells in response to a determination of incomplete information associated with evaluation of the first one of the circuit cells with respect to a first one of the coded rules;
- evaluate at least one other of the circuit cells with respect to at least one of the first one of the coded rules and another one of the coded rules to determine additional evaluation information; and
- re-evaluate the first one of the circuit cells with respect to the first one of the coded rules based on the additional evaluation information.
18. The system of claim 13, wherein the circuit design validation tool is configured to evaluate each of a plurality of hierarchical layers of the circuit cells with respect to at least one of the coded rules, the hierarchical layers comprising a top layer, at least one intermediate layer, and a bottom layer, wherein each of the top layer and the at least one intermediate layer comprises at least one higher level circuit cell that comprises a plurality of lower level circuit layers associated with a next lower layer of the hierarchical layers, wherein the at least one of the coded rules corresponds to at least one of name and connection consistency between the at least one higher level circuit cell and the lower level circuit layers.
19. A circuit design validation tool configured to:
- receive a set of coded rules, each of the coded rules defining conditions for circuit cells to qualify the circuit design as being radiation-hardened;
- access a circuit design netlist associated with the circuit design via a circuit database application programming interface (API) associated with a circuit design database;
- evaluate each of the circuit cells in the circuit design netlist with respect to each of the coded rules; and
- provide a circuit evaluation report to a validation database on the user interface, the circuit evaluation report comprising an indication of failure of a set of the circuit cells with respect to one or more of the coded rules in response to the evaluation.
20. The tool of claim 19, wherein the circuit design validation tool is configured to:
- evaluate each instance of a circuit cell corresponding to each of a plurality of circuit cell templates stored in a circuit design library with respect to at least one first coded rule, wherein each of the circuit cell templates comprises cell definitions that define operational, structural, and intended behavioral characteristics of the type of the circuit cells, wherein the at least one first coded rule corresponds to consistency between a respective one of the circuit cell templates and each of a plurality of instances of the respective circuit cell with respect to the cell definitions; and
- evaluate each of the plurality of instances of each of the plurality of circuit cell types with respect to at least one second coded rule, wherein each of the instances comprises a unique instance name, net names associated with input and output wire couplings associated with the respective instantiation, and connections of the input and output wire couplings to other respective instances of circuit cells, wherein the at least one second coded rule corresponds to defining a standard associated with the instance name, the net names, and the connections for each of the instances.
Type: Application
Filed: Jan 27, 2022
Publication Date: Aug 4, 2022
Patent Grant number: 12236177
Inventors: Lawrence James GEWAX (DALLAS, TX), Timothy Paul DURYEA (DALLAS, TX)
Application Number: 17/586,516