Machine learning (ML)-based static verification for derived hardware-design elements

Disclosed herein are system, computer-readable storage medium, and method embodiments of machine-learning (ML)-based static verification for derived hardware-design elements. A system including at least one processor may be configured to extract a feature set from a hardware description and evaluate a similarity index of a first hardware element with respect to a second hardware element, using an ML process based on the feature set, wherein the first hardware element is described in the hardware description. The at least one processor may be further configured to update one or more parameters corresponding to a static verification of the hardware description while the static verification is being performed, by providing at least one test attribute, corresponding to the second hardware element, applicable to the first hardware element, in response to determining that the similarity index is within a specified range, and additionally output a first result of the static verification.

TECHNICAL FIELD

The present disclosure relates to an electronic design automation (EDA) system. In particular, the present disclosure is related to a system and method for providing machine learning (ML)-based static verification for derived hardware-design elements.

BACKGROUND

Typical circuit designs (e.g., for integrated circuits or programmable logic) may be created by using functional blocks (also referred to as intellectual properties (IPs)) and/or making modifications of designs of existing IP designs to create derivative versions of the existing designs.

A static verification tool, such as a linter, a checker for clock-domain crossings (CDC), reset-domain crossings (RDC), low-power (LP) specification violations, and other formal verification tools, may perform static verification of any given hardware design for signoff (e.g., completing verification before a tape-out process with electronic design automation (EDA)) for a given hardware-design project. In any steps of static verification using any of tools such as those listed above, a user may analyze any violations and decide to take actions to address violations.

Apart from changing the underlying design itself in an attempt to avoid violations, the static verification tool may also address a violation by performing specific actions, such as changing tool settings, specifying constraints for the static verification, and/or applying waivers for certain violations that a user may not need or want to address by other means. Once addressed, verification steps may be repeated until verification passes.

When another derivative version of the same design is run through the same static-verification tool, the static verification typically starts from scratch each time. This may be because different design groups, possibly in different locations, may separately work on the same designs or new designs derived therefrom. The derivative designs may have many parts left unchanged, in common with the existing design, with only some parts being new or modified. Any parameters that may have been set or learned from static-verification actions performed for previous version of the design may go ignored due to the user manually managing verification, and conventional migration of any previous settings may still underutilize specific constraints, settings, or waivers with respect to any hardware-design elements that may be reused or derived from existing designs.

Thus, even where designs may be reused, learning is not easily reused or reusable across runs of static-verification tools. This lack of reuse of learning may result in inefficient usage of human resources and compute resources to reach to same or similar actions. Additionally, such inefficiencies may in turn risk missing out on certain actions that may improve design reliability and that may thus jeopardize the fidelity of a signoff for a given circuit or hardware project.

SUMMARY

Disclosed herein are system, computer-readable storage medium, and method embodiments of ML-based static verification for derived hardware-design elements. A system including at least one processor may be configured to extract a feature set from a hardware description and evaluate a similarity index of a first hardware element with respect to a second hardware element, using an ML process based on the feature set, where the first hardware element is described in the hardware description.

The at least one processor may be further configured to update one or more parameters corresponding to a static verification of the hardware description while the static verification is being performed, by providing at least one test attribute, corresponding to the second hardware element, applicable to the first hardware element, in response to determining that the similarity index is within a specified range, and additionally output a first result of the static verification with respect to at least one hardware element described in the hardware description, in an embodiment.

The feature set may be based at least in part on the at least one test attribute corresponding to one or more hardware elements of the hardware description. Moreover, the at least one test attribute may include a configuration, a setting, a constraint, or a waiver of one or more violations of a specification for the static verification. Additionally, at least one attribute of the first hardware element is propagated to at least one other hardware element in a hierarchy of hardware elements described in the hardware description and for which the similarity index is within the specified range, according to some further embodiments.

Additionally, or alternatively, the present disclosure further includes operations of checking at least one corresponding signature of at least one attribute of the at least one hardware element described in the hardware description with respect to a known signature of at least one known attribute of the second hardware element. The second hardware element may correspond to at least one known hardware element referenced in a database or at least one other hardware element described in the hardware description. A further operation may include, in response to the checking, omitting from the extracting, the evaluating, or the static verification, a given hardware element of the at least one hardware element the hardware description, when a given signature of the given hardware element at least partially matches the known signature of the at least one known attribute of the second hardware element, according to some embodiments of the present disclosure.

