Apparatus and method for time ordering events in a system having multiple time domains

FIELD OF THE INVENTION

The present invention relates generally to time ordering events, and more particularly to time ordering events in a system having multiple time domains.

RELATED ART

Timestamping is a useful technique that may be used in a system, such as, for example, in debugging a system, to indicate when a desired event occurred in the system. Some systems, including systems which are integrated on a single integrated circuit, include a plurality of time domains. For some applications, there may be no easy method for directly correlating time domains with each other and with time references external to the system.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limited by the accompanying figures, in which like references indicate similar elements, and in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates, in block diagram form, a system in accordance with one embodiment of the present invention;

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates, in block diagram form, a time domain message <b>100</b> in accordance with one embodiment of the present invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates, in block diagram form, a time domain message <b>110</b> in accordance with one embodiment of the present invention;

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates, in block diagram form, a master message <b>120</b> in accordance with one embodiment of the present invention; and

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates, in flow diagram form, a method for time-ordering debug events in accordance with one embodiment of the present invention.

Skilled artisans appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve the understanding of the embodiments of the present invention.

DETAILED DESCRIPTION

As used herein, the term “bus” is used to refer to a plurality of signals or conductors which may be used to transfer one or more various types of information, such as, for example, data, addresses, control, or status.

Illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> is a data processing system <b>10</b> generally having a time domain <b>12</b>, a time domain <b>32</b> and a time domain <b>22</b>. The time domain <b>12</b> includes a module that represents functional circuitry <b>14</b>. Contained within functional circuitry <b>14</b> is NEXUS debug circuitry <b>16</b> where “NEXUS”™ refers to the publicly available IEEE ISTO 5001 standard for debugging and/or emulating, and/or testing integrated circuits. Similarly, time domain <b>32</b> has functional circuitry <b>34</b> and NEXUS debug circuitry <b>36</b>. Time domain <b>22</b> has functional circuitry <b>24</b> and NEXUS debug circuitry <b>26</b>. One possible embodiment of the NEXUS debug circuitry <b>36</b> is illustrated in detail. It should be apparent that NEXUS debug circuitry <b>16</b> and NEXUS debug circuitry <b>26</b> may be implemented in the same manner or with variations. The functional circuitry <b>14</b> is coupled to a NEXUS module <b>70</b> by a debug bus <b>18</b>. NEXUS debug circuitry <b>36</b> is coupled to NEXUS module <b>70</b> by a debug bus <b>38</b>, and NEXUS debug circuitry <b>26</b> is coupled to NEXUS module <b>70</b> by debug bus <b>28</b>.

The NEXUS debug circuitry <b>36</b> includes timestamp circuitry <b>40</b> having counter control circuitry <b>42</b> and a reference counter <b>44</b>. NEXUS debug circuitry <b>36</b> also includes a clock status circuit <b>46</b>, a time domain identifier <b>48</b>, a TCODE generator <b>50</b>, and other circuitry <b>52</b>. The debug bus <b>38</b> is formed by a timestamp control bus <b>60</b> coupled from NEXUS module <b>70</b> to the counter control circuitry <b>42</b>, timestamp signals <b>62</b> coupled from the counter control circuitry <b>42</b> to the NEXUS module <b>70</b>, a domain event information bus <b>64</b> coupled from the other circuitry <b>52</b> to NEXUS module <b>70</b>, and a bidirectional bus for other signals <b>66</b>. In one embodiment, the other signals <b>66</b> couple the clock status <b>46</b>, time domain identifier <b>48</b>, TCODE generator <b>50</b>, and other circuitry <b>52</b> to the NEXUS module <b>70</b>. The other signals <b>66</b> are bidirectionally coupled between the other circuitry <b>52</b> and the NEXUS module <b>70</b>.

The NEXUS module <b>70</b> generally includes a timestamp control circuit associated with each time domain. In the illustrated form, timestamp control <b>72</b> is coupled to debug bus <b>18</b>. Timestamp control <b>74</b> is coupled to each bus that forms debug bus <b>38</b>, except the other signals <b>66</b> bus that couples to other control circuitry (not shown) within NEXUS module <b>70</b> that is not relevant to the debug functionality described herein. Timestamp control <b>76</b> is coupled to debug bus <b>28</b>. An arbiter <b>78</b> is bidirectionally coupled to each of timestamp control <b>72</b>, timestamp control <b>74</b> and timestamp control <b>76</b>, and to a plurality of registers <b>80</b>. Each of timestamp control <b>72</b>, <b>74</b>, and <b>76</b> is bidirectionally coupled to the plurality of registers <b>80</b>. A bidirectional NEXUS interface port <b>92</b> is coupled to arbiter <b>78</b>. A bidirectional JTAG interface <b>94</b> is coupled to the plurality of registers <b>80</b>. The plurality of registers <b>80</b> is bidirectionally coupled to and from a system bus <b>96</b>. System bus <b>96</b> is also bidirectionally coupled to each of time domain <b>12</b>, time domain <b>32</b> and time domain <b>22</b>.

