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 .
Claims 1-20 are pending in this office action and presented for examination.
Specification
The disclosure is objected to because of the following informalities. Appropriate correction is required.
In [0015], last two lines, “from peripheral” should be “from a peripheral” for grammatical clarity.
In [0019], line 8, “probe” should be “probe 140” in view of FIG. 1.
In [0041], lines 6-7, “an where” may have been intended to be “an address where”.
In [0048], line 1, “receiving 510 first interrupt” should be “receiving 510 a first interrupt” for grammatical clarity. (See, for example, [0047], line 2.)
In [0052], lines 2-3, “sequence debug trace messages” may have been intended to be “sequence of debug trace messages”.
In [0061], line 6, “based a” should be “based on a” for grammatical clarity.
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. Examiner notes that the general concept of event tracing was well-known and widespread before the effective filing date of the claimed invention; as such, Examiner submits that the title does not have sufficient informative value in indexing, classifying, searching, etc.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 14-15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 14 recites the limitation “a first debug trace message” in lines 2-3. However, it is indefinite as to whether this first debug trace message is the same as, or different from, “a first debug trace message” as recited in claim 7, line 4.
Claim 14 recites the limitation “a timestamp” in line 3. However, it is indefinite as to whether this timestamp is the same as, or different from, “a timestamp” as recited in claim 7, lines 4-5.
Claim 14 recites the limitation “the first debug trace message” in line 4. However, it is indefinite as to whether the antecedent basis for this limitation is “a first debug trace message” in claim 7, line 4, or “a first debug trace message” in claim 14, lines 2-3.
Claim 15 is rejected for failing to alleviate the rejections of claim 14 above.
Claim 15 recites the limitation “the timestamp” in line 1. However, it is indefinite as to whether the antecedent basis for this limitation is “a timestamp” in claim 7, lines 4-5, or “a timestamp” in claim 14, line 3.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6 and 16-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim(s) can be interpreted as software per se and thus can be made without an actual hardware apparatus. For example, while the claim(s) do recite circuitry, paragraph [0070] discloses, for example: “a circuit representation in the form of Verilog or VHDL may be stored on a non-transitory computer readable medium and may be processed by a computer to produce an RTL circuit representation” As such, Examiner recommends inserting the limitation “hardware” in an appropriate part of the claim and all relevant places in further dependent claims (e.g. replacing the limitation “debug trace circuitry” with the limitation “hardware debug trace circuitry”).
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.
Claim(s) 1, 3, 7, and 13-14 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by McGowan et al. (McGowan) (US 20150006863 A1).
Consider claim 1, McGowan discloses an integrated circuit ([0077], line 2, integrated circuit) for executing instructions ([0022], line 6, data processing instructions) comprising:
a processor core ([0020], line 3, data processor 101) configured to execute instructions ([0022], line 6, data processing instructions); a data store configured to store codes ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231) indicating corresponding interrupt causes ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event); a trace buffer configured to store a sequence of debug trace messages ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108); and a debug trace circuitry ([0022], line 15, debug module 116; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) that is configured to: responsive to a first interrupt to the processor core, generate a first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) including ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and a code ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115) from the data store ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231), the timestamp generated based on a coding technique ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE), the code indicating a cause of the first interrupt ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event); and store the first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108), the first debug trace message accessible from the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108) to a host device ([0023], lines 1-10, external debugger 103 may be implemented in a variety of ways. As examples, external debugger 103 may be a debugger integrated with a software development system, a debugger that may support multiple types of processors, a specific-purpose debugger for utilizing a processor for a type of application, a specific-purpose debugger for obtaining, storing, and transmitting program trace information, a debugger for receiving trace messages and displaying the information they contain (with or without decoding the information to be displayed), and the like).
Consider claim 3, McGowan discloses the integrated circuit of claim 1 (see above), wherein the data store is a register of the processor core ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231).
Consider claim 7, McGowan discloses a method comprising: receiving a first interrupt ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) with a processor core ([0020], line 3, data processor 101); writing a code indicating a cause of the first interrupt ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) to a data store ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231); responsive to the first interrupt, generating a first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) including ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and the code ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115) from the data store ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231), the timestamp generated based on a coding technique ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE); and storing the first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in a trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108), the first debug trace message accessible from the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108) to a host device ([0023], lines 1-10, external debugger 103 may be implemented in a variety of ways. As examples, external debugger 103 may be a debugger integrated with a software development system, a debugger that may support multiple types of processors, a specific-purpose debugger for utilizing a processor for a type of application, a specific-purpose debugger for obtaining, storing, and transmitting program trace information, a debugger for receiving trace messages and displaying the information they contain (with or without decoding the information to be displayed), and the like).
Consider claim 13, McGowan discloses the method of claim 7 (see above), further comprising: transmitting contents of the trace buffer to the host device via a debug interface ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108; [0023], lines 1-10, external debugger 103 may be implemented in a variety of ways. As examples, external debugger 103 may be a debugger integrated with a software development system, a debugger that may support multiple types of processors, a specific-purpose debugger for utilizing a processor for a type of application, a specific-purpose debugger for obtaining, storing, and transmitting program trace information, a debugger for receiving trace messages and displaying the information they contain (with or without decoding the information to be displayed), and the like) of an integrated circuit ([0077], line 2, integrated circuit) including the processor core ([0020], line 3, data processor 101).
Consider claim 14, McGowan discloses the method of claim 7 (see above), further comprising: responsive to a branch instruction being executed by the processor core, generating a first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0026], lines 12-15, direct address information ADDR, stored at register 113, that identifies a particular address, such as a destination address of a branch; [0063], lines 1-8, flow proceeds to from block 602 to block 611 in response to the executing instruction being a branch instruction. At block 611, the data processor handles branch debug processing in a predefined manner. For example, the specific embodiment of handling branch instructions as described above can be implemented at block 611. In an alternate embodiment, debug processing of branch instructions can be handled in other manners) that includes ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and an address of the branch instruction ([0026], lines 12-15, direct address information ADDR, stored at register 113, that identifies a particular address, such as a destination address of a branch); and storing the first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers).
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.
Claim(s) 2, 15, 16-17, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan (in the case of claim 2, as applied to claim 1 above; in the case of claim 15, as applied to claim 14 above), and further in view of Bowers et al. (Bowers) (WO 2007116205 A1) and Weng (US 6836525).
Consider claim 2, McGowan discloses the integrated circuit of claim 1 (see above), but does not disclose a Gray code counter, wherein the timestamp is generated using the Gray code counter.
On the other hand, Bowers discloses a Gray code counter, wherein a timestamp is generated using a Gray code counter (page 2, lines 6-7, timestamps are encoded as a binary code, for example Gray code).
The teaching of Bowers facilitates error free encoding for reliability (Bowers, page 8, lines 3-4), and Weng explicitly discloses that a Gray code counter precludes transient values from causing glitches (Weng, col. 1, lines 14-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bowers and Weng with the invention of McGowan in order to facilitates error free encoding for reliability by precluding transient values from causing glitches. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and Gray code as taught by Bowers and Weng) according to known methods (Examiner submits that use of Gray code is a known method, as reflected by the disclosures of Bowers and Weng) to yield predictable results (the invention of McGowan, wherein the timestamps are generated by using a Gray code counter in particular), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Consider claim 15, McGowan discloses the method of claim 14 (see above), but does not disclose the timestamp is generated by using a Gray code counter.
On the other hand, Bowers discloses a timestamp is generated by using a Gray code counter (page 2, lines 6-7, timestamps are encoded as a binary code, for example Gray code).
The teaching of Bowers facilitates error free encoding for reliability (Bowers, page 8, lines 3-4), and Weng explicitly discloses that a Gray code counter precludes transient values from causing glitches (Weng, col. 1, lines 14-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bowers and Weng with the invention of McGowan in order to facilitates error free encoding for reliability by precluding transient values from causing glitches. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and Gray code as taught by Bowers and Weng) according to known methods (Examiner submits that use of Gray code is a known method, as reflected by the disclosures of Bowers and Weng) to yield predictable results (the invention of McGowan, wherein the timestamps are generated by using a Gray code counter in particular), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Consider claim 16, McGowan discloses a system comprising: a processor core ([0020], line 3, data processor 101) configured to execute instructions ([0022], line 6, data processing instructions); a trace buffer configured to store a sequence of debug trace messages ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108); and a debug trace circuitry ([0022], line 15, debug module 116; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) that is configured to: responsive to a branch instruction being executed by the processor core, generate a first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0026], lines 12-15, direct address information ADDR, stored at register 113, that identifies a particular address, such as a destination address of a branch; [0063], lines 1-8, flow proceeds to from block 602 to block 611 in response to the executing instruction being a branch instruction. At block 611, the data processor handles branch debug processing in a predefined manner. For example, the specific embodiment of handling branch instructions as described above can be implemented at block 611. In an alternate embodiment, debug processing of branch instructions can be handled in other manners) including ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and an address of the branch instruction ([0026], lines 12-15, direct address information ADDR, stored at register 113, that identifies a particular address, such as a destination address of a branch); and store the first debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers), the first debug trace message accessible from the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108) to a host device ([0023], lines 1-10, external debugger 103 may be implemented in a variety of ways. As examples, external debugger 103 may be a debugger integrated with a software development system, a debugger that may support multiple types of processors, a specific-purpose debugger for utilizing a processor for a type of application, a specific-purpose debugger for obtaining, storing, and transmitting program trace information, a debugger for receiving trace messages and displaying the information they contain (with or without decoding the information to be displayed), and the like).
However, McGowan does not disclose a Gray code counter, wherein the timestamp is generated using the Gray code counter.
On the other hand, Bowers discloses a Gray code counter, wherein a timestamp is generated using a Gray code counter (page 2, lines 6-7, timestamps are encoded as a binary code, for example Gray code).
The teaching of Bowers facilitates error free encoding for reliability (Bowers, page 8, lines 3-4), and Weng explicitly discloses that a Gray code counter precludes transient values from causing glitches (Weng, col. 1, lines 14-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bowers and Weng with the invention of McGowan in order to facilitates error free encoding for reliability by precluding transient values from causing glitches. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and Gray code as taught by Bowers and Weng) according to known methods (Examiner submits that use of Gray code is a known method, as reflected by the disclosures of Bowers and Weng) to yield predictable results (the invention of McGowan, wherein the timestamps are generated by using a Gray code counter in particular), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Consider claim 17, the overall combination entails the system of claim 16 (see above), wherein the branch instruction is a function call or a return (McGowan, [0067], lines 5-7, generating a trace address message that provides address information identifying the actual return address of the RFEOI).
Consider claim 19, the overall combination entails the system of claim 16 (see above), further comprising: a data store configured to store codes (McGowan, [0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231) indicating corresponding interrupt causes ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event).
Consider claim 20, the overall combination entails the system of claim 19 (see above), wherein the debug trace circuitry (McGowan, [0022], line 15, debug module 116; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) is further configured to: responsive to a first interrupt to the processor core, generate a second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) including ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a second timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and a code ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115) from the data store ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0029], lines 16-20, it will be appreciated that various fields of the debug trace messages 229-231 can correspond to various information stored at register file 109, where trace information can be stored prior to generation of the particular messages 229-231), the code indicating a cause of the first interrupt ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event); and store the second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan as applied to claim 1 above, and further in view of Mulchandani et al. (Mulchandani) (5680542).
Consider claim 4, McGowan discloses the integrated circuit of claim 1 (see above), but does not disclose that the trace buffer is SRAM.
On the other hand, Mulchandani discloses a trace buffer being SRAM (col. 11, lines 15-17, for timing reasons, SRAM is preferable to using DRAM for the trace buffer 50).
SRAM is preferable to using DRAM for timing reasons (Mulchandani, col. 11, lines 15-17).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mulchandani with the invention of McGowan for advantages in timing reasons. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and SRAM as explicitly taught by Mulchandani) according to known methods (Examiner submits that use of SRAM is known) to yield predictable results (the invention of McGowan, wherein the trace buffer is SRAM), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan as applied to claim 1 above, and further in view of Hopkins et al. (Hopkins) (US 20150268302 A1) in view of Liu (US 20120079480 A1).
Consider claim 5, McGowan discloses the integrated circuit of claim 1 (see above), but does not disclose that the first debug trace message includes one or more performance counter values, wherein the one or more performance counter values include a count of instructions executed.
On the other hand, Hopkins discloses that a debug trace message includes one or more performance counter values ([0051], lines 7-20, the debug messages may contain debug data. For example, the debug data may be trace data. Trace data is the output of a component of the system circuitry which a debug unit has recorded passively whilst that component of the system circuitry continues executing. The trace data may be program traces or data traces. As another example, the debug data may be the state of a performance counter. Performance counters may be used to count a variety of events from system circuitry, such as signal edges, clock cycles a signal is high or low for, time spent in a given operational state, time a register is at a specific value or within a prescribed range, or error conditions. This type of debug data may be used to infer the state or operation of part of the system circuitry, or to identify whether specific events have or have not occurred.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Hopkins with the invention of McGowan in order to increase debugging/tracing capabilities. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and performance counters as explicitly taught by Hopkins) according to known methods (Examiner submits that use of performance counters is known) to yield predictable results (the invention of McGowan, wherein the first debug trace message includes one or more performance counter values), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
However, the combination thus far does not entail the one or more performance counter values including a count of instructions executed.
On the other hand, Liu discloses one or more performance counter values including a count of instructions executed ([0027], lines 6-9, these hardware performance counters could be programmed to monitor a number of events, such as the number of cache misses, the number of branch mis-predictions, instruction counts, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Liu with the combination of McGowan and Hopkins in order to increase debugging/tracing capabilities via support for counting a number of instructions executed. Alternatively, this modification merely entails combining prior art elements (the prior art elements of the combination of McGowan and Hopkins cited above, and counting instructions executed as explicitly taught by Liu) according to known methods (Examiner submits that use of performance counters to count instructions executed is known, as reflected by Liu) to yield predictable results (the combination of McGowan and Hopkins, wherein the one or more performance counter values includes a count of instructions executed), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan, Hopkins, and Liu as applied to claim 5 above, and further in view of Willard et al. (Willard) (US 20040019894).
Consider claim 6, the combination thus far entails the integrated circuit of claim 5 (see above), but does not entail that the one or more performance counter values are encoded in a floating point format.
On the other hand, Willard discloses that one or more performance counter values are encoded in a floating point format ([0049], lines 3-7, performance data is the raw data as received from each agent 16 in the system 10, is usually constituted in a relatively primitive data type (integer, floating decimal, string, etc.) and contains the raw value of a specific performance counter).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Willard with the combination of McGowan, Hopkins, and Liu in order to support floating point performance data. Alternatively, this modification merely entails combining prior art elements (the prior art elements of the combination of McGowan, Hopkins, and Liu cited above, and floating point format performance counter values as explicitly taught by Willard) according to known methods (Examiner submits that floating point values are known, as reflected by Willard) to yield predictable results (the combination of McGowan, Hopkins, and Liu, wherein the one or more performance counter values are encoded in a floating point format), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan as applied to claim 7 above, and further in view of Edwards et al. (Edwards) (US 7793261 B1).
Consider claim 8, McGowan discloses the method of claim 7 (see above), further comprising: responsive to execution of an instruction associated with a particular event by the processor core ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event), generating a second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) that includes ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and an identifier ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115); and storing the second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108).
However, McGowan does not disclose that the instruction associated with a particular event is an instruction matching a watchpoint, and the identifier is an identifier of a watchpoint.
On the other hand, Edwards discloses debugging entailing an instruction matching a watchpoint and an identifier of a watchpoint (col. 7, lines 49-53, watchpoint channels include a matching mechanism whereby data values written to registers in processor 102 are compared with data values in processor 102 including instruction addresses, instruction values, operand addresses, performance counters, event counters, and the like; col. 7, lines 54-58, when matched, a controller associated with the watchpoint channel may provide a signal to debug circuit 103 through communication link 215. This signal may take the form of state bits indicating particular watchpoint channel states within the processor 102 communicated in state values 208; col. 8, lines 42-50, debug circuit 103 may also be configured to transmit information received over communication link 215 to an external system 106. Such information may include trace information, timing information, a value of the program counter and the like for debugging purposes. For example, trace messages may be generated based on different watchpoint hits, and these trace messages may contain information values received through a debug circuit-processor communication link such as links).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Edwards with the invention of McGowan to enhance debugging capability via use of watchpoints. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and watchpoints as explicitly taught by Edwards) according to known methods (Examiner submits that use of watchpoints is known, as reflected by Edwards) to yield predictable results (the invention of McGowan, supporting watchpoints), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan as applied to claim 7 above, and further in view of Yamashita (US 6467083 B1).
Consider claim 9, McGowan discloses the method of claim 7 (see above), further comprising: responsive to a particular event ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event), generating a second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) that includes ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and information ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115); and storing the second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108).
However, McGowan does not disclose that the particular event is a write to a register in a set of instrumented trace registers, and the information is an index identifying the register in the set of instrumented trace registers, and a value written to the register in the set of instrumented trace registers.
On the other hand, Yamashita discloses a particular event is a write to a register in a set of instrumented trace registers, and information is an index identifying the register in the set of instrumented trace registers, and a value written to the register in the set of instrumented trace registers (col. 1, lines 18-29, it is rare for a target program to be installed in a target system such as a facsimile and an image processing system to correctly run jobs upon completion of the development. Usually, a debugging system runs the target program, and traces the target program to see how the instructions are sequentially executed, how the execution changes the contents of registers and what data codes are left in the addressable memory locations in a main memory. The debugging system stores the results of the tracing operation in a trace memory as pieces of trace data information indicative of errors in the target program, and a programmer eliminates the bugs from the target program).
Yamashita’s teaching facilitates debugging (Yamashita, col. 1, lines 18-29).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yamashita with the invention of McGowan to facilitate debugging. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan cited above, and Yamashita’s teaching as cited above) according to known methods (Examiner submits that tracing register writes is known, as reflected by the teaching of Yamashita) to yield predictable results (the invention of McGowan, incorporating the teaching of Yamashita cited above), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan as applied to claim 7 above, and further in view of Sohm et al. (Sohm) (US 20060259751 A1).
Consider claim 10, McGowan discloses the method of claim 7 (see above), further comprising: responsive to a particular event ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event), generating a second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103; [0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0057], lines 25-26, generation of trace messages to communicate the occurrence of the exception/interrupt; [0078], lines 1-3, various trace messages are generated and communicated to an external debugger in response to an exception/interrupt event) that includes ([0026], lines 1-3, by way of example, various debug/trace information that can be transmitted as part of a trace message are illustrated as stored at registers 110-115) a timestamp ([0054], lines 1-6, trace timestamp message 400 that includes a timestamp value (TIMESTAMP) that corresponds to particular a particular event. The event causing the timestamp to be generated can be identified in the trace timestamp message by a particular BTYPE (not shown) or TCODE) and a code indicating an event ([0026], lines 7-10, a BTYPE value, stored at register 112, that identifies a type associated with a particular encountered event that is associated with the trace message, such as a branch type, an interrupt, an exception, and the like; [0027], lines 1-5, as execution units 117 execute instruction code, debug module 116 can obtain information about the execution of those instructions via various connections and store the information in registers 110-115); and storing the second debug trace message ([0022], lines 16-18, generate debug messages that include debug information for analysis by external development system (debugger) 103; [0025], lines 12-15, message generation module 132 is capable of generating debug messages, referred to as trace messages, that transmit various information to the external debugger 103) in the trace buffer ([0028], lines 6-9, trace messages, or information used to generate trace messages (e.g., values described with respect to registers 110-115), may be stored in trace buffers (e.g., first-in-first-out (FIFO) buffers) before being transmitted via connection 108).
However, McGowan does not disclose that the particular event is an external trigger signal from a component of an integrated circuit including the processor core that is outside of the processor core, and the event is an event of the component.
On the other hand, Sohm discloses a particular event is an external trigger signal from a component of an integrated circuit including a processor core that is outside of the processor core, and the event is an event of the component ([0026], lines 4-18, through the operation of the processor 200 many events 205 may occur that are significant for debugging and profiling the code being executed by the processor 200. The term "events" or "event data" herein is being used broadly to describe any type of stall in which processor 200 is forced to wait before it can complete executing an instruction, such as a CPU stall or cache stall; any type of memory event, such as a read hit or read miss; and any other occurrences which may be useful for debugging and profiling the code being executed on circuitry 145. The internal trace memory 210 records the events 205 as event data and outputs the event data through connection 150 to computer 105. This enables a user of the computer 105 to see how the execution of the code is being implemented on circuitry 145; [0003], line 1, integrated circuits; [0032], lines 1-3, Table I below provides a non-exhaustive list of memory events that can be monitored in accordance with preferred embodiments of the invention; [0033], lines 1-6, external events 335 may also be input to event encoder 340. External events 335 may include interrupt routines executed on processor core 300 for interacting with external devices. Table II below provides a non-exhaustive list of external events that can be monitored in accordance with preferred embodiments of the invention).
Sohm’s teaching facilitates gaining a full understanding of how code is being executed by a processor (Sohm, [0047], lines 1-7).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sohm with the invention of McGowan in order to increase debugging/tracing capabilities and facilitate gaining a full understanding of how code is being executed by a processor. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan as cited above, and the tracing/debugging of external events as explicitly taught by Sohm) according to known methods (Examiner submits that tracing/debugging external events was known, as reflected by Sohm) to yield predictable results (the invention of McGowan, further entailing tracing/debugging external events), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan and Sohm as applied to claim 10 above, and further in view of Moyer (US 20050193256 A1).
Consider claim 11, the combination thus far entails the method of claim 10 (see above), wherein the component is a direct memory access controller and the event is an end of a data transfer operation by the component (Sohm, [0033], Table II, DMA Completion Interruption DMA indicates that transfer is complete), but does not entail the event is a start of a data transfer operation by the component.
On the other hand, Moyer discloses an event is a start of a data transfer operation by a component (abstract, at least one of the debug messages implements a watchpoint function, such as indicating when a transfer starts or ends; [0035], lines 4-11, the direct memory access device controls channels of information, each channel of the channels of information transfers information from a source to a destination in the system via a channel transfer. Debug control circuitry is coupled to the DMA device, the debug control circuitry providing debug messages that periodically provide at least one status parameter for at least one predetermined channel; [0035], lines 16-20, the debug control circuitry additionally provides debug messages that indicate that a channel transfer has started. The debug control circuitry additionally provides a debug message that indicates that a channel transfer has ended)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Moyer with the combination of McGowan and Sohm in order to increase debugging/tracing capabilities and facilitate gaining a full understanding of how code is being executed by a processor. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan and Sohm as cited above, and a debug message providing a start of a DMA data transfer operation as explicitly taught by Moyer) according to known methods (Examiner submits that starts of DMA data transfer operations were known, as reflected by Moyer) to yield predictable results (the combination of McGowan and Sohm, further entailing a debug message providing a start of a DMA data transfer operation), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan and Sohm as applied to claim 10 above, and further in view of Bolen (US 20160132395 A1).
Consider claim 12, the overall combination entails the method of claim 10 (see above), wherein the component is a bus controller and the event is a bus error ([0033], Table II, External Bus Error – An Error occurred on the external memory bus).
To any extent to which Sohm does not inherently or implicitly disclose a bus controller, Bolen explicitly discloses a bus controller ([0032], lines 12-13, the bus controller functionality may include notifications and alerts, such as interrupts, to processor 220).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bolen with the combination of McGowan and Sohm in order to facilitate bus transactions and debugging via a bus controller. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan and Sohm as cited above, and the bus controller as explicitly taught by Bolen) according to known methods (Examiner submits that bus controllers were known, as reflected by Bolen) to yield predictable results (the combination of McGowan and Sohm, further entailing a bus controller), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over McGowan, Bowers, and Weng as applied to claim 17 above, and further in view of Gliwa (US 20180365127 A1).
Consider claim 18, the combination thus far entails the system of claim 17 (see above), but does not entail that the debug trace circuitry is further configured to: ignore other types of branch instructions as triggers for generating debug trace messages.
On the other hand, Gliwa discloses debug trace circuitry ignoring other types of branch instructions as triggers for generating debug trace messages ([0006], lines 1-2, hardware-based tracing captures each taken branch; [0025], lines 7-9, in another embodiment of the invention, only function call instruction but no jump instructions are traced).
Gliwa’s teaching simplifies tracing (Gliwa, [0025], lines 1-3, due to a large variety of jump instructions typically present in a software application, tracing jumps can be a complex task; [0025], line 15, simplified tracing).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gliwa with the combination of McGowan, Bowers, and Weng in order to simplify tracing. Alternatively, this modification merely entails combining prior art elements (the prior art elements of McGowan, Bowers, and Weng cited above, and debug trace circuitry ignoring other types of branch instructions as triggers for generating debug trace messages as taught by Gliwa) according to known methods (Examiner submits that selective tracing is known, as reflected by Gliwa) to yield predictable results (the combination of McGowan, Bowers, and Weng, wherein the debug trace circuitry ignores other types of branch instructions as triggers for generating the debug trace messages), which is an example of a rationale that may support a conclusion of obviousness, as per MPEP 2143.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Williams et al. (US 20110219376 A1) discloses “By triggering a timestamp request on the occurrence of an exception event, the following trace packet will be generated together with a timestamp and so exception points can be identified in the trace stream” (see paragraph [0012]); a trace buffer and trace module (see FIG. 9); and “The trace packets generated may indicate many types of characteristics of the data processing apparatus or the data processing performed by the data processing apparatus. For example, the trace packets may indicate characteristics of at least one of: data processed during said processing; data generated during said processing; instructions executed during said processing; memory addresses accessed during said processing; values stored in registers of said data processing apparatus; and the occurrence of a hardware event. The hardware event may include, for example, the start of processing using a hardware accelerator, co-processor, or other processing circuitry of the data processing apparatus, or the receipt of an external signal” (see paragraphs [0027]-[0034]), which is relevant to the claimed trace message, interrupt, timestamp, trace buffer, debug trace circuitry, codes, external trigger signal, and so forth.
Norrie et al. (US 9875167 B1) discloses “storing, by the computing system and in at least one memory buffer, data identifying one or more hardware events occurring across processor units that include the first processor component and the second processor component. Each hardware event represents at least one of data communications associated with a memory access operation of the program code, an issued instruction of the program code, or an executed instruction of the program code. The data identifying each of the one or more hardware events includes a hardware event time stamp and metadata characterizing the hardware event” (see col. 1, lines 40-56) and “detecting, by the computing system, a trigger function associated with portions of program code being executed by at least one of the first processor component or the second processor component; and responsive to detecting the trigger function, initiating, by the computing system, at least one trace event that causes data associated with the one or more hardware events to be stored in the at least one memory buffer” (see col. 1, line 62 to col. 2, line 5), which is relevant to the claimed trace, timestamp, code, debug trace circuitry, and so forth.
Patwardhan et al. (US 12182003 B1) discloses a “low-bandwidth trace mode is contemplated in which traced instructions are limited to subroutine call and return instructions, thereby providing indications of software subroutine executions. Such a low-bandwidth trace mode may provide an adequate amount of trace data while also reducing an impact to program execution” (see col. 3, line 66, to col. 4, line 4), which is relevant to the claimed ignoring other types of branch instructions.
Alexander et al. (US 20200201636 A1) discloses “Exception causes are recorded within architectural state (an exception type register) and can be interrogated by external agents to ascertain the source of the exception. One such external agent may be a debug tool which can interrogate the state via the debug interface 120” (see paragraph [0073]), which is relevant to the claimed data store.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH E VICARY whose telephone number is (571)270-1314. The examiner can normally be reached Monday to Friday, 9:00 AM to 5:00 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, Jyoti Mehta can be reached at (571)270-3995. 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.
/KEITH E VICARY/Primary Examiner, Art Unit 2183
Prosecution Insights