Additionally, or alternatively, the present disclosure further includes operations of identifying a specification for the static verification, and indicating, based at least in part on the similarity index and on the specification, that a first attribute of the first hardware element is similar to a second attribute of the second hardware element. Further operations may include retrieving a second result of an additional static verification with respect to the second hardware element and the specification, using the second attribute instead of the first attribute, and returning the second result as the first result with respect to the first hardware element.

At least some aspects of this summary, among other aspects of the present disclosure, may be implemented via various system, apparatus, article of manufacture, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for using technology in innovative ways to enable ML-based static verification for derived hardware elements.

In the drawings, like reference numbers generally indicate identical or similar elements.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to ML-based static verification for derived hardware-design elements. Further aspects of the present disclosure relate to static verification of hardware designs, such as those compiled from hardware-description languages (HDL) or other higher-level representations. More specifically, the present disclosure further describes, according to some embodiments, ML and related processes and techniques that may be applied to enhance accuracy, speed, and efficiency of such static verification.

Hardware designs may include various hardware-design elements, for which various parameters in testing tools may be configured and adjusted when hardware designs are tested, such as with static verification against various specifications. Examples of such parameters include tool switches (e.g., app_vars), to run a tool in a certain mode or to control various aspects of how the tool runs a given test for any applicable part of a DUT. For example, setting a parameter of case_analysis may assume a constant value for a set of design nodes (e.g., hardware-design elements) and propagate these constant values appropriately to other nodes in the DUT, in order to run a test tool with these assumed constants. Assumed constants, as opposed to design constants, may be set by control logic during hardware operation as it would run under such logic controls, test tools may be run under assumption of these constants, in some embodiments.

For purposes of the present disclosure, with any given hardware-design element, any special settings of parameters for a run of a test tool may be generally referred to as test attributes. Some examples of test attributes include constraints, settings, and waivers, according to some embodiments. An example of the present techniques described herein includes recording at a time when a given test is being performed (e.g., using a specific linter, checker, or similar static-verification routine), constraints that a user or other entity may set for purposes of the given test (e.g., selecting or excluding quasi_static or case_analysis parameters, to provide a few non-limiting example parameters that may be treated as constraint attributes), settings, modes, or other configuration options a user may be using or may have otherwise set for the given test (e.g., any specific app_vars, or other variables for tool configurations), and/or any waivers that a user or other entity may apply during or after verification, such as to ignore or eliminate certain violations from consideration if permissible when proceeding to a subsequent step of a design or test phase for a given circuit or hardware project, according to some embodiments. Additionally, or alternatively, the above recording of test attributes (e.g., a constraint, a setting, and a waiver), may be recorded as actions (e.g., of setting or unsetting) rather than as the attributes' configuration values per se, for example, per some embodiments.

Such recordings may also be propagated (e.g., ported, moved over, pushed down) to additional levels of a design hierarchy (e.g., from system-on-a-chip (SoC) level to chiplet level or other IP level). Moreover, further recordings as propagated or inherited may be made attributable to those corresponding design blocks, again either as configuration values of test attributes (e.g., a constraint, a setting, and a waiver) and/or as test actions themselves. Even if an entire project design is not reused as a whole, parts of the design may be reused, and may thus benefit from inheriting applicable attributes in this way.

For example, if a SoC signal is marked as set case_analysis=1 for a given test (constituting a case_analysis constraint to assume a ‘1’ value for a given signal in a DUT), and that signal reaches down to a certain level in a hierarchy (e.g., IP core), then such a signal marking (or action thereof) may be recorded as a case_analysis constraint at both the SoC level and the certain IP level, as well. Similarly, if a user applies a waiver, and the waiver is contained inside a given IP only, the waiver may be recorded as an IP-level waiver also by appropriately modifying the hierarchical names, according to some embodiments.

When a new design is run through static verification, a tool may scan the design and check whether the full design, or any parts of the design, may appear similar to designs saved in database. The similarity matching is not necessarily exact, but may instead be triggered upon a certain degree of correlation of features of a given design, including at a hardware-description level. Correlation of features may be reflected by a similarity index, which may reflect any level of transformations as applied to vectorized features extracted from a given design. ML techniques may be used as further facilitating identification of similar designs.

When a DUT and another existing design have overlapping features, such as with respect to other designs in a given hardware project and/or with respect to other designs in a reference data store (e.g., a library and a database), the DUT and existing design with overlapping features may be considered to be similar. This overlap may occur when a design is copied in one or more instances, and a component is modified, while other components remain unmodified. Such copying and modification may be found in designs, according to some embodiments, containing or referencing other known designs, such as reusable design templates for various elements (e.g., an SoC, an IP core, and other circuitry) or other already-modified derived designs or the like. Thus, similar designs are not identical to each other, but they may have certain features in common. Static verification, when performed on such similar designs, may therefore benefit from having certain test-tool attributes or actions propagated automatically from one design element to a similar design element.

Once similar design components are identified, a recommender may be used, according to some embodiments, to recommend accumulated attributes or actions stored in a database. The present static verification system may allow a user to accept or reject a recommendation manually, for example, in some implementations, as opposed to having recommendations be automatically applied, in other embodiments.

Some potential issues and problems to solve may be identified by way of example below. When a design goes through static verification (e.g., lint, CDC, RDC, and/or LP, among other options), one example workflow from testing to signoff may proceed as follows:

A user (engineer) may change a design of a hardware element in order to remedy an underlying issue causing any given violation(s), such as a bug fix. The user may fix a specific design issue identified by the violation, e.g., with respect to hardware description, register-transfer level (RTL) logic, and/or netlist representations, or by any other means for remedying an underlying design to address a violation.

Additionally, or alternatively, in some use cases, an issue triggering a violation may be addressed in meta-design data, such as by changing test or design specifications such as in Unified Power Format (UPF), such as per Institute of Electrical and Electronics Engineers (IEEE) Standard IEEE 1801, to name a non-limiting example. Other test attributes, such as constraints (C), settings (S), waivers (W), or other tool configurations, may also address violations without necessarily altering an underlying hardware design.

In some use cases, a user, program, or other entity may specify new or additional constraints in a given static-verification tool to address a given violation raised by that tool. A user may set and/or apply a set case_analysis parameter to specify at least one constraint in which a net is assumed constant (e.g., fixed at 0 or 1 for purposes of testing) at a particular design node, to name one example of C.

In some use cases, the user, program, or other entity may apply a tool setting or similar configuration option to tune or configure tests such as static analysis and/or verification based on a given design style. As an example of S, a user may apply a setting, e.g., set app_var handle hanging_crossover=true, to specify for a given test tool how to handle a hanging node in a given design, such as for tests running LP analysis with respect to any nodes without a load or a driver, for example.

In some use cases, a user, program, or other entity may apply waivers to violations, in order to disregard a particular violation or class of violations. This approach may not directly address an underlying design issue, but can make a given violation go away from a given test result, often at the discretion of a user or project manager for purposes of signoff.

While design practices may favor constraints or settings over waivers, tools may handle any of these test attributes (C, S, W) arbitrarily as instructed. However, conventional tools fail to handle propagation of such attributes across derivative design elements, such as those derived from hardware design elements reused across a design hierarchy, for example.

Changes to attributes such as C, S, and W, may go poorly managed by design teams manually, for example, and electronic design automation (EDA) tools may not propagate attributes usably to a subsequent version of the hardware design as part of design collateral (e.g., non-RTL representations or metadata) in many cases. This disconnect or shortcoming in conventional techniques may result in duplication of work, errors, and delays in signoff completion for hardware designs and related projects. The present systems and methods, among other embodiments disclosed herein, address these issues and provide solutions, according to some example embodiments.

FIG. 1illustrates saving of constraints, settings, and waivers for various design levels, according to some embodiments of the present disclosure. As shown, the depiction ofFIG. 1shows an example flow of saving attributes or actions performed on the design. Here, from the design's top level (top102), may be saved in a corresponding data store, database, or database entry (top database124) that may include constraints (C), settings (S), waivers (W), or any combination thereof, among other possible records or fields, for example. In an embodiment, C, S, and W used to run a test on top102may be saved in top database124, so that if top102or corresponding description may be used later in some other design, then C, S, and/or W from top database124may be reused as available for later tests of hardware-design elements similar to top102.

However, saving such test attributes or actions only at top design level may not be sufficient to achieve desired gains in efficiency. Even if the same design may not be reused as an exact copy in another instance or level of hierarchy, that parts of that same design may be reused in different structural or functional contexts, and in other levels of a design hierarchy, such as chiplet level or IP block level, in some use cases, in different parts of a given SoC design, for example.