Note that a common standard used for integrated circuit debug, emulation, and/or testing purposes is the well known JTAG (Joint Test Action Group) IEEE (Institute of Electrical and Electronic Engineers) 1194.1 test access port and boundary scan architecture. Although debug interface <b>90</b> has been illustrated as having a JTAG interface, alternate embodiments of system <b>10</b> may use any desired interface. For example, in addition to the standard JTAG interface, there are a wide variety of other debug, emulation, and/or test interfaces used for integrated circuits. Similarly, alternate embodiments may use a wide variety of other debug, emulation, and/or test interfaces in place of the NEXUS interface <b>92</b>.

In one embodiment of system <b>10</b>, debugger <b>93</b> may optionally be coupled to debug interface <b>90</b> during at least a portion of the debugging process for system <b>10</b>. Alternate embodiments may not require an external debugger <b>93</b> to perform debugging functionality. In one embodiment, system <b>10</b> may be implemented on a single integrated circuit and debugger <b>93</b> may be implemented external to that integrated circuit. For some embodiments, debugger <b>93</b> is not coupled to debug interface <b>90</b> during normal operation of system <b>10</b>. Debugger <b>93</b> may be implemented using any combination of hardware and software.

Operation of the system <b>10</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> will now be described. In one embodiment that is illustrated, a plurality of time domains <b>12</b>, <b>22</b>, <b>32</b> may provide time-related information regarding when an event within the time domain occurred. In one embodiment, time domains are local regions in system <b>10</b> with a common power and/or clock domain. Elements within a time domain remain synchronized by design, however time domains are not typically required to remain fully synchronized with other time domains. In one embodiment, each one of time domains <b>12</b>, <b>22</b>, <b>32</b> includes functional circuitry <b>14</b>, <b>24</b>, <b>34</b>, respectively, which functions using an independent clock or derivatives of a same clock. Functional circuitry <b>14</b>, <b>24</b>, and <b>34</b> may perform any desired function. Note that each time domain <b>12</b>, <b>22</b>, <b>32</b> also includes NEXUS debug circuitry <b>16</b>, <b>26</b>, and <b>36</b>, respectively. Alternate embodiments may use other circuitry <b>16</b>, <b>26</b>, <b>36</b> which is not NEXUS debug circuitry.

Note that although system <b>10</b> has been illustrated to have three time domains, namely times domain <b>12</b>, <b>22</b>, and <b>32</b>, alternate embodiments may have any number of time domains. One example of a system <b>10</b> which may have a plurality of time domains <b>12</b>, <b>22</b>, <b>32</b> is an integrated circuit in which time domain <b>12</b> includes a processor which operates at a very high clock rate or frequency, time domain <b>22</b> includes circuitry which operates at a lower clock rate or frequency in order to conserve power, and time domain <b>32</b> which includes peripheral modules that are designed to operate at a third clock rate or frequency. Alternate embodiments may delineate the boundaries of time domains using any desired criteria.

In some embodiments, circuitry in different time domains operates independently and with no relative constraints between the clock frequencies or duty cycles of other time domains. In addition, the clocking of circuitry within a time domain may be suspended or undergo a change in frequency as the state of the overall system <b>10</b> changes, and this may occur independently of the clocking of any other time domain. Time domains may function and be defined differently in alternate embodiments. In one embodiment, independent clock rates include clock rates that are separate and distinct in one or more of a variety of ways, such as, for example, clocks that are sub-multiples of a common clock, clocks that are separately generated and are not intentionally related, and a common clock source that is temporarily stopped to a particular time domain.

In one embodiment, independent clock rates are clocks rates that are separately controllable in some manner, thus are not guaranteed to have a specific relationship, and thus may be considered to be independent at least under certain conditions. Note that it is possible for independent clock rates to be related to each other for a subset of possible conditions. Although the timestamp messaging functionality described herein is very useful when used with a plurality of time domains (e.g. <b>12</b>, <b>22</b>, <b>32</b>) having independent clock rates, alternate embodiments may not require that any, some, or all of the plurality of time domains have independent clock rates.

