Platform and platform component commissioning performed by multiple commissioning systems

Abstract

Embodiments herein relate to logic configured to identify, based on a header of a first packet, that the first packet is related to a first debug process of a component to which the logic is communicably coupled, where the first debug process is performed by a first DTS; identifying, based on a header of a second packet, that the second packet is related to a second debug process of the component, where the second debug process is performed by a second DTS; routing the first packet between the component and the DTS based on identifying that the first packet is related to the first debug process; and routing the second packet between the component and the DTS based on identifying that the second packet is related to the second debug process. Other embodiments may be described and / or claimed.

Description

Background Art

[0001] Embodiments of the present disclosure relate generally to the field of debugging, and in particular, to a debugging system that may be used to debug a platform and / or one or more components of such a platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The embodiments will be easily understood by the detailed description below in conjunction with the accompanying drawings. To facilitate this description, the same reference numerals designate the same structural elements. In the drawings in the accompanying drawings, the embodiments are illustrated by way of example and not by way of limitation.

[0003] Figure 1 An example of a parallel configuration of a debug probe according to various embodiments is illustrated.

[0004] Figure 2 Examples of alternative configurations of debug probes according to various embodiments are depicted.

[0005] Figure 3 Depicted are examples of alternative parallel configurations of debug probes in accordance with various embodiments.

[0006] 4A , 4B, 4C, and 4D (collectively “ FIG. 4 ”) depict examples of debug configurations in accordance with various embodiments.

[0007] Figure 5 Alternative examples of debug configurations according to various embodiments are depicted.

[0008] Figure 6 Depicted are alternative examples of debug configurations according to various embodiments.

[0009] Figure 7 Describes various embodiments that may be used with Figure 6 An example debugging-related process flow used together with the debug configuration.

[0010] Figure 8 Depicted are alternative examples of debug configurations according to various embodiments.

[0011] Fig. 9 Describes various embodiments that may be used with Figure 8 An example debugging-related process flow used together with the debug configuration.

[0012] Fig.10 Depicted are exemplary data structures that may be used by a debug system in accordance with various embodiments.

[0013] Fig.11 An exemplary process is illustrated. DETAILED DESCRIPTION

[0014]

[00136] Embodiments described herein may include apparatus, systems, techniques, or processes related to platform or platform component debugging or testing systems.

[0015] As used herein, the term "platform" may refer to a functional system that may include one or more boards and one or more components disposed on the one or more boards. In an embodiment, one or more of the boards and / or components may be debugged. The (one or more) elements being debugged (e.g., (one or more) boards and / or (one or more) components) may be referred to as a target system (TS) and may be referred to as a "device under test" or "DUT".

[0016] As used herein, the term "component" may refer to an independent computing element (e.g., a microcontroller, a microprocessor, etc.) that can be debugged. Such a component may, for example, be located in an independent package (e.g., a system on a chip (SoC), a platform controller hub (PCH), a microcontroller (such as an embedded controller (EC)), a dedicated graphics processing unit (dGPU), a field programmable gate array (FPGA), etc.). Additionally or alternatively, such a component may be located in an integrated sensor hub (ISH), an audio and context engine (ACE), a computing core, a converged security and manageability engine (CSME), a power management controller (PMC), an operating system security engine (OSSE), etc.

[0017] Typically, legacy implementations can use one of the following example configurations to support debugging of the platform: A debug and test system (DTS) is configured to debug a single platform or a single component within a platform; or multiple debuggers are used to debug different platform components separately.

[0018] However, such conventional implementations may not provide a configuration in which multiple DTSs can debug the same TS (eg, the same platform(s) and / or the same platform component(s)).

[0019] In addition, the MIPI Alliance may define specifications related to debugging technology and protocols for debugging. However, such traditional definitions may not provide a standard mechanism for secure, multi-access, collaborative debugging of platforms and / or platform components.

[0020] Embodiments herein may relate to collaborative debugging of components from different vendors on a platform.Embodiments may further relate to collaborative debugging of component(s) and / or portions of platform(s) that may be standardized by the MIPI Alliance.

[0021] Typically, DTS traditional solutions may only allow DTS to debug TS via direct connection or remote connection. In addition, traditional DTS related solutions may allow DTS to debug multiple TS via a single connection, or debug multiple TS when multiple TS are connected via different connections.

[0022] Figure 1-3 Depicts exemplary configurations in which a probe of a DTS may be coupled to a platform and / or one or more components of such a platform. For example, Figure 1 An exemplary configuration is depicted in which two probes are present, and each probe is communicatively coupled to (eg, operable to test) a single TS.