Derived designs may involve changes such as replacing some IPs with newer version while other IPs may be left to remain the same as before, using one or more additional copies of the same IP (e.g., using multiple identical central processing unit (CPU) cores or deriving variations of the same CPU cores), using new IPs that may have different functionality or that add new functionality while other IPs remain the same, or employing a combination of the above, to name a few non-exhaustive and non-limiting example use cases.

Accordingly, the present techniques as disclosed herein include, by way of illustrative examples for description, show how test attributes or actions may be applied at an SoC level or full-chip level, and, as needed or desired for a given level of reliability and efficiency, propagate applicable actions to lower-level design elements in a design hierarchy (e.g., at a chiplet level, and at an IP level).

Propagation of Constraints

Propagation of constraints may also be considered as constraint characterization. A few non-limiting examples are provided below.

Using set case_analysis, a net or port may be marked as assume-constant and then propagated down to a lower level of design hierarchy. If a case-analysis constraint reaches an IP boundary, the constraint may also be saved in an IP database or data store, according to some embodiments.

Additionally, or alternatively, quasi_static CDC constraints may be specified at a top level of a design. If a given signal reaches an IP boundary without going through any multi-input gate, then the quasi_static CDC constraints may also be saved in an IP database as well, for example. Similarly, in some use cases, where a specified clock signal reaches an IP boundary, a corresponding clock constraint may be saved in an IP database, according to some embodiments.

Propagation of Settings or Other Configuration Options

Tool settings and configurations may be global in nature, in which case they may be applied within various levels of a design hierarchy. But in some cases, corresponding configuration options may be overridden for specified parts of hierarchy. In such cases, those special configuration overrides may be propagated to subordinate elements lower in the hierarchy, until any point at which the same setting or configuration option may be again overridden. Constraints, like settings or other configuration options, may be propagated in similar fashion.

A few non-exhaustive, non-limiting example configurations may be provided as follows: N-flip-flop synchronizer depth for CDC, control-sync qualifier for CDC (sequential depth down to which another CDC datapath can be propagated for synchronization), how to handle hanging nets for low-power analysis, whether to check for diode violations, whether memory blocks are to be considered separately for RDC analysis, etc.

Propagation of Waivers

Before, during, or after analysis, a user may wish to waive certain violations or classes thereof, thus applying at least one waiver. Reasons for waiving may vary, e.g., a specific design style not understood by the tool or otherwise mishandled by the tool, or the violations may be harmless in the given environment, etc. Subsequent runs of the same test for the same design then may not show these same violations, thus reducing an amount of “noise” (undesired or unhelpful violations) that may be reported to the user, according to some use cases.

Waivers may be applied in a context of a current SoC, or may be contained in a specific IP or specific branch of a design hierarchy at a level below a top design level, for example. At a top level, or within specific lower-level branches, waivers may also be propagated in similar fashion as with constraints, settings, and/or other configuration options as described elsewhere herein.

FIG. 2illustrates propagation of a waiver from a top level of a hierarchy to a lower level of the hierarchy, according to some embodiments of the present disclosure. While a waiver is shown in the particular example ofFIG. 2, other attributes (e.g., constraints, settings, or other configuration options) may be propagated in similar fashion as appropriate.

InFIG. 2, an example is shown as to how a waiver is applied in Top202, at a relative top level of a design hierarchy, where the waiver may be propagated or ported to lower-level IP blocks, in an embodiment. In the example shown, the waiver may operate on design elements completely contained inside IP1206, for example, including functional elements such as specific flip-flops F1208and F2210, and other arbitrary logic or gate arrays, e.g., G1212. While SoC-level test attributes may also be propagated to other elements, e.g., G2214and IP2216(including F3218), attributes specific to IP1206may not necessarily correspond to IP2216or F3218, for example.

As also shown inFIG. 2, clock signals at the SoC level may be traced back to a given IP level, e.g., to IP1206through a higher-level part1204within the same relative top level of the design hierarchy (Top202). By such signal traces, corresponding clocks may be identified in a given hardware design or description thereof. Thus, in a case where a waiver is propagated to the IP1level, the waiver may also be saved (by itself and/or as an action) in a corresponding IP1database, e.g., IP1database122or IP1database422, as shown inFIGS. 1 and 4, respectively, and may also be saved or ported to a corresponding part1database, analogous to blk1database120ofFIG. 1, corresponding to blk1104ofFIG. 1and part1204ofFIG. 2, for example.

As shown inFIG. 1, where other elements have respective corresponding databases as shown, e.g., top database124corresponding to top102, IP2database126corresponding to IP2114and IP2118, blk2128corresponding to blk2110;FIG. 4likewise shows additional databases corresponding to the additional classes of similar design elements, reused or otherwise. For example, newtop database424corresponds to newtop402, at least by virtue of having different design elements as components deeper in the contained design hierarchy.

Similarly, newblk1database440corresponds to newblk1404, which replaces blk1104ofFIG. 1(corresponding database blk1database420no longer applies to this design, as shown by the lack of arrows referencing blk1database420inFIG. 4). Other databases, e.g., IP1database422, IP2database426, and blk2database428ofFIG. 4likewise correspond to IP1database122, IP2database126, and blk2database128ofFIG. 1. The IP3database434newly corresponds to IP3432and IP3430(arrow not shown between IP3database434and IP3430where applicable, assuming no attributes or actions are overridden).

In some use cases, not all waivers may be ported to lower levels. For example, some waivers not fully contained inside a given hierarchy may not be ported to lower-level elements within related hierarchies. An example of this use case is shown inFIG. 3.

FIG. 3illustrates non-propagation of a waiver from a top level of a hierarchy to a lower level of the hierarchy, according to some embodiments of the present disclosure. In this non-limiting example embodiment, depicted is a waiver that spans two hierarchies. Because this waiver is contained only in one hierarchy, it is not necessarily propagated to lower-level elements within either hierarchy, according to this use case as shown.

While the waiver is different betweenFIG. 3andFIG. 2, the hardware-design elements are otherwise analogous, e.g., with Top302corresponding to Top202, part1304corresponding to part1204, IP1306corresponding to IP1206, IP2316corresponding to IP2216, and so on for F1308to F1208, F2310to F2210, G1312to G1212, G2314to G2214, and F3318to F3218. The similarities and differences betweenFIG. 3andFIG. 2thus serve to illustrate different propagation rules for different attributes, in some use cases.

For a given design hierarchy attributes and/or actions may be saved. Additionally, or alternatively, a signature may be derived or generated based at least in part on the content of the hierarchy, and saved alongside or in lieu of other representations of attributes or actions, according to some embodiments.

For some implementations, the signature may be computed using a hash function. For some database embodiments, the signature may serve as a key value to reference data corresponding to a given representation of an attribute and/or action.

In further embodiments, any attributes, actions, and/or signatures may be omitted from databases in which design modules are not reused or are otherwise marked as unlikely for reuse, e.g., by a user, program, or other entity.

A sub-design or sub-element may be instantiated multiple times, and propagated attributes or actions for corresponding instances may be accumulated or otherwise aggregated. For example, IP1is instantiated three times as shown by corresponding rectangles inFIG. 1(e.g., IP1106, IP1112, and IP1116), Propagated attributes or actions from these three instances are shown as being accumulated and recorded in a database of attributes or actions for IP1(IP1database122), as indicated by corresponding arrows inFIG. 1.

Priority of an attribute or action may be increased in accordance with more instances having a given attribute or action, for example. In a particular use case, if an attribute or action is applied to all instances of a given reused design element, then that attribute or action may be assigned highest priority relative to other attributes or actions.

In an example test workflow for ML-based static verification of hardware-design elements, a run of the testing tools may be started, e.g., by a user, program, or other entity, with respect to a new version of an existing design, where the new version includes derivative elements derived from (modifying some elements of) the original existing design.

Further, where actions may have been taken with respect to a previous design, certain parts of the new design may be identified that remain unchanged (or sufficiently similar, as may be determined with ML assistance) with respect to the previous design. For those identified parts, the same attributes or actions from a corresponding previous test may be retrieved from the database and/or recommended to be applied to the new design. Recommendations for actions or attributes may also be generated with ML assistance, as with other recommendation engines processing database entries for recommendation, for example.

FIG. 4illustrates depicts derived version of the design ofFIG. 1, with some modification, according to some embodiments of the present disclosure. The new design newtop402may be regarded as a modified version of the design top102shown inFIG. 1. Compared to design100ofFIG. 1, design400ofFIG. 4includes the following changes: blk1104ofFIG. 1is replaced by newblk1404, which contains IP3430instead of IP2108, while blk2110and IP2118are reused as-is (blk2410and IP2416), as shown inFIG. 4. An additional instance of IP2408is shown, as well as an additional instance of IP3432, in the top level (newtop402) not within other design-element blocks.