For some embodiments, in order to properly reconstruct the temporal ordering of events within system <b>10</b>, the relationships between reference counters (e.g. <b>44</b>) within individual time domains (e.g. <b>12</b>, <b>22</b>, <b>32</b>) must be determined. Determining these relationships as the individual time domains transition through low power states, clock frequency altering events, and other factors affecting the relative rate at which individual reference counters are updated is very helpful in determining the relationship of other timestamped debug events occurring within the individual time domains of system <b>10</b>. The timestamp messaging functionality described herein provides the necessary information for determining the relationship between the distributed reference counters used for applying timestamp information to other debug message types as are generated by NEXUS debug circuitry <b>16</b>, <b>36</b>, and <b>26</b>. These other debug message types are well known in the NEXUS standard, and include messages such as Program Trace, Data Trace, and Watchpoint messaging. In one embodiment, each of these messages generated by a particular time domain may be augmented with a timestamp value related to the state of the reference counter within the particular time domain. For proper trace reconstruction of the temporal ordering of events generated across multiple time domains, the reference counter values provided within a particular debug message must be correlated to each other. The timestamp messaging described herein provides this overall coordination capability by providing a way to determine the relationships of the individual reference counters within system <b>10</b>.

Upon the occurrence of a particular event in one or more of time domains <b>12</b>, <b>22</b>, and <b>32</b>, the values of one or more reference counters (e.g. <b>44</b>) may be captured and transmitted via a timestamp message to debugging circuitry <b>93</b> external to debug interface <b>90</b>. By providing these values, the relationships of the various distributed reference counters (e.g. <b>44</b>) may be maintained, and thus proper temporal ordering of other debug message types which have been annotated with a timestamp may be performed. Since for some embodiments the reference counters (e.g. <b>44</b>) operate independently of one another with no fixed relationship, the rate at which one or more reference counters change state is independent of all other of the reference counters. Reference counters (e.g. <b>44</b>) may be temporarily halted while a particular time domain <b>12</b>, <b>22</b>, <b>32</b> enters a low power state, or may change to be incremented at a faster or slower rate as the dynamics of the particular time domain change. By messaging out information about the value and clock status of a reference counter (e.g. <b>44</b>) within a particular time domain (e.g. <b>32</b>), it is possible to maintain an ordering of counter values across multiple time domains <b>12</b>, <b>22</b>, <b>32</b>.

In one embodiment, system <b>10</b> performs this “timestamp messaging” function in such a manner to facilitate ordering of events in system <b>10</b> which are timestamped by multiple independent reference counters (e.g. <b>44</b>) operating at dynamically varying rates and to accomplish synchronization of the distributed sources' values by a tool (e.g. debugger <b>93</b>) external to debug interface <b>90</b>. Timestamp messaging is a new source of debug information which allows for proper temporal ordering of events in a distributed system with multiple time-varying clock domains. Timestamp messages may use either absolute or relative timing information. In some embodiments, relative timing information allows for shorter message length and message bandwidth reduction. Master Timestamp Sync Messages may also be used on a periodic basis to capture the values of some or all of the time domain reference counters (e.g. <b>44</b>). This allows for a debug tool (e.g. debugger <b>93</b>) to synchronize the time domain <b>12</b>, <b>22</b>, <b>32</b> relationships, to allow for accurate reconstruction of the actual sequence of system <b>10</b> events given individual time domain timestamped debug messages.

In one embodiment, a time domain Timestamp Sync Message may be messaged via debug interface <b>90</b> (provided Timestamp Messaging is enabled) for the following time domain events:

Initial Target Domain Timestamp Sync Message after exit from system reset or whenever Target Domain Timestamp Messaging is enabled

Upon a change in reference clock

Upon entering into a Low Power state

Upon returning from a Low Power state

Upon entering into Debug Mode

Upon returning from Debug Mode

Upon occurrence of counter overrun

Upon a periodic counter expiration

Upon occurrence of one or more User selectable events within system <b>10</b>

Note that alternate embodiments may use more, fewer, or different time domain events than those listed above.

In one embodiment, a Master Timestamp Sync Message may be messaged via debug interface <b>90</b> (provided Timestamp Messaging is enabled) for the following time domain events:

Initial Master Timestamp Sync Message after exit from system reset or whenever Master Timestamp Messaging is enabled

Upon a change in system <b>10</b> reference clock

Upon a change in any (or selected ones of) Target Domain clocks

Upon entering into a Low Power state

Upon returning from a Low Power state

Upon entering into Debug Mode

