Low-power debug architecture and system for system-on-chip (SOC)

Abstract

The present application relates to a low-power debug architecture and system for a system-on-chip (SOC). In one embodiment, an apparatus includes: a central debug unit that receives one or more functional debug signals, the central debug unit further configured to receive debug information from at least one firmware source, at least one software source, and at least one hardware source, and output compressed debug information; a system trace module that receives and time-stamps the compressed debug information; a parallel trace interface that receives and parallelizes the time-stamped compressed debug information; and / or an output unit that outputs the parallelized time-stamped compressed debug information on one of a plurality of output paths. Other embodiments are described and claimed.

Description

[0001] This application is a divisional application of the invention patent application with the application date of August 13, 2015, application number 201580041764.8 (PCT international application number is PCT / US2015 / 044958), and the name “Low-power debug architecture for system on chip (SOC) and system”. Technical Field

[0002] Embodiments relate to debug operations for integrated circuits and systems incorporating such circuits. Background Art

[0003] Today's systems-on-chips (SoCs) and other integrated circuits (ICs) are designed with low-power instructions to achieve long battery life. Debugging such ICs and SoCs is challenging because multiple low-power domains are designed into the device, waking and sleeping at a higher granularity than previous generations. Currently available debug environments offer limited capabilities for executing debug firmware and low-power operations. Summary of the Invention

[0004] In one aspect, an apparatus includes: a central debug unit that receives debug signals from a plurality of sources, the plurality of sources including at least one hardware source, at least one firmware source, and at least one software source; a trace merging unit that receives debug signals from the central debug unit and has arbitration logic to select between debug signals from one or more of the plurality of sources and functional debug signals from a plurality of hardware units, the trace merging unit time-stamping the selected debug signals or functional debug signals; and a parallel trace interface that receives the time-stamped selected debug signals or functional debug signals and time-stamps the time-stamped debug signals. a serial trace interface that receives the time-tagged selected debug signal or functional debug signal and serializes the time-tagged selected debug signal or functional debug signal; and a selection unit that receives the debug signal from the central debug unit and the parallelized time-tagged selected debug signal or functional debug signal from the parallel trace interface, and selects one of the debug signal and the parallelized time-tagged selected debug signal or functional debug signal for output on an output path, wherein the output path is selected from a plurality of output paths. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram of a portion of a processor according to an embodiment.

[0006] Figure 2 is another block diagram of a processor according to an embodiment of the present invention.

[0007] Figure 3 is a block diagram of a tracking aggregation unit according to an embodiment of the present invention.

[0008] Figure 4 is a flowchart of a method according to an embodiment of the present invention.

[0009] Figure 5 is a block diagram of a system according to an embodiment of the present invention.

[0010] Figure 6 is a block diagram of an example system with which embodiments may be used.

[0011] Figure 7 is a block diagram of another example system with which embodiments may be used.

[0012] Figure 8 is a block diagram of a system on chip according to an embodiment. DETAILED DESCRIPTION

[0013] In various embodiments, a power-aware low-power debug architecture is provided for processors and other systems-on-chip (SoCs), including system-in-package (SiPs), multi-chip packages (MCPs), such that various aspects of these devices implemented in the system can be tested / debugged, such as firmware operations including but not limited to boot-up, low-power operations including but not limited to low-power state entry / exit, etc. The debug architecture can be used to debug low-power tablet and smartphone IC / SoCs, embedded devices such as Internet of Things (IoT) devices, wearable devices, and low-power devices used in client / server applications. Thus, embodiments provide observability of hardware / software / firmware, low-power conditions, and low-power entry / exit transitions during early boot debug, thereby providing effective debugging of the entire operational range of the system. In various embodiments, debug triggers can be included in any firmware, operating system, or other software, thereby triggering points where debug information can be selectively collected to test various platform operating conditions.

[0014] Furthermore, because advanced ICs / SoCs have more stringent power consumption requirements, embodiments provide techniques for selectively enabling and disabling debug logic so that power consumption of such logic can be avoided in a large number of shipped products having such processors. However, it should be understood that embodiments may also provide for selective enabling when one of these products is returned from a debug / failure analysis site.

[0015] In various embodiments, a power-aware low-power debug scheme enables early-start debugging of logic operating in an always-on (AON) domain. In embodiments, a central debug unit (which is the primary controller for debug operations) can be configured with minimal logic and can be kept in the AON domain or a separate debug power domain to enable debugging of logic that is active early in the power-up phase and during low-power transitions, which can often be the most difficult circuits within a processor to debug.

[0016] In this way, since the debug path and debug logic are maintained in the AON or debug power domain, debug operations can be performed at early startup and during low-power transitions. That is, if, with a given design, the inclusion of debug logic (e.g., according to a design specification) causes the power consumption target of the processor or platform to be exceeded, the debug logic can be placed in a separate debug power domain. This separate debug power domain can be maintained separately from the AON power domain and one or more controllable power domains, which can include the core and other functional units of the processor. Subsequently, before shipping, the debug power domain can be configured to be permanently powered off during manufacturing (e.g., by fusing one or more sets of configuration fuses or other configuration values) to save power, including power lost due to leakage current lost in the debug power domain. In cases where power needs to be applied to the returned portion of a return material authorization (RMA) debug or for another reason (e.g., field testing), fuse override can be provided, for example, by a test access port (TAP) controller.

