DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Office Action responds to the Application and preliminary amendment filed on 2/28/2023, IDS filed on 2/28/2023, 3/14/2025 and 8/21/2025. Claims 1-19,21 are pending, wherein claims 1-19 have been amended, claim 20 has been cancelled and claim 21 has been newly added.
Information Disclosure Statement
The information disclosure statement filed 3/14/2025 fails to comply with 37 CFR 1.98(a)(3)(i) because it does not include a concise explanation of the relevance, as it is presently understood by the individual designated in 37 CFR 1.56(c) most knowledgeable about the content of the information, of each reference listed that is not in the English language, wherein all references cited have been considered except for WEI WEIWEI ET AL.("The road to advanced chip design - In-depth understanding of the SpyGlass CDC process (Pa 1)"; 2020-03-25; https://zhuanlan.zhihu.com/p/116888880, pp. 1-12) which is NOT in the English language and there’s no concise explanation of relevance as noted above, wherein although there are some English texts in this document, the relevance of this document as a whole cannot be determined without full text English translation. It has been placed in the application file, but the information referred to therein has not been considered.
Drawings
Figures 1 and 2 should be designated by a legend such as --Prior Art-- because only that which is old is illustrated (see Applicant’s specification, paragraphs [0005]-[0006], [0025] being part of the background art or typical assertion-based verification methods). See MPEP § 608.02(g). Corrected drawings in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 14, 21 are objected to because of the following informalities:
As per claim 13, “the simulation argument files and the formal files” (line 2) should be –the simulation setup files and the formal analysis files” for proper antecedent basis.
As per claim 14, “the simulation argument files employ” (line 2) should be –simulation argument files are employed using—for proper antecedent basis.
As per claim 21, --further—should be inserted after “instructions” (line 3) to properly define the further limitations.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11,15-19,21 is/are rejected under 35 U.S.C. 103 as being obvious over Ayari et al. ("Don't Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon”, Verification Horizons, Vol. 15, No. 3, 31 December, pp. 30-37) in view of Bisht et al. (“Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon”, Verification Horizons, Verification Academy, 30 June 2019, 8 pages).
The applied reference has a common joint inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2).
This rejection under 35 U.S.C. 103 might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
As per claims 1-3, 6,19, 21, Ayari et al. disclose the elements of the claim as illustrated in Fig. 1, comprising:
extracting, from a CDC static analysis database, information regarding the presence of structures is performed as part of CDC static analysis (i.e., extraction or identification of the presence of synchronization structures—see page 31, left column, 3rd paragraph) in the CDC path(s) and any associated CDC protocol assertions and functional coverage (see page 31, 3rd paragraph as part of CDC protocol assertions generation; see also page 31, right column, last paragraph, i.e., synchronizers are verified which necessarily involve extraction or identification of the synchronizers; see also, page 32, left column, 1st paragraph where assertions are generated based on the sychronizer);
binding the CDC protocol assertions and functional coverage to the RTL design in a bind file (“SystemVerilog assertion and SystemVerilog bind files must be added to the formal and simulation environments”…”so designers can easily add protocol assertions and can avoid manually adding multiple assertions and bind module files to their simulation”—page 31, left column, last paragraph; see also page 32, left column, last paragraph to right column, 1st paragraph);
generating formal analysis and simulation setup files from the RTL design, setup and constraint data for the CDC path extracted from the static CDC analysis database and compiling the bind files using the generated formal analysis and simulation setup files (see page 32, right column, 2nd paragraph);
running formal analysis of the RTL design to determine proven and non-proven CDC protocol assertions (see page 32, right column, last paragraph);
updating the simulation setup files to turn off the proven CDC protocol assertions (see page 33, left column, 1st and 2nd paragraphs)
running the simulation of the RTL design with the non-proven protocol assertions and functional coverage (see page 33, left column, 1st paragraph);
updating a centralized results database with the results of both the formal analysis and the simulation of the RTL design (Fig. 1 shows both “Static formal analysis” and “simulation” which are updated in the central database represented as “Proven Assertions” and “Covered Assertions”; page 33, left-hand column, 3rd paragraph, "Review and Debug CDC Protocol Results: Review the aggregated structural CDC analysis, formal verification, and simulation results. The correlation between the multiple technologies (static CDC analysis, formal model checking, simulation) enables designers to more quickly"); and
generating a visualization of the formal analysis and simulation results for at least one of reviewing or debugging (see page 33, left column, 3rd paragraph; see Fig. 1, “Review Assertion Violations” with the visualization screen);
wherein the data processing system comprising a processor, non-transitory computer-readable storage medium that stores instructions to perform this methodology, are inherently part of the computer-implemented methodology of Ayari et al. (see page 30 and Fig. 1) being necessary to perform the computer-implemented methodology as is known in the art.
However, Ayari et al. failed to teach that each CDC path is allocated a persistent unique identifier, and wherein the centralized results database is updated using the persistent unique identifier to label the associated CDC protocol assertions, functional coverage and results of the formal analysis and simulation. Such use of persistent unique identifier is taught in Bisht et al. as part of the same proposed methodology (see page 5, Fig. 7 which contains unique identifier under “CD_ID” as shown are a combination of text and numerical characters, which are associated with the CDC protocol assertions (i.e., “Protocol ID”), coverage, formal analysis results and simulation results) were presented later in more detail description by Ayari et al.. It would have obvious to one of ordinary skilled in the art at the time of the effective filing date of the invention to further incorporate the teachings of Bisht et al. into the method/system of Ayari et al. because such incorporation would further allow the method/system of Ayari et al. to help ensure that the bugs are not missed and protocols for synchronizers on CDC paths are not violated as taught by Bisht et al. (see page 5, number 6 of the proposed methodology).
As per claims 4-5, Bisht et al. further teach that the unique identifiers are added to the CDC path as shown in Fig. 7, as part of the “CD_ID” which identifies the CDC path and are added to the assertion under the corresponding “Protocol ID”, which are associated with the particular structures as shown in Fig. 7.
As per claim 7, Ayari et al. in view of Bisht et al. teach all of the elements of claim 1, from which the claim depends, as discussed in the rejection of claim 1 above, wherein since the methodology of Ayari et al. identifies or verifies the structures in the CDC path, from which the associated CDC protocol assertions are generated based on these structures (see page 31, last paragraph to page 32, first paragraph), in the event that there is an absence of structures in the CDC path, it would have been obvious to one of ordinary skilled in the art at the time of the effective filing data of the invention, to further generate the associated CDC protocol assertions that are based accordingly on the absence of the structure since the methodology provides for automatic protocol assertions generation.
As per claim 8, Ayari et al. further teach that the non-proven CDC protocol assertions are violated or inconclusive (see page 33, 1st and last paragraphs).
As per claim 9, Ayari et al. further teach that during formal analysis, a counter-example is generated indicating a stimulus that violates a CDC protocol assertion (page 33, right column, 3rd paragraph).
As per claim 10-12, Ayari et al. further teach that during formal analysis, a sanity waveform is generated for proven CDC protocol assertions indicating a stimulus that violates or does not violate a CDC protocol assertion (see Fig. 1, waveforms displayed associated with “Review Assertion Violations”).
As per claim 15, Ayari et al. teach further teach the updating the static CDC analysis database with results information for the CDC protocol assertion and functional coverage (see page 33, 1st to 3rd paragraphs).
As per claims 16-17, Ayari et al. further teach that the CDC protocol assertions and functional coverage are SystemVerilog Assertions (SVAs) and SystemVerilog coverpoints and covergroups (see page 31, left column, last paragraph to right column, 1st paragraph; page 32, left column, last paragraph to right column, 1st paragraph).
As per claim 18, the setup files include simulation compile and simulation argument files; formal analysis compile and run scripts; and formal analysis constraints files (see page 32, right column, 1st to 3rd paragraphs).
Claims 13-14 is/are rejected under 35 U.S.C. 103 as being obvious over Ayari et al. ("Don't Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon”, Verification Horizons, Vol. 15, No. 3, 31 December, pp. 30-37) in view of Bisht et al. (“Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon”, Verification Horizons, Verification Academy, 30 June 2019, 8 pages) and Synopsys, (“SystemVerilog for RTL Modeling, Simulation, and Verification--Introduction”, https://systemverilog.dev/9.htlm#,1800-2023, first appear in 2002, chapter 9, 35 pages).
As per claim 13, Ayari et al. in view of Bisht et al. teach all of the elements of claim 8, from which the claim depends, as discussed in the rejection of claim 8 above, wherein Ayari et al. teach that the simulation setup files including simulation argument file(s) and the formal (analysis) files of are used to control what are to be formally verified and simulated, and allowing for automatically updating the simulation setup and formal analysis re-run (see Ayari et al., page 33, 1st to 3rd paragraphs), including use SystemVerilog to perform this formal analysis and simulation (see Ayari et al., page 31, left column, last paragraph; see also page 32, left column, last paragraph to right column, 1st paragraph). However, Ayari et al. in view of Bisht et al. failed to particular teach the use of callback function to update the centralized results database. Such use of callback function is taught by Synopsys as part of the SystemVerilog language specification Synopsys teaches that callbacks (i.e., callback functions, including PLI) are the most common way in SystemVerilog to interact with the simulation and inject custom logic to various places (see section 9.1.2). It would have
been obvious to one of ordinary skilled in the art at the time of the effective date of the invention to further make use of the callback functions as defined in SystemVerilog as taught by Synopsys, to update the centralized results database is enabled, because such incorporation would allow for updating the centralized database in SystemVerilog as taught by Synopsys while providing the desired updating functionality as taught by Ayari et al. in view of Bisht et al..
As per claim 14, , Ayari et al. in view of Bisht et al. teach all of the elements of claim 12, from which the claim depends, as discussed in the rejection of claim 12 above, wherein Ayari et al. teach that the simulation setup files including simulation argument file(s) and the formal (analysis) files for capturing/storing assertion information including proven and unproven assertions performed during formal analysis and simulation run and re-runs (i.e., validity of the assertions) (see Ayari et al., page 33, 1st to 3rd paragraphs), and using SystemVerilog to perform this formal analysis and simulation (see Ayari et al., page 31, left column, last paragraph; see also page 32, left column, last paragraph to right column, 1st paragraph). However, Ayari et al. in view of Bisht et al. failed to particular teach the use of a PLI callback function a PLI callback function to capture assertion information comprising data showing whether a stimulus violated a CDC protocol assertion or not. Such use of a PLI callback function is taught by Synopsys as part of the SystemVerilog language specification Synopsys teaches that callbacks (i.e., callback functions, including PLI functions) are the most common ways in SystemVerilog to interact with the simulation and inject custom logic to various places (see section 9.1.2). ). It would have been obvious to one of ordinary skilled in the art at the time of the effective date of the invention to further make use of the PLI callback functions as defined in SystemVerilog as taught by Synopsys, to assertion information comprising data showing whether a stimulus violated a CDC protocol assertion or not, because such incorporation would allow for capturing/storing of assertion in SystemVerilog as taught by Synopsys while providing the capturing/storing functionality as taught by Ayari et al. in view of Bisht et al..
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHALLAKA KIK whose telephone number is (571)272-1895. The examiner can normally be reached Maxiflex Mon-Fri 8:30AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jack Chiang can be reached at 5712727483. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Any response to this action should be mailed to:
Commissioner for Patents
P. O. Box 1450
Alexandria, VA 22313-1450
or faxed to:
571-273-8300
/PHALLAKA KIK/Primary Examiner, Art Unit 2851 December 26, 2025