Upon returning from Debug Mode

Upon occurrence of a particular Target Domain counter overrun

Upon a periodic counter expiration

Upon an internally or externally generated system <b>10</b> event

Upon occurrence of one or more User selectable events within system <b>10</b>

Note that alternate embodiments may use more, fewer, or different time domain events than those listed above.

Although the illustrated form of system <b>10</b> will be described in the context of performing timestamping for debug purposes, alternate embodiments may perform timestamping for any desired purpose. Also, although the debug interface <b>90</b> is described as using standard debug interface circuitry and protocols, such as the JTAG interface <b>94</b> and the NEXUS interface <b>92</b>, alternate embodiments may use any desired interface, standard or non-standard, for debug interface <b>90</b>.

Referring now to <figref idrefs="DRAWINGS">FIG. 5</figref>, <figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a method for time-ordering debug events in accordance with one embodiment of system <b>10</b>. The flow <b>200</b> starts at oval <b>202</b>, and proceeds to step <b>204</b> where debug registers <b>80</b> (see <figref idrefs="DRAWINGS">FIG. 1</figref>) are programmed with timestamp control information. Note that alternate embodiments of system <b>10</b> may provide the timestamp control information directly to the time domains. For example, the timestamp control information may be received from debug interface <b>90</b>, other interconnects going external to system <b>10</b> (not shown), system bus <b>96</b>, or another source internal or external to system <b>10</b> (not illustrated). For some embodiments of system <b>10</b>, registers <b>80</b> may be read and/or written by way of one or both of system bus <b>96</b> and debug interface <b>90</b>. In alternate embodiments of system <b>10</b>, registers <b>80</b> may be located anywhere within system <b>10</b>.

The flow of <figref idrefs="DRAWINGS">FIG. 5</figref> continues from step <b>204</b> to step <b>206</b> where the timestamp control information in transmitted to one or more of NEXUS debug circuitry <b>16</b>, <b>26</b>, and <b>36</b>. Note that for one embodiment of system <b>10</b>, timestamp control signals <b>60</b> are used to provide this timestamp control information to NEXUS debug circuitry <b>36</b>. For one embodiment of system <b>10</b>, the timestamp control information is provided to the counter control circuitry <b>42</b>. In one embodiment of system <b>10</b>, the timestamp control information may include control information for enabling reference counter <b>44</b>, and any other control information that may be used to affect the information provided on timestamp signals <b>62</b>.

The flow of <figref idrefs="DRAWINGS">FIG. 5</figref> continues from step <b>206</b> to decision diamond <b>208</b> where the question is asked “has a time domain event occurred in any time domain <b>12</b>, <b>22</b>, <b>32</b>?”. If a time domain event has not occurred in any time domain <b>12</b>, <b>22</b>, <b>32</b>, the flow stays at decision diamond <b>208</b> and continues to check whether a time domain event has occurred in any time domain <b>12</b>, <b>22</b>, <b>32</b>. If a time domain event has occurred in any time domain <b>12</b>, <b>22</b>, <b>32</b>, the flow continues to step <b>210</b> where a timestamp value, based on one or more selected time domain events, is transmitted to the NEXUS module <b>70</b> from one or more time domains.

Note that the time domain <b>12</b>, <b>22</b>, <b>32</b> which had the time domain event occur within it, may not necessarily be the time domain <b>12</b>, <b>22</b>, <b>32</b> which provides the timestamp value. For example, a time domain event which occurs in time domain <b>12</b> may trigger time domain <b>32</b> to provide a timestamp via timestamp signals <b>62</b> to NEXUS module <b>70</b>. As an example, one possible use of this functionality may be to allow a power down time domain event in time domain <b>12</b> to cause time domain <b>32</b> to provide a timestamp via timestamp signals <b>62</b> so that it is possible to determine what functional circuitry <b>34</b> is doing when functional circuitry <b>14</b> is powered down. This functionality may be used for a wide variety of other purposes. One embodiment implements this functionality by way of the information shared between timestamp control circuits <b>72</b>, <b>74</b>, and <b>76</b>. Alternate embodiments may provide other ways for functional circuitry <b>14</b>, <b>24</b>, and <b>34</b> to share information, such as, for example, by one or more signals coupled between two or more of functional modules <b>14</b>, <b>24</b>, and <b>34</b>.

