Abstract:
A method that enables testing any point (target point) within a core, including a point within a combinatorial circuit of a core, permits testing of points that are not otherwise unobservable in normal debugging processes. Such a target point is tested by identifying a fanout cone from that point to observable outputs, and by performing one or more tests, where each test sensitizes one or more paths that extend the signal of the target point, or its complement, to one or more of the observable outputs, and ascertains the values at those observable outputs. By having more than one observable output at which the signal of target point (or its complement) is tested significantly increases the level of confidence in the test when the observable points concur in the signal value of the target point.

Description:
RELATED APPLICATION 
   This application is related to U.S. patent application Ser. Nos. 10/425,101, filed Apr. 28, 2004, 10/956,854, filed Oct. 1, 2004, 11/051,774, filed Feb. 4, 2005, and 11/120,041, filed May 2, 2005, which are incorporated by reference herein. 
   BACKGROUND 
   This invention relates to functional testing and debugging of integrated circuits (ICs), and in particular testing and debugging of systems-on-chip (SoCs) that include blocks of previously verified logic, referred to as cores. 
   Determining the value of an internal signal in an IC is a fundamental problem in debugging a malfunctioning circuit when one is trying to find the root cause of its misbehavior. Of course, this problem is relevant only for signals that are not part of the circuit&#39;s state, because the values of signals that are part of the circuit&#39;s state can be easily determined by scanning out the state registers. That&#39;s because in modern ICs, all registers can be configured as shift registers, whose contents can be set by a scan-in operation, and can be read by a scan-out operation. 
   A useful technique for checking the design of ICs is called assertion checking. In assertion checking, a collection of conditions is identified that are expected to hold true at any time during the operation of a properly working SoC. The model of the SoC being tested can be simulated by application of various input test vectors, and its signals can be then checked against the collection of assertions. In a simulation, the signals checked by an assertion may include any internal signal. When an assertion “fires,” indicating that the asserted condition that should be met is not met, simulation can stop and the party performing the testing can attempt to analyze the reason for the assertion&#39;s failure. 
   The aforementioned U.S. patent application Ser. No. 10/425,101 discloses an SoC arrangement where cores of the SoC are encompassed by wrappers, and at least some of the wrappers include a functionally reconfigurable module (FRM). The aforementioned U.S. patent application Ser. No. 10/956,854 discloses use of the FRM in efficient assertion checking of SoCs. 
   Assertion checking in hardware, in contrast to simulation, is limited to checking only those signals that are made visible to the checking hardware. The set of signals to be checked at run-time is defined during the design of the SoC, and different subsets of this set can be selected at run-time. Such an example can be found in the paper “Silicon Debug: Scan Chains Alone Are Not Enough” by Rootselaar and Vermeulen,  Proceedings of the International Test Conference,  1999 
   If assertion checking is done when the functional clocks of the SoC have stopped, then the values stored in flip-flops of the SoC (and thus form a part of—or in part define—the state of the SoC) can be also examined by full-scan dumps. A full-scan dump consists of scanning out all the flip-flop values and then using software to extract the values needed to be examined. A different analysis method is described in the aforementioned Ser. No. 11/051,774, where bit extractors are configured in FRMs to extract the bits required for the assertion checking and make them available to assertion checkers that are also implemented in FRMs. The converse of bit extractors are bit injectors where flip-flops of the SoC are set via a stream of scanned-in bits. 
   One limitation common to all the methods mentioned above is that values of outputs of combinatorial logic elements within the SoC which are not directly observable by the checking hardware cannot be used for assertion checking. The need to determine the value of such a signal may appear many times during the hardware debugging process, and currently there is no method to determine such a value in a malfunctioning circuit. It is an objective, therefore, to enable checking the signal value of any internal point of an SoC in the course of debugging an SoC. 
   SUMMARY 
   The above deficiency is remedied, the objective is achieved, and an advance in the art is realized with a method that enables determining the value of any signal (target signal) in a combinatorial circuit of an SoC, typically of a core, that is otherwise unobservable. Such a target signal is tested by identifying a fanout cone from that signal to observable outputs, and by performing one or more tests, where each test sensitizes one or more paths that propagate the value of the target signal (or its complement) to one or more of the observable outputs, and ascertains the values at those observable outputs. By having more than one observable output at which the value of target signal (or its complement) is observed significantly increases the level of confidence in the result when the observable points concur in the value of the target signal. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  depicts an arrangement for checking the signal value of a combinatorial circuit within an SoC; 
       FIG. 2  illustrates the need to be careful about sensitizing paths so as not to change the value of the target signal; and 
       FIG. 3  is a flowchart of the method disclosed herein. 
   

   DETAILED DESCRIPTION 
     FIG. 1  shows an arrangement that includes core element  10  whose inputs and outputs are connected to wrapper  20 . Although for simplicity  FIG. 1  shows a wrapper—meaning that all functional inputs and outputs of core  10  pass through the wrapper—that is not a requirement of this invention, except as described below. Signals passing through a wrapper go through “replacement” multiplexers  22 ,  23 , . . . ,  26 . Every such multiplexer either allows the input or the output of the core to go through unchanged, or it replaces that signal with a signal provided by the FRM within wrapper  20 .  FIG. 1  illustratively also includes internal SoC test points  36 ,  37 , and  38  that are extended to the output of core  10  and attached to multiplexer  21 . The multiplexer  21  arrangement enables one to observe the values of the various test points that had been preselected in the design of the SoC and which are thereby selectable by multiplexer  21  at run-time. Such values can also be used as inputs to assertions implemented in wrapper  20 . For simplicity,  FIG. 1  does not show how the output of the multiplexer  21  is actually observed; for example, it may be further routed to an output port of the SoC, or its value may be captured in a flip-flop residing in wrapper  20 , from where it may be scanned out. Absent the methods described below, however, this arrangement is unable to determine the value of internal signals within the SoC, such as the signal  30 , which is the output of some combinatorial circuit  31 . 
   Given a signal  30 , a combinatorial circuit  31  can always be found with inputs that are observable. Thus, the set of possible inputs to circuit  31  includes outputs of internal flip-flops, such as inputs  11  and  13 , functional inputs of the core that arrive from wrapper  20 , such as inputs  12  and  14 , and outputs from other (combinatorial) circuits within the SoC that also happen to have been extended to multiplexer  21  (signals  37  and  38 ). In connection with the specific example of  FIG. 1 , it might be convenient to express the above by the equation
 
 S   30   =F   B ( S   11   , S   12   , S   13   , S   14   , S   37   , S   38 )
 
