Opinion
5:20-cv-02819-EJD
04-21-2023
SYNOPSYS, INC., Plaintiff, v. REAL INTENT, INC., Defendant.
CLAIM CONSTRUCTION ORDER
EDWARD J. DAVILA, UNITED STATES DISTRICT JUDGE.
Plaintiff Synopsys, Inc. (“Synopsys”) brings this suit against Defendant Real Intent, Inc. (“Real Intent”) for infringement of U.S. Patent No. 9,721,057, entitled “System and Method for Netlist Clock Domain Crossing Verification” (the “ '057 Patent”). The parties dispute the proper construction of eight terms. See Opening Claim Construction Br. of Pl. Synopsys, Inc. (“Synopsys Br.”), ECF No. 48; Real Intent, Inc.'s Responsive Claim Construction Br. (“Real Intent Br.”), ECF No. 52-4; Reply Claim Construction Br. of Pl. Synopsys, Inc. (“Synopsys Reply Br.”), ECF No. 61. Upon consideration of the claims, specification, prosecution history, and other relevant evidence, and after hearing the arguments of the parties, the Court construes the contested language of the patent-in-suit as set forth below.
Synopsys also alleges that Real Intent improperly copied Synopsys's copyrighted expression and breached contractual obligations to Synopsys.
I. BACKGROUND
Synopsys is a leader in the electronic design automation and semiconductor intellectual property industry. Second Am. Compl., ECF No. 145 ¶ 1. It develops, manufactures, sells, and licenses products and services that enable designers to create, model, and verify complex integrated circuit designs from concept to silicon. Id. The '057 Patent, which Synopsys holds by assignment, generally relates to a particular type of circuit verification called clock domain crossing (“CDC”) verification. In modern computer chip designs, a single chip often contains circuits that operate at different clock speeds. '057 Patent at 1:21-27. When signals from one part of the chip are transmitted to another part of the chip that is running at a different clock speed, there may be errors that lead to chip failure if the signals aren't “synchronized.” Id. at 1:27-34. CDC verification is the step in the design process where engineers identify and correct those errors and has become an essential part of chip design flows. Id. at 1:34-36. At this step, engineers conduct “[a]nalysis and verification of asynchronous interfaces for correct synchronization mechanisms.” Id. at 1:30-32.
CDC verification occurs at multiple stages of the design process. One stage is at the Register Transfer Level (“RTL”). Id. at 2:5-7. At this level, engineers use RTL code to define the functional behavior of a circuit. Expert Rpt. of Dr. Baris Taskin re Claim Construction (“Taskin Rpt.”), ECF No. 48-3 ¶ 13. “Electronic chip designers check for CDC problems by running CDC checks while they develop the register-transfer-level (RTL) design.” '057 Patent at 2:5-7. After the RTL design stage, designers proceed to the netlist design stage. Id. at 2:17-19. At the netlist design stage, the RTL code is translated into a “gate-level description of the circuit design through a process called logical synthesis.” Taskin Rpt. ¶ 14. “Logical synthesis is typically performed by a logical synthesis tool, which is sometimes also referred to as an RTL compiler.” Id. “The resulting gate-level description is called a gate-level netlist or netlist for short.” Id. The netlist “specifies individual logic gates . . . as well as the connections between the gates.” Id.
CDC checks are also conducted at the netlist design stage. '057 Patent at 2:13-17. According to the '057 Patent, prior methods of CDC verification at the netlist design level were difficult and time consuming. Id. at 2:23-39. One reason for this was because the netlist had different net names than the RTL design, and the designer had to formulate new CDC constraints that refer to the new net names in the netlist. Id. at 2:25-28. The '057 Patent described other reasons why the CDC verification at the netlist design stage was burdensome:
Well-defined structures like multiplexors used to select between clocks may be difficult to identify in the netlist. Due to the application 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 netlist. For example, clock constraints corresponding to two different RTL blocks may correspond to fanouts of the same clock at a higher hierarchy level. Thus, the netlist may have additional clock domain crossings not present in the RTL, may have clock domain crossings that don't map to RTL, and may have crossings that have become unsynchronized.Id. at 2:28-39. The '057 Patent was intended to introduce an automated approach to make CDC verification at the netlist level quick and easy. Id. at 2:40-41. In this automated approach, the netlist-level CDC constraints are created from the RTL-level CDC constraints. Taskin Rpt. ¶ 17. The '057 Patent calls this automated process “migration.” Id. In the Summary Disclosure, the '057 Patent claims “[a] system and method for netlist clock domain crossing (NCDC) verification [that] leverages the corresponding RTL clock domain crossing (CDC) verification data and results by migrating RTL-level constraints and waivers to the netlist design so that the user does not have to re-enter them.” '057 Patent at 2:45-49.
After the netlist has been verified, “the components in the gate-level description of the circuit design are physically assigned a location on the chip and the wires in the gate-level description are routed.” Taskin Rpt. ¶ 19. This process generates a layout of the circuit, which is then used to manufacture the circuit. Id.
II. LEGAL STANDARDS
Claim construction is a question of law to be decided by the court. Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996). “[T]he interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim.” Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (citation omitted). Consequently, courts construe claims in the manner that “most naturally aligns with the patent's description of the invention.” Id. (citation omitted).
In construing disputed terms, a court looks first to the claims themselves, for “[i]t is a bedrock principle of patent law that the claims of a patent define the invention to which the patentee is entitled the right to exclude.” Id. at 1312 (citation and internal quotation marks omitted). Generally, the words of a claim should be given their “ordinary and customary meaning,” which is “the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention.” Id. at 1312-13 (citations omitted). In some instances, the ordinary meaning to a person of skill in the art is clear, and claim construction may involve “little more than the application of the widely accepted meaning of commonly understood words.” Id. at 1314.
In many cases, however, the meaning of a term to a person skilled in the art will not be readily apparent, and a court must look to other sources to determine the term's meaning. Id. Under these circumstances, a court should consider the context in which the term is used in an asserted claim or in related claims, bearing in mind that “the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.” Id. at 1313. Indeed, the specification is “always highly relevant” and “[u]sually, it is dispositive; it is the single best guide to the meaning of a disputed term.” Id. at 1315 (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). The court may also consider the patent's prosecution history, which consists of the complete record of proceedings before the United States Patent and Trademark Office and includes cited prior art references. Id. at 1317.
Finally, the court is also authorized to consider extrinsic evidence in construing claims, such as “expert and inventor testimony, dictionaries, and learned treatises.” Markman, 52 F.3d at 980 (internal citations omitted). Although the court may consider evidence extrinsic to the patent and prosecution history, such evidence is considered “less significant than the intrinsic record” and “less reliable than the patent and its prosecution history in determining how to read claim terms.” Phillips, 415 F.3d at 1317-18 (citation omitted). Thus, while extrinsic evidence may be useful in claim construction, ultimately “it is unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence.” Id. at 1319.
III. REQUEST TO STRIKE DR. TASKIN'S REPORT AND DECLARATION
Real Intent asks the Court to strike the Expert Report of Dr. Baris Taskin, dated February 8, 2021, as well as Dr. Taskin's three-page declaration filed in support of Synopsys's Opening Claim Construction Brief on March 17, 2021. See ECF Nos. 48-3, 48-4. Real Intent contends that the declaration is a tardy “supplemental” expert report because it was not filed within 60 days after service of Real Intent's Invalidity Contentions as required by Patent Local Rule 4-3 and Federal Rule of Civil Procedure 26(a)(2)(B). Real Intent Br. at 4-6. Further, Real Intent contends that Dr. Taskin's opinions are unreliable because he essentially adopted the constructions prepared by Synopsys's attorneys and failed to consider extrinsic evidence. Id. at 6-7.
The request to strike is denied. It is undisputed that Dr. Taskin's original report was timely and that Real Intent deposed Dr. Taskin prior to the claim construction hearing. Pursuant to Patent Local Rule 4-5(a), parties are permitted to file supporting evidence with their claim construction briefs. See Patent L.R. 4-5(a) (“[Plaintiff] shall serve and file an opening brief and any evidence supporting its claim construction.”). Dr. Taskin's declaration is such supporting evidence. Arguably, the substance of Dr. Taskin's declaration should have been incorporated into a supplemental expert report and disclosed in accordance with Rule 26(a)(2)(B). See Patent L.R. 4-3 (“[Expert] reports shall comply with the disclosure requirements of Fed.R.Civ.P. 26(A)(2)(B)”). Nevertheless, because the five-paragraph declaration is relatively short and simply summarizes portions of Dr. Taskin's deposition, Real Intent cannot credibly claim it suffered any harm. Absent a showing of prejudice, the purported untimeliness does not justify striking Dr. Taskin's declaration. See Symantec Corp. v. Zscaler, Inc., No. 17-cv-04426-JST, 2018 WL 6270954, at *1 (N.D. Cal. Nov. 30, 2018) (declining to strike expert declaration for lack of harm where expert was disclosed in joint claim construction statement and moving party deposed expert). Nor do Synopsys's various challenges to the substance of Dr. Taskin's report justify exclusion. Synopsys does not challenge Dr. Taskin's report under the standards articulated in Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993). Instead, Synopsys's challenges go to the weight and not to the admissibility of Dr. Taskin's report.
IV. CONSTRUCTION OF DISPUTED TERMS
A. Clock domain crossing (CDC) / CDC (Claims 1, 2, 4, 6-8, 10-12, 15, 17-18)
Synopsys Proposal
Real Intent Proposal
Court's Construction
signal from a first clock domain that is sampled in a second clock domain, where the clocks have a variable phase relationship with one another
the sending and receiving of signals between at least two sections of a circuit design driven by different clocks
the sending and receiving of signals between at least two sections of a circuit design driven by different clocks
The parties agree that a clock domain crossing occurs when signals in a circuit cross from one clock domain to another clock domain. According to Synopsys, the parties dispute what constitutes a clock domain. Synopsys contends that multiple clocks can be in the same clock domain so long as those clocks have a “fixed phase relationship,” whereas Real Intent's proposed construction assigns each different clock to its own clock domain. Synopsys Br. at 4. Real Intent frames the dispute differently. Real Intent contends that the difference between the two parties' constructions rests on “whether clock domains can have a deterministic relationship to one another, as Real Intent proposed, or whether clock domain crossings must necessarily involve asynchronous clock domains, as Synopsys proposes.” Real Intent Br. at 18.
The intrinsic evidence supports Real Intent's proposed construction. The specification states that “[t]he NCDC identifies all clock domain crossings, determines if they are synchronous or asynchronous and applies a number of CDC checks,” unambiguously indicating that clock domain crossings may be either synchronous or asynchronous. '057 Patent at 7:18-20 (emphasis added). The '057 Patent also refers to “asynchronous clock domain crossings” in both the specification and the claims. See e.g., id. at 3:23-24 (“Next, the processor checks the received netlist for asynchronous clock domain crossings . . . .”); 7:41-44 (“Normal CDC checking would indicate an asynchronous clock domain crossing as unsynchronized due to the presence of lock-up latch 340.”); 9:6-7 (Claim 1); 9:65-66 (Claim 8); 10:30-31 (Claim 10). The use of the modifier “asynchronous,” particularly in the context of the claims, is highly instructive. Philips, 415 F.3d at 1314. In an analogous situation, the Federal Circuit explained that reference to “‘steel baffles' . . . strongly implies that the term ‘baffles' does not inherently mean objects made of steel.” Id. Likewise, the fact that the claims include “asynchronous” before “clock domain crossings” strongly implies that the term “clock domain crossings” does not inherently mean all clock domain crossings involve asynchronous clock domains. If all clock domain crossings were asynchronous, there would be no need to use “asynchronous” in the claims to describe the clock domain crossings.
Cited prior art references in the '057 Patent additionally weigh in favor of Real Intent's proposed construction. Specifically, the ‘057 Patent cites to U.S. Patent No. 7,412,678. Decl. of Kristin Hucek (“Hucek Decl.”), ECF No. 53-1, Ex. O (“ '678 Patent”). In turn, the '678 Patent regularly distinguishes between synchronous and asynchronous clock domain crossings. For example, the '678 Patent is titled, “Method and Computer Program for Management of Synchronous and Asynchronous Clock Domain Crossing in Integrated Circuit Design.” Id. (emphasis added). It also describes its invention as “a computer program product for managing synchronous and asynchronous clock domain crossings,” and Claim 9 of the '678 Patent reads in pertinent part, “A computer readable storage medium tangibly embodying program instructions that when executed by a computer implement a method of managing synchronous and asynchronous clock domain crossings.” Id. at 1:40-42, 6:3-6 (emphasis added). All this suggests that, when the phrase “clock domain crossings” is not preceded by a modifier, the phrase encompasses both synchronous and asynchronous clock domain crossings. Further contrary to Synopsys's argument that different clock domains must be asynchronous, the '678 Patent provides that its invention functions by “identifying paths between synchronous clock domains and paths between asynchronous clock domains,” signaling that clock domains may have either a synchronous or asynchronous relationship. Id. at 1:47-48 (emphasis added).
Synopsys's supporting intrinsic evidence consists of a single sentence from the specification stating that a “CDC-based design” is “a design that has one clock asynchronous to, or has a variable phase relation with, another clock.” '057 Patent at 1:37-39. This sentence makes the point that CDC-based designs involve at least some clocks that are asynchronous to one another. But it does not follow that the definition of “clock domain crossing” is limited to the transfer of signals across asynchronous clock domains. The sentence demonstrates only that the presence of asynchronous relationships necessitates CDC verification; signals sent between synchronous clocks may not require verification, but they can still be clock domain crossings. Therefore, this single sentence does not contradict Real Intent's proposed construction.
The extrinsic evidence also supports Real Intent's proposed construction. An article from Atrenta, an early pioneer in clock domain crossing verification, explains that a clock domain crossing occurs whenever data is transferred from a flop driven by one clock to a flop driven by another clock, without requiring the clocks to have an asynchronous relationship. See Hucek Decl., Ex. E at 1. The Atrenta article goes on to canvas different types of clock domain crossings, including both synchronous clock domain crossings and asynchronous clock domain crossings. It describes a synchronous clock domain crossing as one between synchronous clocks, or in other words, between clocks with a known phase and frequency relationship. Id. at 3. By contrast, it defines asynchronous clock domain crossings as those between clocks which do not have a known phase or frequency relationship between them. Id. at 6. The Atrenta article contemplates that clock domain crossings may be asynchronous or synchronous, reinforcing that Synopsys's proposed claim construction is too narrow insofar as it does not encompass synchronous clock domain crossings.
Synopsys contends that Real Intent's proposed construction should be rejected because it does not capture the concept that a signal must cross clock domains. Synopsys reasons that Real Intent's proposed construction only requires a signal to cross “sections,” and that a person of ordinary skill in the art (“POSITA”) would understand that “sections” of a circuit driven by different clocks may still be part of a single clock domain if those clocks have a fixed phase relationship. Synopsis Br. at 5 (citing Taskin Rpt. ¶ 31). That does not necessarily mean Real Intent's proposed construction is incorrect. The mere possibility a POSITA may understand Real Intent's proposed construction to refer to signals sent and received within the same clock domain in the abstract does not mean that a POSITA would reach that understanding in the context of the intrinsic and extrinsic evidence discussed above.
The Court recognizes that at least some of the extrinsic evidence cited by Synopsys lends support to its proposed construction, including the opinions offered by Dr. Taskin, a March 2010 paper from Atrenta, and a user guide published by LEDA Design. See Taskin Rpt. ¶¶ 26-37. Nevertheless, it is the intrinsic evidence that “is the most significant source of the legally operative meaning of disputed claim language.” Vitronics, 90 F.3d at 1582. The Court finds that the claims and other intrinsic evidence as outlined above support Real Intent's position that clock domain crossings do not involve only asynchronous clock domains. Accordingly, the Court adopts Real Intent's proposed construction for “clock domain crossing.”
B. Asynchronous clock domain crossings (Claims 1, 8, 10)
“Clock domain crossings” is given the construction adopted by the Court above in Section IV.A.
Synopsys contends a POSITA would understand the term “asynchronous clock domain crossings” to mean “unsynchronized clock domain crossings,” and goes on to further construe “unsynchronized” as meaning “without proper or sufficient synchronization mechanisms.” Synopsys Br. at 7. Real Intent contends that Synopsys is conflating the terms “asynchronous” and “unsynchronized” even though the terms have different meanings in the art and serve different purposes. Real Intent Br. at 21-22. Real Intent explains that clock domain crossings can be asynchronous or synchronous (as discussed previously), and also unsynchronized or synchronized. Id. According to Real Intent, the distinction is that the former set of adjectives (asynchronous / synchronous) refers to the nature of the relationship between two clocks, whereas the latter set of adjectives (unsynchronized / synchronized) refers to employing a synchronizer to address issues such as meta-stability. Id.
The Court agrees with Real Intent that the two sets of adjectives refer to different concepts. If Synopsys were correct that “asynchronous” and “unsynchronized” were synonyms, then an asynchronous clock domain crossing could never be synchronized. Yet, that is not what the intrinsic evidence indicates. The '678 Patent, which is cited as prior art by the '057 Patent, repeatedly suggests that use of synchronization mechanisms may cause asynchronous clock domains to become synchronized. See, e.g., '678 Patent at 4:19-21 (“[P]aths between asynchronous clock domains that are synchronized, for example, by clock synchronization circuits, are removed from the list.”); id. at 2:4-5 (“Synchronization of valid data paths between asynchronous clock domains is important ....”). The '057 Patent itself demonstrates the same, showing that synchronization mechanisms can be used to correct problems arising from asynchronous clock domain crossings. See, e.g., '057 Patent at 1:30-33 (“Analysis and verification of asynchronous interfaces for correct synchronization mechanisms in such designs have become an essential part of [system on a chip] design flows.”) (emphasis added); id. at 1:4147 (“Transferring signals between asynchronous clock domains may lead to setup or hold timing violations of flip-flops. These violations may cause signals to be meta-stable. Even if synchronizers could eliminate the meta-stability, incorrect use . . . may also result in functional CDC errors.”) (emphasis added). Indeed, the '057 Patent treats the two terms as referring to separate concepts when it states, “Normal CDC checking would indicate an asynchronous clock domain crossing as unsynchronized due to the presence of lock-up latch 340.” Id. At 7:41-44. Synopsys points to just one instance where the '057 Patent uses “asynchronous” and “unsynchronized” interchangeably, when it describes the “Sync/Unsync” column of a table as identifying if “the CDC crossing is synchronous or asynchronous.” Id. at 5:54-55. Given that Synopsys can only identify one piece of intrinsic support, the weight of the intrinsic evidence cuts against Synopsys's proposed construction.
Nor does extrinsic evidence from Dr. Taskin weigh in favor of Synopsys's proposed construction. While he opines that “asynchronous” is equivalent to “unsynchronized” (Taskin Rpt. ¶ 58), that conclusion is not consistent with the rest of his report. In fact, Dr. Taskin explicitly defines “asynchronous” and “unsynchronized” differently. He defines “asynchronous” as describing clocks with “a variable phase relationship with respect to one another.” Id. ¶ 60; see also id. ¶¶ 29-30, 35. But he defines “unsynchronized” as “crossings without proper or sufficient synchronization mechanisms.” Id. ¶ 59. These definitions are more consistent with Real Intent's position than Synopsys's, and they confirm that the two terms refer to different concepts.
Although the Court rejects Synopsys's proposed claim construction, the Court is not persuaded that Real Intent's proposed construction is an appropriate alternative. The phrase, “having no guaranteed or known phase and/or frequency,” does not clarify the meaning of “asynchronous clock domain crossing.” According to Dr. Taskin, the term “guaranteed” is unclear and ambiguous, and it is not a word a POSITA would typically use to describe clock phase relationships. Taskin Rpt. ¶ 66. Dr. Taskin also opines that whether two clocks have a “known” or “unknown” phase relationship is not a defining characteristic of an asynchronous clock domain crossing. Id. He explains, “one could argue that the phase relationship between two clocks with frequency 2f and 3f is known, since, at any given point in time, one could calculate the phase offset between these two clocks. However, because that phase offset varies over time, these clocks are part of different clock domains.” Id.
Instead, the Court construes “asynchronous clock domain crossings” to mean “clock domain crossings between clocks with a variable phase relationship.” While neither party proposed this construction, it is consistent with the intrinsic and extrinsic evidence. The '057 Patent explicitly defines “asynchronous” as meaning “having a variable phase relation,” a definition that both parties appear to accept at points in their briefing. '057 Patent at 1:37-39 (“A CDC-based design is a design that has one clock asynchronous to, or has a variable phase relation with, another clock.”) (emphasis added); see also Synopsys Br. at 4 n.1, 8; Real Intent Br. at 20. And Dr. Taskin adopts the same definition, as does the user guide for LEDA Design's CDC tool. Taskin Rpt. ¶¶ 29-30, 35, 60. Accordingly, the Court adopts its own construction of “asynchronous clock domain crossing.”
C. Register transfer-level (RTL) design / RTL design (Claims 1, 3, 6-8, 10, 12, 14, 17)
Synopsys Proposal
Real Intent Proposal
Court's Construction
description of a digital electronic circuit written in a behavioral hardware design language such as Verilog or VHDL
description of a digital electronic circuit written in a behavioral design language such as Verilog or VHDL that describes data transfers between registers in the circuit and the operations performed on the data
description of a digital electronic circuit at the register level written in a behavioral hardware design language such as Verilog or VHDL
The parties agree that “RTL Design” is a description of a digital electronic circuit written in a behavioral hardware design language such as Verilog or VHDL. The parties' disagreement pertains to the additional language in Real Intent's proposed construction: “that describes data transfers between registers in the circuit and the operations performed on the data.”
The Court concludes that Synopsys's proposed construction is preferable. It is consistent with the specification of the '057 Patent, which describes an RTL design in terms of the language used to represent the design: “The RTL design 110 is typically written in a behavioral design language such as Verilog or VHDL.” '057 Patent at 4:44-45. The additional language Real Intent proposes is unnecessary. See Taskin Rpt. ¶ 41. A POSITA would understand the term “RTL design” in the context of the '057 Patent to mean a circuit specified in a behavioral hardware description language. Id. ¶ 40. The additional language Real Intent proposes is also incomplete insofar as it includes some aspects of an RTL design but excludes other aspects of an RTL design such as “control mechanisms that control the sequence of operations (e.g. if-else if statements).” Id. ¶ 41.
Real Intent counters that its additional proposed language is crucial because the netlist level of a chip design, which is distinct from the RTL level of design, can also be written in a behavioral hardware design language such as Verilog or VHDL. Real Intent Br. at 14-15. This is a legitimate concern. Dr. Taskin was asked at his deposition:
Q. Are hardware description languages like VHDL and Verilog only used at the RTL level?
A. No, they're not.
Q. Okay. What other levels use Verilog and VHDL?
A. One example would be the netlist level.
* * *
Q. So then you would use hardware description language like VHDL or Verilog to describe the netlist level; is that correct?
A. That's right.Hucek Decl., Ex. A at 98:7-20. However, it is not necessary to add Real Intent's proposed language to distinguish between the RTL and netlist level design stages. Dr. Taskin explains in his report that “RTL - which is an abbreviation for Register Transfer Level - is a level of the design process where the chip design is described in terms of the behavior of data at the register level.” Taskin Rpt. ¶ 40. Consistent with his report, Dr. Taskin testified during his deposition that Synopsys's proposed claim construction would not encompass netlist designs:
Q. So would your definition also apply equally to the netlist?
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. 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.Decl. of Helen Trac, ECF No. 61-1, Ex. 5, at 103:22-104:4.
Nevertheless, to capture the distinction between the RTL and netlist stages of design, the Court will add the phrase “at the register level” to Synopsys's proposed construction so that it reads: “description of a digital electronic circuit at the register level written in a behavioral hardware design language such as Verilog or VHDL.” Adding this phrase comports with Dr. Taskin's report and deposition testimony, as well as the patent applicant's acknowledgment to the Patent Office during the examination process that the “RTL-level and netlist-level are two different stages within the chip design process.... After RTL development, designers use an RTL compiler to flatten and optimize the logic and generate the netlist design.” Hucek Decl., Ex. C at 6 (internal quotation marks omitted); see also '057 patent at 4:55-56 (“After completing RTL development the designer generates a netlist design.”). The Court therefore adopts Synopsys's proposed construction, as modified.
D. RTL-level CDC constraints; Netlist CDC constraints (Claims 1, 8, 10)
Synopsys Proposal
Real Intent Proposal
Court's Construction
RTL-level CDC constraints
one or more limits on parameter values for a clock signal identified by its RTL-level name
timing and restrictions, including blocks and paths to include or exclude from checking, specified for the RTL design under which CDC verification of the RTL design is performed
one or more limits on parameter values for a clock signal identified by its RTL-level name
Netlist CDC constraints
one or more limits on parameter values for a clock signal identified by its gate-level netlist name
timing and restrictions, including blocks and paths to include or exclude from checking, specified for the gate-level design of a digital electronic circuit under which CDC verification of the gate-level circuit design is performed
one or more limits on parameter values for a clock signal identified by its gate-level netlist name
Synopsys's proposed constructions are supported by the intrinsic evidence. Namely, the specification describes CDC constraints as follows:
Electronic chip designers check for CDC problems by running CDC checks while they develop the register-transfer-level (RTL) design. The designers specify CDC constraints identifying clock signals and parameters specifying clock frequency, clock-phase and clock source. The constraints also specify blocks and path[s] to include or exclude from checking. The designers also create a waivers file that tells the CDC checker to ignore the specified issues.'057 Patent at 2:5-12 (emphasis added). The second sentence explains that CDC constraints have two parts: clock signals and parameters. The specification also makes clear that at the RTL level, the CDC constraints are identified by RTL-level names, and at the netlist level, the CDC constraints are identified by gate-level netlist names. See id. at 2:50-52 (“[M]igration of CDC constraints is can [sic] be performed by identifying and mapping the RTL signal names to the corresponding netlist signal names.”).
The extrinsic evidence further supports Synopsys's proposed construction. Dr. Taskin explains that “CDC constraints are a type of constraint used to perform CDC verification - a process which analyzes the clock domain crossings in a circuit to determine whether they are properly and sufficiently synchronized.” Taskin Rpt. ¶ 45. CDC constraints “state the permissible values of clock timing parameters for the clocks in a design.” Id. In other words, each CDC constraint identifies the name of a clock signal and describes its timing characteristics. Id. Dr. Taskin opines that a POSITA would understand that the term “RTL-level CDC constraints” means “one or more limits on parameter values for a clock signal identified by its RTL-level name” (Id. ¶ 52), and that the term “netlist CDC constraints” means “one or more limits on parameter values for a clock signal identified by its gate-level netlist name” (Id. ¶ 57).
Real Intent raises two challenges to Synopsys's proposed construction. First, citing to the same portion of the specification quoted above, Real Intent argues that Synopsys's proposed construction is too narrow insofar as does not require both “clock signals and parameters” and insofar as it omits blocks and paths. Real Intent Br. at 17. Real Intent's proposed construction is intended to capture these elements.
Synopsys's proposed construction already requires both parameters and clock signals. It defines CDC constraints as limits on parameter values, and it calls for identification of the particular clock signal to which those limits will apply. As for Real Intent's challenge to the omission of blocks and paths, the Court declines to include them in the construction of “CDC constraints.” Although the portion of the specification quoted by Real Intent explicitly states that “[t]he constraints also specify blocks and paths to include or exclude from checking,” the Court finds Dr. Taskin's interpretation of the specification persuasive. According to Dr. Taskin, a POSITA would understand the quoted portion of the specification as describing three separate inputs that are provided to the CDC verification tool: “(1) CDC constraints identifying clock signals and parameters; (2) exclusion constraints which specify blocks or paths to include or exclude from checking; and (3) [] waivers that tell the verification tool to waive a reported violation.” Decl. of Dr. Baris Taskin in Support of Synopsys' Opening Claim Construction Br. (“Taskin Decl.”), ECF No. 48-4 ¶ 4. Dr. Taskin explains that a POSITA would understand CDC constraints and exclusion constraints are two different types of constraints because they convey different types of information to the verification tool. Id. He also explains that CDC constraints do not explicitly contain path names, block names, or inclusion/exclusion information. Taskin Rpt. ¶ 50. And his interpretation is consistent with the '057 Patent, which notes that the exclusion of paths is an exclusion constraint, not a CDC constraint. '057 Patent at 7:20-22.
Second, Real Intent contends that Synopsys's proposed constructions do not make clear that CDC constraints “are specifically and separately formulated for the RTL design and the netlist-level design for use in RTL CDC verification and netlist CDC verification, respectively.” Real Intent Br. at 16. Real Intent's proposed construction is intended to make the distinction between the two types of CDC constraints clearer by including the phrases “under which CDC verification of the RTL design is performed” in the construction of “RTL-level CDC constraints,” and “under which CDC verification of the gate-level circuit design is performed” in the construction of “netlist CDC constraints.” The Court finds that Real Intent's additional language is redundant and therefore unnecessary. The claims in which the disputed terms appear already specify that RTL-level CDC constraints are “for the RTL design,” and the netlist CDC constraints are used to “check[] . . . the received netlist . . . and report[] any CDC violations found in the netlist.” '057 Patent at 8:67-9:1, 9:6-10 (Claim 1) (emphasis added); see also id. at 9:54-55, 9:6510:2 (Claim 8); 10:24, 10:30-34 (Claim 10). The context of the claims makes clear that RTL-level CDC constraints are used in CDC verification of RTL-level design, and netlist CDC constraints are used in CDC verification of gate-level design. Consequently, the Court adopts Synopsys's proposed constructions.
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, 10, 12)
Synopsys Proposal
Real Intent Proposal
Court's Construction
creating netlist CDC constraints from RTL- level CDC constraints
automatically creating netlist CDC constraints from RTL-level CDC constraints using signal mapping heuristics on the received RTL design
creating netlist CDC constraints from RTL-level CDC constraints
The parties' proposed constructions overlap. Both include the phrase “creating netlist CDC constraints from RTL- level CDC constraints,” but Real Intent's proposed construction includes additional language. Specifically, Real Intent proposes three additional requirements: (1) “automatically” creating netlist CDC constraints; and (2) using “signal mapping heuristics” (3) “on the received RTL design.”
First, Real Intent contends that under the doctrine of prosecution disclaimer, any migration of RTL-level CDC constraints to netlist CDC constraints must be automatic. Real Intent Br. at 8. Synopsys does not dispute that the migrating step must be performed automatically but argues the requirement for automatic migration is already captured in the claim preamble. Synopsys Br. at 13; '057 Patent at 8:61 (stating that that each of the claimed steps are part of “an automated method”), 9:48 (same). The Court agrees that it is redundant to include “automatically” in the construction.
Second, Real Intent contends that the use of “signal mapping heuristics” to migrate RTL-level CDC constraints to netlist CDC constraints is the only embodiment disclosed in the intrinsic record for performing this function. In the Detailed Description, the specification states that “[t]he NCDC [netlist design clock domain crossing checker] migrates constraints . . . by applying multiple signal mapping heuristics.” '057 Patent at 4:29-31. Real Intent reasons that because this description is not prefaced with the phrase, “in one embodiment,” the description is the only embodiment disclosed such that it should be included in the construction. Real Intent Br. at 7-8.
The Court disagrees with Real Intent's interpretation of the specification. The '057 Patent explains that the migrating step “includes identifying and mapping RTL signal names in the received RTL design to corresponding netlist signal names in the received netlist.” '057 Patent at 3:10-15. This process, according to the specification, “may” involve applying one or more of change name rules, bus naming styles, and logic equivalence checking mapping. Id. at 3:15-20. The use of the word “may” suggests that the migrating step does not necessarily involve any of the listed techniques for signal mapping. Indeed, Dr. Taskin opines that a POSITA would understand that the list of techniques is non-exclusive, and that additional methods of signal mapping exist. Taskin Rpt. ¶ 71. Further, the '057 Patent describes the use of a “matching guidance file” with “rules that assist[] the NDC is [sic] matching RTL signal names to netlist signal names.” '057 Patent at Fig. 1, 4:62-64. Dr. Taskin opines that a POSITA would understand that a matching guidance file encompasses both heuristic and exact signal mapping techniques to migrate RTL- level CDC constraints to netlist CDC constraints. Taskin Decl. ¶ 5. This evidence shows that the use of heuristics is an exemplary embodiment, and the claims encompass other, non-heuristic methods as well.
Third, Real Intent contends the intrinsic record confirms that all signal mapping must be performed “on the received RTL design.” Real Intent Br. at 8. The specification does not support this requirement. Rather, the patent describes migration as being performed by “mapping the RTL signal names to the corresponding netlist signal names”; the process is applied to signal names and not to the design as a whole. '057 Patent at 2:51-52 (emphasis added); see also Taskin Rpt. ¶ 72 (“[S]ignal mapping heuristics are used to map RTL-level signal names to netlist-level signal names. Thus, at most, one could say that signal mapping heuristics are applied to RTL-level signal names and not to an RTL design.”).
For the reasons stated above, the Court adopts Synopsys's proposed construction and rejects Real Intent's proposed construction.
F. Identify correspondences between RTL and netlist level crossings (Claims 1, 8, 10)
Synopsys Proposal
Real Intent Proposal
Court's Construction
No construction necessary. Plain and ordinary meaning.
identify equivalent clock domain crossings in the RTL design and the netlist design
No construction necessary. Plain and ordinary meaning.
The crux of the parties' dispute is whether identifying “correspondences” means identifying “equivalent” crossings. Real Intent argues that crossings must be equivalent to correspond while Synopsys maintains that crossings may correspond even if there are slight differences at the RTL and netlist levels. Real Intent Br. at 10; Synopsys Br. at 13. Although “equivalent” may be an acceptable synonym for “correspondence,” the Court agrees with Synopsys that in the context of the '057 Patent, it is not. The '057 Patent uses the word “correspondence”-as well as “corresponds” and corresponding”-to describe a relationship between items. For example, the netlist can correspond to the RTL design. '057 Patent at 2:6064. Similarly, RTL signal names can correspond to netlist signal names (Id. at 2:49-52), RTL- level clock domain crossings can correspond to netlist clock domain crossings (Id. at 2:52-55), and output states can correspond to input states (Id. at 8:11-13).
Nowhere in the specification is “equivalent” and “correspondence” used synonymously. Instead, Real Intent infers from the specification that the claimed invention must be identifying only equivalent clock domain crossings in the RTL design and the netlist design. Real Intent Br. at 10. Specifically, Real Intent relies on the statement that “the netlist may have additional clock domain crossings not present in the RTL, may have clock domain crossings that don't map to RTL, and may have crossings that have become unsynchronized.” '057 Patent at 2:36-39. According to Real Intent, this statement describes three types of netlist crossings that are not equivalent to crossings in the RTL design. But even if that were true-and other than its say-so, Real Intent cites no intrinsic or extrinsic evidence to that effect-it does not shed light on the meaning of “correspondence.” All that Real Intent's argument would show is that a netlist might contain some clock domain crossings that are not equivalent to any in the RTL design. The presence of some non-equivalent crossings does require “correspondence” to mean “equivalent.” Moreover, it is difficult to reconcile Real Intent's proposed construction with Claims 7 and 18 of the '057 Patent. Both of those claims involve reporting the differences between “respective crossings” in the netlist and RTL design. Id. at 9:40-47 (Claim 7); 11:9-16 (Claim 18). Although they do not use the word “correspondence,” the fact that there can be “respective crossings” with differences implies that non-equivalent crossings may be matched with each other for purposes of comparison. Put another way, Claims 7 and 18 imply that non-equivalent correspondences are possible.
Because intrinsic evidence suggests that correspondences need not be equivalent, extrinsic evidence shows that a POSITA would understand “correspondence” in accordance with its plain and ordinary meaning (Taskin Rpt. ¶¶ 76-77), and the Court discerns no other limits on the plain and ordinary meaning of “correspondence” in either the intrinsic or extrinsic evidence, the Court adopts Synopsys's proposed construction.
G. Previously provided by a user for sign-off (Claims 2, 11)
Synopsys Proposal
Real Intent Proposal
Court's Construction
No construction necessary. Plain and ordinary meaning.
finalized by a user after completing the RTL design based
No construction necessary. Plain and ordinary meaning.
The core of the parties' dispute over this term is the level of finality that the term “sign-off” signals. Synopsys asserts that “sign-off” means the CDC constraints are ready for the next stage of the design process but does not foreclose the possibility that engineers may return to the RTL stage if they discover glitches. Synopsys Br. at 15-16. Real Intent disagrees, contending that once sign-off has been given, there is no turning back. Real Intent Br. at 12.
The Court concurs with Synopsys. The intrinsic evidence suggests that sign-off is not as final as Real Intent urges. Figure 1 of the '057 Patent illustrates part of the design flow between the RTL and netlist stages. It contains a double arrow between the netlist CDC checker and the RTL-level CDC constraints, indicating that the RTL-level CDC constraints can feed into the netlist CDC checker, but the netlist CDC checker can also provide changes to the RTL-level CDC constraints. This demonstrates that the design process is iterative, and sign-off to proceed to the netlist stage does not prevent return to the RTL stage. Extrinsic evidence from Dr. Taskin comports with that understanding. He explains that “CDC constraints are never finalized in the design process” because a designer can always add to or revise those constraints. Taskin Rpt. ¶ 86. He also notes that the circuit design process is iterative, and “errors in the circuit design found in later levels of the design process may be addressed by correcting the RTL design.” Id. ¶ 87. Real Intent's only evidence to the contrary is an extrinsic user manual that implies sign-off is final. Hucek Decl., Ex. G at 6. But how a user chooses to deploy an invention does not supply limitations to the invention itself. At most, the manual offers a suggestion for how Synopsys believes engineers should use its software, not how it must be used. In light of the intrinsic evidence and Dr. Taskin's opinions, the Court finds that the user manual does not limit the claims of the '057 Patent. As a result, the Court adopts Synopsys's proposed construction.
V. CONCLUSION
For the reasons set forth above, the Court construes the disputed terms as follows:
Claim Terms
Court's Construction
Clock domain crossing (CDC) / CDC (Claims 1-2, 4, 6-8, 10-12, 15, 17-18)
the sending and receiving of signals between at least two sections of a circuit design driven by different clocks
Asynchronous clock domain crossings (Claims 1, 8, 10)
clock domain crossings between clocks with a variable phase relationship
Register transfer-level (RTL) design / RTL design (Claims 1, 3, 6-8, 10, 12, 14, 17)
description of a digital electronic circuit at the register level written in a behavioral hardware design language such as Verilog or VHDL
RTL-level CDC constraints (Claims 1, 8, 10)
one or more limits on parameter values for a clock signal identified by its RTL-level name
Netlist CDC constraints (Claims 1, 8, 10)
one or more limits on parameter values for a clock signal identified by its gate-level netlist name
Migrat[e/ing] . . . the RTL level CDC constraints to netlist CDC constraints / migrating RTL-level CDC constraints to netlist CDC constraints (Claims 1, 8, 10, 12)
creating netlist CDC constraints from RTL- level CDC constraints
Identify correspondences between RTL and netlist level crossings (Claims 1, 8, 10)
No construction necessary. Plain and ordinary meaning.
Previously provided by a user for sign-off (Claims 2, 11)
No construction necessary. Plain and ordinary meaning.
IT IS SO ORDERED.