[0017] Now refer to Figure 1 , a block diagram of a portion of a processor, such as a SoC, according to an embodiment is shown. The illustrated portion 100 of the SoC primarily involves the design of X (DFx) circuitry, which can be used for various purposes, including design for test, design for verification, design for debug, and so on (the "X" in DFx can be replaced by a "T" to indicate design for test, a "D" to indicate design for debug, a "V" to indicate design for verification, and so on). This particular design is for the purpose of design for debug, as the logic is primarily used for debugging purposes. Generally, this circuitry can be used to receive input from one or more functional units of the processor or other debug host and appropriately process this information into a desired format for internal or external transmission to the debug host. This DFx circuitry can be used during the design, development, and debugging of the processor, and can also be used during the integration of the processor into a platform, such as a portable computing device (e.g., a smartphone, tablet, phablet, or any other portable or other computing device). Of course, the DFx circuitry can also be used for post-platform manufacturing test and debug operations.

[0018] In the embodiment shown, SoC 100 may include several functional circuits including one or more cores 1300-130 n In an embodiment, such a core may be, for example, a given Of course, in other embodiments, alternative cores from other manufacturers (e.g., cores based on ARM) may be present. And in other embodiments, cores based on A combination of cores and ARM-based cores or other logic.

[0019] generally, Figure 1 The remaining circuitry shown in FIG1 is related to the DFx circuitry of the processor. As can be seen, the DFx unit 120 is configured to receive inputs from various on-chip sources (including different sets of hardware, firmware, and / or software). The DFx unit 120 includes a central debug unit (CDU) 125 that is configured to collect the various inputs received from the different sources and send them along with selected debug signals via a first internal interconnect 138. During operation, debug signals including hardware (HW), software (SW), and firmware (FW) debug traces are sent to the CDU 125. As used herein, a "trace" refers to a collection of streams of signals or other information obtained from a desired on-chip location and can generally provide information about activity that can be viewed in real time or stored and later retrieved for viewing by a given user (e.g., an application developer, an application, or an external facility) to observe system activity. Note that internal debug signals received from the various functional units of the processor can be collated using block-level selectors in individual blocks, intermediate selectors in intermediate blocks (e.g., non-core logic between debug blocks of interest), and final selectors within the CDU 125. Signals related to low-power debug can be placed in the AON domain within the block and sent as AON signals to enable low-power debug. Alternatively, as described above, these signals can also be placed in the debug domain (which can be fused after manufacturing test / debug or disabled at manufacturing time by alternative methods).

[0020] In an embodiment, at least a portion of the central debug unit 125 can be maintained in the AON power domain, with only the necessary logic powered by this domain, thereby minimizing the power consumption of the debug logic. In an embodiment, the CDU 125 includes a centralized packager, trigger logic, and compression logic. Of course, it should be understood that in other embodiments, additional logic may be present in the CDU 125. In an embodiment, the debug signals output from the CDU 125 may be a collection of debug signals from the microprocessor, as shown, and these signals may be provided to multiple destinations, including the selection logic 160 and the trace merging unit 140.