The flow of <figref idrefs="DRAWINGS">FIG. 5</figref> continues from step <b>210</b> to step <b>212</b> where a NEXUS timestamp message is transmitted from NEXUS module <b>70</b> by way of NEXUS interface <b>90</b>. In one embodiment, this NEXUS timestamp message uses the master message <b>120</b> format illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref>. Alternate embodiments may use any message format. For example, one alternate embodiment may sequentially provide time domain messages (e.g. using one or more of the formats illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref> and <figref idrefs="DRAWINGS">FIG. 3</figref>) with a NEXUS TCODE indicating a start of the sequence and a NEXUS TCODE indicating an end of the sequence. Note that alternate embodiments of system <b>10</b> may use any desired format for providing timestamp information. The message formats illustrated in <figref idrefs="DRAWINGS">FIGS. 2-4</figref> are for illustrative purposes only. Alternate message formats may be independent of NEXUS and may not use TCODES. Alternate message formats may or may not relate to debug functionality.

The flow of <figref idrefs="DRAWINGS">FIG. 5</figref> continues from step <b>212</b> to decision diamond <b>214</b> where the question is asked “continue tracing?”. If tracing is continued, the flow returns to decision diamond <b>208</b> and continues to check whether a time domain event has occurred in any time domain <b>12</b>, <b>22</b>, <b>32</b>. If tracing is not continued, the flow continues to END oval <b>216</b> where the flow ends.

Referring now to <figref idrefs="DRAWINGS">FIGS. 2 and 3</figref>, <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates one embodiment of a time domain message <b>100</b> format which uses an absolute time domain reference value, while <figref idrefs="DRAWINGS">FIG. 3</figref> illustrates one embodiment of a time domain message <b>110</b> format which uses a relative time domain reference value. For one embodiment, the formats for time domain messages <b>100</b> and <b>110</b> may be the same except for fields <b>102</b> and <b>112</b>. In one embodiment, absolute time domain reference count bit field <b>102</b> may include the actual value of reference counter <b>44</b> (see <figref idrefs="DRAWINGS">FIG. 1</figref>) at approximately the time that the present domain event occurred. In one embodiment, relative time domain reference count bit field <b>112</b> may include the difference between: (1) the actual value of reference counter <b>44</b> at approximately the time that the present domain event occurred; and (2) the previous value of reference counter <b>44</b> at approximately the time that the previous domain event occurred. Note that for some embodiments, less bandwidth or fewer signals (e.g. in timestamp signals <b>62</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>) may be required to transmit a relative time domain reference count as compared to an absolute time domain reference count.

Still referring to <figref idrefs="DRAWINGS">FIGS. 2 and 3</figref>, time domain messages <b>100</b>, <b>110</b> include a clock status bit field <b>104</b>, <b>114</b>, respectively. In one embodiment, the clock status field <b>104</b>, <b>114</b> may include information regarding whether clocks are enabled, what clock frequency is being used, or any other information regarding the status of clocks in the corresponding time domain <b>32</b>. Time domain message formats <b>100</b>, <b>110</b> also include a time domain identifier bit field <b>106</b>, <b>116</b>, respectively. In one embodiment, the time domain identifier <b>106</b>, <b>116</b> may include information regarding which time domain <b>12</b>, <b>22</b>, <b>32</b> is providing the information in the time domain message. Time domain message formats <b>100</b>, <b>110</b> also include a TCODE bit field <b>108</b>, <b>118</b>, respectively. In one embodiment, the TCODE bit field <b>108</b>, <b>118</b> may include information regarding which NEXUS message type is the message type used by time domain message <b>100</b> and <b>110</b>.

Referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, master message <b>120</b> includes a time domain absolute count <b>122</b>, <b>124</b>, <b>126</b> for each time domain <b>12</b>, <b>22</b>, <b>32</b>, which provided a timestamp in response to a domain event. Thus, master message <b>120</b> includes one or more time domain absolute count bit fields <b>122</b>, <b>124</b>, <b>126</b>. Note that for one embodiment, if time domain <b>32</b> did not provide a timestamp to NEXUS module <b>70</b> (e.g. by way of timestamp signals <b>62</b>), then bit field <b>126</b> will not include a useful count value, or will not be included in master message <b>120</b>. Similarly, if time domain <b>12</b> did not provide a timestamp to NEXUS module <b>70</b>, then bit field <b>122</b> will not include a useful count value, or will not be included in master message <b>120</b>. Likewise, if time domain <b>22</b> did not provide a timestamp to NEXUS module <b>70</b>, then bit field <b>124</b> will not include a useful count value, or will not be included in master message <b>120</b>. Note that if one or more time domains <b>12</b>, <b>22</b>, <b>32</b> provide a relative time domain reference count (e.g. <b>112</b>) rather than an absolute time domain reference count to NEXUS module <b>70</b>, if desired, one or more relative time domain reference count values (e.g. <b>112</b>) can be converted to a corresponding absolute time domain reference count (e.g. <b>102</b>), for example, by way of timestamp control circuitry <b>72</b>, <b>74</b>, <b>76</b> (see <figref idrefs="DRAWINGS">FIG. 1</figref>). In an alternate embodiment, all time domains <b>12</b>, <b>22</b>, <b>32</b> which are providing a timestamp for the master message <b>120</b> may use the absolute time domain reference count (e.g. <b>102</b>), instead of the relative time domain reference count (e.g. <b>112</b>).

