Synopsys, Inc. v. Real Intent, Inc.

• Court: District Court, N.D. California
• Decided: April 21, 2023
• Docket: 5:20-cv-02819
• Status: Unknown

Opinion

1 2 3 4 UNITED STATES DISTRICT COURT 5 NORTHERN DISTRICT OF CALIFORNIA 6 SAN JOSE DIVISION 7 8 SYNOPSYS, INC., Case No. 5:20-cv-02819-EJD

9 Plaintiff, CLAIM CONSTRUCTION ORDER

v. 10

11 REAL INTENT, INC., Defendant. 12

13 Plaintiff Synopsys, Inc. (“Synopsys”) brings this suit against Defendant Real Intent, Inc. 14 (“Real Intent”) for infringement of U.S. Patent No. 9,721,057, entitled “System and Method for 15 Netlist Clock Domain Crossing Verification” (the “ ’057 Patent”).1 The parties dispute the proper 16 construction of eight terms. See Opening Claim Construction Br. of Pl. Synopsys, Inc. (“Synopsys 17 Br.”), ECF No. 48; Real Intent, Inc.’s Responsive Claim Construction Br. (“Real Intent Br.”), ECF 18 No. 52-4; Reply Claim Construction Br. of Pl. Synopsys, Inc. (“Synopsys Reply Br.”), ECF No. 19 61. Upon consideration of the claims, specification, prosecution history, and other relevant 20 evidence, and after hearing the arguments of the parties, the Court construes the contested 21 language of the patent-in-suit as set forth below. 22 I. BACKGROUND 23 Synopsys is a leader in the electronic design automation and semiconductor intellectual 24 property industry. Second Am. Compl., ECF No. 145 ¶ 1. It develops, manufactures, sells, and 25 licenses products and services that enable designers to create, model, and verify complex 26