[0021] As further shown, the trace merging unit 140 also receives incoming functional debug signals, which in embodiments may take the form of real-time instruction trace (RTIT) signals (and / or real-time data trace signals) or proprietary forms of debug signals (e.g., To this end, trace merging unit 140 includes arbitration logic 145 that is configured to perform arbitration between internal debug signals and functional debug signals or other core debug signals, thereby arbitrating between these different paths of incoming signals and providing the selected signal to the rest of trace merging unit 140.

[0022] Typically, the trace merging unit 140 is configured to further process the CDU output by adding time stamp information. Next, the trace merging unit 140 streams the time stamped debug trace information in a manner compatible with one or more protocols. For example, in an embodiment, the trace merging unit 140 may be compatible with the Mobile Industry Processor Interface (MIPI) Alliance System Trace Protocol (STP). In another embodiment, the trace merging unit 140 may be compatible with an ARM trace funnel that implements the Trace Wrapper Protocol, ARM Embedded Trace Macrocell (ETM), or other protocols. Of course, other protocols (e.g., RTIT or PT). By providing internal debug signals via the trace merging unit 140, such internal debug signals are time-stamped and sent using a given protocol (e.g., the MIPI STP protocol). These processed and time-stamped signals can then be output from the processor and received and used by a given debugging tool (e.g., a logic analyzer, a trace port analyzer (TPA), or other tool for deciphering the emitted time-stamped debug stream). Using such a tool, these signals can be deciphered and visualized, thereby performing debugging. Furthermore, time-stamped tracing enables temporal correlation between signals, thereby facilitating debugging.

[0023] These processed debug signals are provided via interconnect 148 to parallel trace interface (PTI) logic 150, which can further process the signals. In an embodiment, PTI logic 150 is configured to parallelize the received debug information. Note that the extent of parallelization can be controlled based on the number of pins or other output paths selected for output (e.g., 1, 2, 4, 8, or 16). The processed signals are provided to selection logic 160 via interconnect 155. Typically, selection logic 160 is configured to select either the processed signal received via interconnect 155 or the more microprocessed debug signal received via interconnect 138, and output the selected signal to output unit 170 via interconnect 165. Typically, output unit 170 provides output paths via on-die interconnects to one or more sets of output connections, which, in an embodiment, may correspond to dedicated output pins of the SoC, input / output (I / O) pins, and / or pins coupled to system memory (which may be on-chip static random access memory) or other interconnects. In an embodiment, these output connections may include output pins 1800-180 n The first set and output pins 1900-190 n In an embodiment, the first output pin 180 may be a general purpose IO (GPIO) pin, and the second output pin 190 may be another type of pin connection (e.g., a PTI pin). In an embodiment, certain output paths may be coupled (e.g., via a PTI pin) to micro secure digital (SD) pins of a closed chassis system that enables form factor debugging (FFD) or closed chassis debugging in addition to open chassis debugging.

[0024] In some embodiments, instead of parallelization, the processed debug signals from the trace merging unit 140 may be sent to the destination via a high-speed serial stream. In this case, in response to a trace data selection signal output by the CDU 125, trace data may be selected in the selection unit 110 from the output of the PTI logic 150 or from the trace merging unit 140. In an embodiment, the default selection for the selection logic 110 is to select the output of the display controller 105, and based on the debug, the selection is changed to select debug trace data. The selected output is provided to the display logic 112, which converts the parallel trace data into a serial stream and adds protocol information to drive the high-speed serial I / O interface 114. It should be understood that although in Figure 1 This particular high-level view is shown in , but the scope of the present invention is not limited in this regard.

[0025] Now refer to Figure 2 , further showing the details of the processor 100. More specifically, Figure 2 Provides a high-level view of the overall SoC, which includes the Figure 1 The debug circuitry is described in the context of additional SoC circuitry. Figure 2 A core 106 is shown, which in embodiments may be the main central processing unit (CPU) of the SoC and, in embodiments, may be an advanced out-of-order execution core configured to execute instructions of one or more instruction set architectures. Next, the core 106 is coupled to a north unit 108, which in embodiments may include various interfaces and other control circuitry (e.g., a memory controller and / or other interface circuitry). As can be seen, the north unit 108 is coupled to a DFx unit 120.

[0026] Furthermore, West unit 111 is also coupled to DFx circuitry 120. In various embodiments, West unit 111 includes one or more processing units, such as one or more coprocessors, graphics processors, fixed function units, etc. Furthermore, South unit 115 may include additional or different units, interface units, etc., and is also coupled to DFx unit 150. Note that additional details regarding trace collection and communication are shown for South unit 115. More specifically, within South unit 115, various traces are provided to trace collection unit 118.

[0027] In the illustrated embodiment, message tracing includes software tracing, firmware tracing, and hardware tracing, and in embodiments, message tracing may include AON tracing because these traces are associated with circuits that are powered on even when a given platform in which the SoC resides is in a low-power mode. For example, in the context of a mobile platform (e.g., a smartphone, a tablet computer, an Internet of Things (IoT) device, etc.), although the platform is powered on but not in use (e.g., its display is off and no user interaction is occurring), certain circuits of the SoC remain always on to maintain a connection to, for example, a base station of a wireless communication system (e.g., a cellular system).

[0028] In an embodiment, the trace collection unit 118 may be controlled by signals received via a Joint Test Action Group (JTAG) unit 119, which receives control signals from, for example, an off-chip (and off-platform source (e.g., a logic analyzer)) via, for example, a JTAG interface of a SoC that is in turn coupled to the JTAG unit 119. In another embodiment, the trace collection unit 118 may be controlled (e.g., via a debugger, serial line debugger, I 2 C, etc.) receives control signals from any other memory mapped input / output (MMIO) access mechanism. Thus, the various trace signals collected in the trace collection unit 118 are provided to the DFx unit 120, and more specifically to the DFx unit 120, which can be used with Figure 1The CDU 125 corresponds to the debugging logic for the processing described herein. Note that, Figure 2 The remainder of the debug circuit shown in the figure can generally be compared to the Figure 1 The rest of the debug circuit discussed corresponds to this. Figure 2 The embodiments are shown in this high-level form, but it should be understood that the scope of the present invention is not limited in this regard.

[0029] Now refer to Figure 3 , shows further details of the trace collection unit according to an embodiment of the present invention. Note that the trace collection unit 200 can generally be used with Figure 2 2. The trace collection unit 200 corresponds to the trace collection unit 118 of FIG. 2. It should be understood that multiple such trace collection units can be located, for example, in different clusters or units of a processor. As can be seen, the trace collection unit 200 is configured to receive incoming trace information from multiple sources, including software messages 210, firmware messages 220, internal signal multiplexer (or switchable power domain) sources 230, and always-on (or non-switchable power domain) sources 240. Note that a selection unit 245 (e.g., a multiplexer) can select between source 230 and source 240.

[0030] Various trace information from these sources may be provided to respective trace buffers 215, 225, and 235 for intermediate storage. Ultimately, selection logic 250 (e.g., another multiplexer) may be controlled in response to configuration signals received via configuration inputs to select the respective traces for output via output paths 260 (e.g., an internal interconnect coupled to a central debug unit or other destination). Although Figure 3 This limiting circuit is shown in FIG, but it should be understood that the scope of the present invention is not limited in this regard.

[0031] In an embodiment, hardware traces may be collected at the cluster level via an internal debug signal multiplexer architecture (where internal signals are connected to a multiplexer tree via multiplexer inputs for observability) or via fabric trace hooks (FTHs). Note that such hardware traces may be collected at the protocol level or with respect to low power or transition debugging. These HW traces may originate from the AON region or elsewhere, but in either case the signals are sent to an internal debug multiplexer within the AON region, which may avoid the need for store and replay (also known as save and restore). Store and replay is used instead when the state of the machine was saved before the power was turned off (for power conservation purposes), and the state is restored after the machine is powered on.

[0032] In embodiments, software traces can be handled flexibly within a cluster, dynamically selecting a software master (e.g., using a multiplexer selection). In some cases, multiple software masters can be interleaved if debugging is required. As discussed above, embodiments also provide for handling firmware (FW) traces, where such traces can be streamed in real time because the AON logic can be used for debugging.

[0033] Using embodiments, debug information about low power entry / exit or transitions between different power states can be obtained and output. In this way, embodiments provide observability of internal signals and events (e.g., HW, SW, FW) and all kinds of traces that will become observable at the output ports of the SoC or other IC.

[0034] In other words, embodiments provide observability of hardware (transaction level and signal level) tracing, software tracing, and firmware tracing at all times, including but not limited to, early debug, low power entry / exit transitions, and regular run-time debug, and also provide signal level observability and transition level observability. Furthermore, embodiments provide time stamping of internal debug HW, SW, and FW traces by reusing the STM block to handle internal debug flows in addition to functional unit debug signals.

[0035] As such, embodiments enable fully generic, efficient, and scalable debug capabilities for all types of debug sources (e.g., hardware, software, and firmware) by leveraging the ability to trigger, filter, package, and compress debug data to fit within the output bandwidth of effective debug. Furthermore, debug architectures according to embodiments can conserve power in production by configuring some or all debug logic on a separate debug power plane, where power to that debug power plane can be shut down, for example, via fuses or some other means that shut down debug logic power to conserve power at the component level, and then overlaying the capability to similarly conserve platform power to enable it to power debug backends.

[0036] Additionally, because embodiments can be used to perform low-power debugging (e.g., during an ACPI system low-power state (e.g., SOix)), the output path can be coupled to other locations, such as a high-speed serial trace port including DisplayPort, PCIe, USB, or a Type-C connector, by placing logic in one of the AON or debug power domains. In some cases, trace information can also be transmitted via an embedded DFx interface or a direct connect interface (DCI) according to the USB protocol for closed chassis debugging. Thus, embodiments can be used for debugging many different types of ICs, including low-power mobile SoCs and client / server ICs and SoCs, among others.

[0037] Now refer to Figure 4 , shows a flow chart of a method according to an embodiment of the present invention. More specifically, Figure 4 The method 300 involves debugging operations performed during firmware execution using debug logic of a SoC. Figure 4 The particular implementation shown in FIG. 1 is related to pre-boot firmware operations, but it should be understood that the scope of the present invention is not limited to such an environment, and firmware-based debugging may equally be performed during normal system operation of a platform including a SoC.

[0038] As can be seen, method 300 begins by powering up the AON portion of the SoC (block 310). During this operation, because the platform and SoC are not fully functional, only a limited portion of the SoC (referred to as the AON power domain) is powered up. Therefore, in an embodiment, where portions of the debug circuitry are placed in the AON power domain, these portions are also powered up. In another embodiment, where the debug circuitry is instead incorporated into its own debug power domain, this debug power domain can also be powered up.

[0039] Control then passes to block 320 where the debug circuitry may be configured to collect firmware and hardware trace information. This configuration may be performed via a test interface of the SoC (e.g., via a JTAG interface) such that various selectors (e.g., different levels of a multi-level multiplexer architecture) are configured to provide such hardware and firmware trace information.

[0040] Next, control passes to block 330, where SoC operation begins in a pre-boot environment, wherein at least a portion of the platform firmware is executed, for example, according to Unified Extensible Firmware Interface (UEFI) firmware (e.g., different modules of the basic input / output system (BIOS)). During this operation, firmware and hardware trace information is processed in the debug circuitry (block 340). In response to this processing, the processed information can be streamed from the SoC via a selected output path (block 350). For example, in some cases (e.g., during development of the platform in prototype form), an open chassis arrangement may be present, such that trace information can be streamed out via a set of GPIO pins (or a portion of such pins), or sent to memory for later extraction and debugging, or sent via alternative pins for debugging purposes. Alternatively, when the platform design is further advanced and a fully functional platform exists, closed chassis debugging operations may occur, and trace information can be streamed out via other output paths (e.g., via a set of one or more microSD pins or other pins (e.g., HDMI, USB, or alternative pins available on the final product)).

[0041] Still refer to Figure 4During platform debugging, based on the streamed trace information, it can be determined whether an error is detected (diamond 360). If no error is detected, the platform can transition to the boot environment (block 365). Note that upon transitioning to the boot environment (e.g., depending on a given OS), additional configuration of debug circuitry may occur so that software trace information (in addition to certain hardware trace information) can be obtained, rather than firmware trace information.

[0042] If one or more errors are detected during the pre-boot environment, control passes to block 370 where the error detection event may be time-stamped. In an embodiment, such time-stamping may be partially influenced by using time-stamping information from received stream trace information (which may be received in a format that includes time-stamps). Ultimately, at block 380, the time-stamped error detection event may be reported to, for example, a user of a trace analysis tool coupled to the platform. It should be understood that, although Figure 4 The embodiments are shown in this advanced form, but the scope of the present invention is not limited in this regard.

[0043] Now refer to Figure 5 , shows a block diagram of a system according to an embodiment of the present invention. Figure 5 In an embodiment, the system 900 may be a SoC including multiple domains, each of which may be controlled to operate at an independent operating voltage and operating frequency. As a specific illustrative example, the system 900 may be based on Architecture Core TM SoCs (e.g., i3, i5, i7) or other such processors available from Intel Corporation. However, other low-power SoCs or processors, such as those available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, California, ARM-based designs from ARM LLC or their licensors, or MIPS-based designs from MIPS Technologies, Inc. of Sunnyvale, California or their licensors or successors, may instead be present in other embodiments, such as the Apple A7 processor, Qualcomm's Snapdragon processor, or Texas Instruments' OMAP processor. Such SoCs may be used in low-power systems (e.g., smartphones, tablets, mobile tablets, Ultrabooks, etc.) TM computers, IoT devices, wearable devices, or other portable computing devices).