[0023] Figure 2 An alternative configuration is depicted, which may be referred to as a Joint Test Action Group (JTAG) chain configuration, a daisy chain configuration, a star configuration, etc. In this embodiment, a single probe may be communicatively coupled to two different TSs (e.g., components of a platform in this example), and each of the TSs may be communicatively coupled to each other. Figure 2 The performance of the solution may be limited by various factors, such as the topology of the platform. Specifically, the topology (i.e., the routing between the DTS and the different TSs) may affect the electrical properties of the signal between the DTS and the TS. For example, the length of the routing between the DTS and the TS may affect the maximum possible speed of the signal transmission between the DTS and the TS, because a longer route may have a greater resistance and, therefore, cause the signal to transmit more slowly than a shorter route.

[0024] Figure 3 Depicts an alternative configuration in which multiple probes may be used. Specifically, multiple probes may be communicatively coupled to multiple TSs on a single debug port. In this configuration, only one probe may be active, while the other probe is tri-stated. As used herein, "tri-stated" may refer to a configuration in which the DTS does not drive a signal between the DTS and the TS.

[0025] Figure 4a , 4b , 4c and 4d (collectively referred to as "FIG. 4") depict examples of debugging configurations according to various embodiments. Specifically, Figure 4a An exemplary configuration is depicted in which a single DTS is configured to debug multiple TSs via separate debug connections. That is, a different debug connection is used to communicatively couple the DTS to another TS than the debug connection used to communicatively couple the DTS to one TS. Figure 4bAn exemplary configuration is depicted in which a single DTS is configured to debug the TS via a single debug connection to a platform that is internally connected to multiple TSs (eg, components).

[0026] Figure 4c An exemplary configuration is depicted in which multiple DTSs are configured to debug multiple components of a single TS via separate debug connections. That is, a first DTS is configured to debug a first TS via a first connection, and a second DTS is configured to debug a second TS via a second connection.

[0027] Figure 4d An exemplary configuration is depicted in which a single DTS is configured to debug multiple TSs via a single physical connection (e.g., between one input / output (I / O) port of the DTS and one I / O port of the platform). However, as shown in the figure, the DTS may be running multiple debugging applications that are separately logically coupled to different TSs (e.g., different components of the platform).

[0028] However, the above configuration may experience one or more disadvantages. For example, such a configuration may not include a mechanism for connecting multiple DTSs to the same TS, wherein the multiple DTSs are configured to debug the same TS. Similarly, such a configuration may not include a mechanism for connecting multiple DTSs to the same TS so that the multiple DTSs are configured to debug the same TS at least partially simultaneously. Conversely, in the above scheme, each debug probe may require physical access to the debug port of the platform, which may limit the usability of the solution.

[0029] Additionally, traditional debugging solutions over a network may not allow or address collaboration between individual DTSs. Access to TSs may be based on dedicated access to a single debugger at a time, and any collaboration may be based on configurations such as screen sharing.

[0030] Embodiments herein relate to a secure, multi-access, collaborative debugging solution. Embodiments herein may be used, for example, in a collaborative remote debugging configuration (e.g., where multiple DTSs are able to debug the same TS even if at least one of the multiple DTSs is not physically located with the TS).

[0031] Embodiments herein may involve or include one or more of the following elements or characteristics: - Logic implemented in the TS (may be implemented as hardware, firmware, software, or some combination thereof). This logic may provide secure debug access, filters, routers, and may arbitrate debug commands or messages from different DTSs. Such commands or messages may include, for example, authentication, establishment of secure sessions, etc. This logic may be referred to herein as "debug access filter, router, and arbitrator logic," and may be abbreviated as "DAFRA logic" for purposes of discussion herein, but it will be appreciated that other embodiments or implementations may refer to the DAFRA logic by some other name.

[0032] - Logic implemented in the component being debugged (which may be implemented as hardware, firmware, software, or some combination thereof). This logic may be configured to handle multiple accesses from different DTSs, and may be configured to bifurcate the debug session where appropriate. This logic may be referred to herein as "multi-access handler logic," or may be abbreviated for discussion herein as "MAH logic," but it will be appreciated that other embodiments or implementations may refer to MAH logic by some other name.

[0033] - Message exchanges implemented at the debug protocol level to enable detection and / or setup of a collaborative debug session.

[0034] - An interface and / or associated protocol logically placed between one or both of the above logics and the component being debugged. The interface and / or protocol may be configured to facilitate multi-access and arbitrated transmission of commands to and / or responses from the component.

[0035] As a result, the embodiments herein may be able to achieve Figure 5 Specifically, if Figure 5 As can be seen in the foregoing, embodiments may enable multiple DTSs to simultaneously test multiple components of a TS and share the results of the tests with each other.

