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 communication is responsive to application filed on 09/22/2023.
Claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/22/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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, 10, 11, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US Publication No. 2006/0015313 A1 issued to Wang et al.
Claim 1. Wang et al discloses a method comprising:
generating configuration data by a design tool to implement circuitry for emulation of a design-under-test (DUT) on programmable logic of a system-on-chip (SoC) (See: Abstract, A co-verification system includes a computer programmed to act as a simulator for simulating behavior of a first portion of an electronic device under test (DUT) by acquiring, processing and generating data representing DUT signals. The co-verification system also includes emulation resources programmed to emulate a second portion of the DUT by receiving, processing and generating emulation signals representing DUT signals. The signals of the DUT are mapped to separate addresses within a memory space, and the simulator controls and reads states of emulation signals by writing data to and reading data from addresses of the memory space states mapped to the DUT signals the emulation signals represent; [0069] A co-validation system is particularly suitable for emulating "System-On-Chip" (SoC) integrated circuits that may include embedded processors, memories and other large, standardized intellectual property (IP) components);
generating testbench executable code from testbench source code by the design tool, wherein the testbench executable code is configured to generate stimuli to the circuitry on the programmable logic (See: [0014] FIG. 5 is a dataflow diagram illustrating how various parts of co-verification system 40 of FIG. 4 might implement an IC device under test (DUT) and the various test functions of a testbench using a co-verification process to simulate and emulate various modules of the DUT. The netlist included in the testbench describes the DUT as having several modules, and in this example workstation 46 simulates some of the DUT modules 60 while resource boards 42 emulate other DUT modules. In this example, software within workstation 46 also handles the test vector generation 62 and data acquisition 64 functions specified by the testbench); and
configuring a processor of the SoC to execute the testbench executable code and the programmable logic to implement the circuitry for emulation of the DUT (See: [0041] A netlist is a computer-readable data structure modeling an electronic circuit such as an integrated circuit (IC) or a portion of an IC. A netlist model of a circuit references each component of the circuit and indicates how nets are to interconnect terminals of the components to one another and to the circuit's input and output terminals. A testbench is a data structure that includes a netlist modeling a circuit, along with a model of the time varying behavior of the input signals to be applied to the circuit during a test. The testbench will also indicate which of various signals of interest produced by the circuit in response to the input signals are to be monitored during the test; [0042] A circuit simulator is a computer programmed to simulate and test the behavior of a circuit described by a netlist by calculating the states of the signals to be monitored when the circuit is stimulated by input signals having the behavior described by the testbench. A circuit emulator employs programmable logic devices such as FPGAs to emulate the behavior of a circuit described by a netlist in response to input signals described by the testbench. An emulator will typically employ a programmable pattern generator to stimulate the emulated DUT with input signals having the behavior described by the testbench, and will employ a data acquisition system to sample the circuit signals during the test to provide data representing circuit behavior. The invention relates to a co-verification system that uses one or more computers to simulate some portions of a circuit described by a netlist while using programmable logic devices and/or other hardware resources to emulate other portions of the circuit).
Claim 10. Wang et al discloses the method of claim 1, wherein: the SoC includes a plurality of processors, and the plurality of processors includes a first processor and a second processor (See: [0013] An IC may include large standardized components such embedded computer processors and memories, and in lieu of using programmable logic devices to emulate the behavior of such components, system 40 of FIG. 4, acting a "co-verification system" may employ a suitably programmed workstation 46 to simulate the behavior of an embedded processor and memory while the FPGAs 44 emulate various logic blocks of the IC; [0069] A co-validation system is particularly suitable for emulating "System-On-Chip" (SoC) integrated circuits that may include embedded processors, memories and other large, standardized intellectual property (IP) components. FIG. 10 depicts the components of a typical SoC IC 140 including a standard processor 141 a standard memory 142, and various other components including a DMA bus master 143, a computer bus 144, a UART 145, a timer 146, a keypad I/O port 147 and a PIO port 148, a peripheral bus 149, and a bridge 150 linking buses 144 and 149. An IC may also include, for example, an application specific integrated circuit (ASIC) 152 and a memory 154 accessed by the ASIC); generating the testbench executable code (See: [0041] A netlist is a computer-readable data structure modeling an electronic circuit such as an integrated circuit (IC) or a portion of an IC. A netlist model of a circuit references each component of the circuit and indicates how nets are to interconnect terminals of the components to one another and to the circuit's input and output terminals. A testbench is a data structure that includes a netlist modeling a circuit, along with a model of the time varying behavior of the input signals to be applied to the circuit during a test. The testbench will also indicate which of various signals of interest produced by the circuit in response to the input signals are to be monitored during the test) includes: partitioning the testbench source code into a plurality of partitions, and the plurality of partitions includes a first partition and a second partition (See: [0101] At step 110 of FIG. 9, the workstation allocates the various co-validation system resources for simulating or emulating each portion of the electronic circuit described by the netlist and also allocates resources for handling the vector generation and data acquisition functions described in the testbench. FIG. 18 depicts step 110 in more detail, with respect to the manner in which the workstation allocates FPGAs for emulating portions of the testbench. At step 180 the workstation carries out a main partitioning process in which it determines which portions of the testbench are to be simulated or emulated by the workstation, the FPGAs, and other resources), and compiling the first partition into first executable code, and compiling the second partition into second executable code (See: [0006] he testbench also indicates which IC signals that are to be monitored during the simulation. A compiler 16 then generates a program for a computer-based simulator 20 based on the testbench 10 and on the behavioral descriptions provided by the cell library 18 of instances of cells to be incorporated into the IC; [0009] As illustrated in FIG. 2 one or more compilers 24 compile the netlist 12 describing the IC and the cell library description of the cells to be included the IC into programs for the PLDs and any other programmable resources included in emulator 26. Another compiler 28 compiles the vector file 14 into a program for a pattern generator 30 for providing input signals to emulator 26. Compiler 28 also compiles a program for a data acquisition system 32, such as a logic analyzer, for monitoring various signals within emulator 26 to determine how the emulated circuit behaves in response to the input signals provided by pattern generator 30); and configuring the processor includes configuring the first processor to execute the first executable code and configuring the second processor to execute the second executable code).
As per Claims 11 and 19: The instant claims recite substantially same limitation as the above rejected claims 1 and 10 and therefore rejected under the same rationale.
20. Wang et al discloses a system-on-chip (SoC), comprising: programmable logic circuitry configured to emulate a design-under-test (DUT) (See: [0003] The present invention relates to a co-verification system employing programmable logic devices and other resources for verifying the behavior of an electronic circuit described by a netlist, and in particular to a method of programming such a co-verification system; [0009] As illustrated in FIG. 2 one or more compilers 24 compile the netlist 12 describing the IC and the cell library description of the cells to be included the IC into programs for the PLDs and any other programmable resources included in emulator 26. Another compiler 28 compiles the vector file 14 into a program for a pattern generator 30 for providing input signals to emulator 26. Compiler 28 also compiles a program for a data acquisition system 32, such as a logic analyzer, for monitoring various signals within emulator 26 to determine how the emulated circuit behaves in response to the input signals provided by pattern generator 30; [0013] An IC may include large standardized components such embedded computer processors and memories, and in lieu of using programmable logic devices to emulate the behavior of such components, system 40 of FIG. 4, acting a "co-verification system" may employ a suitably programmed workstation 46 to simulate the behavior of an embedded processor and memory while the FPGAs 44 emulate various logic blocks of the IC; [0042] A circuit simulator is a computer programmed to simulate and test the behavior of a circuit described by a netlist by calculating the states of the signals to be monitored when the circuit is stimulated by input signals having the behavior described by the testbench. A circuit emulator employs programmable logic devices such as FPGAs to emulate the behavior of a circuit described by a netlist in response to input signals described by the testbench. An emulator will typically employ a programmable pattern generator to stimulate the emulated DUT with input signals having the behavior described by the testbench, and will employ a data acquisition system to sample the circuit signals during the test to provide data representing circuit behavior. The invention relates to a co-verification system that uses one or more computers to simulate some portions of a circuit described by a netlist while using programmable logic devices and/or other hardware resources to emulate other portions of the circuit); and a processor coupled to the programmable logic circuitry and configured to execute testbench executable code that generates stimuli to the DUT (See: [0013] An IC may include large standardized components such embedded computer processors and memories, and in lieu of using programmable logic devices to emulate the behavior of such components, system 40 of FIG. 4, acting a "co-verification system" may employ a suitably programmed workstation 46 to simulate the behavior of an embedded processor and memory while the FPGAs 44 emulate various logic blocks of the IC; [0014] FIG. 5 is a dataflow diagram illustrating how various parts of co-verification system 40 of FIG. 4 might implement an IC device under test (DUT) and the various test functions of a testbench using a co-verification process to simulate and emulate various modules of the DUT. The netlist included in the testbench describes the DUT as having several modules, and in this example workstation 46 simulates some of the DUT modules 60 while resource boards 42 emulate other DUT modules).
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-4, 6, 8, 9, 12-14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2006/0015313 A1 issued to Wang et al in view of US Patent No. 8, 099, 271 B2 issued to Schubert et al.
Claim 2. Wang et al discloses the method of claim 1. However, Wang et al discloses a programmable logic. Wang et al does not specify but Schubert et al discloses generating instrumentation code to execute on the processor; generating configuration data to implement an instrumentation interface as circuitry (See: Col. 13 lines 24-36, The basic instrumentation processing 200 initially receives 202 a HDL description for an electronic system. The HDL description is then analyzed 203 to understand the characteristics of the electronic system. Next, parts (or portions) of the electronic system that are to be examined and/or modified are determined 204. Typically, the parts of the electronic system to be examined and/or modified (e.g., instrumented) are within a DUT such as the DUT 102 illustrated in FIGS. 1A and 1B. Hence, the parts of the electronic system to be examined and/or modified represent various signals and/or components within the DUT. After the parts of the electronic system to be examined and/or modified have been determined 204, design instrumentation circuitry (DIC) is generated 206; Col. 21 lines The instrumentation system 700 receives a HDL description 702 of an electronic system. A Design Instrumentation (DI) graphical user interface 704 can display the HDL description on a display device. A user can interact with the graphical user interface 704 to make or enter instrumentation directives. A front-end module 706 receives the HDL description 702 and parses the HDL description 702 to form a parse-tree structure. The resulting parse-tree structure is stored in a parse-tree database 708. A code generation module 710 reads the parse-tree structure from the parse-tree database 708 and produces a hierarchical design representation associated with the electronic system); and configuring the processor to execute the instrumentation code and the programmable logic to implement the instrumentation interface (See: Col. 6 lines 48-52, as an integrated circuit product, one embodiment of the invention includes at least: circuitry that implements functionality of the integrated circuit product, and customized instrumentation circuitry that enables internal signals produced by the circuitry to be examined and/or modified; Col. 9 lines 9-17, A "PLD" is an Programmable Logic Device. PLDs are electronic components that have a configurable function. These devices are able to change their functionality via an information stream transferred to the device. These electronic components are available from a number of different suppliers in a wide range of sizes and speeds. One example of these devices are the Apex PLD devices from Altera Corporation in San Jose, Calif. A PLD design may be described using HDL and implemented using synthesis).
It would have been obvious before the effective filing date to combine design instrumentation circuitry as taught by Schubert et al to method of programming a co-verification system of Wang et al would be to efficiently debugging general hardware of electronic systems (Schubert et al, Col. 1 lines 20-21).
Claim 3. Schubert et al discloses the method of claim 2, wherein generating the instrumentation code includes generating instrumentation code that communicates directly with the circuitry of the instrumentation interface (See: Col. 13 lines 24-36, The basic instrumentation processing 200 initially receives 202 a HDL description for an electronic system. The HDL description is then analyzed 203 to understand the characteristics of the electronic system. Next, parts (or portions) of the electronic system that are to be examined and/or modified are determined 204. Typically, the parts of the electronic system to be examined and/or modified (e.g., instrumented) are within a DUT such as the DUT 102 illustrated in FIGS. 1A and 1B. Hence, the parts of the electronic system to be examined and/or modified represent various signals and/or components within the DUT. After the parts of the electronic system to be examined and/or modified have been determined 204, design instrumentation circuitry (DIC) is generated 206).
Claim 4. Wang et al discloses the method of claim 2, wherein: configuring the processor includes configuring the SoC to boot the operating system on the processor (See: [0069] A co-validation system is particularly suitable for emulating "System-On-Chip" (SoC) integrated circuits that may include embedded processors, memories and other large, standardized intellectual property (IP) components. FIG. 10 depicts the components of a typical SoC IC 140 including a standard processor 141 a standard memory 142, and various other components including a DMA bus master 143, a computer bus 144, a UART 145, a timer 146, a keypad I/O port 147 and a PIO port 148, a peripheral bus 149, and a bridge 150 linking buses 144 and 149. An IC may also include, for example, an application specific integrated circuit (ASIC) 152 and a memory 154 accessed by the ASIC; [0070] When processing a testbench including a description of SoC 140, the workstation 72 determines at step 110 (FIG. 6) the nature of the various modules of the SoC DUT and other portions of the testbench to be verified and then allocates available emulation resources for verifying each component. Since the IP component designers will have already tested the functionality of IP components such as processor 141 and memory 142 that may be included in SoC 140, a system for emulating SoC 140 employing an IP component need only simulate or emulate the behavior of those IP components at a relatively high level of abstraction, a task which for a suitably programmed workstation is well-suited).
Wang et al does not specify but Schubert et al discloses generating the instrumentation code includes generating instrumentation code that interfaces with an operating system (See: Col. 17 line 66 through Col. 18 line 3, The selection processing 500 initially displays 502 a HDL description. The 1-IDL description pertains to the electronic system. At this point, a user can interact with a graphical user interface to make a specific instrumentation directive with respect to the HDL description being displayed).
It would have been obvious before the effective filing date to combine design instrumentation circuitry as taught by Schubert et al to method of programming a co-verification system of Wang et al would be to efficiently debugging general hardware of electronic systems (Schubert et al, Col. 1 lines 20-21).
Claim 6. Wang et al discloses the method of claim 2, wherein: the testbench source code includes hardware description language (HDL) code (See: [0056] A circuit designer typically generates a conventional hardware description language (HDL) "testbench" including a netlist description of the IC device under test (DUT). The testbench includes the netlist description of a DUT and describes the time-varying behavior of test signals (vectors) to be applied to inputs of the DUT. The testbench also identifies various signals within the DUT that are to be monitored during the verification process); generating the testbench executable code includes generating code that interfaces with an HDL simulator (See: Abstract, A co-verification system includes a computer programmed to act as a simulator for simulating behavior of a first portion of an electronic device under test (DUT) by acquiring, processing and generating data representing DUT signals. The co-verification system also includes emulation resources programmed to emulate a second portion of the DUT by receiving, processing and generating emulation signals representing DUT signals; [0014] FIG. 5 is a dataflow diagram illustrating how various parts of co-verification system 40 of FIG. 4 might implement an IC device under test (DUT) and the various test functions of a testbench using a co-verification process to simulate and emulate various modules of the DUT. The netlist included in the testbench describes the DUT as having several modules, and in this example workstation 46 simulates some of the DUT modules 60 while resource boards 42 emulate other DUT modules. In this example, software within workstation 46 also handles the test vector generation 62 and data acquisition 64 functions specified by the testbench; [0056] A circuit designer typically generates a conventional hardware description language (HDL) "testbench" including a netlist description of the IC device under test (DUT). The testbench includes the netlist description of a DUT and describes the time-varying behavior of test signals (vectors) to be applied to inputs of the DUT. The testbench also identifies various signals within the DUT that are to be monitored during the verification process); generating code that interfaces between the HDL simulator and an operating system (See: [0013] An IC may include large standardized components such embedded computer processors and memories, and in lieu of using programmable logic devices to emulate the behavior of such components, system 40 of FIG. 4, acting a "co-verification system" may employ a suitably programmed workstation 46 to simulate the behavior of an embedded processor and memory while the FPGAs 44 emulate various logic blocks of the IC. During the co-verification process, FPGAs and workstation 46 communicate though backplane wiring in motherboard 45. Processors and memory ICs mounted on other resource boards 48 installed in slots of motherboard 45 can be also used to simulate large component behavior); and configuring the processor includes configuring the SoC to boot the operating system on the processor and execute the HDL simulator (See: [0069] A co-validation system is particularly suitable for emulating "System-On-Chip" (SoC) integrated circuits that may include embedded processors, memories and other large, standardized intellectual property (IP) components. FIG. 10 depicts the components of a typical SoC IC 140 including a standard processor 141 a standard memory 142, and various other components including a DMA bus master 143, a computer bus 144, a UART 145, a timer 146, a keypad I/O port 147 and a PIO port 148, a peripheral bus 149, and a bridge 150 linking buses 144 and 149. An IC may also include, for example, an application specific integrated circuit (ASIC) 152 and a memory 154 accessed by the ASIC; [0070] When processing a testbench including a description of SoC 140, the workstation 72 determines at step 110 (FIG. 6) the nature of the various modules of the SoC DUT and other portions of the testbench to be verified and then allocates available emulation resources for verifying each component. Since the IP component designers will have already tested the functionality of IP components such as processor 141 and memory 142 that may be included in SoC 140, a system for emulating SoC 140 employing an IP component need only simulate or emulate the behavior of those IP components at a relatively high level of abstraction, a task which for a suitably programmed workstation is well-suited).
Wang et al does not specify but Schubert et al discloses generating the instrumentation code (See: Col. 13 lines 24-36, The basic instrumentation processing 200 initially receives 202 a HDL description for an electronic system. The HDL description is then analyzed 203 to understand the characteristics of the electronic system. Next, parts (or portions) of the electronic system that are to be examined and/or modified are determined 204. Typically, the parts of the electronic system to be examined and/or modified (e.g., instrumented) are within a DUT such as the DUT 102 illustrated in FIGS. 1A and 1B. Hence, the parts of the electronic system to be examined and/or modified represent various signals and/or components within the DUT. After the parts of the electronic system to be examined and/or modified have been determined 204, design instrumentation circuitry (DIC) is generated 206).
It would have been obvious before the effective filing date to combine design instrumentation circuitry as taught by Schubert et al to method of programming a co-verification system of Wang et al would be to efficiently debugging general hardware of electronic systems (Schubert et al, Col. 1 lines 20-21).
Claim 8. Schubert et al discloses the method of claim 1, further comprising: generating instrumentation code to execute on the processor; generating configuration data to implement an instrumentation interface as circuitry on the programmable logic (See: Col. 13 lines 24-36, The basic instrumentation processing 200 initially receives 202 a HDL description for an electronic system. The HDL description is then analyzed 203 to understand the characteristics of the electronic system. Next, parts (or portions) of the electronic system that are to be examined and/or modified are determined 204. Typically, the parts of the electronic system to be examined and/or modified (e.g., instrumented) are within a DUT such as the DUT 102 illustrated in FIGS. 1A and 1B. Hence, the parts of the electronic system to be examined and/or modified represent various signals and/or components within the DUT. After the parts of the electronic system to be examined and/or modified have been determined 204, design instrumentation circuitry (DIC) is generated 206; configuring the processor to execute the instrumentation code and the programmable logic to implement the instrumentation interface; and wherein the instrumentation interface is configured to test a state of a signal from the circuitry of the DUT and interrupt the processor in response to the state of the signal satisfying a condition specified in a specification of the DUT (See: Col. 21 lines 48-59, The setting and detecting of at least one trigger condition in the DIC and examining the operation of the HDL design and/or the software program can be done in the following operations. First, a trigger condition is set in the HDL-based hardware debugger (HHD) 122. Second, the HHD 122 configures the DIC 106 via a communication link 2104. Third, if the trigger condition is met, one or more trigger actions are issued in the DIC 106. One trigger action in the DIC 106 notifies the HHD 122 via the communication link 2104. One trigger action in the DIC 106 notifies the CPU 2002 via a communication link 2106. On the CPU side, the communication link 2106 may be connected to an interrupt input).
Claim 9. Wang et al discloses the method of claim 8, wherein the instrumentation interface is configured to: stop a clock signal to the circuitry of the DUT in response to the state of the signal satisfying the condition (See: [0090] The FPGA 92 in each resource board then begins writing probe data to RAM 93 at the start of the period of interest with N set to the appropriate value, and then stops the emulation process at the end of the period of interest; [0097] the emulator must stop the emulation after each clock cycle, acquire the snapshot data for that clock cycle and forward it to the workstation); and start the clock signal to the circuitry of the DUT in response to the instrumentation code signaling to resume the clock signal (See: [0065] After programming all resources, workstation 70 starts the emulation process (step 138), for example by sending packets signaling transactors to reset the emulated DUT to an initial state and to begin supplying test signal inputs to emulation resources and to begin processing resource output signals; [0090] The FPGA 92 in each resource board then begins writing probe data to RAM 93 at the start of the period of interest with N set to the appropriate value, and then stops the emulation process at the end of the period of interest; [0091] Another way to reset the co-validation process to a state it had at the start of some period of interest during a previous emulation process is to drive it directly to that state).
As per Claims 12-13, and 16-18: The instant claims recite substantially same limitation as the above rejected claims 2-4, 6, and 8-9 and therefore rejected under the same rationale.
Claims 5, 7, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al & Schubert et al as applied to independent claims above, and further in view of US Publication No. 2020/0272701 A1 issued to Robertson et al.
Claim 5. Wang and Schubert et at al discloses the method of claim 2.
Wang et al and Schubert et al does not specify but Robertson et al discloses SystemC (See: [0018] Said another way, UVM is a methodology for the functional verification of digital hardware, primarily using simulation. The hardware or system to be verified is typically described using Verilog™ SystemVerilog™, VHDL™ or System C™ at any appropriate abstraction level, although alternative languages could be used and would be known to one of ordinary skill in the art).
It would have been obvious before the effective filing date to combine hardware verification process as taught by Robertson et al to method of programming a co-verification system of Wang et al would be to enable faster, more efficient, more flexible and more robust design of hardware and software (Roberson et al, par [0001]).
Claim 7. Wang et al discloses the testbench code. However, neither Wang et al nor Schubert et al discloses a universal verification methodology (UVM) or an open verification methodology (OVM). Roberston et al discloses a universal verification methodology (UVM) or an open verification methodology (OVM) (See: [0015] As a preliminary matter, Universal Verification Methodology (UVM) is a term used herein to describe a standardized methodology for verifying integrated circuit designs. UVM is derived mainly from the OVM (Open Verification Methodology) which was, in large part, based on the eRM (e Reuse Methodology) for the e Verification Language developed by Verisity Design in 2001. The UVM class library brings much automation to the SystemVerilog™ language, such as sequences and data automation features (e.g. packing, copy, compare, etc.), and, unlike previous methodologies developed independently by the simulator vendors, is an Accellera standard supported by multiple vendors, including Aldec, Cadence, Mentor Graphics, and Synopsys).
It would have been obvious before the effective filing date to combine hardware verification process as taught by Robertson et al to method of programming a co-verification system of Wang et al would be to enable faster, more efficient, more flexible and more robust design of hardware and software (Roberson et al, par [0001]).
As per Claim 15: The instant claims recite substantially same limitation as the above rejected claim 5 and therefore rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hall et al (US Patent No. 8, 504, 344 B2) discloses Abstract, an interface capable of communicating with test software running on an embedded processor is used to control and monitor the flow of data into the external interface of the design. Thus, a connection is made between the verification environment and the design under test running on the accelerator/emulator via a connection formed directly between the verification environment and embedded software running on the emulator for simulation and monitoring purpose at a very low frequency so that high-speed acceleration may still be achieved.
Daw et al (US Publication No. 2005/0144585 A1) discloses:
PNG
media_image1.png
582
591
media_image1.png
Greyscale
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KIBROM K GEBRESILASSIE whose telephone number is (571)272-8571. The examiner can normally be reached M-F 9:00 AM-5:30 PM.
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.
KIBROM K. GEBRESILASSIE
Primary Examiner
Art Unit 2189
/KIBROM K GEBRESILASSIE/Primary Examiner, Art Unit 2189 09/16/2026
Prosecution Insights