[0044] exist Figure 5 In the high-level view shown in FIG, SoC 900 includes multiple core units 9100-910 n. Each core unit may include one or more processor cores, one or more cache memories, and other circuits. Each core unit 910 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added to the latest versions); the MIPS instruction set; the ARM instruction set (with additional extensions such as NEON)) or other instruction sets or a combination thereof. Note that some core units may be heterogeneous resources (e.g., of different designs). In addition, each such core may be coupled to a cache memory (not shown), which in an embodiment may be a cache memory of a shared layer (L2). The non-volatile storage device 930 may be used to store various programs and other data. For example, the storage device may be used to store at least a portion of the microcode, startup information such as BIOS, other system software, etc.

[0045] Each core unit 910 may also include an interface (e.g., a bus interface unit) to enable interconnection to additional circuitry of the SoC. In an embodiment, each core unit 910 is coupled to a coherent fabric (which may serve as an interconnect on the primary cache coherent die), which in turn is coupled to a memory controller 935. The memory controller 935 in turn controls the communication with memory devices such as DRAM (not shown for simplicity). Figure 5 Communication with memories such as those shown in FIG.

[0046] In addition to the core units, there are additional processing engines within the processor, including at least one graphics unit 920, which may include one or more graphics processor units (GPUs) to perform graphics processing and possibly general-purpose operations on the graphics processor (referred to as GPGPU operations). In addition, there may be at least one image signal processor 925. The signal processor 925 can be configured to process input image data received from one or more capture devices (internal to the SoC or external to the chip).