[0036] Embodiments may provide many advantages. For example, instead of the traditional solution that may require a single DTS for each debugger, embodiments may help alleviate supply chain shortages by allowing collaborative use of a single DTS. In addition, embodiments may provide a cost-effective debugging solution. Embodiments may further provide a faster debugging experience, thereby reducing the time to market of the platform and / or associated components.

[0037] In general, embodiments herein may be described with reference to various functions and elements. As described above, one such element may be DAFRA logic. In embodiments, DAFRA logic may be implemented in a TS (e.g., in a platform) and may function as one or more of a filter, a router, and an arbitrator.

[0038] In some embodiments, the DAFRA logic may expose a new register set. The register set may describe platform support for standard collaborative debugging. The register set may be configurable and may be used to enable or disable collaborative debugging features. The register set may additionally be used to configure collaborative debugging attributes, such as the level of collaborative debugging and / or components or elements within components that can be collaboratively debugged.

[0039] In some embodiments, the DAFRA logic may be configured to perform authentication and debugging functions on the test system. Such functionality may not exclude mutual authentication. Specifically, in some cases, the TS may verify the entity of the user of the DTS to ensure that such entity is an authorized debugger (e.g., by comparing the entity's credentials to a registry of pre-identified authorized debuggers, or by some other type of authentication). However, in some embodiments, it may also be desirable for the DTS to verify the TS to ensure that the TS is the expected component / platform. Mutual authentication refers to a situation in which the DTS and TS are enabled to authenticate each other. Such authentication may, for example, be configurable in the DAFRA logic (e.g., at runtime, compile time, or some other form of configuration).

[0040] The DAFRA logic may also be configured to establish a secure debugging session between a DTS and a TS using standards such as the Distributed Management Task Force (DMTF) security protocol and the Security Protocol and Data Model (SPDM) specification. The DAFRA logic may also be configured to establish the ability to share debug responses from a component being debugged across DTSs (assuming such sharing is authorized). The DAFRA logic may also be configured to establish (one or more) collaborative sessions between various DTSs to allow collaborative debugging functionality across DTSs. The DAFRA logic may also be configured to schedule and / or arbitrate the transmission or receipt of debug-related commands and / or responses between multiple DTSs and one or more components being debugged.

[0041] In some embodiments, the DAFRA logic may be configured to manage debug regions across DTSs to prevent unwanted overwrites, as described in more detail below. Specifically, the DAFRA logic may include filtering and / or routing capabilities that can be configured using metadata and / or "profiles" that include details about debuggable platform components. The metadata and / or profiles may be part of a packet header, part of a register, or otherwise attached to or associated with a packet related to debug functionality (such as a debug command, request, response, etc.).

[0042] Metadata or configuration files may be used to indicate, for example, which capabilities and / or actions may require independent access and which capabilities and / or actions can handle multiple / simultaneous accesses. For example, a configuration file may be used to configure a particular debugging capability as something that only one debugger can access at a time or as something that multiple debuggers can access at least partially concurrently.

[0043] In some embodiments, the capabilities and / or actions may be programmed into the DTS by a debugging application (e.g., a user-facing software component). In some embodiments, the debugging application may additionally attach an identifier (e.g., attaching an identifier in the header of various packets related to debugging or attaching an identifier to the above-mentioned register). The identifier may be used to identify which capabilities and / or actions are allowed for simultaneous and / or multiple accesses. In some embodiments, a trusted component in the platform may manage these capabilities. As used herein, the term "trusted component" may refer to a security agent configured to handle the security / protection of the platform, and may be referred to as a platform root of trust (PRoT).

[0044] In some embodiments, the DAFRA logic may be configured to manage a debug session. For example, the DAFRA logic may append, remove, and / or process identifiers (e.g., in a header of a debug message (such as a debug command or request)) to maintain a debug zone and route debug requests / commands (e.g., to or from a DTS and component / TS).

[0045] As used herein, a "debug area" may refer to an element related to a particular debugging process, such as a specific code area(s) (e.g., a specific area of ​​memory in a microcontroller used to store program code), a data area(s) (e.g., a specific area of ​​memory in a microcontroller used to store data), a set of one or more registers, a specific location in a component's static random access memory (SRAM), etc. It will be understood that in some embodiments, a single component may include multiple debug areas.

[0046] For example, as described above, in some embodiments, the MAH logic may be configured to fork a debug session (i.e., divide a single debug process into multiple debug processes) to create two instances of a debug session. In this case, each of the debug sessions may have its own debug area. For security and to prevent errors that may be caused by overwriting, it may be desirable to enforce that the debug areas do not overlap (e.g., do not share one or more of the various types of storage locations listed above). The DAFRA logic may be configured to route various requests, commands, or data related to a debug session or debug area to ensure that such overlap does not occur.

[0047] Some embodiments may include MAH logic as described above. MAH logic may be implemented in various TSs to be debugged, and may be configured to support or handle multiple accesses from a single debugger or from multiple debuggers. Figure 7 An example of such support from multiple debuggers (eg, DTS1 on the left and DTS2 on the right) is shown.

[0048] As described above, some embodiments may include message exchanges implemented at the debug protocol level. The message exchanges may be used for validation using, for example, the SPDM specification or some other specification. The message exchanges may additionally / alternatively be used to allow information exchange between the DTS and the DAFRA logic (and / or the MAH logic) to enable or disable multi-access, DTS priority levels, etc. The message exchanges may additionally / alternatively be used to enable or disable collaborative debug sessions across DTSs. The message exchanges may additionally or alternatively be used to allow communication between the DTS and the DAFRA logic (and / or the MAH logic) to allow or not allow debug response sharing between the DTSs. The message exchanges may additionally / alternatively be used to implement separation of different debug areas, as described above.

[0049] As described above, some embodiments may also include an interface or protocol between the DAFRA logic (and / or MAH logic) and one or more components of the TS. The interface and / or protocol may be used to facilitate multi-access and arbitration command or response transmission (such as using parameters in the debug message header).

[0050] First Exemplary Implementation exist Figure 6 An exemplary implementation of DAFRA logic 601 is depicted in FIG. Figure 6 Depicts an example of how such DAFRA logic 601 can use time slicing to manage debug regions during a collaborative debugging session. For example, a DTS / owner / collaborative debugger / etc. can perform an atomic read-modify-write operation, which will then be completed without interruption. If another collaborator attempts to access the same capability, such access can be delayed until a completion notification is sent to the other collaborators before a new read-modify-write or write operation request is performed on the same capability.

[0051] It will be noted that Figure 6DAFRA logic is depicted as being housed in a TS (depicted as "Target System 1"). The TS may be communicatively coupled to two separate DTSs (depicted as "Debug and Test System 1" which may be referred to as DTS1 and "Debug and Test System 2" which may be referred to as DTS2). One or both of the DTSs may include logic 603, which may be implemented as hardware, software, firmware, and / or some combination thereof. Logic 603 may be configured to configure the DAFRA logic in the TS using metadata and / or configuration files. The metadata / configuration files may include an indication of one or both of the following: (1) one or more capabilities / actions that need to be independently accessed by a single DTS; and (2) one or more capabilities / actions that may be allowed to be accessed by multiple DTSs, either sequentially or at least partially concurrently. Logic 603 may additionally append a header to a debug-related command / request / etc., the header having one or more identifiers indicating capabilities / actions that are allowed for at least partially concurrent access. Figure 6 Further depicted is indicator 602, which shows a change in (one or more) related debug request packets, commands or responses including a header having the aforementioned identifier. It will be appreciated that although Figure 6 The connection between the DTS and TS is illustrated as being via an I / O port, but in other embodiments, such a connection may be remote (eg, via a wireless link such as a cellular link, a Bluetooth link, a wifi link, etc.).

[0052] An exemplary use case for such an implementation may include a situation in which DTS1 is performing run control debugging and DTS2 may be capturing trace data (eg, data generated by a TS and transmitted to the DTS for analysis of the behavior of the TS).

[0053] If the DAFRA logic 601 establishes a secure relationship between DTS1 and DTS2 for the purpose of sharing debug responses from components subject to debugging, the DAFRA logic 601 may also be configured to share trace messages with DTS1 (requestable by DTS2) and to share error events encountered during run control debugging with DTS2 (e.g., observable by DTS1).

[0054] Typically, DAFRA logic 601 may perform debugging and session management messaging to ensure consistency of debugging operations across DTSs to prevent overlap. Additionally or alternatively, DAFRA logic 601 may forward debug messages between different DTSs. Additionally or alternatively, DAFRA logic 601 may maintain consistency, for example, by ensuring that messages are correctly transmitted between DTSs and TSs.

[0055] More generally, logic (such as DAFRA logic 601, logic 603, or other logic described herein) may be configured to support the following situation: one DTS may temporarily "own" a TS component, and in this case, other DTSs may be viewed as passive observers of the component. For example, the "owning" DTS may be allowed to perform "destructive" tasks related to the component, such as write operations, while other DTSs may be limited to performing only non-destructive tasks, such as read operations that do not change the state of the component.

[0056] Figure 7 Graphics and Figure 6 An exemplary process flow associated with the above-described first exemplary implementation.

[0057] Second Exemplary Implementation Figure 8 Describe alternative implementations. Figure 8 The implementation can be similar to Figure 6 801 , and includes similar elements as shown and / or labeled in the figure. In addition, various components of the TS may include MAH logic 801, as shown in the figure. The MAH logic 801 may be configured to fork (e.g., fork) debugging instances from multiple components where possible. Specifically, the MAH logic 801 may be configured to create separate instances of the debugging session, such as by virtualizing the component being debugged, so that each DTS may be able to debug an instance of the component.

[0058] The MAH logic 801 may additionally or alternatively be configured to virtualize the debug instance when it is necessary to preserve the state machine within the component.For example, the MAH logic 801 may be configured to create a virtual instance of a component (or a portion thereof).

[0059] The MAH logic 801 may additionally or alternatively be configured to serialize debug instances such that if multiple DTSs need to access a single component (eg, a component that may not be virtualized), the MAH logic 801 may manage those accesses in sequence so that the multiple DTSs do not interfere with each other.

[0060] will understand, though not in Figure 8 , but in some embodiments, the configuration may include a network routed to various platform components subject to debugging. Such a network may be distributed throughout the platform.

[0061] Fig. 9 Graphics and Figure 8 An exemplary process flow associated with the above-described second exemplary implementation.

[0062] As previously mentioned, in some cases, the header structure of a debug packet (eg, command, request, response, etc.) may be changed to enable collaborative debugging. Fig.10An example of such a collaborative debugging header structure is depicted. For the purpose of discussion, Fig.10 The specific example of may relate to a MIPI SneakPeek protocol command, however, it will be appreciated that this example is intended to be non-limiting and that the header may additionally / alternatively be applied to other debug protocol messages.

[0063] The following Table 1 describes Fig.10 Examples of attributes in the collaborative debugging header structure of . In some embodiments, the attributes of Table 1 can be considered as a minimum list of attributes that can be used.

[0064] Table 1 Table 2 below indicates an example of a register set (eg, for one or more of the aforementioned registers). In some embodiments, this register set may be considered to indicate an example of a minimum register set.

[0065] Table 2 Embodiments herein may be used in various scenarios. Some scenarios may include, for example, a multi-socket central processing unit (CPU) for a server, where a virtual machine and / or hardware may manage a debugging session. Another scenario may include, for example, collaborative debugging of a system where components have different owners, vendors, and / or manufacturers. For example, an operating system security engine (OSSE) may be owned by an independent software vendor, a power management unit (PMU) may be owned by a system-on-chip (SoC) vendor, an integrated sensor hub (ISH) may be owned by an original equipment manufacturer (OEM) or SoC vendor, an embedded controller (EC) may be owned by an EC vendor and / or OEM, etc.

[0066] Fig.11 An exemplary process 1100 of debugging performed by multiple DTSs is illustrated. The process 1100 may be performed, for example, by logic such as DAFRA logic as described herein (eg, DAFRA logic 601).

[0067] Process 1100 may include: at 1105, based on a header of the first packet, identifying that the first packet is associated with a first debug process of a component to which the logic is communicatively coupled, wherein the first debug process is executed by a first debug and test system (DTS) to which the logic is communicatively coupled; at 1110, based on a header of the second packet, identifying that the second packet is associated with a second debug process of the component, wherein the second debug process is executed by a second DTS to which the logic is communicatively coupled; at 1115, based on identifying that the first packet is associated with the first debug process, routing the first packet between the component and the DTS; and at 1120, based on identifying that the second packet is associated with the second debug process, routing the second packet between the component and the DTS.

[0068] It should be understood that Fig.11 The actions described may not necessarily occur in the order described. For example, some elements may occur in an order different from the order described, occur concurrently with each other, etc. In some embodiments, process 1100 may include more or fewer elements than depicted or described.

[0069] In the foregoing description, various aspects of illustrative implementations are described using terms commonly used by those skilled in the art to convey the essence of their work to other persons skilled in the art. However, it will be clear to those skilled in the art that embodiments of the present disclosure may be implemented using only some of the aspects described. For purposes of explanation, specific numbers, materials, and configurations are set forth to provide a thorough understanding of illustrative implementations. It will be clear to those skilled in the art that embodiments of the present disclosure may be implemented without specific details. In other examples, well-known features have been omitted or simplified to avoid blurring illustrative implementations.

[0070] In the foregoing detailed description, reference is made to the accompanying drawings forming a part thereof, wherein like numerical symbols designate like parts throughout, and wherein are shown as illustrations embodiments in which the subject matter of the present disclosure may be implemented. It should be understood that other embodiments may be used and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the detailed description should not be understood in a limiting sense.

[0071] For purposes of this disclosure, the phrase "A and / or B" means (A), (B), or (A and B). For purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). More generally, various embodiments may include any suitable combination of the above-described embodiments, including alternative (or) embodiments to the embodiments described above in conjunction form (and) (for example, "and" may be "and / or"). In addition, some embodiments may include one or more articles of manufacture (e.g., non-transitory computer-readable media) having instructions stored thereon, which, when executed, bring about the actions of any of the above-described embodiments. In addition, some embodiments may include a device or system having any suitable components for performing the various operations of the above-described embodiments.