Still referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, master message <b>120</b> includes a status bit field <b>128</b>. In one embodiment of system <b>10</b>, the status field <b>128</b> may include, in an encoded or non-encoded form, all or a portion of the information from one or more clock status fields <b>104</b>, <b>114</b>. In one embodiment of system <b>10</b>, one or more of the time domains <b>12</b>, <b>22</b>, <b>32</b> that provide a count value to one of time domain absolute count fields <b>122</b>, <b>124</b>, <b>126</b> may also provide any desired status information to status bit field <b>128</b>. In one embodiment of system <b>10</b>, the status bit field <b>128</b> may include more status information than that included in clock status bit fields <b>104</b>, <b>114</b>. This status information may relate to any desired status of circuitry within one or more time domains <b>12</b>, <b>22</b>, and <b>32</b>.

Master message <b>120</b> also includes a TCODE bit field <b>130</b>. In one embodiment, the TCODE bit field <b>130</b> may include information regarding which NEXUS message type is the message type used by master message <b>120</b>.

Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, in the illustrated embodiment, one embodiment of NEXUS debug circuitry <b>36</b> and debug bus <b>38</b> is described in detail for time domain <b>32</b>. Time domain <b>12</b> also has NEXUS debug circuitry <b>16</b> and debug bus <b>18</b> which may be implemented in a different manner or in the same manner as in time domain <b>32</b>. Likewise, time domain <b>22</b> also has NEXUS debug circuitry <b>26</b> and debug bus <b>28</b> which may be implemented in a different manner or in the same manner as in time domain <b>32</b>.

The operation of the illustrated embodiment for time domain <b>32</b> will now be described. In one embodiment of system <b>10</b>, timestamp control circuitry <b>74</b> provides timestamp control information to counter control circuitry <b>42</b> by way of timestamp control signals <b>60</b>. Counter control circuitry <b>42</b> then uses this control information to control reference counter <b>44</b>. In one embodiment of system <b>10</b>, other circuitry <b>52</b> provides all domain events to timestamp control <b>74</b> by way of domain event information signals <b>64</b>. In alternate embodiments, timestamp control signals <b>60</b> may provide information to other circuitry <b>52</b> regarding which domain events have been selected and thus should be provided to timestamp control <b>74</b> by way of domain event information <b>64</b>.

Once timestamp control <b>74</b> has determined that a selected domain event has occurred, timestamp control <b>74</b> provides control information to counter control circuitry <b>42</b> by way of timestamp control signals <b>60</b> to indicate that the value in reference counter <b>44</b> should be captured and provided to timestamp control <b>74</b> by way of timestamp signals <b>62</b>. Note that a domain event in time domain <b>12</b> or <b>22</b> may also be used by timestamp control <b>74</b> to trigger a capture of the value in reference counter <b>44</b>. This is possible because timestamp control <b>72</b>, <b>74</b>, and <b>76</b> may share information. Alternate embodiments may want to shorten the delay between the occurrence of the domain event and the capturing of the value in the reference counter. One embodiment of system <b>10</b> may accomplish this by moving some of the functionality of the timestamp control circuitry <b>74</b> into the NEXUS debug circuitry <b>36</b> so that the detecting of the domain event directly triggers the capture of the value of the reference counter <b>44</b>, without any involvement of circuitry (e.g. timestamp control <b>74</b>) outside of the NEXUS debug circuitry <b>36</b>.

Note that the value of reference counter <b>44</b> may be provided by the timestamp signals <b>62</b> and may be considered to provide the absolute time domain reference count <b>102</b> in time domain message <b>100</b> (see <figref idrefs="DRAWINGS">FIG. 2</figref>). The value of reference counter <b>44</b> must be appropriately modified by counter control circuitry <b>42</b> to provide a relative time domain reference count by way of timestamp signals <b>62</b> if the relative time domain reference count format of time domain message <b>110</b> is used (see <figref idrefs="DRAWINGS">FIG. 3</figref>). The format of the timestamp information provided from timestamp circuitry <b>40</b> to timestamp signals <b>62</b> may be determined in any manner. For example, registers <b>80</b> may determine this format. Alternate embodiments may use a fixed format, or may alternately select the format in any desired manner.