where S i  stands for the value of signal i, and F B  stands for “Boolean function.”
 
   Given a signal  30 , a combinatorial circuit  32  can always be found with outputs that are observable. Thus, the set of possible outputs of circuit  32  includes inputs of internal SoC flip-flops, such as flip-flops  16  and  18 , functional outputs of the core  10  that are applied to wrapper  20 , such as outputs  15  and  17 , and test points that had been extended to multiplexer  21 , such as output  36 . All are observable output signals, as flip-flops  16  and  18  can be scanned out, signals  15  and  17  can be captured in flip-flops residing in wrapper  20 , from where they can also be scanned out, and signal  36  is observable via multiplexer  21 . 
   If the debugging of the SoC is performed on a tester, then the primary inputs and primary outputs of the SoC are visible to the tester. However, if the SoC is debugged while it is operating in a system, its primary inputs and outputs are connected to other devices and are not directly observable for debug. But most integrated circuits today are designed in accordance to the IEEE standard 1149.1, described in “Standard Test Access Port and Boundary-Scan Architecture,” IEEE Standard 1149.1-1990, May 1990. The standard specifies that every chip has a boundary-scan register, which can capture the values of the pins of the chip, and this register can be scanned out to make these values observable. 
   Circuitry  31  is sometimes referred to as the “fanin cone” of signals that can affect the value of signal  30 , and circuitry  32  is sometimes referred to as the “fanout cone” of signals that signal  30  might affect. To reiterate, all inputs of a fanin cone and all outputs of a fanout cone are observable, and in a synchronous circuit where all state flip-flops are part of scan chains, for any internal signal such as 30 one can always determine a fanin cone bound by flip-flops and primary inputs, and a fanout cone bound by flip-flops and primary outputs 
   To review, it is an objective herein to enable determining the value of any internal target signal of an SoC, such as 30, in the course of debugging an SoC. This is accomplished by stopping the SoC functional clocks when the signal value of the target point is to be observed and proceeding with one or more tests, where each test sensitizes one or more paths that propagate the value of the target signal to one or more of the observable outputs and ascertains the values at those observable outputs. Path sensitization is described, for example, in “Digital Systems Testing and Testable Design” by Abramovici, Breuer, and Friedman,  IEEE Press,  1990. The result of the one or more experiments is either a determination of the target signal value, or a determination that an error condition exists in the fanout cone, or both. 
   For example, in  FIG. 1  a sensitized path for S 30  can be created by setting the output of flip-flop  19  to “0” and the output of the replacement multiplexer  25  to “1” (as illustrated in  FIG. 1 ), thus causing the outputs of gates  33  and  35  to be S 30 . This value can be captured in flip-flop  18  and the state of this flip-flop can be scanned out. A different sensitized path can be concurrently created by setting the output of flip-flop  39  to “1” (also illustrated in  FIG. 1 ), thus causing the output of gate  34  (signal  15 ) to be  S   30 . This value can be captured in a flip-flop in wrapper  20 , such as flip-flop  40 , and the state of this flip-flop can be scanned out. Whereas the two sensitized paths mentioned above can be established concurrently, effectively in one test, a skilled artisan will readily realize that in some cases this may not be possible, and two or more different tests/experiments may be needed to sensitize different paths. Use of a plurality of paths is necessary in order to make sure that the observable output truly reflects the target signal value, rather than a value dictated by a malfunctioning fanout cone element. Thus, if we obtain S 18 =1 and S 15 =0, these results are in agreement with each other, because both imply S 30 =1, and we can conclude with a fairly high level of confidence that the actual value of signal  30  is “1”, because an error that would affect propagation on the two disjoint paths is quite unlikely. Obviously, the more outputs of circuit  32  that can be made to reflect the value S 30 , and the more disjoint the sensitized paths, the greater is the level of confidence in the above conclusion. If, on the other hand, we obtain S 18 =S 15 =1, then it is known that an error exists in fanout cone  32  (regardless of whether S 30  is correct), because in a correctly operating circuit the values S 18  and S 15  must be complementary. Knowing the expected value of signal  30  (say “0”), we can determine which one of the output values is likely to be the incorrect one (assuming that the circuit does not suffer from two errors that mask the situation). In this example, S 15 =1 agrees with the expected value of the target signal, so we can conclude the error affects propagation along the path through gates  33  and  35  and flip-flop  18 . 
   In general, for a sensitized path from i to j, the relation between the values of the two signals is given by
 
S j =S i ⊕inv ij  
 
where inv ij  is the inversion parity of the sensitized path (1 if the number of inversions between i and j is odd, and 0 otherwise). To illustrate, in  FIG. 1 , the path from 30 to 15 has one inversion (inv ij =1), while the path from 30 to 18 has no inversions (inv ij =0).
 
   Flip-flop values needed for path sensitization can be obtained by scanning them in or by the method described in the aforementioned Ser. No. 11/051,774, where bit injectors are configured in FRMs to inject the required values. 
   Of course, any value assigned to sensitize a path should not modify the value of the target signal. For example, flip-flop  19  in  FIG. 2  affects both S 30  (via AND gate  41 ) and the fanout cone of S 30 , If S 30  is currently “1”, trying to sensitize the path from signal  30  to flip-flop  18  requires changing flip-flop  19  from “1” to “0”, but this changes the value S 30  to “0.” However, it is always possible to find at least one combination of values that will propagate the value of the target signal without changing it, provided that both the stuck-at-0 and the stuck-at-1 faults on the target signal are detectable in the given circuit. 
   It is important to make sure that the scan chains and the wrappers are correctly functioning before running any experiment that relies on their operation to set and observe values in the circuit. 
   The procedure to determine the value of an internal, otherwise unobservable, signal of an SoC is shown in  FIG. 3  and may be summarized as follows (though not all of the steps are essential to the invention per se): 
   1. (Preparation) Verify the operation of the scan chains and of the wrappers (not shown in  FIG. 3 ). 
   2. (Preparation) Identify a target signal and its fanin and fanout cones. 
   3. Run the circuit in its normal mode of operation. 
   4. Stop the functional clocks at a selected time (for example, when an assertion has fired, or after the operation lasted a user-specified number of clock cycles, etc.). 
   5. Save the state of the SoC by scanning out registers. 
   6. Sensitize a path or paths from the target signal to outputs of its fanout cone, thereby forming a set of relevant observable outputs, without changing the value of the target signal, and configure a processing module in the FRM for making determinations regarding the values obtained at the one or more observable outputs where the target signal value or its complement is to appear. Set the values needed for sensitization as follows:
         a. For SoC flip-flops, scan-in their required values or, use bit injectors configured in the FRM.   b. For primary inputs of the SoC, scan-in their required value in their corresponding boundary-scan flip-flops.   c. For inputs of the fanout cone traversing a wrapper, generate their required values in the wrapper and configure their corresponding replacement multiplexers to apply the generated values to the fanout cone inputs.       

   7. Collect and analyze the values of the relevant observable outputs
         a. For SoC flip-flops, scan-out their captured values or, use bit extractors configured in the FRM.   b. For primary outputs of the SoC, capture their values in their corresponding boundary-scan flip-flops, and scan-out their captured values.   c. For outputs of the fanout cone traversing a wrapper, capture their values in the flip-flops residing in wrappers and scan them out, or use bit extractors configured in wrappers.       

   8. Determine the values of the target signal based on the observed value and the inversion parity of the sensitized paths. Advantageously, the determining is performed in a processing module configured within the FRM (in step 6). 
   9. Check whether the determined values are consistent with each other and with a previously determined value. Advantageously, this is performed within the FRM. 
   10. If not, report a problem. 
   11. Otherwise, determine whether the desired level of confidence was reached. 
   12. If not, store the value of target signal in a Previous Value (PV) flip-flop of the FRM and return to step 6 so that different path, or paths, can be sensitized. 
   13. Otherwise, report the determined value. 
   14. Restore the state of the SoC by scanning in the state saved in step 5 and restart the functional clock.