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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 contains the trademark/trade name “Codasip Architecture Language”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe the source of the programming language and, accordingly, the identification/description is indefinite.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Prikryl (US 20150234965 A1).
Regarding Claim 1, Prikryl teaches:
A method for a design of a processor's programming and/or simulation tools, comprising: (¶2 automatic processor design and verification; ¶30 automatically generates the programming and simulation tools)
developing a single model of a processor (¶14 Since there is only single model; ¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results.; ¶40 The reference model 128 prepares expected outputs for the designed ASIP.; examiner notes the reference enummerates how its single model functions in ¶34-40)
from a group consisting of: the processor; (¶26 a conceptual structure and information flow among elements of the conceptual structure for design and verification of an application-specific instruction-set processor.; ¶37 The ASIC/FPGA synthesis module 126 takes hardware description 124 and creates a description for the target hardware technology, e.g., silicon chip, or an FPGA; see also ¶34-36 in general)
a hardware description of the processor; and (¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106.; ¶37 The ASIC/FPGA synthesis module 126 takes hardware description 124 and creates a description for the target hardware technology, e.g., silicon chip, or an FPGA.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
a processor's specifications confirmed to represent the processor and/or the hardware description; and (¶27 The specifications may change during the design process based on results of ASIP simulation, synthesis, and/or verification.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106 ... The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute.; ¶45 The generated verification environment carries a verification of the ASIP design by verifying the generated hardware description 124 against the reference model 128)
generating automatically by an Electronic Design Automation tool the processor's programming and/or the simulation tools from the single model of the processor (¶27 The design process starts by determining requirements for a newly developed ASIP in accordance with the target application, resulting in ASIP specifications 102, which determine tools and ASIP design generated by an EDA tool as disclosed infra.)
and a set of design parameters. (¶27 Such ASIP specifications 102 comprise a separate description of an instruction set specifications and a micro-architecture specification.)
Regarding Claim 2, Prikryl teaches:
developing the single model in a language designed to unify a description of an instruction set and a description of a micro-architecture. (¶10 The second category allows to describe and modify all parts of ASIP. Examples of this category are Language for Instruction Set Architectures (LISA), nML, Codasip Architecture Language (CodAL).)
Regarding Claim 3, Prikryl teaches:
wherein the language, comprises: a Codasip Architecture Language. (¶10 The second category allows to describe and modify all parts of ASIP. Examples of this category are Language for Instruction Set Architectures (LISA), nML, Codasip Architecture Language (CodAL).)
Regarding Claim 4, Prikryl teaches:
wherein the set of design parameters is empty. (¶28 The EDA tool 108 is agnostic to whether the IA model 104 and the CA model 106 are template-based or fully configurable.; ¶29 Additional inputs to the EDA tool 108 may comprise optional design parameters 107 influencing the behavior of the EDA tool 108.; ¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36)
Regarding Claim 5, Prikryl teaches:
generating automatically by the Electronic Design Automation tool a verification environment in addition to the programming and/or the simulation tools from the single model of the processor; and verifying the programming tools by the verification environment by: (¶28; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
executing at least one verification application and optional port(s) value(s) on a reference entity resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one value; (¶40 Were the reference model 128 be generated from the final CA model 106, a potential error/irregularity existing in the final CA model 106 would be reflected in both the generated hardware description 124 and the reference model 128; consequently, the verification process would be unable to discover this error/irregularity.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106. The generated verification environment 130 comprises a program specifying usage of a set of tools, libraries and/or functions designed to support verification. In particular, the verification environment 130 program creates instances of the drivers and conceptual structures, defines relationships there-between, as disclosed in reference to FIG. 2 infra. )
determining whether the at least one value characterizing each of the at least one state agrees with at least one expected value characterizing each of the at least one state; and providing the processor's programming tools when the determining shows agreement. (¶37 the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.; ¶41 The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute; ¶42 Because the programming and simulation tools are generated from both the final IA model 104 and the final CA model 106 and the EDA tool 108 extracts parameters describing the micro-architecture from the final CA model 106, the programming tools are aware of a micro-architecture of the ASIP. Therefore, the verification environment 130 is also able to verify that the programming tools are correctly aware of the micro-architecture of the ASIP.)
Regarding Claim 6, Prikryl teaches:
modifying the developed single model of the processor when the determining does not show agreement; and repeating the method as claimed in independent claim 1. (¶35 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results.; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
Regarding Claim 7, Prikryl teaches:
at least one verification application forms a set of pre-prepared verification applications provided by the Electronic Design Automation tool, wherein each verification application includes at least one expected value. (¶40 The reference model 128 prepares expected outputs for the designed ASIP; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106.)
Regarding Claim 8, Prikryl teaches:
generating by the Electronic Design Automation tool from the single model of the processor automatically a random program generator; and (¶32 a random generator of assembly language application(s) may be used.; ¶33 The assembly language representation of the application(s) 120, obtained by either aspect supra, is provided to the assembler 112, which produces a binary representation of the application(s) in a form of one or more object files.)
generating the at least one verification application and the at least one expected value characterizing each of the at least one state by the random program generator. (¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106. The hardware description 124 comprises generated hardware implementation in the language for hardware description and a relevant test environment; see the citations regarding verification presented for claim 5)
Regarding Claim 9, Prikryl teaches:
wherein the reference entity is the processor or a third-party simulator (¶28 In yet another aspect, the IA model 104 and/or the CA model 106 may be produced by/for the specific EDA tool 108 and supplied by a third party.)
Regarding Claim 10, Prikryl teaches:
generating automatically by the Electronic Design Automation tool a verification environment in addition to the programming and/or the simulation tools from the single model of the processor; and verifying the simulation tools by the verification environment by: (¶28; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
verification application and optional port(s) value(s) on the simulation tools, resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one first value; (¶47 the verification environment 230 is a program comprising instructions for the set of tools, libraries and/or functions designed to support verification to create drivers, structures, interfaces to models to be verified, and relations there-between. Thus, on the conceptual level, the verification environment 230 is divided into a predicted results unit 232, and a monitor unit 234.; see the discussion of the reference in ¶47-55, which falls within the scope of the verification claimed here)
executing the at least one verification application and optional port(s) value(s) on a reference entity, resulting in at least one state of the at least one resource, each of the at least one state being characterized by at least one second value; (¶40 Were the reference model 128 be generated from the final CA model 106, a potential error/irregularity existing in the final CA model 106 would be reflected in both the generated hardware description 124 and the reference model 128; consequently, the verification process would be unable to discover this error/irregularity.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106. The generated verification environment 130 comprises a program specifying usage of a set of tools, libraries and/or functions designed to support verification. In particular, the verification environment 130 program creates instances of the drivers and conceptual structures, defines relationships there-between, as disclosed in reference to FIG. 2 infra. )
determining whether the at least one first value characterizing each of the at least one state agree with the at least one second value characterizing each of the corresponding at least one state; and providing the processor's simulation tools when the determining shows agreement. (¶37 the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.; ¶41 The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute; ¶42 Because the programming and simulation tools are generated from both the final IA model 104 and the final CA model 106 and the EDA tool 108 extracts parameters describing the micro-architecture from the final CA model 106, the programming tools are aware of a micro-architecture of the ASIP. Therefore, the verification environment 130 is also able to verify that the programming tools are correctly aware of the micro-architecture of the ASIP.)
Regarding Claim 11, Prikryl teaches:
modifying the developed single model of the processor when the determining does not show agreement; and repeating the method as claimed in independent claim 1. (¶35 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results.; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
Regarding Claim 12, Prikryl teaches:
at least one verification application forms a set of pre-prepared verification applications provided by the Electronic Design Automation tool, wherein each verification application includes at least one expected value. (¶40 The reference model 128 prepares expected outputs for the designed ASIP; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106.)
Regarding Claim 13, Prikryl teaches:
generating by the Electronic Design Automation tool from the single model of the processor automatically a random program generator; and (¶32 a random generator of assembly language application(s) may be used.; ¶33 The assembly language representation of the application(s) 120, obtained by either aspect supra, is provided to the assembler 112, which produces a binary representation of the application(s) in a form of one or more object files.)
generating the at least one verification application and the at least one expected value characterizing each of the at least one state by the random program generator. (¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106. The hardware description 124 comprises generated hardware implementation in the language for hardware description and a relevant test environment; see the citations regarding verification presented for claim 5)
Regarding Claim 14, Prikryl teaches:
wherein the reference entity is the processor or a third-party simulator. (¶28 In yet another aspect, the IA model 104 and/or the CA model 106 may be produced by/for the specific EDA tool 108 and supplied by a third party.)
Regarding Claims 15-22:
Claims 15-22 are substantively similar to claims 1, 4-6, 9-11, and 14 respectively. They are rejected under the same grounds as those presented for claims 1, 4-6, 9-11, and 14 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20190258755 A1 discloses a unified model of a network device that falls within the scope of claim 1, see ¶7, 9-10, 12-13, 29-32, 36-37, and 58-60.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIJAN MAPAR whose telephone number is (571)270-3674. The examiner can normally be reached Monday - Thursday, 11:00-8:30.
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, Rehana Perveen can be reached at 571-272-3676. 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.
/BIJAN MAPAR/ Primary Examiner, Art Unit 2189