Patent Application
20140359374
System-on-chip (“SoC”) designs, which are incorporated into portable computing devices, are getting more complex, frequently with more and more processors to perform different functionality and meet the increasing demands for such devices. SoCs typically include a trace infrastructure for recording and analyzing data about program execution for purposes of debugging and/or monitoring the execution of computer programs or diagnosing problems with software. The trace infrastructure generally comprises one or more trace sources that originate data related to the execution of programs embodied in hardware and/or software components residing on the SoC. The trace data is sent to one or more trace sinks residing off-chip or a trace buffer. The trace sinks may have associated files or memory components (i.e., trace dumps) for storing or dumping the trace data for subsequent processing and analysis by a trace parser.
Existing SoC trace solutions are limited, however, to choosing between high bandwidth on-chip trace capture resources (which typically have limited capacity) and relatively lower bandwidth off-chip resources.
Thus, there is a need in the art for improved mechanisms for managing SoC trace data in a portable computing device.
Systems, methods, and computer programs are disclosed for managing trace data in a portable computing device. An embodiment of a method for managing trace data in a portable computing device comprises: configuring trace data from a single trace source on a system-on-chip for trace capture at a plurality of trace sinks; sending the trace data from the single trace source to the plurality of trace sinks; and; reassembling the trace data originated by the single trace source from the plurality of trace sinks.
An embodiment of a system for managing trace data in a portable computing system comprises a system-on-chip and a trace parser. The system-on-chip comprises a plurality of trace sources for originating corresponding trace data and a trace system configured to receive and dump the trace data from one of the trace sources to a plurality of trace sinks. The trace parser is configured to reconstruct the trace data dumped to the plurality of trace sinks.
Another embodiment comprises a computer program for managing trace data in a portable computing device. The computer program is embodied in a computer-readable medium for execution by a processor. The computer program comprises logic configured to: configure trace data from a single trace source on a system-on-chip for trace capture at a plurality of trace sinks; send the trace data originated from the single trace source to the plurality of trace sinks; and reassemble the trace data originated by the single trace source from the plurality of trace sinks.
In the drawings, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals with letter character designations such as “102A” or “102B”, the letter character designations may differentiate two like parts or elements present in the same figure. Letter character designations for reference numerals may be omitted when it is intended that a reference numeral to encompass all parts having the same reference numeral in all figures.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
In this description, the term “application” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, an “application” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
The term “content” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, “content” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
As used in this description, the terms “component,” “database,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application or module running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution, and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components may execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).
A “portable computing device” (“PCD”) may comprise, for example, a cellular telephone, a satellite telephone, a pager, a personal digital assistant, a smart phone, a navigation device, a smart book or electronic reader, a media player, a tablet computer, a laptop computer, or other such devices.
SoC 102 may support any desirable architecture (e.g., ARM) and may include various hardware and/or software components to perform different functionality (e.g., central processing units (CPUs), digital signal processors (DSPs), etc.
In an embodiment of system 100, CPUs, DSPs, and other hardware/software components on the SoC 102 may support trace units capable of outputting out-of-order (“000”) gigabits per second (“Gbps”) of trace data under normal operation in a PCD. Some processors (e.g., Krait processors) may provide up to 8 Gbps of trace data. As known in the art, CPU and other traces are not that useful if traces are made to send data to a trace sink 109 that is not equipped to handle its bandwidth. For example, a Krait processor (or other high bandwidth trace source 104) attempting to trace over to a trace port interface unit (“TPIU”) to Trace32 may experience bandwidth mismatch. As understood by one of ordinary skill in the art, the trace subsystem 106 may support “Trace32”, which refers to a conventional hardware assisted debug tool for embedded systems, such as, SoC 102. TPIU is a parallel trace interface used in ARM-based ecosystems and is one of many possible examples of trace interfaces that may be used. In conventional systems, a trace sink 109 typically cannot handle its bandwidth when lots of trace data is lost due to the bandwidth mismatch, which results in “gray areas” or unknown boxes on the Trace32 trace window. For this reason, high bandwidth traces are almost entirely relegated to be captured in a high bandwidth capable trace sink, such as trace buffer 107.
However, on-chip trace capture resources are significantly limited relative to off-chip capture resources (often on the order of kilobytes (“kB”) for on-chip versus Megabyte (“MB”) or Gigabyte (“GB”) for off-chip). Furthermore, external trace sinks (e.g., trace sinks 109a, 109b, 109c, and 109d) are typically limited in bandwidth. TPIU is typically limited to approximately 4-5 Gbps in a 16 data pin, 150 MHz double data rate (DDR) configuration. Other external trace sinks, such as universal serial bus 3 (USB3) is typically limited to approximately 3 Gbps. While these limitations have been addressed by, for example, adding pins to the SoC 102 or increasing the frequency on trace sinks, such as, TPIU, this comes at the expense of SoC design complexity and costs.
To address these and other disadvantages of conventional SoC tracing solutions, the system 100 further comprises a single source multi-sink control module 105 located on the SoC 102 and a trace reassembly module 114 integrated with the trace parser 112. It should be appreciated that system 100 comprises an improved trace management solution that provides a fully-scalable means of leveraging existing SoC trace sinks 109 without adding SoC pins and/or increasing interface frequencies while also allowing reduction of on-die trace capture storage. The system 100 may also allow reduction of external trace interface pin count for dedicated trace interfaces, such as, TPIU.
As illustrated in
It should be appreciated that single trace source dumping to two or more trace sinks 109 may provide various design and operational advantages. For instance, reassembling the single trace source 104a trace data from multiple trace dumps 110a and 110b, may allow for reduction of trace buffer resources (e.g., on-chip embedded trace buffer (ETB) resources in ARM ecosystems) because the trace buffer may be the highest bandwidth sink available. Furthermore, two or more trace interfaces may be combined using the single source multi-sink control module 105 to provide an increased bandwidth solution for a single trace source 104a that is currently unavailable in existing solutions. The ability to use external trace storage (e.g., trace dumps 110a and 110b) in lieu of a trace buffer for high bandwidth capture may provide improved storage capacity and permit more data intensive, frequent, and/or longer duration trace capture from a single trace source 104a.
Additional benefits may include the ability to reduce pin count and/or frequency of existing dedicated trace interfaces. A combination of dedicated and/or non-dedicated traces may provide single source high bandwidth tracing, which may enable a reduction of SoC pins and/or frequency. In an embodiment, system 100 may combine existing trace interfaces (e.g., a Krait™ brand processor trace to TPIU, USB, Peripheral Component Interconnect Express (“PCIe”), etc. In this regard, it should be appreciated that that trace sinks 109 may incorporate any desirable trace interfaces, trace sinks, trace dumps, etc. including those mentioned above, debugger applications, and memory, such as, double data rate (DDR) memory devices.
The trace protocol stack 400 may further comprise a specially-configured “layer 2” periodic trace control packet for enabling the trace reassembly module 114 to de-interleave trace dumps 110a and 110b containing the respective trace data originated from the single trace source 104a. As illustrated in
Referring again to
As illustrated in
As shown, the PCD 700 includes an SoC 322 that includes a multicore CPU 402A. The multicore CPU 402A may include a zeroth core 410, a first core 412, and an Nth core 414. A display controller 328 and a touch screen controller 330 may be coupled to the GPU 106. In turn, the touch screen display 108 external to the SoC 322 may be coupled to the display controller 328 and the touch screen controller 330.
Further, as shown in
As further illustrated in
As depicted in
In a particular aspect, one or more of the method steps described herein may be stored in the memory 404A as computer program instructions, such as the modules described above in connection with the system 100 as illustrated in
These instructions may be executed by the multicore CPU 402A in combination or in concert with the memory channel optimization module 102 to perform the methods described herein. Further, the multicore CPU 402A, the trace subsystem 106, the single source multi-sink control module 105, the trace reassembly module 114, memory 404A of the PCD 700, or a combination thereof may serve as a means for executing one or more of the method steps described herein.
Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the scope and spirit of the invention. In some instances, certain steps may be omitted or not performed without departing from the invention. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.
Additionally, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example.
Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the Figures which may illustrate various process flows.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.
Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
Disk and disc, as used herein, includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