Using at least a saved or computed signature of a design element the design hierarchy, and machine learning, in some embodiments, reused or derived parts of a given design under test (DUT), etc., may be identified as being the same or sufficiently similar to elements of a previous design. For example, IP1, IP2, and blk2may be identified as having remained the same across design400ofFIG. 4and/or across a previous design, e.g., design100ofFIG. 1. Similarly, new design hierarchies that may exist in a derived version, e.g., IP3430,432, and newblk1404, may have attributes or actions propagated and saved in a similar manner, as described elsewhere herein. Any matching and propagation (e.g., as shown by broken-line arrows inFIG. 4) may further be assisted by machine learning, as also described elsewhere herein.

For the matched hierarchy, saved attributes or actions may be recommended. In some embodiments, attributes, actions, and/or recommendations may be sorted by priority, for example. For some use cases, attributes or actions may be applied when accepted or selected by a user (e.g., engineer, manager) presented with such recommendations in response to reporting of violations, in some embodiments. Moreover, recommended attributes or actions accepted by a user may be fed back to a corresponding database, and may further result in a corresponding priority value being incremented, for example.

FIG. 5is a flowchart illustrating a method500for operation of the ML-based techniques for static verification for derived hardware-design elements described herein, according to some embodiments. Method500may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

Method500shall be described with reference toFIGS. 5, 7, and 8. However, method500is not limited only to those example embodiments. The steps of method500may be performed by at least one computer processor coupled to at least one memory device. An example processor and memory device(s) are described below with respect toFIG. 8. In some embodiments, method500may be performed by components of systems shown inFIGS. 7 and 8, or any combination thereof, which may further include at least one processing device and memory such as those ofFIG. 8.

In502, memory804and at least one processor (e.g., processing device802) may be configured (e.g., by instructions826) to extract a feature set from a hardware description, according to some embodiments. As noted elsewhere herein, features may correspond to any parts of a design or description thereof, and may be represented as values in vectorized representations, such as may form a vectorized feature set, for example.

As also noted elsewhere herein, features of a hardware design or description may correspond to any number of wires, signals, ports, inputs/outputs, gates, etc.; or any relative or absolute configuration thereof, e.g., different logical ordering or connection. Such features may be evaluated (as per504) to determine correlation, such as for purposes of similarity indexing, among other use cases.

Moreover, in some embodiments, the feature set may be based at least in part on at least one attribute of the hardware description, wherein the at least one attribute corresponds to one or more hardware elements of the hardware description, and wherein the at least one attribute includes a configuration, a setting, a constraint, or a waiver of one or more violations of a specification for the static verification. At least one attribute of the first hardware element is propagated to at least one other hardware element in a hierarchy of hardware elements described in the hardware description and for which the similarity index is within the specified range, per some example use cases.

Additionally, for purposes of502, to extract a feature set, as described here, may include computing appropriate vector values, tensors, or other data, etc., based on an analysis of a hardware description, for example. In other embodiments, additionally, or alternatively, to extract a feature set may include retrieving the feature set from a data store, in whole or in part, where the feature set or relevant part thereof has been previously extracted by analysis of equivalent or similar hardware descriptions, for example.

In504, processing device802may be configured to evaluate, via a machine-learning process having input including the feature set, a similarity index of a first hardware element with respect to a second hardware element, where the first hardware element is described in the hardware description, according to some embodiments.

Algorithms for the evaluation of504may include ML processes for matching similar designs or descriptions thereof. Additional ML processes may include hashing algorithms to generate signatures of descriptions, such as of hardware elements, in whole or in part. For example, representations of input/output (I/O) ports, pins, wires, gates, etc., may be stored lexicographically, and signatures may be hashed numerical representations of these lexicographic representations, in some embodiments.

Additionally, or alternatively, signatures may themselves be unique lexicographic representations of hardware elements. Similarity detection may operate on the signatures and/or lexicographic representation, using algorithms suited for determining similarity, e.g., cross-correlation, peak similarity, root-mean-square measures, and/or ML techniques including similarity learning by regression, classification, ranking, or locality-sensitive hashing (LSH), fuzzy matching of attributes, descriptions, or signatures, etc., to name a few non-limiting examples.

Moreover, RTL image-creation techniques may be used in conjunction with image comparison to determine similarity between RTL images of DUT elements and known elements of original or reused designs from which derivative designs are derived, for example. Such comparisons may be performed hierarchically so that even if a full design is not similar, any parts of the design hierarchy that may be similar to other known design modules seen earlier may thus be detected as similar. A result may be an identification of a similar design element, within a specified threshold of a similarity index, which may be determined by any of the numeric, lexicographic, or other equivalent algorithms such as those described elsewhere herein.