For alternate embodiments, all or some of the functionality performed by timestamp control <b>74</b> may be centralized as illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>, or may alternately be distributed within the time domains <b>12</b>, <b>22</b>, <b>32</b> themselves. In the embodiment of system <b>10</b> illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>, the time domain identifier circuitry <b>48</b> is used to provide the time domain identifier (see bit field <b>106</b> in <figref idrefs="DRAWINGS">FIG. 2</figref> and bit field <b>116</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>) by way of other signals <b>66</b>. Similarly, TCODE generator <b>50</b> is used to provide the TCODES (see bit field <b>108</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>, bit field <b>118</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>, and bit field <b>130</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>) by way of other signals <b>66</b>. Similarly, clock status <b>46</b> is used to provide the clock status information (see bit field <b>104</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>, bit field <b>114</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>, and bit field <b>128</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>) by way of other signals <b>66</b>.

In one embodiment of system <b>10</b>, arbiter <b>78</b> may be used to arbitrate and determine which timestamp control circuit <b>72</b>, <b>74</b>, or <b>76</b> is allowed to provide information to debug interface <b>90</b> for transmission external to system <b>10</b>.

In one embodiment of system <b>10</b>, the clock status field <b>104</b>, <b>114</b> may include information regarding whether clocks are enabled, what clock frequency is being used, or any other information regarding the status of clocks in the corresponding time domain <b>32</b>. Time domain message formats <b>100</b>, <b>110</b> also include a time domain identifier bit field <b>106</b>, <b>116</b>, respectively. In one embodiment, the time domain identifier <b>106</b>, <b>116</b> may include information regarding which time domain <b>12</b>, <b>22</b>, <b>32</b> is providing the information in the time domain message. Time domain message formats <b>100</b>, <b>110</b> also include a TCODE bit field <b>108</b>, <b>118</b>, respectively. In one embodiment, the TCODE bit field <b>108</b>, <b>118</b> may include information regarding which NEXUS message type is the message type used by time domain message <b>100</b> and <b>110</b>.

Although the embodiments have been described with respect to specific conductivity types or polarity of potentials, skilled artisans appreciated that various modifications may be implemented. For example, any type of functional circuitry may be used with the NEXUS debug circuitry. Various semiconductor processes may be implemented and conductivity types and polarities of potentials may be reversed. The system <b>10</b> may be implemented either on a single integrated circuit as a system on a chip (SOC) or may be implemented with discrete components on a printed circuit board level. The physical positioning of the various fields of the timestamping messages may be arranged in differing orders than that illustrated. Various arbitration schemes may be used to implement arbiter <b>78</b>. Any type of storage device may be used to implement the registers <b>80</b>. The counters described herein may be implemented with various types of known hardware counter circuits and is not limited to any one particular type of counter. The bus sizes may be implemented with any of various possible bit widths. The above description of various modifications is intended for illustrative purposes only. A wide variety of other modifications are also possible.

