Patent Application
20080270835
When testing circuit devices such as system-on-a-chip (SOC) devices, various test data items may be logged, including test results and alerts. Typically, the test data items are displayed to a user by compiling them into a single list, and then displaying the list via a graphical user interface (GUI).
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,
After or during the parsing of the test data items, the identified test results and at least some of the context information is displayed in a first display area of a graphical user interface (GUI), and the error alerts and at least some of the context information is displayed in a second display area of the GUI. See, blocks 104 and 106. By way of example, the first and second display areas may take forms such as 1) first and second panes of a single window of the GUI, or 2) first and second windows of the GUI.
The method 100 is useful in that it displays test results and alerts in separate display areas, but with context information that enables a user to determine how each of them (the test results and the alerts) relates to a test execution sequence. Because there are typically far fewer alerts than there are test results, the method 100 enables a user to find the alerts much more quickly than in the past, without having to hunt for them amongst thousands or even millions of test results. Separating the displays of the alerts and test results also enables a user to more easily assess failures on a global level.
In some cases, the first and second display areas provided by the method 100 may be formatted differently, to better convey the test results and alerts to a user. For example, the test results and context information displayed in the first display area may be displayed via a table, with each of the test results and context information forming an entry (e.g., row) in the table. In contrast, the alerts and context information displayed in the second display area may be displayed via a list. In one embodiment, lines of the list may be indented to distinguish different levels of related context information.
The method 100 shown in
The test result of each test data entry 204, 206, 208 may be conveyed in various ways, including, as a value 210 in a “Result” field and/or a check 212 in a “Fail” field (e.g., for those tests that have failed). For measurement-type test results, “Low Limit” and “High Limit” fields may also be populated.
As further shown in
The contextual information displayed in the display area 216 may take various forms, and in some cases may comprise any or all of: test program identifiers 234, test identifiers 220, and other information. In one embodiment, different levels of a contextual outline displayed in the area 216 may correspond to: test program identifiers 234, testflow identifiers 236, test suite identifiers 238, test site identifiers (e.g., test site number 222), test identifiers (e.g., test numbers 220), and test bin information (not shown). The alerts 218 displayed in the display area 216 may also take various forms, such as user alerts, error alerts, warnings, and test execution mode messages (e.g., messages related to switches between production and debug test execution modes).
In some cases, some or all of the context information displayed in the areas 202 and 216 of the GUI 200 may be the same. However, it is envisioned that the type and format of the context information displayed in the two areas 202, 216 will often differ.
As previously mentioned, the alerts displayed in the area 216 may take different forms, including those of error alerts and system alerts. In addition, the formats of the alerts may take different forms. For example, alerts may comprise messages (e.g., an error message 218 indicating that a “DSP array size parameter is out of range”) or codes (e.g., an error code “32”).
Preferably, the display areas 202 and 216 are 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). Test results and alerts can then be displayed via the display areas 202 and 216 as they are acquired, and a user can be provided “real-time” displays of test results and alerts. Alternately, device testing can be completed, and logs of test results, alerts, and their context information can be saved to volatile or non-volatile storage (e.g., memory or a hard disk). The test results, alerts 218 and context information can then be read and displayed in succession via the display areas 202 and 216 (i.e., not in real-time).
Typically, the test data entries 204, 206, 208 and alerts 218 that are displayed at any one time represent only some of the test data entries alerts that are generated during execution of a plurality of tests. As a result, one or more user-operable navigation mechanisms such as scroll bars 220, 222 may be provided via the GUI 200, thereby enabling a user to navigate to different test data entries or alerts.
The scroll bar 220 is associated with the display area 202, and the scroll bar 222 is associated with the display area 216. In one embodiment, scrolling activity within the display areas 202 and 216 may be synchronized, such that navigation to a particular test data entry in the display area 202 causes the display area 216 to display alerts (if any) that are proximate to the context of the test data entries shown in the display area 202. Similarly, navigation to a particular alert in the display area 216 may cause the display area 202 to display one or more test results (or test data entries) that are proximate to the context of the alerts shown in the display area 216. In an alternate embodiment, the scroll bars 220 and 222 function independently, and the display areas 202 and 216 are not synchronized.
In addition (or in lieu of) the scroll bar 222, other user-operable navigation mechanisms may be associated with the display area 216. For example, the GUI 200 may provide one or more buttons 224, 226 for navigating from one alert to another. These buttons may include a button 224 for navigating to a next alert, and a button 226 for navigating to a previous alert. Alternately, different sets of buttons could be provided for navigating different types of alerts (e.g., separate sets of buttons for navigating error versus system alerts), or a single button could be provided for simply jumping to the next alert. A pair of buttons 228, 230 may also be associated with a text field 232, and may be used to navigate to alerts containing the term or terms entered in the text field 232. As with the scroll bar 222, the buttons 224, 226, 228, 230 for navigating from one alert to another may, or may not, be configured to operate independently from any mechanisms 220 for navigating from one test result (or test data entry) to another.
In one embodiment, the alerts that are displayed via the display area 216 may be emphasized by highlighting them, bolding them or underlying them. Alerts may also be emphasized in other ways, or in combinations of ways. An alert may also be emphasized upon a user's navigation to the alert. Or, an alert that has already been emphasized in one manner may be emphasized in a different manner upon a user's navigation to the alert.
