Synopsys Inc v. Real Intent Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Synopsys, Inc. (Delaware)
  • Defendant: Real Intent, Inc. (California)
  • Plaintiff’s Counsel: Willkie Farr & Gallagher LLP
• Case Identification: 5:25-cv-10399, N.D. Cal., 12/04/2025
• Venue Allegations: Venue is alleged to be proper as Defendant is a California corporation with its principal place of business in Sunnyvale, California, within the Northern District of California.
• Core Dispute: Plaintiff alleges that Defendant’s electronic design automation (EDA) software products for static verification infringe six patents related to analyzing and verifying complex integrated circuit designs.
• Technical Context: The technology at issue involves EDA software, a critical component of the semiconductor industry used to detect design flaws in integrated circuits (e.g., Systems-on-a-Chip) before the costly manufacturing process begins.
• Key Procedural History: The complaint alleges Defendant had pre-suit knowledge of several patents-in-suit. Specifically, it alleges knowledge of U.S. Patent Nos. 9,792,394, 10,289,773, and 8,650,513 based on citations made by patent examiners during the prosecution of Defendant's own patent applications. The complaint also makes a broader allegation that Defendant has known of the patents-in-suit since at least 2018 after searching for and reviewing Plaintiff's patent portfolio. These allegations form the basis for claims of willful infringement.

Case Timeline

Date	Event
2010-09-20	Earliest Priority Date for U.S. Patent No. 8,650,513
2010-10-05	Earliest Priority Date for U.S. Patent No. 8,359,560
2011-03-09	Earliest Priority Date for U.S. Patent No. 8,607,173
2013-10-31	Earliest Priority Date for U.S. Patent No. 9,529,948
2013-12-10	U.S. Patent No. 8,607,173 Issued
2013-12-10	U.S. Patent No. 9,529,948 Issued
2014-02-11	U.S. Patent No. 8,650,513 Issued
2014-02-11	U.S. Patent No. 8,359,560 Issued
2015-08-21	Earliest Priority Date for U.S. Patent No. 9,792,394
2016-06-30	Earliest Priority Date for U.S. Patent No. 10,289,773
2016-09-15	Date Defendant allegedly became aware of the '’513 patent
2017-10-17	U.S. Patent No. 9,792,394 Issued
2019-05-14	U.S. Patent No. 10,289,773 Issued
2020-02-07	Date Defendant allegedly became aware of the '’394 patent
2020-04-03	Date Defendant allegedly became aware of the '’773 patent
2025-12-04	Complaint Filed

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,607,173 - Hierarchical Bottom-Up Clock Domain Crossing Verification

Issued December 10, 2013

The Invention Explained

• Problem Addressed: The patent's background describes the challenge of performing clock-domain crossing (CDC) verification on large, modern integrated circuits (ICs), also known as Systems-on-a-Chip (SoCs). As ICs grow in size and complexity, running verification on the entire design becomes excessively time-consuming and can produce incomplete results due to the inability to fully analyze pre-designed intellectual property (IP) blocks ('’173 Patent, col. 1:17-56; Compl. ¶25).
• The Patented Solution: The invention provides a hierarchical, "bottom-up" verification method. Instead of analyzing the entire IC at once, the method first verifies individual, lower-level modules. Once a module successfully passes verification, it is replaced by a simplified "abstraction module" that retains essential information, such as the clock domains for its inputs and outputs. This process is repeated for progressively higher-level modules, using the abstracted models of the lower-level components to streamline the analysis ('173 Patent, col. 1:63-2:9; Compl. ¶25). This hierarchical process is illustrated in Figure 1 of the patent, where module M4 is verified before M2, and M2 is verified before M1 ('173 Patent, col. 3:36-57; Compl. ¶26).
• Technical Importance: This approach significantly reduces the time and computational resources required for CDC verification of complex SoCs by decomposing a large problem into a series of smaller, more manageable verification tasks (Compl. ¶28).

Key Claims at a Glance