The similarity index may be calculated, among other possible ways, from various transforms, comparisons, weighted averaging, etc., of features from the feature sets corresponding to any two or more hardware elements. In some embodiments, parts of hardware elements or corresponding descriptions (e.g., modules, submodules, functional descriptions, or other structural elements) may be compared, matched, classified, and/or evaluated across different hardware elements, for example.

Additionally, or alternatively, in some embodiments, a same design element may be identified by structural or functional equivalency checks, for example. Even if different instances of hardware description are not an exact match, such as with derived designs (e.g., derivative elements based on reused elements), there may be certain parts of a first description that match or resemble other parts present in a second description, for example. Such descriptions may vary in ways that may not significantly affect compiled output (e.g., comments, names of elements such as wires, signals, ports, inputs/outputs, gates, etc.).

In another sense, such descriptions may vary in ways that may result in relatively small variations of compiled output based on a derived design (e.g., different number of wires, signals, ports, inputs/outputs, gates, etc.; or a modified configuration thereof, e.g., different logical ordering or connection), while still maintaining some of the structure or function of an original design from which a derivative hardware element is derived.

A similarity index may increase based on a number (absolute or relative) of like features across multiple hardware elements or descriptions thereof. Like features may include features that are identical (equal or otherwise equivalent) in some respects, or that may be within a given range set as sufficient to establish similarity for a given value, feature, or preponderance of values or features. At least one similarity index may be applied to one or more parts of a given hardware element, collectively, to multiple parts as a whole, to specific hardware elements or descriptions thereof (absolute or relative within each description or element), or to any combination thereof.

In some embodiments, a similarity index may be calculated by deterministic logic, algebraic and/or relational operators, statistical analysis, or other such operations. Additionally, or alternatively, evaluation of any given similarity index may be enabled, facilitated, and/or enhanced by ML processing as described elsewhere herein.

In506, processing device802may be configured to update parameters corresponding to a static verification of the hardware description while the static verification is being performed, in response to determining that the similarity index is within a specified range. To update the parameters of the static verification, processing device802may transform, modify, or otherwise provide one or more specific test attributes or actions applicable to a given hardware element (e.g., SoC, chiplet, IP, or subelement), where the provided actions or attributes correspond to a different hardware element, for example, that has a similarity index within a predetermined range. Corresponding test attributes or actions may be applied automatically or upon selection of recommended attributes or actions, e.g., by a user. The range may be set in accordance with preferences of a user or end-user, system parameters, or other considerations on the part of the user, manager, partner, or other relevant third party, for example. Similarly, in some embodiments, the range may correspond with priority values for attributes, actions, or design elements, etc., as described elsewhere herein.

In some embodiments, the updating and corresponding transformation of506may apply to the same test types and algorithms for a given static verification, for example, modifying a selected set of test attributes corresponding a given hardware design element for the given static-verification test, while the given test is being performed, or between discrete phases of the given test, for example The transformation of506may be made using any logical or relational operator(s), for example, with respect to any endpoint or other value within the predetermined range. Other conditional operators may also be applied, depending on other parameters of interest. Additionally, or alternatively, machine-learning or other processes that may be the same as, equivalent to, or similar to those of the evaluation of504may further factor into, facilitate, or otherwise enhance the parameter updates of506and any constituent functions or transforms thereof, according to some embodiments.

In508, processing device802may be configured to output a first result of the static verification with respect to at least one hardware element described in the hardware description. Output may be in the form of a violation report, for example. Additionally, or alternatively, the output may accompany a recommendation of an attribute to be applied or an action to be taken with respect to a given hardware-design element under a given static-verification test, for example.

In an embodiment, a violation report or recommendation therein may include a notification that the first attribute of the first hardware element is similar to the second attribute of the second hardware element, a notification that the second result is returned as the first result with respect to the first hardware element, an option to modify the first hardware element, an option to substitute the first hardware element with the second hardware element, an option to run the check of the first hardware element with respect to the specification using the first attribute instead of the second attribute, an option to run the check of the first hardware element with respect to the specification using a third attribute, or a combination thereof. Additional options may be included in further embodiments; the examples listed herein are for illustrative purposes and are not specifically limiting.