27 1 Synopsys also alleges that Real Intent improperly copied Synopsys’s copyrighted expression and 1 integrated circuit designs from concept to silicon. Id. The ’057 Patent, which Synopsys holds by 2 assignment, generally relates to a particular type of circuit verification called clock domain 3 crossing (“CDC”) verification. In modern computer chip designs, a single chip often contains 4 circuits that operate at different clock speeds. ’057 Patent at 1:21–27. When signals from one part 5 of the chip are transmitted to another part of the chip that is running at a different clock speed, 6 there may be errors that lead to chip failure if the signals aren’t “synchronized.” Id. at 1:27–34. 7 CDC verification is the step in the design process where engineers identify and correct those errors 8 and has become an essential part of chip design flows. Id. at 1:34-36. At this step, engineers 9 conduct “[a]nalysis and verification of asynchronous interfaces for correct synchronization 10 mechanisms.” Id. at 1:30-32. 11 CDC verification occurs at multiple stages of the design process. One stage is at the 12 Register Transfer Level (“RTL”). Id. at 2:5-7. At this level, engineers use RTL code to define the 13 functional behavior of a circuit. Expert Rpt. of Dr. Baris Taskin re Claim Construction (“Taskin 14 Rpt.”), ECF No. 48-3 ¶ 13. “Electronic chip designers check for CDC problems by running CDC 15 checks while they develop the register-transfer-level (RTL) design.” ’057 Patent at 2:5-7. After 16 the RTL design stage, designers proceed to the netlist design stage. Id. at 2:17-19. At the netlist 17 design stage, the RTL code is translated into a “gate-level description of the circuit design through 18 a process called logical synthesis.” Taskin Rpt. ¶ 14. “Logical synthesis is typically performed by 19 a logical synthesis tool, which is sometimes also referred to as an RTL compiler.” Id. “The 20 resulting gate-level description is called a gate-level netlist or netlist for short.” Id. The netlist 21 “specifies individual logic gates . . . as well as the connections between the gates.” Id. 22 CDC checks are also conducted at the netlist design stage. ’057 Patent at 2:13-17. 23 According to the ’057 Patent, prior methods of CDC verification at the netlist design level were 24 difficult and time consuming. Id. at 2:23-39. One reason for this was because the netlist had 25 different net names than the RTL design, and the designer had to formulate new CDC constraints 26 that refer to the new net names in the netlist. Id. at 2:25-28. The ’057 Patent described other 27 reasons why the CDC verification at the netlist design stage was burdensome: 1 Well-defined structures like multiplexors used to select between clocks may be difficult to identify in the netlist. Due to the application 2 of CDC at different hierarchy levels in RTL and netlist, the constraints at RTL blocks may not be mapped independently of each other in the 3 netlist. For example, clock constraints corresponding to two different RTL blocks may correspond to fanouts of the same clock at a higher 4 hierarchy level. Thus, the netlist may have additional clock domain crossings not present in the RTL, may have clock domain crossings 5 that don’t map to RTL, and may have crossings that have become unsynchronized. 6 7 Id. at 2:28-39. The ’057 Patent was intended to introduce an automated approach to make CDC 8 verification at the netlist level quick and easy. Id. at 2:40-41. In this automated approach, the 9 netlist-level CDC constraints are created from the RTL-level CDC constraints. Taskin Rpt. ¶ 17. 10 The ’057 Patent calls this automated process “migration.” Id. In the Summary Disclosure, the 11 ’057 Patent claims “[a] system and method for netlist clock domain crossing (NCDC) verification 12 [that] leverages the corresponding RTL clock domain crossing (CDC) verification data and results 13 by migrating RTL-level constraints and waivers to the netlist design so that the user does not have 14 to re-enter them.” ’057 Patent at 2:45-49. 15 After the netlist has been verified, “the components in the gate-level description of the 16 circuit design are physically assigned a location on the chip and the wires in the gate-level 17 description are routed.” Taskin Rpt. ¶ 19. This process generates a layout of the circuit, which is 18 then used to manufacture the circuit. Id. 19 II. LEGAL STANDARDS 20 Claim construction is a question of law to be decided by the court. Markman v. Westview 21 Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc), aff’d, 517 U.S. 370 (1996). “[T]he 22 interpretation to be given a term can only be determined and confirmed with a full understanding 23 of what the inventors actually invented and intended to envelop with the claim.” Phillips v. AWH 24 Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (citation omitted). Consequently, courts construe 25 claims in the manner that “most naturally aligns with the patent's description of the invention.” Id. 26 (citation omitted). 27 In construing disputed terms, a court looks first to the claims themselves, for “[i]t is a 1 patentee is entitled the right to exclude.” Id. at 1312 (citation and internal quotation marks 2 omitted). Generally, the words of a claim should be given their “ordinary and customary 3 meaning,” which is “the meaning that the term would have to a person of ordinary skill in the art 4 in question at the time of the invention.” Id. at 1312-13 (citations omitted). In some instances, the 5 ordinary meaning to a person of skill in the art is clear, and claim construction may involve “little 6 more than the application of the widely accepted meaning of commonly understood words.” Id. at 7 1314. 8 In many cases, however, the meaning of a term to a person skilled in the art will not be 9 readily apparent, and a court must look to other sources to determine the term’s meaning. Id. 10 Under these circumstances, a court should consider the context in which the term is used in an 11 asserted claim or in related claims, bearing in mind that “the person of ordinary skill in the art is 12 deemed to read the claim term not only in the context of the particular claim in which the disputed 13 term appears, but in the context of the entire patent, including the specification.” Id. at 1313. 14 Indeed, the specification is “always highly relevant” and “[u]sually, it is dispositive; it is the single 15 best guide to the meaning of a disputed term.” Id. at 1315 (quoting Vitronics Corp. v. 16 Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). The court may also consider the 17 patent’s prosecution history, which consists of the complete record of proceedings before the 18 United States Patent and Trademark Office and includes cited prior art references. Id. at 1317. 19 Finally, the court is also authorized to consider extrinsic evidence in construing claims, 20 such as “expert and inventor testimony, dictionaries, and learned treatises.” Markman, 52 F.3d at 21 980 (internal citations omitted). Although the court may consider evidence extrinsic to the patent 22 and prosecution history, such evidence is considered “less significant than the intrinsic record” and 23 “less reliable than the patent and its prosecution history in determining how to read claim terms.” 24 Phillips, 415 F.3d at 1317-18 (citation omitted). Thus, while extrinsic evidence may be useful in 25 claim construction, ultimately “it is unlikely to result in a reliable interpretation of patent claim 26 scope unless considered in the context of the intrinsic evidence.” Id. at 1319. 27 // 1 III. REQUEST TO STRIKE DR. TASKIN’S REPORT AND DECLARATION 2 Real Intent asks the Court to strike the Expert Report of Dr. Baris Taskin, dated February 3 8, 2021, as well as Dr. Taskin’s three-page declaration filed in support of Synopsys’s Opening 4 Claim Construction Brief on March 17, 2021. See ECF Nos. 48-3, 48-4. Real Intent contends that 5 the declaration is a tardy “supplemental” expert report because it was not filed within 60 days after 6 service of Real Intent’s Invalidity Contentions as required by Patent Local Rule 4-3 and Federal 7 Rule of Civil Procedure 26(a)(2)(B). Real Intent Br. at 4-6. Further, Real Intent contends that Dr. 8 Taskin’s opinions are unreliable because he essentially adopted the constructions prepared by 9 Synopsys’s attorneys and failed to consider extrinsic evidence. Id. at 6-7. 10 The request to strike is denied. It is undisputed that Dr. Taskin’s original report was timely 11 and that Real Intent deposed Dr. Taskin prior to the claim construction hearing. Pursuant to Patent 12 Local Rule 4-5(a), parties are permitted to file supporting evidence with their claim construction 13 briefs. See Patent L.R. 4-5(a) (“[Plaintiff] shall serve and file an opening brief and any evidence 14 supporting its claim construction.”). Dr. Taskin’s declaration is such supporting evidence. 15 Arguably, the substance of Dr. Taskin’s declaration should have been incorporated into a 16 supplemental expert report and disclosed in accordance with Rule 26(a)(2)(B). See Patent L.R. 17 4-3 (“[Expert] reports shall comply with the disclosure requirements of Fed. R. Civ. P. 18 26(A)(2)(B)”). Nevertheless, because the five-paragraph declaration is relatively short and simply 19 summarizes portions of Dr. Taskin’s deposition, Real Intent cannot credibly claim it suffered any 20 harm. Absent a showing of prejudice, the purported untimeliness does not justify striking Dr. 21 Taskin’s declaration. See Symantec Corp. v. Zscaler, Inc., No. 17-cv-04426-JST, 2018 WL 22 6270954, at *1 (N.D. Cal. Nov. 30, 2018) (declining to strike expert declaration for lack of harm 23 where expert was disclosed in joint claim construction statement and moving party deposed 24 expert). Nor do Synopsys’s various challenges to the substance of Dr. Taskin’s report justify 25 exclusion. Synopsys does not challenge Dr. Taskin’s report under the standards articulated in 26 Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993). Instead, Synopsys’s 27 challenges go to the weight and not to the admissibility of Dr. Taskin’s report. 1 IV. CONSTRUCTION OF DISPUTED TERMS 2 A. Clock domain crossing (CDC) / CDC (Claims 1, 2, 4, 6-8, 10-12, 15, 17-18)