[0047] Other accelerators may also be present. Figure 5 In the schematic diagram of FIG, a video encoder 950 can perform encoding operations (including encoding and decoding operations on video information), for example, providing hardware acceleration support for high-definition video content. A display controller 955 can also be provided to accelerate display operations, including providing support for internal and external displays of the system. In addition, a debugging unit 945 can be present, and the debugging unit 945 can include a low-power debugging architecture as described herein. Each unit can have its power consumption controlled by a power manager 940, which can include control logic for implementing various power management techniques.

[0048] In some embodiments, the SoC 900 may also include a non-coherent fabric coupled to the coherent fabric, to which various peripheral devices may be coupled. One or more interfaces 960a-960d enable communication with one or more off-chip devices. Such communication may be based on various communication protocols, such as PCIe TM ,GPIO,USB,I 2 C, UART, MIPI, SDIO, DDR, SPI, HDMI, and other types of communication protocols. Figure 5 The embodiments are shown in this high-level form, but it should be understood that the scope of the present invention is not limited in this regard.

[0049] Now refer to Figure 6 , shows a block diagram of an example system that embodiments may use. As can be seen, system 1200 may be a smartphone or other wireless communicator. Baseband processor 1205 is configured to perform various signal processing for communication signals to be sent from or received by the system. Next, baseband processor 1205 is coupled to application processor 1210 (which may be the main SoC of the system), thereby executing the OS and other system software, in addition to user applications such as many well-known social media apps and multimedia apps. Application processor 1210 may also be configured to perform various other computing operations for the device and may include a low-power debug architecture as described herein.

[0050] Next, the application processor 1210 can be coupled to a user interface / display 1220, such as a touchscreen display. Additionally, the application processor 1210 can be coupled to a memory system that includes non-volatile memory (referred to as flash memory 1230) and system memory (referred to as dynamic random access memory (DRAM) 1235). As further shown, the application processor 1210 is also coupled to a capture device 1240, such as one or more image capture devices that can record video and / or still images.