Together, or separately, other configuration options, such as constraints, settings, or waivers, may be applied with respect to any element (e.g., any corresponding hardware description) for purposes of a given test (e.g., any variety of static verification procedures). Further examples of constraints, settings, waivers, or other configuration options, etc., may be included, and are described in further detail elsewhere herein.

Any or all of the above steps may be performed as part of embodiments as shown and described further above with respect toFIGS. 1-4 and/or 6-8, in some embodiments. Additionally or alternatively, any or all of the above steps may be performed as part of processing demonstrated inFIGS. 5 and/or 6, for example.

Not all steps of method500may be needed in all cases to perform the present techniques disclosed herein. Further, some steps of method500may be performed simultaneously, or in a different order from that shown inFIG. 5, as will be understood by a person of ordinary skill in the art.

FIG. 6is a flowchart illustrating a method600for operation of the ML-based techniques for static verification for derived hardware-design elements described herein, according to further embodiments in addition to those shown inFIG. 5with method500. Method600may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

Method600shall be described with reference toFIGS. 5-8. However, method600is not limited only to those example embodiments. The steps of method600may be performed by at least one computer processor coupled to at least one memory device. An example processor and memory device(s) are described below with respect toFIG. 8. In some embodiments, method600may be performed by components of systems shown inFIGS. 7 and 8, or any combination thereof, which may further include at least one processing device and memory such as those ofFIG. 8.

In602, memory804and at least one processor (e.g., processing device802) may be configured (e.g., by instructions826) to check at least one corresponding signature of at least one attribute of the at least one hardware element described in the hardware description with respect to the second hardware element, wherein the second hardware element corresponds to a known signature of at least one known attribute of at least one known hardware element referenced in a database or at least one other hardware element described in the hardware description, in some embodiments. Examples of such checking, including comparing, matching, recommending, and other options by ML-assisted processes, are described further elsewhere herein.

In604, processing device802may be further configured to omit, in response to602, from the extracting502, the evaluating504, or the static verification506, a given hardware element of the at least one hardware element the hardware description, according to some embodiments. A given signature of the given hardware element at least partially matches the known signature of the second hardware element, as described in further detail elsewhere herein.

Any or all of the above steps may be performed as part of embodiments as shown and described further above with respect toFIGS. 1-5 and/or 7-9, in some embodiments. Additionally or alternatively, any or all of the above steps may be performed as part of processing demonstrated inFIGS. 5 and/or 6, for example.

Not all steps of method500may be needed in all cases to perform the techniques disclosed herein. Further, some steps of method500may be performed simultaneously, or in a different order from that shown inFIG. 5, as will be understood by a person of ordinary skill in the art.

FIG. 7illustrates an example set of processes700used during the design, verification, and fabrication of an article of manufacture such as an integrated circuit to transform and verify design data and instructions that represent the integrated circuit. Each of these processes can be structured and enabled as multiple modules or operations. The term ‘EDA’ signifies the term ‘Electronic Design Automation.’ These processes start with the creation of a product idea710with information supplied by a designer, information which is transformed to create an article of manufacture that uses a set of EDA processes712. When the design is finalized, the design is taped-out734, which is when artwork (e.g., geometric patterns) for the integrated circuit is sent to a fabrication facility to manufacture the mask set, which is then used to manufacture the integrated circuit. After tape-out, a semiconductor die is fabricated 736 and packaging and assembly processes738are performed to produce the finished integrated circuit740.

During netlist verification720, the netlist is checked for compliance with timing constraints and for correspondence with the HDL code. During design planning722, an overall floor plan for the integrated circuit is constructed and analyzed for timing and top-level routing.

During analysis and extraction726, the circuit function is verified at the layout level, which permits refinement of the layout design. During physical verification728, the layout design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that circuitry function matches the HDL design specification. During resolution enhancement730, the geometry of the layout is transformed to improve how the circuit design is manufactured.

The computer system800may further include a network interface device808to communicate over the network820. The computer system800also may include a video display unit810(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device812(e.g., a keyboard), a cursor control device814(e.g., a mouse), a graphics processing unit822, a signal generation device816(e.g., a speaker), graphics processing unit822, video processing unit828, and audio processing unit832.

The data storage device818may include a machine-readable storage medium824(also known as a non-transitory computer-readable medium) on which is stored one or more sets of instructions826or software embodying any one or more of the methodologies or functions described herein. The instructions826may also reside, completely or at least partially, within the main memory804and/or within the processing device802during execution thereof by the computer system800, the main memory804and the processing device802also constituting machine-readable storage media.