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 .
Response to Amendment
Claim 20 is amended, claims 3, 8, and 14 are cancelled, and claims 21-23 are new. Claims 1-2, 4-7, 9-13, and 15-23 are pending.
Response to Arguments
Applicant's arguments filed 5/13/2026 have been fully considered.
Regarding the rejection of claim 20 under 112(b), noted on page 8 of Applicant’s response, the amendment to claim 20 overcomes the rejection, which is withdrawn.
Regarding the prior art rejections, Examiner respectfully disagrees with Applicant’s arguments for the following reasons.
On page 8 of the response, Applicant contends that the Office Action incorrectly equates Bernardi’s switching the source of an instruction stream via an external multiplexer to the claimed subject matter of changing a microarchitectural state of the processor core. In support, Applicant asserts that Bernardi merely utilizes a multiplexer on the system bus to provide an alternate architectural sequence to the processor core such that the core simply executes instructions fed to it from the bus without modifying its internal hardware execution mechanics, meaning there is no change to a microarchitectural state.
Examiner submits that while Bernardi’s disclosed multiplexer and alternate instructions sets themselves do not constitute a microarchitectural state, the switch from normal operations instructions streams to the test mode instructions constitutes a change of the microarchitectural state of the processor because the test instructions change the manner in which the processor executes instructions (e.g., execution flow/sequencing as described on page 2761, 1. Introduction, paragraph beginning with “As a consequence of the above ideas …”).
Therefore, the rejections of independent claims 1 and 20 under 102 (claim 20 switched to 102 rejection) and claim 11 under 103 are maintained.
Regarding claim 10, Applicant contends on page 9 of the response that the Office Action improperly equates Bernardi’s 1-bit D flip-flop, which stores a binary state to toggle the test mode on or off, to the recited test status register. In support, Applicant asserts that a 1-bit flip-flop mathematically cannot indicate three distinct states and therefore cannot write an indication of running, interrupted, or completed.
Examiner submits that the broadest reasonable interpretation of claim 10 lines 7-8 does not require that the test status register be able to indicate all three statuses as alternates. Instead, as currently presented, the claim only requires that the status register be able to indicate any one or more of running, interrupted, or completed. If Applicant intends the interpretation suggested by Applicant’s argument, claim 10 should be amended to clearly convey that the status register is configured to indicate any of all three states – e.g., “write an indication of test status to the test status register, wherein the indication of test status includes each of a set of test statuses including whether the test is running, interrupted, and completed.”
With continued reference to claim 10, Applicant contends on page 9 that the Office Action incorrectly asserts that the specification provides no description of a test identifier to improperly equate Bernardi’s 1-bit enable signal to the recited test identifier. Applicant notes that the specification discloses a multi-bit (3-bit) field in the test status register.
Examiner submits that the embodiment depicting a “test identifier” is exemplary and does not compel an interpretation of the test identifier as being multi-bit.
Therefore, the rejection of claim 10 under 103 is maintained.
Claim Objections
Claim 23 is objected to because of the following informalities:
A period should be inserted at the end of claim 23.
Appropriate correction is required.
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-2, 5, and 9 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bernardi et al., "MIHST: A Hardware Technique for Embedded Microprocessor Functional On-Line Self-Test," in IEEE Transactions on Computers, vol. 63, no. 11, pp. 2760-2771, Nov. 2014.
As to claim 1, Bernardi teaches “[a]n integrated circuit (Abstract describing testing structure solution applicable to processor cores embedded in a System on Chip (SoC)) comprising:
a processor core configured to execute instructions (FIG. 1 depicting example system architecture including a CPU (processor core) (inherently configured to execute instructions); page 2761, 1 Introduction, paragraph below FIG. 1 beginning with “As a consequence…” describing execution of instructions by the processor being tested);
one or more test mode registers configured to store test mode selection data (page 2760, I. Introduction, paragraph beginning with “1 The system may be either in normal or in test state…” describing the MIHST unit providing test instructions (test instructions implement a given test sequence and thereby effectuate a “selection” of a “test mode”) to processor under test; page 2761, 1 Introduction, paragraphs beginning with “The most evident advantage …” and “The MIHST unit is programmed …” explaining that the MIHST is programmed to include the test data/instructions and therefore regular system memory (memory outside the processor’s internal storage) is not required for such storage; FIG. 3 depicting MIHST (test) mode instructions stored in instruction register; page 2762, 3 Proposed Approach, paragraph beginning with “As a further explanation…”; FIG. 5 depicting MIHST unit architecture as generating and storing the test opcodes and operands for test instructions; page 2764, MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture includes …” describing MIHST instruction register);
one or more test result registers configured to store test result data (FIG. 5 depicting MIHST unit architecture including Result Collection; page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature and may be implemented by a MISR (multi-input signature register) module); and
a test mode circuitry (FIGS. 1 depicting MIHST unit and MUX, FIG. 14 MIHST Unit, D flip-flop, and MUX; Abstract describing MIHST unit as a hardware module (i.e., implemented via circuitry)) configured to:
change a microarchitectural state of the processor core from a first state to one or more test mode states (FIG. 1 test mode input to MUX for selectively switching between normal mode of CPU (input from Code Memory to system bus/CPU) to test mode of CPU (input from MIHST to system bus/CPU). Examiner notes that the differing instruction inputs received and processed by the CPU changes the microarchitectural state of the CPU; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” describing switch to test mode as including that the ISR enables the MIHST and forces the system to enter the test mode (pulse on the test_ON signal)) based on test mode selection data written to the one or more test mode registers (the test instructions from the MIHST unit that changes the microarchitectural state of the CPU are stored in register(s) per page 2764, MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture includes …” describing MIHST instruction register and FIG. 3 depicting MIHST (test) mode instructions stored in instruction register, and page 2762, 3.1 Forced Instruction Sequence, paragraph beginning with “As a further explanation…” (CPU instruction register effectuating test and therefore also constituting “test mode” register));
execute a sequence of instructions on the processor core in the one or more test mode states (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (i.e., processor execution of the test instructions); page 2761, 1 Introduction, paragraph beginning with “As a consequence…”) to obtain a resulting architectural state of the processor core (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (state is in part determined by processor activity which alters its state in accordance with program sequence dependent context of the processor as for example, inferred on page 2761, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” explaining that a given processor “state” in terms of register contents is preserved for testing));
store test result data based on the resulting architectural state (page 2761, 1 Introduction, paragraph beginning with “This working principle …” describing observing test instruction results (i.e., processor behavior/state)) in the one or more test result registers (FIG. 5 depicting MIHST unit architecture including Result Collection; page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature and may be implemented by a MISR (multi-input signature register) module); and
after executing the sequence of instructions, restore the microarchitectural state of the processor core to the first state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” describing that interrupt feature used to preserve processor state; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” explaining that the “test execution flow” includes a state preservation step (c. 1. prior to testing, saves all general purpose registers (GPRs) to be used in testing), 7. exits the test mode, and e. 8. restores the GPR contents and f. restores system context prior to testing interrupt) based on test mode selection data written to the one or more test mode registers (the foregoing GPR/context restoration, described on page 2768, performed as part of “test execution flow” that includes resetting FIG. 14 D flip-flop with test_Off as described in item “7.” and “e.”).
As to claim 2, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) a processor pipeline branch of the processor core to be selected (page 2762, 3 Proposed Approach, paragraph beginning with “The sample code includes …” describing test model as including a jump/branch instruction (instruction to select a processor branch); Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors) in a dispatch stage of the processor core (execution of instructions in a pipelined processor such as branch instruction inherently entails instruction dispatch (control passes to another instruction sequence)).”
As to claim 5, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) each of multiple processor pipelines of the processor core (Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors (inherently applied parallel processing of instructions via multiple independent execution stages) to be selected in fixed order by a dispatch stage of the processor core (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that the instruction execution sequence (inherently includes dispatch) is forced as a fixed MIHST-determined matter).”
As to claim 9, Bernardi teaches “[t]he integrated circuit of claim 1, in which the test mode circuitry is configured to:
responsive to an interrupt (page 2768, Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “d.7.” that execution exits test mode in response to pulse on the test_OFF signal), write to the one or more test mode registers (FIG. 14 depicting test mode off from output of MIHST and input to flip-flop (effectively a register storing a binary on/off condition) to change test_mode) to restore the microarchitectural state of the processor core to the first state (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items “e.” and “f.” that control is returned to the native ISR, GPR contents are restored and the system context of the microprocessor is restored); and
after completion of a handling routine for the interrupt (pages 2767-2768, 6. Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology was defined …” and “When the test is activated …” describing use of system interrupt for initiating testing) and completion of execution of the sequence of instructions (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items a. through d. (completion of execution of instruction sequence) , check the one or more test mode registers to determine whether the test mode has been interrupted (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “7.” exiting test mode in response to test_OFF pulse, which resets the test_mode bit of the flip-flop depicted in FIG. 14).”
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.
Claims 4 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Mishaeli (US 2020/0096569 A1).
As to claim 4, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions).”
While Bernardi does not explicitly teach register renaming for allocating physical registers, Bernardi further discloses that the MIHST/test sequence includes a branch/jump execution sequence (FIG. 2 (c) MIHST mode execution depicting test instruction sequence including jump instruction; page 2762, 3 Proposed Approach, paragraphs beginning with “FIG. 2 exemplifies …” and “The sample code …”) for a pipelined processor (Abstract) that includes an instruction “MOV [addr], R3” at a second instance of program counter position “3” (FIG. 2 (c)) that presents a writing/rewriting of register R3 (architectural register) as part of the jump/branch instruction (FIG. 2 (c)) that would typically trigger a register renaming processor to allocate a physical register to store the value in the execution fixed order (architectural order) as is well-known in out-of-order processing to avoid false dependencies.
For example, Mishaeli discloses an apparatus for implementing processor testing (Abstract) for pipelined processors ([0021]) that includes executing branch instructions in which a rename stage of the processor allocates physical registers of the processor (FIGS. 8A and 8B depicting instruction pipeline 800 including the Alloc and Rename portion of branch prediction (executed by rename/allocator unit 852 in execution end unit 850 in FIG. 8B) for remapping instruction cache registers (physical register file units 858) in the programmed order (in accordance with pipeline 800)) in a fixed order ([0068] register renaming may be implemented for an in-order architecture (i.e., branch execution in program counter instruction order)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli’s teaching of using register renaming (i.e., renaming architectural registers to physical registers) that may be applied to an in-order (fixed) execution sequence to apparatus taught by Bernardi in which the test execution flow including jump/branch instructions are implemented in a preset (fixed) manner as depicted in (FIG. 2 (c)) by sequential access (program counter selecting preset sequence of instruction set registers) such that in combination the test mode of the apparatus includes forcing a rename stage of the processor core to allocate physical registers of the processor core in a fixed order.
The motivation would have been to enable a fixed instruction set execution that accommodates the need to reallocate/rename registers for branch instructions.
As to claim 22, Bernardi teaches “[t]he integrated circuit of claim 1,” but does not appear to teach “in which the test mode circuitry is further configured to set an allocation of physical registers into a deterministic mode in which an order of allocation is independent of stalls.”
While Bernardi does not explicitly teach register renaming for allocating physical registers in a deterministic mode/manner, Bernardi further discloses that the MIHST/test sequence includes a branch/jump execution sequence (FIG. 2 (c) MIHST mode execution depicting test instruction sequence including jump instruction; page 2762, 3 Proposed Approach, paragraphs beginning with “FIG. 2 exemplifies …” and “The sample code …”) for a pipelined processor (Abstract) that includes an instruction “MOV [addr], R3” at a second instance of program counter position “3” (FIG. 2 (c)) that presents a writing/rewriting of register R3 (architectural register) as part of the jump/branch instruction (FIG. 2 (c)) that would typically trigger a register renaming processor to allocate a physical register to store the value in the execution fixed order (architectural deterministic order) as is well-known in out-of-order processing to avoid false dependencies.
For example, Mishaeli discloses an apparatus for implementing processor testing (Abstract) for pipelined processors ([0021]) that includes executing branch instructions in which a rename stage of the processor allocates physical registers of the processor (FIGS. 8A and 8B depicting instruction pipeline 800 including the Alloc and Rename portion of branch prediction (executed by rename/allocator unit 852 in execution end unit 850 in FIG. 8B) for remapping instruction cache registers (physical register file units 858) in the programmed order (in accordance with pipeline 800)) in a fixed/deterministic order ([0068] register renaming may be implemented for an in-order architecture (i.e., branch execution in program counter instruction order)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli’s teaching of using register renaming (i.e., renaming architectural registers to physical registers) that may be applied to an in-order (fixed) execution sequence to apparatus taught by Bernardi in which the test execution flow including jump/branch instructions are implemented in a preset (fixed) manner as depicted in (FIG. 2 (c)) by sequential access (program counter selecting preset sequence of instruction set registers) such that in combination the test mode circuitry is configured to set an allocation of physical registers into a deterministic mode.
The motivation would have been to enable a fixed instruction set execution that accommodates the need to reallocate/rename registers for branch instructions.
In such a configuration, and based on Bernardi’s use of a test mode that effectively disables the processor’s usual/native control sequencing (page 2761, 1 Introduction, paragraph beginning with “As a consequence of the above ideas …” describing that the test mode forces instruction sequences independent of native processor flow instructions), the resultant deterministic mode ordering would be implemented independent of stalls (e.g., independent of otherwise used flow control mechanisms used to allocate in consideration of potential processor stall conditions).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Gangasani (US 2012/0226942 A1).
As to claim 6, Bernardi teaches “[t]he integrated circuit of claim 1,” and further teaches compression of the test result data including the architectural state result from the execution of the test sequence (page 2764, 4 MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture of the of the MIHST unit includes …” describing “Results Collection module compressing the monitored address, data and control bus signals” related to the test signature), but does not expressly teach that the compression is via XOR of the result data and therefore does not teach “in which the test result data includes an XOR of data, including the resulting architectural state, generated when executing the sequence of instructions.”
Prior to the effective filing date, using XOR as a testing results compression technique was known. For example, Gangasani discloses a method/apparatus for implementing run-time self-testing for testing processors (Abstract) that compresses test result data that reflects the architectural state (FIG. 4 output from unit under test (UUT) 450 processed by compacter 460 prior to storing result signature in MISR 470, [0045]-[0046] test vector patterns applied as stimulus to UUT and UUT data (state as stimulated) captured and loaded into compacter 460) by using an XOR of the test result data ([0046] compacter 460 applies XOR that compacts the result data).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Gangasani’s teaching of applying XOR to output architectural result data to the apparatus taught by Bernardi, which teaches compressing the processor architecture test results, such that in combination the apparatus is configured such that the test result data includes an XOR of data, including the resulting architectural state, generated when executing the sequence of instructions.
The motivation would have been to compress the result data to conserve overall storage capacity of the apparatus using a known design option for implementing such compression with predictable success.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Gangasani (US 2012/0226942 A1), and in further view of Sane (US 2020/0310957 A1).
As to claim 7, Bernardi teaches “[t]he integrated circuit of claim 1,” and further teaches compression of the test result data (page 2764, 4 MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture of the of the MIHST unit includes …” describing “Results Collection module compressing the monitored address, data and control bus signals” related to the test signature), but does not expressly teach that the compression is via XOR of the result data and therefore does not teach “in which the test result data includes an XOR of data, including opcodes for retired instructions, generated when executing the sequence of instructions.”
Prior to the effective filing date, using XOR as a testing results compression technique was known. For example, Gangasani discloses a method/apparatus for implementing run-time self-testing for testing processors (Abstract) that compresses test result data that reflects the architectural state (FIG. 4 output from unit under test (UUT) 450 processed by compacter 460 prior to storing result signature in MISR 470, [0045]-[0046] test vector patterns applied as stimulus to UUT and UUT data (state as stimulated) captured and loaded into compacter 460) by using an XOR of the test result data ([0046] compacter 460 applies XOR that compacts the result data).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Gangasani’s teaching of applying XOR to result data to the apparatus taught by Bernardi, which teaches compressing test results, such that in combination the apparatus is configured such that the test result data includes an XOR of data.
The motivation would have been to compress the result data to conserve overall storage capacity of the apparatus using a known design option for implementing such compression with predictable success.
Neither of Bernardi nor Gangasani appears to teach that the compressed results may include opcodes for retired instructions and therefore do no teach the XOR data “including opcodes for retired instructions, generated when executing the sequence of instructions.”
Sane discloses a system/method for implementing processor core performance monitoring (Abstract; [0026]) that includes storing instructions having opcodes in the monitoring result signatures ([0026] allocation paths derived from last branch record (LBR) information are translated using hash into fixed bit signatures; FIG. 2B depicting allocation paths 250, 260, 270, and 280 compressed via hash into corresponding signatures 255, 265, 275, and 285 as described in [0030]-[0031]; [0057] the instructions include opcodes), including applying the results processing (hash) to retired instructions (Abstract LBR records store recently retired instructions; [0088] and claim 3 hash applied to recently retired instructions).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Sane’s teaching of processor performance monitoring that includes generating signature results in the form of last branch records including corresponding instructions including retired instructions to the apparatus taught by Bernardi as modified by Gangasani, which teaches generating results signatures (Bernardi: page 2764, 4 MIHST Unit Architecture and Behavior, second column, bullet point beginning with “A Results Collection module …”; “ Gangasani: [0046]) using XOR as the result compression technique (Gangasani: [0046]), such that in combination the apparatus is configured such that “the test result data includes an XOR of data, including opcodes for retired instructions, generated when executing the sequence of instructions.”
The motivation would have been to compress the result data, including preserving instruction data, which as disclosed by Sane may be useful as monitoring/testing results, as well as “execution output” to conserve overall storage capacity of the apparatus.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi.
As to claim 10, Bernardi teaches “[t]he integrated circuit of claim 1, comprising:
a test controller (FIG. 14 MIHST architecture including MIHST Unit, D flip-flop, and MUX external to CPU),” “configured to periodically initiate testing of the processor core by writing to the one or more test mode registers (periodic testing initiated with respect to system bus control by “test_On” write to the D flip flop to set “test_mode” into active test mode. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a testing control function and therefore constitutes part of “a test controller.”);
a test status register (FIG. 14 D flip-flop storing test_mode state Q) accessible by the test controller (FIG. 14 D flip flop receives “test_On” and “test_Off” inputs and is therefore accessible by test controller); and
the test mode circuitry (portion of “test controller” providing “test_On” input and MIHST Unit providing “test_Off” input) is configured to:
write a test identifier to the test status register (FIG. 14 “test_On” input (write) to D flip flop results in output Q (test_mode) being set to indicate/identify test enabled. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a test function and therefore constitutes part of “test mode circuitry.” Applicant’s specification provides no description, purpose, or example of a “test identifier” such that “test identifier” may be reasonably interpreted as any indicator that serves to identify testing in a broad manner so as to encompass a signal that indicates a test); and
write an indication of test status to the test status register, wherein the indication of test status indicates whether a test is running, interrupted, or completed (FIG. 14 MIHST unit writes to D flip flop via test_Off “control” to reset test_mode indicating completion of test).”
Bernardi does not explicitly teach that the “test controller, external to the processor core” features depicted in FIG. 14 (e.g., any of MIHST Unit, D flip-flop, and MUX) actually provide the “test_On” write to the D flip flop to set “test_mode” into active test mode such that Bernardi does not expressly teach a test controller, “external to the processor core,” configured to periodically initiate testing of the processor core by writing to the one or more test mode registers.
Bernardi teaches in FIG. 14 that the test controller “external to the processor core” at least provides the test_Off signal that effectuates a write (clear) to the D flip flop as part of completing the test mode.
It would have been obvious to one of ordinary skill in the art before the effective filing date, in view of Bernardi’s teaching that the MIHST Unit is configured to control the setting of the D flip flop at least by providing the “test_Off” input, to have configured the MIHST Unit to also provide the “test_On” input.
The motivation would have been to leverage the test-related programming of the MIHST Unit for determining when to enter test mode processing (responsive, for example, to an initial signaling of test mode enable at the enable input of the MIHST Unit) as well as for competing/exiting the test mode.
As to claim 20, Bernardi teaches “[a] non-transitory computer readable medium storing instructions (FIGS. 1 depicting MIHST unit and MUX, FIG. 14 MIHST Unit, D flip-flop, and MUX; Abstract describing MIHST unit as a hardware module implementing instructions) that, upon execution on a system on chip (Abstract and page 2760, 1 Introduction, paragraph beginning with “To address the above issues …” explaining processor being tested may be deployed on system on chip. Examiner notes that the execution of the instructions of the MIHST is implemented on the processor structure, which is on the SoC), cause operations comprising:
changing a microarchitectural state of a processor core from a first state to one or more test mode states (FIG. 1 test mode input to MUX for selectively switching between normal mode of CPU (input from Code Memory to system bus/CPU) to test mode of CPU (input from MIHST to system bus/CPU). Examiner notes that the differing instruction inputs received and processed by the CPU changes the microarchitectural state of the CPU; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” describing switch to test mode as including that the ISR enables the MIHST and forces the system to enter the test mode (pulse on the test_ON signal)) based on test mode selection data written to one or more test mode registers (the test instructions from the MIHST unit that changes the microarchitectural state of the CPU are stored in register(s) per page 2764, MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture includes …” describing MIHST instruction register and FIG. 3 depicting MIHST (test) mode instructions stored in instruction register, and page 2762, 3.1 Forced Instruction Sequence, paragraph beginning with “As a further explanation…” (CPU instruction register effectuating test and therefore also constituting “test mode” register));
executing a sequence of instructions on the processor core in the one or more test mode states (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (i.e., processor execution of the test instructions); page 2761, 1 Introduction, paragraph beginning with “As a consequence…”) to obtain a resulting architectural state of the processor core (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (state is in part determined by processor activity which alters its state in accordance with program sequence dependent context of the processor as for example, inferred on page 2761, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” explaining that a given processor “state” in terms of register contents is preserved for testing));
storing test result data based on the resulting architectural state (page 2761, 1 Introduction, paragraph beginning with “This working principle …” describing observing test instruction results (i.e., processor behavior/state)) in one or more test result registers (FIG. 5 depicting MIHST unit architecture including Result Collection; page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature and may be implemented by a MISR (multi-input signature register) module); and
after executing the sequence of instructions, restoring the microarchitectural state of the processor core to the first state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” describing that interrupt feature used to preserve processor state; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” explaining that the “test execution flow” includes a state preservation step (c. 1. prior to testing, saves all general purpose registers (GPRs) to be used in testing), 7. exits the test mode, and e. 8. restores the GPR contents and f. restores system context prior to testing interrupt) based on test mode selection data written to the one or more test mode registers (the foregoing GPR/context restoration, described on page 2768, performed as part of “test execution flow” that includes resetting FIG. 14 D flip-flop with test_Off as described in item “7.” and “e.”).”
Claims 11-13, 15-16, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi et al., "MIHST: A Hardware Technique for Embedded Microprocessor Functional On-Line Self-Test," in IEEE Transactions on Computers, vol. 63, no. 11, pp. 2760-2771, Nov. 2014 in view of Rajsuman (US 6,249,892 B1).
As to claim 11, Bernardi teaches “[a] method, comprising:
writing to one or more test mode registers (FIG. 14 test_ON written to/stored by D flip-flop (register for providing MUX selection to switch to and from test mode)) to change a microarchitectural state of a processor core from a first state to one or more test mode states (FIG. 14 test_mode input to MUX selects MIHST test instruction input to CPU; Examiner notes that the differing instruction inputs received and processed by the CPU changes the microarchitectural state of the CPU; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” describing switch to test mode as including that the ISR enables the MIHST and forces the system to enter the test mode (pulse on the test_ON signal));
executing a sequence of instructions on the processor core in the one or more test mode states (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (i.e., processor execution of the test instructions); page 2761, 1 Introduction, paragraph beginning with “As a consequence…”) to obtain a resulting architectural state of the processor core (execution of the test mode instructions results in an architectural state of CPU);” and
“writing to the one or more test mode registers (GPR/context restoration, described on page 2768, performed as part of “test execution flow” that includes resetting FIG. 14 D flip-flop with test_Off as described in item “7.” and “e.”) to restore the microarchitectural state of the processor core to the first state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” describing that interrupt feature used to preserve processor state; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” explaining that the “test execution flow” includes a state preservation step (c. 1. prior to testing, saves all general purpose registers (GPRs) to be used in testing), 7. exits the test mode, and e. 8. restores the GPR contents and f. restores system context prior to testing interrupt).”
Bernardi does not appear to teach “comparing the resulting architectural state to an expected architectural state associated with the sequence of instructions to obtain a test result.”
Rajsuman discloses a method/system for testing microprocessors (Abstract) that includes comparing microprocessor testing results with expected results to obtain a test result (col. 4 lines 28-32 describing implementing processor testing; col. 4 lines 51-54 content of MISR (test results) compared with pre-computed simulation signature (expected results) to determine whether there is a fault).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Rajsuman’s teaching of comparing the processor testing results with expected results to obtain a test result to the method taught by Bernardi, which teaches testing to generate architectural states of the processor, such that in combination the method includes comparing the resulting architectural state to an expected architectural state associated with the sequence of instructions to obtain a test result.
The motivation would have been to effectuate a significant purpose in performing the processor testing in terms of determining whether the performance under test meets performance expectations as disclosed by Rajsuman.
As to claim 12, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states forces (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) a processor pipeline branch of the processor core to be selected (Bernardi: page 2762, 3 Proposed Approach, paragraph beginning with “The sample code includes …” describing test model as including a jump/branch instruction (instruction to select a processor branch); Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors) in a dispatch stage of the processor core (Bernardi: execution of instructions in a pipelined processor such as branch instruction inherently entails instruction dispatch (control passes to another instruction sequence)).”
As to claim 13, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states causes a processor pipeline branch of the processor core to be disabled (Bernardi: page 2761, 1 Introduction, paragraph beginning with “As a consequence of …” explaining that MIHST execution (test mode) moves execution control sequencing (e.g., conditional jump (branch)) from the processor to the MIHST-determined instruction sequence (in this manner, otherwise processor-determined branches are effectively disabled)).”
As to claim 15, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states forces (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) each of multiple processor pipelines of the processor core (Bernardi: Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors (inherently applied parallel processing of instructions via multiple independent execution stages) to be selected in fixed order by a dispatch stage of the processor core (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that the instruction execution sequence (inherently includes dispatch) is forced as a fixed MIHST-determined matter).”
As to claim 16, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, comprising:
responsive to an interrupt (Bernardi: page 2768, Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “d.7.” that execution exits test mode in response to pulse on the test_OFF signal), writing to the one or more test mode registers (Bernardi: FIG. 14 depicting test mode off from output of MIHST and input to flip-flop (effectively a register storing a binary on/off condition) to change test_mode) to restore the microarchitectural state of the processor core to the first state (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items “e.” and “f.” that control is returned to the native ISR, GPR contents are restored and the system context of the microprocessor is restored); and
after completion of a handling routine for the interrupt (Bernardi: pages 2767-2768, 6. Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology was defined …” and “When the test is activated …” describing use of system interrupt for initiating testing) and completion of execution of the sequence of instructions (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items a. through d. (completion of execution of instruction sequence), checking the one or more test mode registers to determine whether the test mode has been interrupted (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “7.” exiting test mode in response to test_OFF pulse, which resets the test_mode bit of the flip-flop depicted in FIG. 14).”
As to claim 23, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, further comprising:
writing a test identifier of a test of the processor core to a test status register (Bernardi: FIG. 14 “test_On” input (write) to D flip flop results in output Q (test_mode) being set to indicate/identify test enabled. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a test function and therefore constitutes part of “test mode circuitry.” Applicant’s specification provides no description, purpose, or example of a “test identifier” such that “test identifier” may be reasonably interpreted as any indicator that serves to identify testing in a broad manner so as to encompass a signal that indicates a test), the test initiated by a test controller (Bernardi: FIG. 14 MIHST architecture including MIHST Unit, D flip-flop, and MUX external to CPU. Periodic testing initiated with respect to system bus control by “test_On” write to the D flip flop to set “test_mode” into active test mode. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a testing control function and therefore constitutes part of “a test controller.”)” “and
writing an indication of test status to the test status register, wherein the indication of test status indicates whether the test is running, interrupted, or completed (Bernardi: FIG. 14 MIHST unit writes to D flip flop via test_Off “control” to reset test_mode indicating completion of test)
Bernardi does not explicitly teach that the “test controller external to the processor core” features depicted in FIG. 14 (e.g., any of MIHST Unit, D flip-flop, and MUX) actually provide the “test_On” write to the D flip flop to set “test_mode” into active test mode, such that Bernardi does not expressly teach a test controller “external to the processor core,” configured to periodically initiate testing of the processor core by writing to the one or more test mode registers.
Bernardi teaches in FIG. 14 that the test controller “external to the processor core” at least provides the test_Off signal that effectuates a write (clear) to the D flip flop as part of completing the test mode.
It would have been obvious to one of ordinary skill in the art before the effective filing date, in view of Bernardi’s teaching that the MIHST Unit is configured to control the setting of the D flip flop at least by providing the “test_Off” input, to have configured the MIHST Unit to also provide the “test_On” input.
The motivation would have been to leverage the test-related programming of the MIHST Unit for determining when to enter test mode processing (responsive, for example, to an initial signaling of test mode enable at the enable input of the MIHST Unit) as well as for competing/exiting the test mode.
Claims 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Rajsuman as applied to claim 11 above, and further in view of Mishaeli (US 2023/0102991 A1), Mishaeli ‘991.
As to claim 17, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11,” and Bernardi teaches that the MIHST testing utilizes processor registers for execution of the test instructions (pages 2760-2761, 1 Introduction, paragraphs beginning with “The MIHST approach is founded …” and “As a consequence …” explaining processor execution of the instruction sequence provided by MIHST (would inherently entail using processor registers such as instruction register as depicted in FIG. 3)) including using the native processor interrupt handling functions for entering test mode and preserving processor state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on online testing …” and pages 2767-2768, 6 Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology …” and “When the test is activated …” describing using of the interrupt service of the microprocessor to enter test mode while preserving processor state).
Use of a control status register for interrupt activation and storing state during interrupt handling was known prior to the effective filing date. For example, Mishaeli ‘991 discloses a method/system for testing processors (Abstract) in which a control register included in the processor core architecture (FIG. 2 processor core 110 including control registers 206A, [0046] control registers 206A serve at least in part to control testing) is used to save the state and isolate a processor core for testing (transferring of status/context) (Abstract setting of control register results in switch to test mode status of processor including preserving processor state and control transfer; [0054], [0070], and [0082]-[0084] control register written to for activating functional testing including saving processor state and transfer of processor control (effectively an interrupt and context switch)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli ‘991’s teaching of the otherwise well-known use of control registers that affect processor status (a form of control status register) for implement context switches including preserving processor operational state and transfer of processor control to the method taught by Bernardi as modified by Rajsuman, which teaches using native processor interrupt functionality that includes preserving processor state and transferring control to test mode, such that in combination the method is configured such that “the one or more test mode registers include a control status register of the processor core.”
The motivation would have been to leverage native processor interrupt functionality including a control status register for implementing switching between normal operations and test mode for efficiently controllable on-line testing as disclosed by each of Bernardi and Mishaeli ‘991.
As to claim 18, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, and Bernardi teaches using the native processor interrupt handling functions (i.e., native to the processor instruction set architecture) for entering test mode and preserving processor state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on online testing …” and pages 2767-2768, 6 Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology …” and “When the test is activated …” describing using of the interrupt service of the microprocessor to enter test mode while preserving processor state).
Using a control status register instruction for handling interrupts including state context switching (e.g., switching to a different instruction sequence for testing or other interrupt purposes) that would entail writing to registers (e.g., test mode registers if the interrupt is for testing) was known prior to the effective filing date. For example, Mishaeli ‘991 discloses a method/system for testing processors (Abstract) in which a control register included in the processor core architecture (FIG. 2 processor core 110 including control registers 206A, [0046] control registers 206A serve at least in part to control testing) is used to save the state and isolate a processor core for testing (transferring of status/context) (Abstract setting of control register results in switch to test mode status of processor including preserving processor state and control transfer; [0054], [0070], and [0082]-[0084] control register written to for activating functional testing including saving processor state and transfer of processor control (effectively an interrupt and context switch)) and that includes use of a control status register instruction that results in writing to test mode registers (FIG. 3 “Prolog” to testing (SBFT) includes Activate_SBFT instruction (WRMSR) to initiate switch to test mode including saving core state and loading SBFT-test to cache (entails writing to test mode registers because cached test instructions would necessarily have to be loaded into instruction registers for execution); [0033] testing initiated using a read-write machine specific register (WRMSR) command (this particular type of command is used for writing to processor registers for controlling processor behavior)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli ‘991’s teaching of using native control status register instructions for writing to processor registers that for testing constitute test mode registers to the method taught by Bernardi as modified by Rajsuman, which teaches using native processor interrupt functionality that includes preserving processor state and transferring control to test mode, such that in combination the method is configured such that “the one or more test mode registers are written to using a control status register instruction of an instruction set architecture supported by the processor core.”
The motivation would have been to leverage native processor interrupt logic including native control status register instructions for implementing switching between normal operations and test mode for efficiently controllable on-line testing as disclosed by each of Bernardi and Mishaeli ‘991.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Rajsuman as applied to claim 11 above, and further in view of Terechko (US 2019/0278677 A1).
As to claim 19, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which the one or more test mode registers” “are written to using a store instruction of an instruction set architecture supported by the processor core (Bernardi: pages 2766-2767, 5.2 MIHST-Ready Program Generation, paragraph beginning with “Considering the previous …” explaining that test mode execution entails a sequence of branches and register load (store) instructions in which the sequence is generated by the MIHST unit. Examiner notes that execution of such instructions is performed by the processor such that the instructions are supported by the instruction set architecture of the processor).”
Bernardi does not appear to teach memory mapping of the test mode registers.
Memory mapping of registers was known prior to the effective filing date. For example, Terechko discloses a method for testing processor cores (Abstract) in which memory mapping of registers is used to provide external access to register content ([0020] Memory Mapped Input/Output (MIMO) used for sharing test result register contents; [0021] describing shared memory region in which respective memory partitions mapped for respective processor cores).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Terechko’s teaching of memory mapping test registers to the method taught by Bernardi as modified by Rajsuman, which teaches that the test registers may be written to by store instructions, such that in combination the method is configured such that the one or more test mode registers “are memory mapped” and are written to using a store instruction of an instruction set architecture supported by the processor core.
The motivation would have been to enable more efficient access to test data that is stored in registers as disclosed by Terechko.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Kapoor (US 2020/0201728 A1), and in further view of and Gray (US 2016/0378661 A1).
As to claim 21, Bernardi teaches “[t]he integrated circuit of claim 1, in which the test mode circuitry is further configured to:”
“set branch prediction to a mode that predicts branches as taken (page 2761, 1 Introduction, paragraph beginning with “As a consequence of the above ideas …” describing that the test mode forces instruction sequences independent of native processor instructions. Examiner notes that the consequence of such execution precludes making branch predictions based on processor-based rules such as execution history – instead would be performed as taken.).”
Bernardi does not appear to expressly teach that the test mode circuitry is further configured to “disable a call and return stack and an absolute jump prediction of the processor core.” However, as noted above Bernardi teaches that the MIHST execution sequence is implemented in a fixed manner independent of (effective disables) native processor flow instructions.
Call/return stack processing and absolute jump prediction are processor sequencing control processes that were known in the art prior to the effective filing date as disclosed by Kapoor ([0047] processor may include call return stack) and Gray ([0097] branch instructions may include absolute branches/jumps).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have implemented the processor testing disclosed by Bernardi on a variety of processors in which the native processor implements known program sequence control functions such as call/return stack processing and absolute jump prediction since such processors would be readily available for such testing to achieve predictable results. In such a configuration, the setting by the MIHST unit of a fixed instruction execution sequence that is independent of (effectively disables) the processor flow/sequence control function would consequently include disabling a call and return stack and an absolute jump prediction of the processor core.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW W BACA whose telephone number is (571)272-2507. The examiner can normally be reached Monday - Friday 8: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, Andrew Schechter can be reached at (571) 272-2302. 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.
/MATTHEW W. BACA/Examiner, Art Unit 2857
/ANDREW SCHECHTER/Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights