When testing circuit devices such as system-on-a-chip (SOC) devices, both production tests and debug tests may be executed. As defined herein, “production tests” are those tests that are executed during the ordinary course of device testing, while “debug tests” are those tests that are executed for the purpose of extracting additional test data for the purpose of debugging a problem, or monitoring a trend, seen in one or more tested devices. Debug tests can also include tests that are used to debug the operation or effectiveness of a test itself.
Typically, the results of production tests and debug tests are co-mingled. As a result, it is often difficult for a user to determine whether any particular result is a production result or a debug result. Also, software that calculates statistics or performs other sorts of data analysis treats all of the test results the same. Thus, a statistic that is designed to track the outcome of a production test, executed on a large number of devices, could be skewed by a series of debug tests, executed on only one device.
Illustrative embodiments of the invention are illustrated in the drawings, in which:
As a preliminary manner, it is noted that, in the following description, like reference numbers appearing in different drawing figures refer to like elements/features. Often, therefore, like elements/features that appear in different drawing figures will not be described in detail with respect to each of the drawing figures.
In accord with one embodiment of the invention,
The debug indicators may also take various forms. In some cases, one or more of the debug indicators may comprise tags that are associated with individual ones of the test data items. Alternately, or additionally, one or more of the debug indicators may comprise contextual information that is interspersed with a sequential order in which the test data items are generated or received. Regardless of their form, each of the debug indicators is 1) associated with one or more of the plurality of test data items, and 2) specifies or suggests whether one or more of the test data items pertain to a production test mode or a debug test mode.
Returning to the method 100, the method begins with a computer automatically determining whether one or more of the afore-mentioned debug indicators indicate 1) that one or more of the test data items pertain to a production mode, or 2) that one or more of the test data items pertain to a debug mode. See, block 102. Before, during or after this determination, at least one mode selector is displayed via a graphical user interface (GUI). See, block 104. The at least one mode selector provides a graphical mechanism via which a user can select the production mode or the debug mode.
Upon user selection of the production mode, the method 100 updates the GUI to focus on a display of production test data. The production test data includes at least some of the test data items that pertain to the production mode, but none of the test data items that pertain to the debug mode. See, block 106. Upon user selection of the debug mode, the method 100 updates the GUI to focus on a display of debug test data. The debug test data includes at least some of the test data items that pertain to the debug mode, but none of the test data items that pertain to the production mode. See, block 108.
Of note, the steps of the method 100 may take orders other than those shown in
The method 100 can be advantageous in that production test data and debug test data is separately displayed, making it easier to determine what the data means, identify trends, et cetera. In the case of debug data, there will typically be much less data to review, making it easier to determine what the debug data means.
The method 100 shown in
Preferably, the window 202 is displayed during execution of a plurality of tests on which the test data entries 204, 206, 208 are based (i.e., during test of a device under test). New test results can then be displayed via the window as they are acquired, and a user can be provided a “real-time” display of test results. Alternately, device testing can be completed, and a log of test results can be saved to volatile or non-volatile storage (e.g., memory or a hard disk). The test results can then be read and displayed in succession via the window 202 (i.e., not in real-time). Typically, the test data entries 204, 206, 208 that are displayed at any one time represent only some of the test data entries or items that are generated during execution of a plurality of tests. One or more mechanisms such as a scroll bar 232 may be provided to allow a user to navigate to different test data entries or items.
By way of example,
As a result of
Although the “Production” and “Debug” buttons 212, 214 are shown in
Also, in addition to (or instead of) one of the buttons 212, 214 being shown depressed to indicate which of the production display 228 or debug display 230 is currently displayed, the buttons 212, 214 or other identification/selection mechanisms could be distinguished in other ways, such as by use of contrasting colors, highlighting or bolded text labels.
In addition to providing graphical buttons 212, 214 for selecting the production mode or the debug mode, the GUI 200 provides a plurality of graphical tabs 218, 220, 222, 224 labeled “Test Results”, “Test Statistics”, “Test Time” and “Bin Statistics”. These tabs 218, 220, 222, 224 are subservient to the mode selector buttons 212, 214, such that selection of one of the mode selector buttons 212, 214 results in the tabs 218, 220, 222, 224 being alternately configured to access production test data or debug test data. Similarly, test data items pertaining to 1) the production mode or the debug mode, and 2) one of the tabs 218, 220, 222 or 224, are swapped into the common fill area 216. Thus, for example, selection of the “Test Statistics” tab 220 while the “Debug” button 212 is depressed would result in test statistics pertaining to the debug mode being displayed in the common fill area 216, as shown in
The precise format and content of the data which is displayed after user selection of one of the tabs 220, 222 or 224 is beyond the scope of this disclosure.
As further shown in
Similarly to the mode selector buttons 212, 214, the tabs 218, 220, 222 and 224 could also be implemented in other ways. For example, the tabs 218, 220, 222 and 224 could be implemented via any or all of: graphical buttons, check boxes, pull-down menu selections, pop-up menu selections, graphical toolbar icons, or dialog box options.
The window 202 further displays a “Clear” button 226. The “Clear” button 226 is configured to clear test data for whichever mode (production or debug) is currently selected. In some cases, the “Clear” button 226 may be configured to only clear data that corresponds to a currently selected one of the tabs 218, 220, 222 or 224. Alternately, the “Clear” button 226 could be configured to clear all production data or all debug data, depending on which mode has been selected via the buttons 212 and 214. Of note, all of the configurations mentioned in this paragraph may be performed “in the background”, by computer-readable code that supports the GUI 200. Alternately, the configurations could be performed as part of an application setup or configuration routine.
Instead of a “Clear” button 226, a user-selectable mechanism for separately clearing at least a portion of 1) production test data, or 2) debug test data, could be implemented in other ways. For example, the mechanism could be implemented via any or all of: one or more graphical buttons, check boxes, pull-down menu selections, pop-up menu selections, graphical toolbar icons, or dialog box options.
In accord with a second exemplary embodiment of the invention,
The method 400 begins with a computer automatically determining whether one or more of the afore-mentioned debug indicators indicate 1) that one or more of the test data items pertain to a production mode, or 2) that one or more of the test data items pertain to a debug mode. See, block 402. At least one production statistic is then compiled based on 1) at least some of the test data items pertaining to the production mode, but 2) none of the test data items pertaining to the debug mode. See, block 404. Optionally, at least one debug statistic may also be compiled, based on 1) at least some of the test data items pertaining to the debug mode, but 2) none of the test data items pertaining to the production mode. See, block 406. The production and/or debug statistic(s) may then be displayed via a GUI. See, block 408.
The method 400 can be advantageous because it does not skew production statistics with debug test data, and vice versa.
In one embodiment of the method 400, either one or more of the production statistics, or one or more of the debug statistics, are alternately displayed. This may be accomplished via the GUI 200 (
The method 400 may also comprise providing, via the GUI, one or more user-selectable mechanisms for separately clearing 1) one or more of the production statistics, or 2) one or more of the debug statistics. In the GUI 200 (
Similarly to the method 100, the method 400 may be implemented by means of computer-readable code stored on computer-readable media.