In one form there has been provided a method in a system for time ordering events in the system. Control information corresponding to each of a plurality of time domains is provided. The control information indicates when a timestamp message for each of the plurality of time domains is to be generated. A determination is made when a time domain event that requires generation of a timestamp message occurs in any one of the plurality of time domains. A timestamp message is generated corresponding to a predetermined one of the plurality of time domains in response to determining that the time domain event occurred. In one form, a same port is used for all of the plurality of time domains to output timestamp messages. In one form, in response to the control information, included within the timestamp message is a time count in a message generating time domain that is an absolute count value of when the time domain event occurred in the message generating time domain. In another form, in response to the control information, included within the timestamp message is a time count in a message generating time domain that is a relative count value measured from a most recently occurring previous time domain event of when the time domain occurred in the message generating time domain. In another form, in response to the control information, included within the timestamp message is a time count for all of the plurality of time domains corresponding to when the time domain event occurred. In yet another form, included within the timestamp message is a format identifier field that identifies one of a plurality of predetermined formats that the timestamp message has. The control information is used to specify when a time domain event that requires generation of a timestamp message occurs in a predetermined one of the plurality of time domains. A subsequent determination is made that the time domain event has occurred in the predetermined one of the plurality of time domains. In one form, the control information is programmed into a storage device. In another form the timestamp message is generated in response to the control information identifying predetermined operating conditions that create the time domain event in at least one of the plurality of time domains. In yet another form the predetermined operating conditions are identified to be at least one of a user programmable event and a programmable system event. In another form the at least one programmable system event includes at least one of entrance into or exit from a power mode of operation, a change in source of a clock, a change in clock periodicity, a predetermined change in a hardware counter value or entry into and exit from a debug mode of operation. The system, in one form, is made up of a plurality of functional circuit modules, each functional circuit module being clocked by a clock that represents a different time domain and having timestamping circuitry. The timestamping circuitry provides a message that indicates a point in time when a predetermined event occurs. An interface module is coupled to each of the plurality of functional circuit modules, the interface module providing control information to the plurality of functional circuit modules to indicate at least one operating condition that triggers the predetermined event. The interface module receives at least one timestamping message from a first time domain when the predetermined event occurs in one of a plurality of time domains including the first time domain. The interface module further includes storage circuitry for storing the control information as programmable control information that determines the at least one operating condition that triggers the predetermined event. In one form the at least one operating condition that triggers the predetermined event further includes at least one of: entrance into or exit from a power mode of operation, a change in source of a clock, a change in clock periodicity, a predetermined change in a hardware counter value, entry into and exit from a debug mode of operation, and occurrence of at least one user programmable event. In another form the timestamping circuitry further includes a counter for determining either absolute or relative time in a corresponding functional circuit module, time domain identification circuitry for providing a time domain identifier, and clock status circuitry for providing one or more operating characteristics of a clock in the corresponding functional circuit module. In another form the timestamping circuitry further includes circuitry for generating a code to be included in each message to identify a format of information included in a corresponding message. The interface module further includes an arbiter having circuitry for generating a code to be included in each timestamping message to identify a format of information included in a corresponding timestamping message. In one implementation the common interface port of the interface module meets IEEE ISTO 5001 (NEXUS) compliance. In one form the message provided by at least one of the plurality of functional circuit modules has a format that includes at least a time count value that is an absolute value referenced to a known starting value, status information of a clock signal associated with one of the functional circuit modules, and an identifier that indicates a corresponding time domain associated with the timestamping message. In another form the message has a format that further includes a field that identifies that the format of the timestamping message has an absolute value time count value. In yet another form the message provided by at least one of the plurality of functional circuit modules has a format that includes at least a time count value that is a relative value referenced to a last occurring predetermined event, status information of a clock signal associated with one of the functional circuit modules, and an identifier that indicates a corresponding time domain associated with the timestamping message. In a further form, the message has a format that further includes a field that identifies that the format of the timestamping message having a relative value time count value. In another form the timestamping message has a format that includes a time count value corresponding to each of the functional circuit modules and predetermined status information associated with each of the functional circuit modules when the predetermined event occurs. As illustrated, the control information is programmable and the interface module has at least one register for storing the control information.

In another form there is provided a system having a plurality of functional circuit modules on a same integrated circuit. Each functional circuit module is clocked by a clock that represents a different time domain. Each functional module has timestamping circuitry operating at independent clock rates for providing timestamp messages. The timestamp messages each indicate a point in time when a predetermined event occurs. An interface module is coupled to each of the plurality of functional circuit modules, the interface module providing control information to the plurality of functional circuit modules to indicate at least one operating condition that triggers the predetermined event. The interface module receives at least one timestamping message from a first time domain when the predetermined event occurs in one of a plurality of time domains including the first time domain. In another form there is provided a method of reconstructing time ordering of events that occur in multiple time domains in a system. Multiple timestamping messages are received in one of an ordered time sequence and an unordered time sequence. Relative count values of multiple time domain counters associated with the multiple time domains and operating at independent clock rates are tracked. Debug information is sorted in time ordered sequence, the debug information being associated with a timestamp provided from one of the multiple time domains. The debug information is provided via a debug message. The debug messages are implemented as at least one of a program trace message, a data trace message and a watchpoint message. The multiple timestamp messages are generated by providing control information corresponding to each of multiple time domains, the control information indicating when a timestamp message for each of the multiple time domains is to be generated. A determination is made as to when a time domain event that requires generation of a timestamp message occurs in any one of the multiple time domains. A timestamp message is generated corresponding to a predetermined one of the multiple time domains in response to determining that the time domain event occurred.

Note that elements illustrated herein may have intervening elements not illustrated that couple the illustrated elements. The term coupled, as used herein, is defined as joined or linked, although not necessarily directly, and not necessarily mechanically.

In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims. As used herein, the terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.