[0051] Still refer to Figure 6 A universal integrated circuit card (UICC) 1240 includes a subscriber identity module and may include a secure storage device and a cryptographic processor, and is also coupled to the application processor 1210. The system 1200 may also include a security processor 1250, which may be coupled to the application processor 1210. A plurality of sensors 1225 may be coupled to the application processor 1210 to enable input of various sensory information (e.g., accelerometer and other environmental information). An audio output device 1295 may provide an interface for outputting sound (e.g., in the form of voice communication, playing or streaming audio data, etc.).

[0052] As further shown, a near field communication (NFC) contactless interface 1260 is provided that communicates in the NFC near field via an NFC antenna 1265. Figure 6 A single antenna is shown in FIG, but it should be understood that in some implementations one antenna or a different set of antennas may be provided to enable various wireless functionalities.

[0053] A power management integrated circuit (PMIC) 1215 is coupled to the application processor 1210 to perform platform-level power management. To this end, the PMIC 1215 can send power management requests to the application processor 1210 to enter certain low-power states as needed. Furthermore, based on platform constraints, the PMIC 1215 can also control the power levels of other components of the system 1200.

[0054] To enable communications to be sent and received, various circuits may be coupled between the baseband processor 1205 and the antenna 1290. Specifically, a radio frequency (RF) transceiver 1270 and a wireless local area network (WLAN) transceiver 1275 may be present. Typically, the RF transceiver 1270 may be used to receive and transmit wireless data and calls according to a given wireless communication protocol, such as a 3G or 4G wireless communication protocol (e.g., according to Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Long Term Evolution (LTE), or other protocols). In addition, a GPS sensor 1280 may be present. Other wireless communications may also be provided, such as receiving or transmitting radio signals (e.g., AM / FM and other signals). In addition, via the WLAN transceiver 1275, communications, such as those according to Bluetooth®, may also be implemented. TM Wireless communications based on the IEEE 802.11 standard or IEEE 802.11 standard (e.g., IEEE 802.11a / b / g / n).

[0055] Now refer to Figure 7 , shows a block diagram of another example system that embodiments may use. Figure 7 In the schematic diagram of FIG. 1 , system 1300 can be a mobile low-power system, such as a tablet computer, a 2:1 tablet, a phone-tablet, or other convertible or standalone tablet system. As shown, SoC 1310 is present and can be configured to operate as the device's application processor. SoC 1310 can include a low-power debug architecture as described herein.

[0056] Various devices can be coupled to SoC 1310. In the schematic diagram shown, the memory subsystem includes flash memory 1340 and DRAM 1345 coupled to SoC 1310. In addition, a touch panel 1320 is coupled to SoC 1310 to provide display capabilities and user input via touch, including providing a virtual keyboard on the display of touch panel 1320. To provide a wired network connection, SoC 1310 is coupled to an Ethernet interface 1330. A peripheral hub 1325 is coupled to SoC 1310 to enable interfacing with various peripheral devices, for example, which can be coupled to system 1300 via various ports or other connectors.

[0057] In addition to the internal power management circuitry and functionality within the SoC 1310, a PMIC 1380 is coupled to the SoC 1310 to provide platform-based power management, for example, based on whether the system is powered by a battery 1390 or an AC power source via an AC adapter 1395. In addition to this power source-based power management, the PMIC 1380 can also perform platform power management activities based on environmental and usage conditions. Furthermore, the PMIC 1380 can communicate control and status information to the SoC 1310, thereby initiating various power management actions within the SoC 1310.

[0058] Still refer to Figure 7 To provide wireless capabilities, the WLAN unit 1350 is coupled to the SoC 1310 and is coupled to the antenna 1355. In various implementations, the WLAN unit 1350 can be configured to provide wireless communications according to one or more wireless protocols, including IEEE 802.11, Bluetooth, and IEEE 802.11 standards. TM protocol or any other wireless protocol) to provide communication.

[0059] As further shown, a plurality of sensors 1360 may be coupled to the SoC 1310. These sensors may include various accelerometers, environmental and other sensors (including user gesture sensors). Finally, an audio codec 1365 is coupled to the SoC 1310 to provide an interface to an audio output device 1370. It should be understood that although Figure 7 This particular implementation is shown in FIG, but many variations or alternatives are possible.

[0060] Turn below Figure 8, depicts an embodiment of a SoC design according to an embodiment. As a specific illustrative example, SoC 2000 is included in a user equipment (UE). In one embodiment, UE refers to any device to be used by an end user, such as a wearable device, a handheld phone, a smartphone, a tablet, an ultra-thin notebook, a notebook IoT device, or any other similar device. Typically, a UE is connected to a base station or node, which in essence potentially corresponds to a mobile station (MS) in a GSM network.

[0061] Here, SoC 2000 includes cores 2006 and 2007. Similar to the above discussion, cores 2006 and 2007 may conform to an instruction set architecture, for example, based on Architecture Core TM , Advanced Micro Devices, Inc. (AMD) processors, MIPS-based processors, ARM-based processor designs, or their customers and their licensors or successors. Cores 2006 and 2007 are coupled to cache control 2008 associated with bus interface unit 2009 and L2 cache 2010 to communicate with the rest of system 2000. Interconnect 2010 includes an on-chip interconnect.

[0062] Interconnect 2010 provides a communication channel to other components (e.g., debug unit 2030), which may have a low-power architecture as described herein. As can be seen, debug unit 2030 can be connected to multiple off-chip connections. Interconnect 2010 is also coupled to boot ROM 2035 to store boot code for execution by cores 2006 and 2007 to initialize and start SOC 2000; SDRAM controller 2040 to connect to external memory (e.g., DRAM 2060); flash controller 2045 to connect to non-volatile memory (e.g., flash memory 2065); peripheral controller 2050 (e.g., serial peripheral interface) to connect to peripheral devices; video codec 2020 and video interface 2025 to display and receive input (e.g., touch-enabled input) via one of the MIPI or HDMI / DP interfaces; GPU 2015 to perform graphics-related calculations, etc.

[0063] Additionally, the system shows peripheral devices for communication, such as a Bluetooth module 2070, a 3G modem 2075, a GPS 2080, and WiFi 2085. A power controller 2055 is also included in the system.

[0064] The following examples pertain to further embodiments.

[0065] In one example, an apparatus includes: a central debug unit that receives debug signals from a plurality of sources, the plurality of sources including at least one hardware source, at least one firmware source, and at least one software source; a trace merging unit that receives debug signals from the central debug unit and has arbitration logic to select between debug signals from one or more of the plurality of sources and functional debug signals from a plurality of hardware units, the trace merging unit time-stamping the selected debug signals or functional debug signals; and a parallel trace interface that receives the time-stamped selected debug signals or functional debug signals and time-stamps the time-stamped debug signals. a serial trace interface that receives the time-tagged selected debug signal or functional debug signal and serializes the time-tagged selected debug signal or functional debug signal; and a selection unit that receives the debug signal from the central debug unit and the parallelized time-tagged selected debug signal or functional debug signal from the parallel trace interface, and selects one of the debug signal and the parallelized time-tagged selected debug signal or functional debug signal for output on an output path, wherein the output path is selected from a plurality of output paths.

[0066] In an example, the apparatus includes a system-on-chip (SoC), the plurality of output paths including one or more of: a set of general-purpose input / output pins; a set of micro-secure digital (MSD) pins; a set of memory interconnects; and at least one universal serial bus (USB) pin. The selection unit may be configured to output the selected debug signal on the output path corresponding to the set of MSD pins when the SoC is configured in a portable device having an enclosed chassis.

[0067] In the example, the device also includes a distributed selection unit having: a first selection unit, which is located in a first functional unit of the SoC including the device; a second selection unit, which is located in the non-core logic of the SoC, and receives output from multiple first selection units including the first selection unit; and a third selection unit, which receives output from multiple second selection units including the second selection unit and outputs the selected debug signal to the central debugging unit.

[0068] In an example, the apparatus further includes a trace collection unit configured to receive a trace control signal via a test interface of the SoC and, in response to the trace control signal, select one of hardware trace information, software trace information, and firmware trace information for output from the trace collection unit to the central debugging unit.

[0069] In an example, the firmware includes boot code for the SoC.

[0070] In an example, the apparatus includes a first power domain comprising a first portion of a central debug unit and a second power domain comprising a second portion of the central debug unit, wherein the first power domain is to remain powered on and the second power domain is to be powered off when the SoC is to operate in a low power mode.

[0071] In an example, a first portion of the central debug unit will receive and process debug signals associated with the low power mode.

[0072] In an example, the apparatus further includes blow logic configured to disable at least a first portion of the central debug unit during user operation of a portable device including the SoC, wherein the blow logic is configured before the SoC is included in the portable device. The blow logic can be configured to be rewritten to enable the first portion of the central debug unit during debug operation of the portable device.

[0073] In an example, the parallelized time-stamped selected debug signals or functional debug signals are compatible with the MIPI Alliance System Trace Protocol.

[0074] In an example, the SoC is incorporated into a touch-enabled device of a user device.

[0075] In another example, a system includes a display and a memory and includes an apparatus as in one or more of the above examples.

[0076] In another example, at least one computer-readable medium includes instructions that, when executed, cause a system to: configure debug circuitry of a processor to collect firmware trace information and hardware trace information, the debug circuitry causing a first portion located in a first power domain to be powered on when a platform including the processor is turned on and causing a second portion located in a second power domain to be powered off when the platform is in a low-power state; process the firmware trace information and the hardware trace information in the debug circuitry in a pre-boot environment of the platform; and stream the processed firmware trace information and the processed hardware trace information from the processor to an analysis tool coupled to the platform via a selected output path of the processor.

[0077] In an example, the at least one computer-readable medium further includes instructions that, when executed, cause the system to: time-stamp an error detection event responsive to detecting the error based on information in at least one of the processed firmware trace information and the processed hardware trace information.

[0078] In an example, the at least one computer-readable medium further includes instructions that, when executed, enable a first portion of debug circuitry in the pre-boot environment and disable a second portion of debug circuitry in the pre-boot environment.

[0079] In an example, processing the firmware trace information includes one or more of filtering, packaging, and compressing the firmware trace information.

[0080] In another example, a SoC includes at least one core for executing instructions, the at least one core including first debug logic for providing first functional debug signals regarding the operation of the at least one core; non-core logic coupled to the at least one core for performing non-core operations, the non-core logic including second debug logic for providing second functional debug signals regarding the operation of the non-core logic; a central debug unit coupled to the at least one core and the non-core logic for receiving the first functional debug signals and the second functional debug signals, the central debug unit further configured to receive debug information from at least one firmware source and at least one software source and output compressed debug information; a trace merging unit for receiving the compressed debug information and time-stamping the compressed debug information; and an output unit for outputting the time-stamped compressed debug information on one of a plurality of output paths, the one output path being selected based on a configuration provided to the SoC via a test interface.

[0081] In an example, the plurality of output paths includes one or more of: a set of general purpose input / output pins; a set of micro secure digital pins; a set of memory interconnects; and at least one serial pin.

[0082] In an example, the SoC includes a first power domain and a second power domain, the first power domain remains powered on when a platform including the SoC is turned on, and the second power domain is to be powered off when the platform is in a low power state, wherein the central debug unit includes a first part and a second part, the first part being included in the first power domain and the second part being included in the second power domain.

[0083] In an example, the SoC further includes fuse logic configured to disable the central debug unit, the trace merging unit, and the output unit during user operation of a platform including the SoC, wherein the fuse logic is to be rewritten to enable at least a portion of the central debug unit, the trace merging unit, and the output unit during debug operation of the platform.

[0084] In an example, the central debug unit includes at least one of: trigger logic, filtering logic, packaging logic, and compression logic.

[0085] In an example, the parallel trace interface is configured to receive time-stamped compressed debug information and to parallelize the time-stamped compressed debug information.

[0086] In an example, logic is configured to serialize the parallelized time-stamped compressed debug information and output the serialized time-stamped compressed debug information via a serial output path.The logic may output the time-stamped compressed debug information from the trace merging unit via the serial output path.

[0087] It should be understood that various combinations of the above examples are possible.

[0088] Embodiments may be used in many different types of systems. For example, in one embodiment, a communication device may be arranged to perform the various methods and techniques described herein. Of course, the scope of the present invention is not limited to communication devices, and alternative embodiments may be directed to other types of apparatuses for processing instructions, or one or more machine-readable media containing instructions, which, in response to execution of the instructions on a computing device, cause the device to implement one or more of the methods and techniques described herein.

[0089] Embodiments may be implemented in code and may be stored on a non-transitory storage medium (having instructions stored thereon) that may be used to program a system to execute the instructions. The storage medium may include, but is not limited to, any type of magnetic disk including a floppy disk, an optical disk, a solid-state drive (SSD), a compact disk read-only memory (CD-ROM), a compact disk rewritable (CD-RW), and a magneto-optical disk; semiconductor devices such as read-only memory, random access memory (RAM) (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0090] While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the invention.

Claims

1. A method for performing a debugging operation, comprising: configuring debug circuitry of a processor to collect firmware trace information and hardware trace information, wherein a first portion of the debug circuitry, located in a first power domain, is to be powered on when a platform including the processor is powered on, and a second portion of the debug circuitry, located in a second power domain, is to be powered off when the platform is in a low power state; In a pre-boot environment of the platform, enabling the first portion of the debug circuitry and disabling the second portion of the debug circuitry; processing the firmware trace information and the hardware trace information in the debug circuit in a pre-boot environment of the platform; as well as Processed firmware trace information and processed hardware trace information are streamed from the processor to an analysis tool coupled to the platform via a selected output path of the processor.

2. The method of claim 1, further comprising: An error detection event is time-stamped in response to detecting an error based on information in at least one of the processed firmware trace information and the processed hardware trace information.

3. The method according to claim 1, wherein Processing the firmware trace information includes one or more of filtering, packaging, and compressing the firmware trace information.

4. A machine-readable storage medium comprising machine-readable instructions, which, when executed, implement the method as claimed in any one of claims 1 to 3.

5. A device for performing a debugging operation, comprising: means for configuring debug circuitry of a processor to collect firmware trace information and hardware trace information, a first portion of the debug circuitry located in a first power domain to be powered on when a platform including the processor is powered on, and a second portion of the debug circuitry located in a second power domain to be powered off when the platform is in a low power state; means for enabling the first portion of the debug circuitry and disabling the second portion of the debug circuitry in a pre-boot environment of the platform; means for processing the firmware trace information and the hardware trace information in the debug circuitry in a pre-boot environment of the platform; as well as Means for streaming processed firmware trace information and processed hardware trace information from the processor to an analysis tool coupled to the platform via the selected output path of the processor.

6. The apparatus of claim 5, further comprising: Means for time-stamping an error detection event in response to detecting an error based on information in at least one of the processed firmware trace information and the processed hardware trace information.

7. The apparatus of claim 5, wherein: Processing the firmware trace information includes one or more of filtering, packaging, and compressing the firmware trace information.

Images