3 Synopsys Proposal Real Intent Proposal Court’s Construction 4 signal from a first clock the sending and receiving of the sending and receiving of domain that is sampled in a signals between at least two signals between at least two 5 second clock domain, where sections of a circuit design sections of a circuit design the clocks have a variable driven by different clocks driven by different clocks 6 phase relationship with one another 7 8 The parties agree that a clock domain crossing occurs when signals in a circuit cross from 9 one clock domain to another clock domain. According to Synopsys, the parties dispute what 10 constitutes a clock domain. Synopsys contends that multiple clocks can be in the same clock 11 domain so long as those clocks have a “fixed phase relationship,” whereas Real Intent’s proposed 12 construction assigns each different clock to its own clock domain. Synopsys Br. at 4. Real Intent 13 frames the dispute differently. Real Intent contends that the difference between the two parties’ 14 constructions rests on “whether clock domains can have a deterministic relationship to one 15 another, as Real Intent proposed, or whether clock domain crossings must necessarily involve 16 asynchronous clock domains, as Synopsys proposes.” Real Intent Br. at 18. 17 The intrinsic evidence supports Real Intent’s proposed construction. The specification 18 states that “[t]he NCDC identifies all clock domain crossings, determines if they are synchronous 19 or asynchronous and applies a number of CDC checks,” unambiguously indicating that clock 20 domain crossings may be either synchronous or asynchronous. ’057 Patent at 7:18-20 (emphasis 21 added). The ’057 Patent also refers to “asynchronous clock domain crossings” in both the 22 specification and the claims. See e.g., id. at 3:23-24 (“Next, the processor checks the received 23 netlist for asynchronous clock domain crossings . . . .”); 7:41–44 (“Normal CDC checking would 24 indicate an asynchronous clock domain crossing as unsynchronized due to the presence of lock-up 25 latch 340.”); 9:6-7 (Claim 1); 9:65-66 (Claim 8); 10:30-31 (Claim 10). The use of the modifier 26 “asynchronous,” particularly in the context of the claims, is highly instructive. Philips, 415 F.3d 27 at 1314. In an analogous situation, the Federal Circuit explained that reference to “‘steel baffles’ 1 Likewise, the fact that the claims include “asynchronous” before “clock domain crossings” 2 strongly implies that the term “clock domain crossings” does not inherently mean all clock domain 3 crossings involve asynchronous clock domains. If all clock domain crossings were asynchronous, 4 there would be no need to use “asynchronous” in the claims to describe the clock domain 5 crossings. 6 Cited prior art references in the ’057 Patent additionally weigh in favor of Real Intent’s 7 proposed construction. Specifically, the ‘057 Patent cites to U.S. Patent No. 7,412,678. Decl. of 8 Kristin Hucek (“Hucek Decl.”), ECF No. 53-1, Ex. O (“ ’678 Patent”). In turn, the ’678 Patent 9 regularly distinguishes between synchronous and asynchronous clock domain crossings. For 10 example, the ’678 Patent is titled, “Method and Computer Program for Management of 11 Synchronous and Asynchronous Clock Domain Crossing in Integrated Circuit Design.” Id. 12 (emphasis added). It also describes its invention as “a computer program product for managing 13 synchronous and asynchronous clock domain crossings,” and Claim 9 of the ’678 Patent reads in 14 pertinent part, “A computer readable storage medium tangibly embodying program instructions 15 that when executed by a computer implement a method of managing synchronous and 16 asynchronous clock domain crossings.” Id. at 1:40-42, 6:3-6 (emphasis added). All this suggests 17 that, when the phrase “clock domain crossings” is not preceded by a modifier, the phrase 18 encompasses both synchronous and asynchronous clock domain crossings. Further contrary to 19 Synopsys’s argument that different clock domains must be asynchronous, the ’678 Patent provides 20 that its invention functions by “identifying paths between synchronous clock domains and paths 21 between asynchronous clock domains,” signaling that clock domains may have either a 22 synchronous or asynchronous relationship. Id. at 1:47-48 (emphasis added). 23 Synopsys’s supporting intrinsic evidence consists of a single sentence from the 24 specification stating that a “CDC-based design” is “a design that has one clock asynchronous to, 25 or has a variable phase relation with, another clock.” ’057 Patent at 1:37-39. This sentence makes 26 the point that CDC-based designs involve at least some clocks that are asynchronous to one 27 another. But it does not follow that the definition of “clock domain crossing” is limited to the 1 presence of asynchronous relationships necessitates CDC verification; signals sent between 2 synchronous clocks may not require verification, but they can still be clock domain crossings. 3 Therefore, this single sentence does not contradict Real Intent’s proposed construction. 4 The extrinsic evidence also supports Real Intent’s proposed construction. An article from 5 Atrenta, an early pioneer in clock domain crossing verification, explains that a clock domain 6 crossing occurs whenever data is transferred from a flop driven by one clock to a flop driven by 7 another clock, without requiring the clocks to have an asynchronous relationship. See Hucek 8 Decl., Ex. E at 1. The Atrenta article goes on to canvas different types of clock domain crossings, 9 including both synchronous clock domain crossings and asynchronous clock domain crossings. It 10 describes a synchronous clock domain crossing as one between synchronous clocks, or in other 11 words, between clocks with a known phase and frequency relationship. Id. at 3. By contrast, it 12 defines asynchronous clock domain crossings as those between clocks which do not have a known 13 phase or frequency relationship between them. Id. at 6. The Atrenta article contemplates that 14 clock domain crossings may be asynchronous or synchronous, reinforcing that Synopsys’s 15 proposed claim construction is too narrow insofar as it does not encompass synchronous clock 16 domain crossings. 17 Synopsys contends that Real Intent’s proposed construction should be rejected because it 18 does not capture the concept that a signal must cross clock domains. Synopsys reasons that Real 19 Intent’s proposed construction only requires a signal to cross “sections,” and that a person of 20 ordinary skill in the art (“POSITA”) would understand that “sections” of a circuit driven by 21 different clocks may still be part of a single clock domain if those clocks have a fixed phase 22 relationship. Synopsis Br. at 5 (citing Taskin Rpt. ¶ 31). That does not necessarily mean Real 23 Intent’s proposed construction is incorrect. The mere possibility a POSITA may understand Real 24 Intent’s proposed construction to refer to signals sent and received within the same clock domain 25 in the abstract does not mean that a POSITA would reach that understanding in the context of the 26 intrinsic and extrinsic evidence discussed above. 27 The Court recognizes that at least some of the extrinsic evidence cited by Synopsys lends 1 paper from Atrenta, and a user guide published by LEDA Design. See Taskin Rpt. ¶¶ 26-37. 2 Nevertheless, it is the intrinsic evidence that “is the most significant source of the legally operative 3 meaning of disputed claim language.” Vitronics, 90 F.3d at 1582. The Court finds that the claims 4 and other intrinsic evidence as outlined above support Real Intent’s position that clock domain 5 crossings do not involve only asynchronous clock domains. Accordingly, the Court adopts Real 6 Intent’s proposed construction for “clock domain crossing.”

7 B. Asynchronous clock domain crossings (Claims 1, 8, 10) 8 Synopsys Proposal Real Intent Proposal Court’s Construction 9 unsynchronized clock domain the sending and receiving clock domain crossings2 10 crossings of signals between at least between clocks with a two sections of a design variable phase relationship 11 driven by different clocks that have no guaranteed or 12 known phase and/or frequency relationship 13 14 Synopsys contends a POSITA would understand the term “asynchronous clock domain 15 crossings” to mean “unsynchronized clock domain crossings,” and goes on to further construe 16 “unsynchronized” as meaning “without proper or sufficient synchronization mechanisms.” 17 Synopsys Br. at 7. Real Intent contends that Synopsys is conflating the terms “asynchronous” and 18 “unsynchronized” even though the terms have different meanings in the art and serve different 19 purposes. Real Intent Br. at 21-22. Real Intent explains that clock domain crossings can be 20 asynchronous or synchronous (as discussed previously), and also unsynchronized or synchronized. 21 Id. According to Real Intent, the distinction is that the former set of adjectives (asynchronous / 22 synchronous) refers to the nature of the relationship between two clocks, whereas the latter set of 23 adjectives (unsynchronized / synchronized) refers to employing a synchronizer to address issues 24 such as meta-stability. Id. 25 The Court agrees with Real Intent that the two sets of adjectives refer to different concepts. 26 If Synopsys were correct that “asynchronous” and “unsynchronized” were synonyms, then an 27 1 asynchronous clock domain crossing could never be synchronized. Yet, that is not what the 2 intrinsic evidence indicates. The ’678 Patent, which is cited as prior art by the ’057 Patent, 3 repeatedly suggests that use of synchronization mechanisms may cause asynchronous clock 4 domains to become synchronized. See, e.g., ’678 Patent at 4:19-21 (“[P]aths between 5 asynchronous clock domains that are synchronized, for example, by clock synchronization 6 circuits, are removed from the list.”); id. at 2:4-5 (“Synchronization of valid data paths between 7 asynchronous clock domains is important . . . .”). The ’057 Patent itself demonstrates the same, 8 showing that synchronization mechanisms can be used to correct problems arising from 9 asynchronous clock domain crossings. See, e.g., ’057 Patent at 1:30-33 (“Analysis and 10 verification of asynchronous interfaces for correct synchronization mechanisms in such designs 11 have become an essential part of [system on a chip] design flows.”) (emphasis added); id. at 1:41- 12 47 (“Transferring signals between asynchronous clock domains may lead to setup or hold timing 13 violations of flip-flops. These violations may cause signals to be meta-stable. Even if 14 synchronizers could eliminate the meta-stability, incorrect use . . . may also result in functional 15 CDC errors.”) (emphasis added). Indeed, the ’057 Patent treats the two terms as referring to 16 separate concepts when it states, “Normal CDC checking would indicate an asynchronous clock 17 domain crossing as unsynchronized due to the presence of lock-up latch 340.” Id. at 7:41-44. 18 Synopsys points to just one instance where the ’057 Patent uses “asynchronous” and 19 “unsynchronized” interchangeably, when it describes the “Sync/Unsync” column of a table as 20 identifying if “the CDC crossing is synchronous or asynchronous.” Id. at 5:54-55. Given that 21 Synopsys can only identify one piece of intrinsic support, the weight of the intrinsic evidence cuts 22 against Synopsys’s proposed construction. 23 Nor does extrinsic evidence from Dr. Taskin weigh in favor of Synopsys’s proposed 24 construction. While he opines that “asynchronous” is equivalent to “unsynchronized” (Taskin 25 Rpt. ¶ 58), that conclusion is not consistent with the rest of his report. In fact, Dr. Taskin 26 explicitly defines “asynchronous” and “unsynchronized” differently. He defines “asynchronous” 27 as describing clocks with “a variable phase relationship with respect to one another.” Id. ¶ 60; see 1 synchronization mechanisms.” Id. ¶ 59. These definitions are more consistent with Real Intent’s 2 position than Synopsys’s, and they confirm that the two terms refer to different concepts. 3 Although the Court rejects Synopsys’s proposed claim construction, the Court is not 4 persuaded that Real Intent’s proposed construction is an appropriate alternative. The phrase, 5 “having no guaranteed or known phase and/or frequency,” does not clarify the meaning of 6 “asynchronous clock domain crossing.” According to Dr. Taskin, the term “guaranteed” is unclear 7 and ambiguous, and it is not a word a POSITA would typically use to describe clock phase 8 relationships. Taskin Rpt. ¶ 66. Dr. Taskin also opines that whether two clocks have a “known” 9 or “unknown” phase relationship is not a defining characteristic of an asynchronous clock domain 10 crossing. Id. He explains, “one could argue that the phase relationship between two clocks with 11 frequency 2f and 3f is known, since, at any given point in time, one could calculate the phase 12 offset between these two clocks. However, because that phase offset varies over time, these 13 clocks are part of different clock domains.” Id. 14 Instead, the Court construes “asynchronous clock domain crossings” to mean “clock 15 domain crossings between clocks with a variable phase relationship.” While neither party 16 proposed this construction, it is consistent with the intrinsic and extrinsic evidence. The ’057 17 Patent explicitly defines “asynchronous” as meaning “having a variable phase relation,” a 18 definition that both parties appear to accept at points in their briefing. ’057 Patent at 1:37-39 (“A 19 CDC-based design is a design that has one clock asynchronous to, or has a variable phase 20 relation with, another clock.”) (emphasis added); see also Synopsys Br. at 4 n.1, 8; Real Intent Br. 21 at 20. And Dr. Taskin adopts the same definition, as does the user guide for LEDA Design’s CDC 22 tool. Taskin Rpt. ¶¶ 29-30, 35, 60. Accordingly, the Court adopts its own construction of 23 “asynchronous clock domain crossing.” 24 // 25 // 26 // 27 // 1 C. Register transfer-level (RTL) design / RTL design (Claims 1, 3, 6-8, 10, 12, 14, 17) 2 3 Synopsys Proposal Real Intent Proposal Court’s Construction description of a digital description of a digital description of a digital 4 electronic circuit electronic circuit written in electronic circuit at the written in a behavioral a behavioral design register level written in a 5 hardware design language such as Verilog or behavioral hardware design language such as VHDL that describes data language such as Verilog or 6 Verilog or VHDL transfers between registers VHDL in the circuit and the 7 operations performed on the data 8 9 The parties agree that “RTL Design” is a description of a digital electronic circuit written 10 in a behavioral hardware design language such as Verilog or VHDL. The parties’ disagreement 11 pertains to the additional language in Real Intent’s proposed construction: “that describes data 12 transfers between registers in the circuit and the operations performed on the data.” 13 The Court concludes that Synopsys’s proposed construction is preferable. It is consistent 14 with the specification of the ’057 Patent, which describes an RTL design in terms of the language 15 used to represent the design: “The RTL design 110 is typically written in a behavioral design 16 language such as Verilog or VHDL.” ’057 Patent at 4:44-45. The additional language Real Intent 17 proposes is unnecessary. See Taskin Rpt. ¶ 41. A POSITA would understand the term “RTL 18 design” in the context of the ’057 Patent to mean a circuit specified in a behavioral hardware 19 description language. Id. ¶ 40. The additional language Real Intent proposes is also incomplete 20 insofar as it includes some aspects of an RTL design but excludes other aspects of an RTL design 21 such as “control mechanisms that control the sequence of operations (e.g. if–else if statements).” 22 Id. ¶ 41. 23 Real Intent counters that its additional proposed language is crucial because the netlist 24 level of a chip design, which is distinct from the RTL level of design, can also be written in a 25 behavioral hardware design language such as Verilog or VHDL. Real Intent Br. at 14-15. This is 26 a legitimate concern. Dr. Taskin was asked at his deposition:

27 Q. Are hardware description languages like VHDL and Verilog only 1 A. No, they’re not.

2 Q. Okay. What other levels use Verilog and VHDL?

3 A. One example would be the netlist level.

4 * * *

5 Q. So then you would use hardware description language like VHDL or Verilog to describe the netlist level; is that correct? 6 A. That’s right. 7 8 Hucek Decl., Ex. A at 98:7-20. However, it is not necessary to add Real Intent’s proposed 9 language to distinguish between the RTL and netlist level design stages. Dr. Taskin explains in 10 his report that “RTL – which is an abbreviation for Register Transfer Level – is a level of the 11 design process where the chip design is described in terms of the behavior of data at the register 12 level.” Taskin Rpt. ¶ 40. Consistent with his report, Dr. Taskin testified during his deposition that 13 Synopsys’s proposed claim construction would not encompass netlist designs:

14 Q. So would your definition also apply equally to the netlist?

15 A. My definition of RTL design? It would not apply to the netlist, no. I mean, those are two different -- those are two different levels. 16 One is the RTL. The other one is the gate-level netlist definition. RTL is the one that includes the behavioral description of the circuit. 17 18 Decl. of Helen Trac, ECF No. 61-1, Ex. 5, at 103:22-104:4. 19 Nevertheless, to capture the distinction between the RTL and netlist stages of design, the 20 Court will add the phrase “at the register level” to Synopsys’s proposed construction so that it 21 reads: “description of a digital electronic circuit at the register level written in a behavioral 22 hardware design language such as Verilog or VHDL.” Adding this phrase comports with Dr. 23 Taskin’s report and deposition testimony, as well as the patent applicant’s acknowledgment to the 24 Patent Office during the examination process that the “RTL-level and netlist-level are two 25 different stages within the chip design process. . . . After RTL development, designers use an RTL 26 compiler to flatten and optimize the logic and generate the netlist design.” Hucek Decl., Ex. C at 6 27 (internal quotation marks omitted); see also ’057 patent at 4:55–56 (“After completing RTL 1 proposed construction, as modified. 2 D. RTL-level CDC constraints; Netlist CDC constraints (Claims 1, 8, 10) 3 Synopsys Proposal Real Intent Proposal Court’s Construction 4 RTL-level CDC constraints 5 one or more limits on timing and restrictions, one or more limits on parameter values for a clock including blocks and paths to parameter values for a 6 signal identified by its RTL- include or exclude from clock signal identified level name checking, specified for the by its RTL-level name 7 RTL design under which CDC verification of the RTL 8 design is performed Netlist CDC constraints 9 one or more limits on timing and restrictions, one or more limits on 10 parameter values for a clock including blocks and paths to parameter values for a signal identified by its gate- include or exclude from clock signal identified by 11 level netlist name checking, specified for the its gate-level netlist gate-level design of a digital name 12 electronic circuit under which CDC verification of the gate- 13 level circuit design is performed 14 15 Synopsys’s proposed constructions are supported by the intrinsic evidence. Namely, the 16 specification describes CDC constraints as follows:

17 Electronic chip designers check for CDC problems by running CDC checks while they develop the register-transfer-level (RTL) design. 18 The designers specify CDC constraints identifying clock signals and parameters specifying clock frequency, clock-phase and 19 clock source. The constraints also specify blocks and path[s] to include or exclude from checking. The designers also create a 20 waivers file that tells the CDC checker to ignore the specified issues. 21 ’057 Patent at 2:5-12 (emphasis added). The second sentence explains that CDC constraints have 22 two parts: clock signals and parameters. The specification also makes clear that at the RTL level, 23 the CDC constraints are identified by RTL-level names, and at the netlist level, the CDC 24 constraints are identified by gate-level netlist names. See id. at 2:50-52 (“[M]igration of CDC 25 constraints is can [sic] be performed by identifying and mapping the RTL signal names to the 26 corresponding netlist signal names.”). 27 The extrinsic evidence further supports Synopsys’s proposed construction. Dr. Taskin 1 process which analyzes the clock domain crossings in a circuit to determine whether they are 2 properly and sufficiently synchronized.” Taskin Rpt. ¶ 45. CDC constraints “state the permissible 3 values of clock timing parameters for the clocks in a design.” Id. In other words, each CDC 4 constraint identifies the name of a clock signal and describes its timing characteristics. Id. Dr. 5 Taskin opines that a POSITA would understand that the term “RTL-level CDC constraints” means 6 “one or more limits on parameter values for a clock signal identified by its RTL-level name” (id. ¶ 7 52), and that the term “netlist CDC constraints” means “one or more limits on parameter values 8 for a clock signal identified by its gate-level netlist name” (id. ¶ 57). 9 Real Intent raises two challenges to Synopsys’s proposed construction. First, citing to the 10 same portion of the specification quoted above, Real Intent argues that Synopsys’s proposed 11 construction is too narrow insofar as does not require both “clock signals and parameters” and 12 insofar as it omits blocks and paths. Real Intent Br. at 17. Real Intent’s proposed construction is 13 intended to capture these elements. 14 Synopsys’s proposed construction already requires both parameters and clock signals. It 15 defines CDC constraints as limits on parameter values, and it calls for identification of the 16 particular clock signal to which those limits will apply. As for Real Intent’s challenge to the 17 omission of blocks and paths, the Court declines to include them in the construction of “CDC 18 constraints.” Although the portion of the specification quoted by Real Intent explicitly states that 19 “[t]he constraints also specify blocks and paths to include or exclude from checking,” the Court 20 finds Dr. Taskin’s interpretation of the specification persuasive. According to Dr. Taskin, a 21 POSITA would understand the quoted portion of the specification as describing three separate 22 inputs that are provided to the CDC verification tool: “(1) CDC constraints identifying clock 23 signals and parameters; (2) exclusion constraints which specify blocks or paths to include or 24 exclude from checking; and (3) [] waivers that tell the verification tool to waive a reported 25 violation.” Decl. of Dr. Baris Taskin in Support of Synopsys’ Opening Claim Construction Br. 26 (“Taskin Decl.”), ECF No. 48-4 ¶ 4. Dr. Taskin explains that a POSITA would understand CDC 27 constraints and exclusion constraints are two different types of constraints because they convey 1 do not explicitly contain path names, block names, or inclusion/exclusion information. Taskin 2 Rpt. ¶ 50. And his interpretation is consistent with the ’057 Patent, which notes that the exclusion 3 of paths is an exclusion constraint, not a CDC constraint. ’057 Patent at 7:20-22. 4 Second, Real Intent contends that Synopsys’s proposed constructions do not make clear 5 that CDC constraints “are specifically and separately formulated for the RTL design and the 6 netlist-level design for use in RTL CDC verification and netlist CDC verification, respectively.” 7 Real Intent Br. at 16. Real Intent’s proposed construction is intended to make the distinction 8 between the two types of CDC constraints clearer by including the phrases “under which CDC 9 verification of the RTL design is performed” in the construction of “RTL-level CDC constraints,” 10 and “under which CDC verification of the gate-level circuit design is performed” in the 11 construction of “netlist CDC constraints.” The Court finds that Real Intent’s additional language 12 is redundant and therefore unnecessary. The claims in which the disputed terms appear already 13 specify that RTL-level CDC constraints are “for the RTL design,” and the netlist CDC constraints 14 are used to “check[] . . . the received netlist . . . and report[] any CDC violations found in the 15 netlist.” ’057 Patent at 8:67-9:1, 9:6-10 (Claim 1) (emphasis added); see also id. at 9:54-55, 9:65- 16 10:2 (Claim 8); 10:24, 10:30-34 (Claim 10). The context of the claims makes clear that RTL-level 17 CDC constraints are used in CDC verification of RTL-level design, and netlist CDC constraints 18 are used in CDC verification of gate-level design. Consequently, the Court adopts Synopsys’s 19 proposed constructions. 20 E. Migrat[e/ing] … the RTL level CDC constraints to netlist CDC constraints / migrating RTL-level CDC constraints to netlist CDC constraints (Claims 1, 8, 21 10, 12) 22 Synopsys Proposal Real Intent Proposal Court’s Construction 23 creating netlist CDC automatically creating netlist creating netlist CDC constraints from RTL- CDC constraints from RTL- constraints from RTL-level 24 level CDC constraints level CDC constraints using CDC constraints signal mapping heuristics on 25 the received RTL design 26 The parties’ proposed constructions overlap. Both include the phrase “creating netlist 27 CDC constraints from RTL- level CDC constraints,” but Real Intent’s proposed construction 1 “automatically” creating netlist CDC constraints; and (2) using “signal mapping heuristics” (3) 2 “on the received RTL design.” 3 First, Real Intent contends that under the doctrine of prosecution disclaimer, any migration 4 of RTL-level CDC constraints to netlist CDC constraints must be automatic. Real Intent Br. at 8. 5 Synopsys does not dispute that the migrating step must be performed automatically but argues the 6 requirement for automatic migration is already captured in the claim preamble. Synopsys Br. at 7 13; ’057 Patent at 8:61 (stating that that each of the claimed steps are part of “an automated 8 method”), 9:48 (same). The Court agrees that it is redundant to include “automatically” in the 9 construction. 10 Second, Real Intent contends that the use of “signal mapping heuristics” to migrate RTL- 11 level CDC constraints to netlist CDC constraints is the only embodiment disclosed in the intrinsic 12 record for performing this function. In the Detailed Description, the specification states that “[t]he 13 NCDC [netlist design clock domain crossing checker] migrates constraints . . . by applying 14 multiple signal mapping heuristics.” ’057 Patent at 4:29-31. Real Intent reasons that because this 15 description is not prefaced with the phrase, “in one embodiment,” the description is the only 16 embodiment disclosed such that it should be included in the construction. Real Intent Br. at 7-8. 17 The Court disagrees with Real Intent’s interpretation of the specification. The ’057 Patent 18 explains that the migrating step “includes identifying and mapping RTL signal names in the 19 received RTL design to corresponding netlist signal names in the received netlist.” ’057 Patent at 20 3:10-15. This process, according to the specification, “may” involve applying one or more of 21 change name rules, bus naming styles, and logic equivalence checking mapping. Id. at 3:15–20. 22 The use of the word “may” suggests that the migrating step does not necessarily involve any of the 23 listed techniques for signal mapping. Indeed, Dr. Taskin opines that a POSITA would understand 24 that the list of techniques is non-exclusive, and that additional methods of signal mapping exist. 25 Taskin Rpt. ¶ 71. Further, the ’057 Patent describes the use of a “matching guidance file” with 26 “rules that assist[] the NDC is [sic] matching RTL signal names to netlist signal names.” ’057 27 Patent at Fig. 1, 4:62-64. Dr. Taskin opines that a POSITA would understand that a matching 1 level CDC constraints to netlist CDC constraints. Taskin Decl. ¶ 5. This evidence shows that the 2 use of heuristics is an exemplary embodiment, and the claims encompass other, non-heuristic 3 methods as well. 4 Third, Real Intent contends the intrinsic record confirms that all signal mapping must be 5 performed “on the received RTL design.” Real Intent Br. at 8. The specification does not support 6 this requirement. Rather, the patent describes migration as being performed by “mapping the RTL 7 signal names to the corresponding netlist signal names”; the process is applied to signal names 8 and not to the design as a whole. ’057 Patent at 2:51-52 (emphasis added); see also Taskin Rpt. 9 ¶ 72 (“[S]ignal mapping heuristics are used to map RTL-level signal names to netlist-level signal 10 names. Thus, at most, one could say that signal mapping heuristics are applied to RTL-level 11 signal names and not to an RTL design.”). 12 For the reasons stated above, the Court adopts Synopsys’s proposed construction and 13 rejects Real Intent’s proposed construction.

14 F. Identify correspondences between RTL and netlist level crossings (Claims 1, 8, 10) 15

16 Synopsys Proposal Real Intent Proposal Court’s Construction 17 No construction necessary. identify equivalent clock No construction necessary. Plain and ordinary meaning. domain crossings in the Plain and ordinary meaning. 18 RTL design and the netlist design 19 20 The crux of the parties’ dispute is whether identifying “correspondences” means 21 identifying “equivalent” crossings. Real Intent argues that crossings must be equivalent to 22 correspond while Synopsys maintains that crossings may correspond even if there are slight 23 differences at the RTL and netlist levels. Real Intent Br. at 10; Synopsys Br. at 13. Although 24 “equivalent” may be an acceptable synonym for “correspondence,” the Court agrees with 25 Synopsys that in the context of the ’057 Patent, it is not. The ’057 Patent uses the word 26 “correspondence”—as well as “corresponds” and corresponding”—to describe a relationship 27 between items. For example, the netlist can correspond to the RTL design. ’057 Patent at 2:60- 1 level clock domain crossings can correspond to netlist clock domain crossings (id. at 2:52-55), and 2 output states can correspond to input states (id. at 8:11-13). 3 Nowhere in the specification is “equivalent” and “correspondence” used synonymously. 4 Instead, Real Intent infers from the specification that the claimed invention must be identifying 5 only equivalent clock domain crossings in the RTL design and the netlist design. Real Intent Br. 6 at 10. Specifically, Real Intent relies on the statement that “the netlist may have additional clock 7 domain crossings not present in the RTL, may have clock domain crossings that don’t map to 8 RTL, and may have crossings that have become unsynchronized.” ’057 Patent at 2:36-39. 9 According to Real Intent, this statement describes three types of netlist crossings that are not 10 equivalent to crossings in the RTL design. But even if that were true—and other than its say-so, 11 Real Intent cites no intrinsic or extrinsic evidence to that effect—it does not shed light on the 12 meaning of “correspondence.” All that Real Intent’s argument would show is that a netlist might 13 contain some clock domain crossings that are not equivalent to any in the RTL design. The 14 presence of some non-equivalent crossings does require “correspondence” to mean “equivalent.” 15 Moreover, it is difficult to reconcile Real Intent’s proposed construction with Claims 7 and 18 of 16 the ’057 Patent. Both of those claims involve reporting the differences between “respective 17 crossings” in the netlist and RTL design. Id. at 9:40-47 (Claim 7); 11:9-16 (Claim 18). Although 18 they do not use the word “correspondence,” the fact that there can be “respective crossings” with 19 differences implies that non-equivalent crossings may be matched with each other for purposes of 20 comparison. Put another way, Claims 7 and 18 imply that non-equivalent correspondences are 21 possible. 22 Because intrinsic evidence suggests that correspondences need not be equivalent, extrinsic 23 evidence shows that a POSITA would understand “correspondence” in accordance with its plain 24 and ordinary meaning (Taskin Rpt. ¶¶ 76-77), and the Court discerns no other limits on the plain 25 and ordinary meaning of “correspondence” in either the intrinsic or extrinsic evidence, the Court 26 adopts Synopsys’s proposed construction. 27 // 1 G. Previously provided by a user for sign-off (Claims 2, 11) 2 Synopsys Proposal Real Intent Proposal Court’s Construction 3 No construction necessary. finalized by a user after No construction necessary. Plain and ordinary meaning. completing the RTL design Plain and ordinary meaning. 4 based 5 6 The core of the parties’ dispute over this term is the level of finality that the term “sign- 7 off” signals. Synopsys asserts that “sign-off” means the CDC constraints are ready for the next 8 stage of the design process but does not foreclose the possibility that engineers may return to the 9 RTL stage if they discover glitches. Synopsys Br. at 15-16. Real Intent disagrees, contending that 10 once sign-off has been given, there is no turning back. Real Intent Br. at 12. 11 The Court concurs with Synopsys. The intrinsic evidence suggests that sign-off is not as 12 final as Real Intent urges. Figure 1 of the ’057 Patent illustrates part of the design flow between 13 the RTL and netlist stages. It contains a double arrow between the netlist CDC checker and the 14 RTL-level CDC constraints, indicating that the RTL-level CDC constraints can feed into the 15 netlist CDC checker, but the netlist CDC checker can also provide changes to the RTL-level CDC 16 constraints. This demonstrates that the design process is iterative, and sign-off to proceed to the 17 netlist stage does not prevent return to the RTL stage. Extrinsic evidence from Dr. Taskin 18 comports with that understanding. He explains that “CDC constraints are never finalized in the 19 design process” because a designer can always add to or revise those constraints. Taskin Rpt. 20 ¶ 86. He also notes that the circuit design process is iterative, and “errors in the circuit design 21 found in later levels of the design process may be addressed by correcting the RTL design.” Id. 22 ¶ 87. Real Intent’s only evidence to the contrary is an extrinsic user manual that implies sign-off 23 is final. Hucek Decl., Ex. G at 6. But how a user chooses to deploy an invention does not supply 24 limitations to the invention itself. At most, the manual offers a suggestion for how Synopsys 25 believes engineers should use its software, not how it must be used. In light of the intrinsic 26 evidence and Dr. Taskin’s opinions, the Court finds that the user manual does not limit the claims 27 of the ’057 Patent. As a result, the Court adopts Synopsys’s proposed construction. 1 V. CONCLUSION 2 For the reasons set forth above, the Court construes the disputed terms as follows: 3 4 Court's Construction Clock domain crossing (CDC) / CDC the sending and receiving of signals between 5 (Claims 1-2, 4, 6-8, 10-12, 15, 17-18) at least two sections of a circuit design driven by different clocks 6 Asynchronous clock domain crossings clock domain crossings between clocks with a 7 (Claims 1, 8, 10) variable phase relationship Register transfer-level (RTL) design / RTL description of a digital electronic circuit at the 8 design (Claims 1, 3, 6-8, 10, 12, 14, 17) register level written in a behavioral hardware 9 design language such as Verilog or VHDL RTL-level CDC constraints (Claims 1, 8, 10) one or more limits on parameter values for a 10 clock signal identified by its RTL-level name 11 Netlist CDC constraints (Claims 1, 8, 10) one or more limits on parameter values for a clock signal identified by its gate-level netlist a 12 name = 13 Migrat[e/ing] .. . the RTL level CDC creating netlist CDC constraints from RTL- constraints to netlist CDC constraints / level CDC constraints 14 migrating RTL-level CDC constraints to netlist CDC constraints (Claims 1, 8, 10, 12) 15 Identify correspondences between RTL and No construction necessary. Plain and ordinary 16 netlist level crossings (Claims 1, 8, 10) meaning.

= 17 Previously provided by a user for sign-off No construction necessary. Plain and ordinary (Claims 2, 11) meaning. Z 18 19 20 IT IS SO ORDERED. 21 Dated: April 21, 2023 22 23 EDWARD J. DAVILA 24 United States District Judge 25 26 27 28