[0072] The description may have used perspective-based descriptions, such as top / bottom, inside / outside, up / down, and the like. Such descriptions are used to facilitate discussion and are not intended to limit the application of the embodiments described herein to any particular orientation.

[0073] The description may use the phrases "in one embodiment" or "in an embodiment," which may each refer to one or more of the same or different embodiments. Additionally, as used with respect to embodiments of the present disclosure, the terms "comprising," "including," "having," and the like are synonymous.

[0074] The term "coupled to," and its derivatives, may be used herein. "Coupled" may mean one or more of the following. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements are in indirect contact with each other, but still cooperate or interact with each other, and may mean that one or more other elements are coupled or connected between the elements referred to as being coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact.

[0075] As used herein, the term "module" may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and / or memory (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, and / or other suitable components that provide the described functionality, may be part of the above-mentioned devices, or may include the above-mentioned devices.

[0076] These modifications may be made to the embodiments in light of the above detailed description. The terms used in the following claims should not be interpreted to limit the embodiments to the specific implementations disclosed in the specification and claims. Rather, the scope of the present invention should be determined entirely by the following claims, which should be interpreted according to established principles of claim interpretation.

[0077] Example Example 1 includes an electronic system comprising: a platform including a component; one or more ports for coupling with a first debug and test system (DTS) and a second DTS in a communicable manner; and logic disposed between the component and the one or more ports in a communicable manner, wherein the logic is configured to: based on a header of a first packet, identify that the first packet is associated with a first debug process of the component, wherein the first debug process is performed by the first DTS; based on a header of a second packet, identify that the second packet is associated with a second debug process of the component, wherein the second debug process is performed by the second DTS; based on identifying that the first packet is associated with the first debug process, route the first packet between the component and the DTS; and based on identifying that the second packet is associated with the second debug process, route the second packet between the component and the DTS.

[0078] Example 2 includes the electronic system of Example 1 and / or some other example herein, wherein the first packet is related to a read operation or a write operation of the component performed by the first DTS.

[0079] Example 3 includes the electronic system of any of Examples 1-2 and / or some other example herein, wherein the first debug process and the second debug process at least partially overlap in time.

[0080] Example 4 includes an electronic system as described in any of Examples 1-3 and / or some other example herein, wherein if the first debugging process is related to a first operation that changes a state of the component, the logic is further configured to not route the second packet to the DTS if the second process is related to a second operation that changes a state of the component.

[0081] Example 5 includes an electronic system as described in any of Examples 1-4 and / or some other example in the present document, wherein the logic is configured to route the first packet or the second packet based on a predefined entry in a register group associated with a debug process of the electronic system that can be executed by multiple DTSs.

[0082] Example 6 includes the electronic system of any of Examples 1-5 and / or some other example herein, wherein the first DTS is physically coupled to the platform.

[0083] Example 7 includes the electronic system of any of Examples 1-6 and / or some other example herein, wherein the first DTS is wirelessly coupled to the platform.

[0084] Example 8 includes an electronic system as described in any of Examples 1-7 and / or some other example herein, wherein the logic is configured to identify that the first packet is related to the first debug process of the component based on an identifier in the header of the first packet, wherein the identifier is related to the first DTS.

[0085] Example 9 includes an electronic system as described in any of Examples 1-8 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to manage different debug areas of the component.

[0086] Example 10 includes the electronic system of any of Examples 1-9 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to virtualize the debug instance.

[0087] Example 11 includes the electronic system of any of Examples 1-10 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to serialize a debug instance.

[0088] Example 12 includes logic for use in an electronic system, wherein the logic is configured to: based on a header of a first packet, identify that the first packet is associated with a first debug procedure of a component to which the logic is communicatively coupled, wherein the first debug procedure is executed by a first debug and test system (DTS) to which the logic is communicatively coupled; based on a header of a second packet, identify that the second packet is associated with a second debug procedure of the component, wherein the second debug procedure is executed by a second DTS to which the logic is communicatively coupled; based on identifying that the first packet is associated with the first debug procedure, route the first packet between the component and the DTS; and based on identifying that the second packet is associated with the second debug procedure, route the second packet between the component and the DTS.

[0089] Example 13 includes the logic of Example 12 and / or some other example herein, wherein the first packet is related to a read operation or a write operation of the component performed by the first DTS.

[0090] Example 14 includes the logic of any of Examples 12-13 and / or some other example herein, wherein the first debug process and the second debug process at least partially overlap in time.

[0091] Example 15 includes the logic of any of Examples 12-14 and / or some other example herein, wherein if the first debugging process is associated with a first operation that changes a state of the component, the logic is further configured to not route the second packet to the DTS if the second process is associated with a second operation that changes a state of the component.

[0092] Example 16 includes the logic of any of Examples 12-15 and / or some other example herein, wherein the logic is configured to route the first packet or the second packet based on a predefined entry in a register group associated with a debug process of the electronic system executable by multiple DTSs.

[0093] Example 17 includes the logic of any of Examples 12-16 and / or some other example herein, wherein the logic is configured to identify that the first packet is associated with the first debug process of the component based on an identifier in the header of the first packet, wherein the identifier is associated with the first DTS.

[0094] Example 18 includes an electronic system comprising: a platform including a component; one or more ports for coupling with a first debug and test system (DTS) and a second DTS in a communicable manner; and logic disposed between the component and the one or more ports in a communicable manner, wherein the logic is configured to: based on a header of a first packet, identify that the first packet is associated with a first debug process of the component, wherein the first debug process is performed by the first DTS; based on a header of a second packet, identify that the second packet is associated with a second debug process of the component, wherein the second debug process is performed by the second DTS; based on identifying that the first packet is associated with the first debug process, route the first packet between the component and the DTS; and based on identifying that the second packet is associated with the second debug process, route the second packet between the component and the DTS.

[0095] Example 19 includes the electronic system of Example 18 and / or some other example herein, wherein the first packet is related to a read operation or a write operation of the component performed by the first DTS.

[0096] Example 20 includes the electronic system of any of Examples 18-19 and / or some other example herein, wherein the first debug process and the second debug process at least partially overlap in time.

[0097] Example 21 includes an electronic system as described in any of Examples 18-20 and / or some other example herein, wherein if the first debugging process is related to a first operation that changes the state of the component, the logic is further configured to not route the second packet to the DTS if the second process is related to a second operation that changes the state of the component.

[0098] Example 22 includes an electronic system as described in any of Examples 18-21 and / or some other example in the present document, wherein the logic is configured to route the first packet or the second packet based on a predefined entry in a register group associated with a debug process of the electronic system that can be executed by multiple DTSs.

[0099] Example 23 includes the electronic system of any of Examples 18-22 and / or some other example herein, wherein the first DTS is physically coupled to the platform.

[0100] Example 24 includes the electronic system of any of Examples 18-23 and / or some other example herein, wherein the first DTS is wirelessly coupled to the platform.

[0101] Example 25 includes an electronic system as described in any of Examples 18-24 and / or some other example herein, wherein the logic is configured to identify that the first packet is related to the first debug process of the component based on an identifier in the header of the first packet, wherein the identifier is related to the first DTS.

[0102] Example 26 includes an electronic system as described in any of Examples 18-25 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to manage different debug areas of the component.

[0103] Example 27 includes the electronic system of any of Examples 18-26 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to virtualize the debug instance.

[0104] Example 28 includes the electronic system of any of Examples 18-27 and / or some other example herein, wherein the logic is a first logic, and wherein the component includes a second logic configured to serialize a debug instance.

[0105] Example Z01 may include a device comprising components for performing one or more elements of the methods described in or related to any of the examples in this document and / or any other method, process, or technical process described herein, or portions or parts thereof.

[0106] Example Z02 may include a device comprising logic, modules, or circuits for performing one or more elements of the methods described in or related to any of the examples in this document and / or any other methods, processes, or techniques described herein, or portions or portions thereof.

[0107] Example Z03 may include a method, technique, or process as described in or related to any of the examples in this document and / or any other method, process, or technique described in this document, or part or portions thereof.

[0108] Example Z04 may include a signal as described in or related to any of the examples in this document and / or any other method, process, or technique described in this document, or part or portions thereof.

[0109] Example Z05 may include a device comprising one or more processors and a non-transitory computer-readable medium, the non-transitory computer-readable medium comprising instructions that, when executed by the one or more processors, cause the device to perform a method described in or related to any of the examples in this document and / or one or more elements of any other method, process, or technique described herein, or portions or portions thereof.

[0110] Example Z06 may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform a method described in or related to any of the examples in this document and / or one or more elements of any other method, process, or technique described herein, or portions or portions thereof.

[0111] Example Z07 may include a computer program associated with a method described in or related to any of the examples in this document and / or one or more elements of any other method, process, or technique described herein, or portions or parts thereof.

Claims

1. An electronic system comprising: Platform, including components; one or more ports for communicatively coupling with a first debug and test system (DTS) and a second DTS; as well as logic is disposed in a communicable manner between the component and the one or more ports, wherein the logic is configured to: Based on a header of a first packet, identifying that the first packet is associated with a first debugging process of the component, wherein the first debugging process is performed by the first DTS; identifying, based on a header of the second packet, that the second packet is associated with a second debugging process of the component, wherein the second debugging process is performed by the second DTS; routing the first packet between the component and the DTS based on identifying that the first packet is associated with the first debugging process; and Based on identifying that the second packet is related to the second debug process, the second packet is routed between the component and the DTS.

2. The electronic system of claim 1, wherein the first packet is associated with a read operation or a write operation of the component performed by the first DTS. 3 . The electronic system of claim 1 , wherein the first debugging process and the second debugging process at least partially overlap in time.

4. The electronic system of claim 1 , wherein if the first debugging process is associated with a first operation that changes the state of the component, the logic is further configured to not route the second packet to the DTS if the second process is associated with a second operation that changes the state of the component. 5 . The electronic system of claim 1 , wherein the logic is configured to route the first packet or the second packet based on a predefined entry in a register set associated with a debug process of the electronic system executable by a plurality of DTSs.

6. The electronic system of any one of claims 1-5, wherein the first DTS is physically coupled to the platform.

7. The electronic system of any one of claims 1-5, wherein the first DTS is coupled to the platform in a wireless manner.

8. The electronic system of any one of claims 1-5, wherein the logic is configured to identify that the first packet is associated with the first debug process of the component based on an identifier in the header of the first packet, wherein the identifier is associated with the first DTS.

9. The electronic system of any one of claims 1-5, wherein the logic is a first logic, and wherein the component includes a second logic configured to manage different debug areas of the component.

10. The electronic system of any one of claims 1-5, wherein the logic is a first logic, and wherein the component comprises a second logic configured to virtualize a debug instance.

11. The electronic system of any one of claims 1-5, wherein the logic is a first logic, and wherein the component comprises a second logic configured to serialize a debug instance.

12. A logic for use in an electronic system, wherein the logic is configured to: identifying, based on a header of the first packet, that the first packet is associated with a first debug procedure of a component to which the logic is communicatively coupled, wherein the first debug procedure is executed by a first debug and test system (DTS) to which the logic is communicatively coupled; identifying, based on a header of the second packet, that the second packet is associated with a second debug procedure of the component, wherein the second debug procedure is performed by a second DTS to which the logic is communicatively coupled; routing the first packet between the component and the DTS based on identifying that the first packet is associated with the first debugging process; and Based on identifying that the second packet is related to the second debug process, the second packet is routed between the component and the DTS.

13. The logic of claim 12, wherein the first packet is associated with a read operation or a write operation of the component performed by the first DTS.

14. The logic of claim 12, wherein the first debug process and the second debug process at least partially overlap in time.

15. The logic of claim 12, wherein if the first debug process is associated with a first operation that changes the state of the component, the logic is further configured to not route the second packet to the DTS if the second process is associated with a second operation that changes the state of the component.

16. The logic of any one of claims 12-15, wherein the logic is configured to route the first packet or the second packet based on a predefined entry in a register set associated with a debug process of the electronic system executable by a plurality of DTSs.

17. The logic of any of claims 12-15, wherein the logic is configured to identify that the first packet is associated with the first debug process of the component based on an identifier in the header of the first packet, wherein the identifier is associated with the first DTS.

18. An electronic system comprising: Platform, including components; one or more ports for communicatively coupling with a first debug and test system (DTS) and a second DTS; as well as logic is disposed in a communicable manner between the component and the one or more ports, wherein the logic is configured to: Based on a header of a first packet, identifying that the first packet is associated with a first debugging process of the component, wherein the first debugging process is performed by the first DTS; identifying, based on a header of the second packet, that the second packet is associated with a second debugging process of the component, wherein the second debugging process is performed by the second DTS; routing the first packet between the component and the DTS based on identifying that the first packet is associated with the first debugging process; and Based on identifying that the second packet is related to the second debug process, the second packet is routed between the component and the DTS.

19. The electronic system of claim 18, wherein the first packet is associated with a read operation or a write operation of the component performed by the first DTS.

20. The electronic system of any one of claims 18-19, wherein the first debugging process and the second debugging process at least partially overlap in time.

Images