• The complaint asserts independent claim 1 (Compl. ¶69).
• Essential elements of claim 1 include:
  • identifying a module from among a plurality of modules that has not been previously abstracted or changed;
  • performing a CDC verification on the module in a bottom-up fashion by a computer processor device;
  • replacing the module with a corresponding abstraction module that correctly identifies a corresponding clock-domain for each of the input and the output, in response to the module successfully passing verification;
  • repeating the identifying, performing, and replacing for each of the remaining modules; and
  • storing an updated model of the IC comprising at least a replaced module in storage.
• The complaint does not explicitly reserve the right to assert dependent claims for this patent.

U.S. Patent No. 9,792,394 - Accurate Glitch Detection

Issued October 17, 2017

The Invention Explained

• Problem Addressed: The patent addresses the problem of "glitches," which are unintended, transient signal changes in a circuit that can cause malfunctions, particularly when signals cross between different clock domains ('394 Patent, col. 1:28-32; Compl. ¶31). The patent notes that while glitch-blocking circuits exist, conventional detection tools often produce a large number of false positives because it is difficult to determine the correspondence between the high-level design (e.g., Register-Transfer Level or RTL) where blocking circuits are easily identified, and the low-level synthesized design (e.g., a netlist) where glitches actually manifest ('394 Patent, col. 5:47-54, col. 6:8-15; Compl. ¶35).
• The Patented Solution: The invention proposes a method that analyzes the circuit at two levels of abstraction. First, it analyzes the higher-level abstraction (RTL) to identify glitch-blocking circuits, their corresponding enable signals, and the "blocking value" that should prevent a glitch. It then analyzes the lower-level abstraction (netlist) to determine if a potential glitch is not blocked when that enable signal is assigned its blocking value. If the glitch still propagates, the method identifies it as a design problem ('394 Patent, col. 1:67-2:4; Compl. ¶36). The patent's Figure 3 illustrates this flow, showing analysis of a "Higher-level abstraction" feeding into "Accurate glitch detection" which also considers the "Lower-level abstraction" ('394 Patent, Fig. 3; Compl. ¶39).
• Technical Importance: This two-level approach aims to improve the accuracy of glitch detection by reducing false positives, allowing designers to focus on genuine design flaws early in the development cycle before they become costly to fix (Compl. ¶41).

Key Claims at a Glance

• The complaint asserts independent claim 1 (Compl. ¶93).
• Essential elements of claim 1 include:
  • analyzing a higher-level abstraction of the circuit design to identify (1) a set of glitch-blocking circuits, and (2) for each circuit, an enable signal and a blocking value;
  • analyzing a lower-level abstraction of the circuit design to identify a possible glitch in a first signal;
  • identifying a first enable signal in the lower-level abstraction that corresponds to a glitch-blocking circuit that is supposed to block glitches in the first signal; and
  • detecting a design problem in response to determining that the possible glitch is not blocked when the first enable signal is assigned a first blocking value.
• The complaint does not explicitly reserve the right to assert dependent claims for this patent.

U.S. Patent No. 8,650,513 - Reducing X-Pessimism in Gate-Level Simulation and Verification

Issued February 11, 2014

• Technology Synopsis: The patent addresses "X-pessimism," a phenomenon in circuit simulation where indeterminate "X" values propagate more pessimistically than they would in actual silicon, particularly in designs with reconvergent paths. The patented solution involves analyzing a design to identify inputs likely to cause X-pessimism and, if found, adding a "correcting block" to the design that produces the deterministic value the actual circuit would have produced (Compl. ¶¶43, 45-46).
• Asserted Claims: Independent claim 1 is asserted (Compl. ¶119).
• Accused Features: The complaint accuses products including Ascent XV, Meridian RXV, Verix SimFix, SimPortal, and others of infringing by implementing features that "eliminate unnecessary X's caused by X-pessimism" and use static analysis to identify and "fix X-pessimism when it occurs" (Compl. ¶¶120, 122, 124).

U.S. Patent No. 8,359,560 - Hierarchical Bottom-Up Clock Domain Crossing Verification

Issued February 11, 2014

• Technology Synopsis: The patent discloses a method for synchronously debugging an IC design at two different levels (e.g., RTL and gate-level) simultaneously. The method uses at least two debugging processes, each with its own set of windows. When a user selects a signal in one window corresponding to one design level, a corresponding signal in a window for the other design level is automatically selected, reducing debugging time ('’560 Patent, col. 1:30-39; Compl. ¶¶50-51).
• Asserted Claims: Independent claim 1 is asserted (Compl. ¶139).
• Accused Features: The accused products iDebug and SafeConnect are alleged to infringe by providing an integrated debugging environment that operates on both RTL and Netlist levels, correlating information between the two, and allowing a user to select a signal at one level and have it queried at the other (Compl. ¶¶140, 143-146).

U.S. Patent No. 10,289,773 - Reset Domain Crossing Management Using Unified Power Format

Issued May 14, 2019

• Technology Synopsis: The patent presents a method for optimizing IC designs by managing both Reset Domain Crossings (RDCs) and Power Domain Crossings (PDCs) together. Traditionally handled separately, the invention recognizes that signals can cross both domain types, creating an opportunity to use a single, shared isolation circuit. The method analyzes both Hardware Description Language (HDL) and Unified Power Format (UPF) descriptions to identify signals that form both an RDC and a PDC, flagging them as candidates for shared isolation to reduce circuit size and signal delays ('773 Patent, col. 2:18-39; Compl. ¶¶55, 58).
• Asserted Claims: Independent claim 1 is asserted (Compl. ¶164).
• Accused Features: The accused products Meridian RDC and SafeConnect are alleged to infringe by incorporating "power related resets" in their RDC verification, using information from UPF files to identify signals that form both RDCs and PDCs, and generating reports on candidates for shared isolation structures (Compl. ¶¶165, 166, 169).

U.S. Patent No. 9,529,948 - Minimizing Crossover Paths for Functional Verification of a Circuit Description

Issued December 10, 2013

• Technology Synopsis: The patent introduces a method to optimize functional verification by reducing the number of "crossover paths" (signal paths between different power domains) that require analysis. Instead of analyzing all possible paths, the method leverages low-power information from a power design description (e.g., a UPF file) to determine the valid power state combinations. It then generates a reduced, functional subset of crossover paths for verification, making the process faster and more efficient ('’948 Patent, col. 1:46-52, col. 2:53-59; Compl. ¶¶62-63).
• Asserted Claims: Independent claim 1 is asserted (Compl. ¶185).
• Accused Features: The accused products Meridian CDC, Meridian RDC, and SafeConnect are alleged to perform functional verification by generating a set of crossover paths and then using a power design description (UPF format) to determine a smaller, functional subset of those paths for evaluation (Compl. ¶¶186, 190, 194, 196).

III. The Accused Instrumentality

Product Identification

The accused instrumentalities are a suite of EDA software tools sold by Defendant Real Intent, including at least Meridian CDC, Meridian RDC, SafeConnect, Ascent XV, Meridian RXV, Verix SimFix, SimPortal, Ascent AutoFormal, Sentry, and iDebug (including iVision) (Compl. ¶¶70, 94, 120, 140, 165, 186).

Functionality and Market Context

The accused products are software tools used for static verification of digital IC designs, a process that examines a circuit's internal structure to find design errors before manufacturing (Compl. ¶¶5, 7). Specific functionalities alleged to infringe include hierarchical clock-domain crossing (CDC) verification, multi-level glitch detection, reset-domain crossing (RDC) management using power-domain information, and X-pessimism reduction (Compl. ¶¶71, 95, 122, 166). The complaint positions Defendant as a direct competitor to Plaintiff in the EDA static verification market (Compl. ¶8).

IV. Analysis of Infringement Allegations

U.S. Patent No. 8,607,173 Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
identifying a module from among the plurality of modules that has not been previously abstracted or that has not changed...	Meridian CDC operates using a "hierarchical flow" that allows users to perform verification on individual blocks.	¶72	col. 1:63-67
performing a CDC verification on the module in a bottom-up fashion by a computer processor device;	The Meridian CDC product is advertised as enabling "bottom-up... CDC analysis," where an individual IP or block is verified first.	¶¶73, 76	col. 1:67-68
replacing the module with a corresponding abstraction module that correctly identifies a corresponding clock-domain for each of the input and the output...	Meridian CDC creates a "meta-database" that stores the CDC information from block-level analyses, which functions as an abstraction module.	¶74	col. 2:1-5
repeating the identifying, performing, and replacing for each of the remaining modules from among the plurality of modules; and	The product's "Three-Step CDC Sign-off Methodology" is an iterative process where the meta-database from one level is used for sign-off of the next level.	¶76	col. 2:5-7
storing an updated model of the IC comprising at least a replaced module in storage.	Meridian CDC creates a "transparent model database" for hierarchical analysis, which comprises the abstraction models created during verification.	¶¶77-78	col. 2:7-9

• Visual Evidence Referenced: The complaint includes a slide titled "Suggested Hierarchical CDC Flow," which depicts a multi-step process using a "CDC meta-database" to store and reuse verification results from lower-level IP blocks for higher-level integration (Compl. ¶73, p. 23). Another slide, "CDC Meta-Database(1/2)," illustrates the type of information stored in the abstraction model, including clock tree attributes and synchronizer connectivity (Compl. ¶75, p. 24).
• Identified Points of Contention:
  • Scope Questions: A central question may be whether the accused "meta-database" qualifies as an "abstraction module" that "replaces" the verified module as required by the claim. The defense may argue that storing verification results in a database is technically distinct from creating a replacement model used in subsequent verification runs.
  • Technical Questions: The complaint alleges the accused product performs verification in a "bottom-up fashion," but also cites materials stating the flow enables "bottom-up or top-down CDC analysis" (Compl. ¶73). The defense may focus on the availability of a top-down method to argue that the accused product does not meet the "bottom-up" limitation.

U.S. Patent No. 9,792,394 Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
analyzing a higher-level abstraction... to identify (1) a set of glitch-blocking circuits, and (2) for each... an enable signal and a blocking value...	The accused products analyze the higher-level "Block" or "RTL" abstraction to identify glitch-blocking circuits and detect "synchronized CNTL signal(s) blocking or controlling DATA signals."	¶¶98, 100	col. 6:42-44
analyzing a lower-level abstraction... to identify a possible glitch in a first signal... wherein the lower-level abstraction... is generated from the higher-level...	The accused products perform glitch detection at the "Gate-Level Netlist" (the lower-level abstraction), which is generated from the RTL design via synthesis.	¶¶98, 103	col. 6:44-50
identifying a first enable signal in the lower-level abstraction... that corresponds to a glitch-blocking circuit that is supposed to block glitches in the first signal;	The products are alleged to identify corresponding circuitry and signals between the higher-level (RTL) and lower-level (Netlist) abstractions to perform glitch detection.	¶104	col. 6:51-57
detecting a design problem in... response to determining that the possible glitch... is not blocked when the first enable signal is assigned a first blocking value...	The accused products perform a "Glitch Sign-off" function which includes detecting design problems related to "glitch propagation."	¶105	col. 6:63-7:2

• Visual Evidence Referenced: The complaint reproduces a "Glitch Sign-off Flow" diagram from a Real Intent presentation, which explicitly shows two parallel flows for glitch analysis: one for "Meridian CDC" using RTL input and another for "SafeConnect" using Netlist input (Compl. ¶95, p. 29). A slide titled "RTL and Netlist Glitch Verification" further illustrates the concept, showing a design at the "RTL" level being transformed via "Synthesis/Optimization" into a "NETLIST" where a glitch (marked with an 'X') might appear (Compl. ¶102, p. 32).
• Identified Points of Contention:
  • Scope Questions: Does the accused products' analysis of "synchronized CNTL signal(s)" (Compl. ¶100) meet the specific claim requirement of identifying a "glitch-blocking circuit," an "enable signal," and a "blocking value"? The defense may argue their analysis is for a different purpose or does not map to these specific claim terms.
  • Technical Questions: What evidence does the complaint provide that the accused product performs the final step of "determining that the possible glitch... is not blocked when the first enable signal is assigned a first blocking value"? This requires a specific conditional analysis, and the functionality of the accused product in this regard will be a key factual dispute.

V. Key Claim Terms for Construction

For the ’173 Patent:

• The Term: "abstraction module"
• Context and Importance: This term is the core of the invention. The infringement case rests on the theory that the Defendant's "meta-database" (Compl. ¶74) is an embodiment of the claimed "abstraction module." The construction of this term will determine whether a data repository containing verification results is equivalent to a model that "replaces" a circuit block in a subsequent verification step.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent claims an abstraction module "that correctly identifies a corresponding clock-domain for each of the input and the output" ('173 Patent, cl. 1). This language focuses on the information the module contains, which could support a construction that includes a database of properties.
  • Evidence for a Narrower Interpretation: The claim requires "replacing the module with a corresponding abstraction module," and the specification's flowchart shows a step to "Run CDC verification replacing model with its abstract" ('173 Patent, cl. 1; Fig. 6, S645). This may support a narrower construction requiring the "abstraction module" to be a functional, model-based replacement used directly in a subsequent verification run, not merely a static data file.

For the ’394 Patent:

• The Term: "blocking value"
• Context and Importance: The final, dispositive step of the asserted claim is detecting a problem when a glitch is not blocked when an enable signal is assigned a "blocking value." The definition of this term is critical to determining if the accused products perform this specific conditional analysis.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification provides an example where the blocking value is a logic state, such as 0 or 1 ('394 Patent, col. 6:63-65). This could support a broad interpretation where any logic value assigned to an enable signal with the intent to block a signal path qualifies as a "blocking value."
  • Evidence for a Narrower Interpretation: The claim states the blocking value "is supposed to cause the glitch-blocking circuit to block glitches" ('394 Patent, cl. 1). Practitioners may focus on this term because the defense could argue it requires a specific, demonstrable property of the value within the circuit's logic, rather than just any value applied to a control signal that happens to gate a path.

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement to infringe for all six patents-in-suit. The allegations are based on Defendant supplying the accused software products to its customers and providing instructions, documentation, and technical support (e.g., through application engineers) that allegedly direct and encourage customers to use the products in an infringing manner (Compl. ¶¶85, 111, 131, 156, 177, 203).
• Willful Infringement: Willfulness is alleged for all six patents. The allegations are predicated on alleged pre-suit knowledge. For the ’394, ’773, and ’513 patents, the complaint alleges specific dates of knowledge based on citations to these patents by the USPTO during the prosecution of Defendant's own patent applications (Compl. ¶19). For all patents, the complaint makes a general allegation of knowledge since at least 2018, purportedly from when Defendant searched for and reviewed Plaintiff's patent portfolio (Compl. ¶20). The complaint also pleads willful blindness, suggesting Defendant deliberately avoided confirming its infringement (Compl. ¶¶86, 112).

VII. Analyst’s Conclusion: Key Questions for the Case

• Definitional Scope: A core issue will be whether the Defendant's "CDC meta-database," a data repository of verification results, can be construed to be the claimed "abstraction module" that "replaces" a verified circuit block in a hierarchical verification flow. The case for the ’173 patent may turn on whether this term requires a functional, simulatable model or if a database of properties suffices.
• Functional Operation: A key evidentiary question will be one of functional operation: do the accused products perform the specific, multi-step analysis required by the ’394 patent? This will likely focus on whether the software specifically identifies a "blocking value" at a high level of abstraction and then confirms at a lower level that a glitch is not blocked when that specific value is applied.
• Knowledge and Intent: The claims for enhanced damages will depend on Plaintiff's ability to prove pre-suit knowledge. The allegations based on patent examiner citations during Defendant's own prosecution provide specific factual anchors that will be central to the willfulness dispute, raising the question of whether such citations are sufficient to establish knowledge of infringement.