Patent Publication Number: US-11656964-B2

Title: Processor with non-intrusive self-testing

Description:
CROSS-REFERENCED TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 15/841,442, filed on Dec. 14, 2017, which claims priority to India Provisional Application No. 201741027612, filed on Aug. 3, 2017, which is hereby incorporated by reference. 
    
    
     BACKGROUND 
     Microprocessors, microcontrollers, and similar electronic devices, are used in a variety of applications. Various conditions and events can cause failures in such devices that adversely affect device operation. The consequences of such failures are typically of much greater concern when the devices in which the failures occur are performing mission critical processes or processes that affect user safety. To ensure proper operation in such applications, the operational condition of the devices is continuously evaluated. The devices may include self-test features that support the continuous evaluation of operation. 
     SUMMARY 
     Apparatus and methods for monitoring processor operation are disclosed herein. In one example, a processor includes a central processing unit (CPU) and diagnostic monitoring circuitry. The diagnostic monitoring circuitry is coupled to the CPU. The diagnostic monitoring circuitry includes a monitoring and cyclic redundancy check (CRC) computation unit. The monitoring and CRC computation unit is configured to detect execution of a diagnostic program by the CPU, and to compute a plurality of CRC values. Each of CRC values corresponds to processor values retrieved from a given register of the CPU or from a bus coupling the CPU to a memory and peripheral subsystem while the CPU executes the diagnostic program. Each of the CRC values corresponds to various aspects of the CPU, such as registers, memory buses, or internal states during execution of the diagnostic program. 
     In another example, processor diagnostic circuitry includes diagnostic monitoring circuitry. The diagnostic monitoring circuitry includes a monitoring and cyclic redundancy check (CRC) computation unit. The monitoring and CRC computation unit is configured to detect execution of a diagnostic program by a central processing unit (CPU), and to compute a plurality of CRC values. Each of the CRC values corresponds to processor values retrieved from a given register of the CPU or from a bus coupling the CPU to a memory and peripheral subsystem while the CPU executes the diagnostic program. Each of the CRC values corresponds to various aspects of the CPU, such as registers, memory buses, or internal states during execution of the diagnostic program. 
     In a further example, a method for monitoring processor health includes executing, by a processor, instructions of a diagnostic program during discontinuous processor idle intervals. The method also includes detecting, by diagnostic monitoring circuitry, execution of the diagnostic program in the discontinuous idle intervals. The method further includes computing a plurality of cyclic redundancy check (CRC) values, each of CRC values corresponding to processor values retrieved from a given register of a central processing unit (CPU) of the processor while the CPU executes the diagnostic program. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a detailed description of various examples, reference will now be made to the accompanying drawings in which: 
         FIG.  1    shows a block diagram of a processor that includes non-intrusive self-testing in accordance with various examples; 
         FIG.  2    shows a block diagram of a monitoring and cyclic redundancy check computation unit for non-intrusive self-testing in accordance with various examples; 
         FIG.  3    shows an example of a self-test execution time sequence in a processor that includes non-intrusive self-testing in accordance with various examples; 
         FIG.  4    shows a block diagram of a pipeline extraction unit for non-intrusive self-testing in accordance with various examples; 
         FIG.  5    shows a flow diagram for a method for executing a non-intrusive self-test in accordance with various examples; and 
         FIG.  6    shows a flow diagram for a method for non-intrusive self-testing in accordance with various examples. 
     
    
    
     DETAILED DESCRIPTION 
     Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, different parties may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct wired or wireless connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections. The recitation “based on” is intended to mean “based at least in part on.” Therefore, if X is based on Y, X may be a function of Y and any number of other factors. 
     Periodic self-testing is important, or required, in a number of applications (e.g., some embedded real-time applications, mission critical applications, etc.). However, conventional techniques for self-testing may be intrusive or inefficient. For example, hardware built-in self-test (BIST) is intrusive because the central processing unit (CPU) being tested in not available to execute a user application while the hardware BIST is being performed. Alternatively, purely software based self-testing is inefficient because a large number of instructions must be executed to provide adequate fault coverage. 
     Example processors of the present disclosure include self-testing that is non-intrusive and efficient. Self-testing may be fully interruptible to provide the fast response times required in embedded real-time systems. In some examples, self-test programming may execute only during CPU idle time, so application program timing is generally unaffected by self-testing. The disclosed processors may include circuitry that retrieves register and state values from the CPU, processor busses, peripheral devices, etc. During execution of the self-test program, each given type of retrieved value is input to cyclic redundancy check (CRC) circuitry that computes a CRC value for the given type of retrieved value over the length of the self-test. On completion of self-test program execution, the CRC values are compared to predetermined correct CRC values stored with the self-test program to determine whether the CPU and associated systems are operating properly. 
       FIG.  1    shows a block diagram of a processor  100  that includes non-intrusive self-testing in accordance with various examples. The processor  100  may be a general-purpose microprocessor, a microcontroller, a digital signal processor, or other instruction execution device. The processor  100  includes a central processing unit (CPU)  102 , a memory and peripheral subsystem  108 , and diagnostic monitoring circuitry  112 . The CPU  102  includes circuitry that executes instructions retrieved from memory. For example, the CPU  102  may include an execution pipeline including a fetch unit, a decode unit, and an execution unit. Some examples of the CPU  102  may include additional functional units, such as data and/or instruction caches, branch prediction circuitry, etc. The fetch unit retrieves instructions from instruction memory, for execution by the processor  100 . The instruction memory may be included in the processor  100 , or external to the processor  100 . The fetch unit provides the retrieved instructions to the decode unit. 
     The decode unit examines the instructions received from the fetch unit, and translates each instruction into controls suitable for operating the execution unit, processor registers, and other components of the processor to perform operations that effectuate the instructions. The decode unit provides control signals to the execution unit, and other units of the processor  100 , that cause the processor  100  to carry out the operations needed to execute each instruction. 
     The execution unit includes arithmetic circuitry, shifters, multipliers, registers, logical operation circuitry, etc. that are arranged to manipulate data values as specified by the control signals generated by the decode unit. Some implementations of the processor  100  may include multiple execution units that include the same or different data manipulation capabilities. 
     The memory and peripheral subsystem  108  includes various circuits that operate in conjunction with the CPU  102 . For example, the memory and peripheral subsystem  108  may include memories for storing program and data, communication circuits, interrupt control circuits, timer circuits, direct memory access control circuits, and/or various other circuits that provide services to the CPU  102 . The memory and peripheral subsystem  108  is communicatively coupled to the CPU  102  via one or more buses  114 . 
     The diagnostic monitoring circuitry  112  monitors the operation of the CPU  102  and/or the memory and peripheral subsystem  108  to determine whether the processor  100  is operating properly. The diagnostic monitoring circuitry  112  is coupled to the CPU  102 , the memory and peripheral subsystem  108 , and/or the one or more busses  114  for transfer of information regarding the operational state of the CPU  102  and/or the memory and peripheral subsystem  108  to the diagnostic monitoring circuitry  112 . The diagnostic monitoring circuitry  112  includes a pipeline extraction unit  104 , a monitoring and CRC computation unit  106 , and a supervisor circuitry  110 . 
     The pipeline extraction unit  104  is coupled to the CPU  102 . The pipeline extraction unit  104  retrieves information from the CPU  102  that would not otherwise be available to circuitry external to the CPU  102 . For example, the pipeline extraction unit  104  may retrieve from the CPU  102  instruction register contents, pipeline state information, program counter values, and/or other information generated internal to the CPU  102 . The pipeline extraction unit  104  may combine some information retrieved from the CPU  102  so that the amount of information provided to the monitoring and CRC computation unit  106  can be reduced. For example, the pipeline extraction unit  104  may simultaneously retrieve multiple different values from the CPU  102  and combine multiple values using an exclusive-OR function. The exclusive-OR of the multiple values may be provided to the monitoring and CRC computation unit  106 . 
     The monitoring and CRC computation unit  106  is coupled to the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and the one or more buses  114 . The monitoring and CRC computation unit  106  captures information provided by the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and the one or more buses  114  and computes a CRC value for each different type of information captured over the execution of a self-test program (also referred to herein as a diagnostic program) by the processor  100 . For example, the monitoring and CRC computation unit  106  may compute a first CRC value using program counter values retrieved during execution of the self-test program, compute a second CRC value using instruction register values retrieved during execution of the self-test program, etc. 
     The monitoring and CRC computation unit  106  analyzes the information received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and the one or more buses  114  to determine whether a CRC value is to be updated using the received information. Because the CRC values are updated based on execution of the self-test program, some implementations of the monitoring and CRC computation unit  106  examine program counter values to determine whether the self-test program is executing. For example, a range of address values at which the self-test program is stored may be pre-programmed into the monitoring and CRC computation unit  106 . If the program counter address value falls within the range of address values, then the monitoring and CRC computation unit  106  may update CRC values using the information retrieved from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and the one or more buses  114 . 
     When execution of the self-test program is complete, the CRC values computed by the monitoring and CRC computation unit  106  may be compared to predetermined correct CRC values to determine whether the processor  100  passed or failed the self-test. For example, the predetermined expected CRC values may be stored as part of the self-test program and comparison of the computed CRC values to the predetermined correct CRC values may be performed by the CPU  102  as part of self-test program execution or performed by the monitoring and CRC computation unit  106 . Results of the self-test may be stored for further processing and/or provided to a user. 
     The supervisor circuitry  110  monitors self-testing to ensure that execution of the self-test program is in accordance with established specifications. For example, if an established specification provides that the self-test program should execute for at least a first amount of time in a predetermined time interval, then the supervisor circuitry  110  may measure execution time of the self-test in the predetermined time interval and adjust operating parameters of the processor  100  to change the execution time of the self-program based on the measured execution time. Adjustments may include enforcing a minimum execution time for the self-test program in preemption of user programs. 
       FIG.  2    shows a block diagram of the monitoring and CRC computation unit  106  in accordance with various examples. The monitoring and CRC computation unit  106  includes CRC computation circuitry  202 , CRC control circuitry  204 , and CRC registers  206 . The CRC registers  206  include a register  208  for each of a plurality of CRC values computed by the monitoring and CRC computation unit  106 . For example, the CRC registers  206  may include a register  208  for storage of each of a write data CRC value, a write address CRC value, a read data CRC value, a read address CRC value, an instruction register CRC value, a program counter CRC value, and an internal nodes CRC value. The number of bits provided in each CRC register  208  may vary in different implementations. In some implementations, a CRC register  208  may store a 32-bit CRC value. 
     The CRC computation circuitry  202  is coupled to the CRC registers  206 , the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114 . The CRC computation circuitry  202  includes circuitry that evaluates a CRC polynomial with respect to the current value of a CRC register  208  and a new information value received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114 . Thus, the CRC computation circuitry  202  retrieves a value from the CRC registers  206 , computes a CRC value based on the value retrieved from the CRC registers and a new information value, and stores the result of polynomial evaluation in the CRC registers  206 . Some implementations of the CRC computation circuitry  202  may include separate CRC evaluation circuits for each CRC register  208 . 
     The CRC control circuitry  204  examines the information received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114  to determine whether the self-test is executing and the CRC values stored in the CRC registers  206  should be updated based on the information received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114 . For example, the CRC control circuitry  204  may store information defining a range of address values at which the self-test program is stored. If a program counter address value received from the pipeline extraction unit  104  falls within the range, then the CRC control circuitry  204  may determine that the self-test is executing, and in-turn may select a CRC register  208  corresponding to received information to be updated and enable the CRC computation circuitry  202  to update the CRC value stored in the selected CRC register  208 . 
       FIG.  3    shows self-test execution in the processor  100  in accordance with various examples. In implementations of the processor  100 , execution of the self-test program is interleaved with execution of user programs. In  FIG.  3   , execution of the self-test  304  is interleaved with execution of a user task  302 . For example, the processor  100  may execute the self-test  304  only when no user task  302  is ready to execute. That is, the processor  100  may execute the self-test  304  only when the CPU  102  would be idle otherwise (i.e., CPU idle time). Thus, execution of the self-test  304  does not interfere with the timing of execution of the user task  302 . Because execution of the self-test  304 , from start to end, is performed over any number of discontinuous execution intervals, the monitoring and CRC computation unit  106  identifies execution of the self-test program. The monitoring and CRC computation unit  106  enables updating of the CRC registers  206  over the entire discontinuous execution of the self-test program, and disables updating of the CRC registers  206  if a user task  302  is executing. 
       FIG.  4    shows a block diagram of the pipeline extraction unit  104  in accordance with various examples. As shown in  FIG.  1   , the pipeline extraction unit  104  interfaces with the CPU  102 . In  FIG.  4   , the pipeline nodes  402 ,  404 ,  406 ,  408 , and  410  may be outputs of registers or other circuits in the CPU  102 . The pipeline extraction unit  104  passes some information retrieved from a pipeline node through to the monitoring and CRC computation unit  106  without modification. Thus, the pipeline extraction unit  104  provides the monitoring and CRC computation unit  106  with direct access to information generated in the CPU  102 . In  FIG.  4   , information retrieved from the pipeline node  410  is passed without modification to the monitoring and CRC computation unit  106  as raw output  416 . Implementations of the pipeline extraction unit  104  may pass, without modification, information retrieved from any number of pipeline nodes of the CPU  102 . 
     The pipeline extraction unit  104  may also include circuitry to process or combine information retrieved from some pipeline nodes of the CPU  102 . By combining information retrieved from multiple pipeline nodes of the CPU  102 , the pipeline extraction unit  104  reduces the number of different data values provided to the monitoring and CRC computation unit  106 , which in turn reduces the number of CRC values maintained by the monitoring and CRC computation unit  106 . In the example of  FIG.  4   , the pipeline extraction unit  104  includes exclusive-OR circuitry  412 . Information retrieved from pipeline nodes  402 ,  404 ,  406 , and  408  is combined by the exclusive-OR circuitry  412  to produce a composite output  414  that is provided to the monitoring and CRC computation unit  106 . Implementations of the pipeline extraction unit  104  may combine information retrieved from any number of pipeline nodes of the CPU  102  to produce a composite output, and implementations may produce any number of different composite outputs that combine different pipeline nodes of the CPU  102 . 
       FIG.  5    shows a flow diagram for a method for executing a non-intrusive self-test in accordance with various examples. Though depicted sequentially as a matter of convenience, at least some of the actions shown can be performed in a different order and/or performed in parallel. Additionally, some implementations may perform only some of the actions shown. At least some of the operations of the method  500  can be implemented by the processor  100 . 
     In block  502 , the processor  100  is executing instructions retrieved from program storage (i.e., instructions retrieved from memory). The monitoring and CRC computation unit  106  is receiving information from the pipeline extraction unit, the memory and peripheral subsystem  108 , and/or the buses  114 . If the instructions being executed are part of a user program (i.e., user task  302 ), then monitoring of program execution continues in block  502 . 
     On the other hand, if no user program is being executed in block  502  (i.e., no user program is ready for execution), then in block  504 , the processor  100  starts or resumes execution of instructions of a self-test program (i.e., self-test  304 ). 
     In block  506 , the processor  100  is executing the self-test program started in block  504 . The processor  100  determines whether a user program is ready to be executed. If no user program is ready to be executed, then the processor  100  continues to execute the self-test program. 
     If a user program is ready to be executed in block  506 , then in block  508 , the processor  100  suspends execution of the self-test program and starts/resumes execution of the user program. 
     Thus, the processor  100  executes the self-test program only if no user program is executing or ready to be executed. In this way, implementations of the processor  100  provide self-testing that is non-intrusive respect to the timing or functionality of user programs. 
       FIG.  6    shows a flow diagram for a method for non-intrusive self-testing in accordance with various examples. Though depicted sequentially as a matter of convenience, at least some of the actions shown can be performed in a different order and/or performed in parallel. Additionally, some implementations may perform only some of the actions shown. At least some of the operations of the method  600  can be implemented by the processor  100 . 
     In block  602 , the processor  100  is executing instructions retrieved from program storage (i.e., instructions retrieved from memory). The pipeline extraction unit  104  retrieves various information values from the CPU  102 . The information values may include a program counter value, an instruction value, a read address value, a read data value, a write address value, and/or a write data value, and/or various state/data values provided in registers of the CPU  102  and/or present at pipeline nodes of the CPU  102 . 
     In block  604 , the pipeline extraction unit  104  combines some of the information values retrieved from the CPU  102  to reduce the number of values provided to the monitoring and CRC computation unit  106 . Some implementations of the pipeline extraction unit  104  may apply an exclusive-OR function to produce a value that is a composite of multiple values retrieved from the CPU  102 . 
     In block  606 , the monitoring and CRC computation unit  106  evaluates the information received from the pipeline execution unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114  to determine whether the CPU  102  is currently executing a self-test (i.e., self-test  304 ). For example, the monitoring and CRC computation unit  106  may compare the address of an executing instruction received via the pipeline extraction unit  104  to the address range at which the self-test program is stored to determine whether the self-test is executing. If the self-test is not executing, then the method continues in block  602  with retrieval of additional information from the CPU  102 . 
     If, in block  606 , the monitoring and CRC computation unit  106  determines that the self-test is executing, then in block  608 , the monitoring and CRC computation unit  106  computes a CRC value for each of a plurality of information values received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114 . Computing the CRC value may include retrieving a current CRC value from storage (e.g., a register  208 ) and applying the current CRC value and a new information value received from the pipeline extraction unit  104 , the memory and peripheral subsystem  108 , and/or the buses  114  to a predetermined polynomial. 
     In block  610 , the processor  100  determines whether self-test execution is complete. For example, execution of the self-test may include setting a state value that designates self-test completion. In various implementations, the determination of self-test completion may be made by the supervisor circuitry  110 , the CPU  102 , the monitoring and CRC computation unit  106 , or other component of the processor  100 . If the self-test is complete, then in block  616 , the processor  100  determines whether the self-test failed or passed. The processor  100  may compare the CRC values computed by the monitoring and CRC computation unit  106  during self-test execution to predetermined correct CRC values. For example, for each CRC value computed by the monitoring and CRC computation unit  106  a predetermined correct CRC value may be stored in memory (e.g., as part of the self-test program). If the CRC values computed by the monitoring and CRC computation unit  106  during self-test execution are equal to the predetermined correct CRC values, then the processor  100  is deemed to pass the self-test in block  618 . On the other hand, if the CRC values computed by the monitoring and CRC computation unit  106  during self-test execution are not equal to the predetermined correct CRC values, then the processor  100  is deemed to fail the self-test in block  620 . 
     If, in block  610 , the processor  100  determines that execution of the self-test is not complete, then in block  612 , the supervisor circuitry  110  determines whether a minimum amount of time has been devoted to execution of the self-test. The minimum amount of time may be at least a predetermined test execution time within a given time interval (e.g., 10 milliseconds per second). If the time devoted to execution of the self-test is low (e.g., execution time of user tasks allows too little time for self-test execution), then in block  614 , the supervisor circuitry  110  adjusts operation of the processor  100  to ensure that the self-test executes for at least the minimum execution time. For example, the supervisor circuitry  110  may disable preemption of the self-test by user tasks for at least a time selected to provide the self-test with the required minimum execution time. 
     The above discussion is meant to be illustrative of the principles and various examples of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.