EP3382552A1 - Synchrone hardware-ereignis-sammlung - Google Patents

Synchrone hardware-ereignis-sammlung Download PDF

Info

Publication number
EP3382552A1
EP3382552A1 EP17199338.9A EP17199338A EP3382552A1 EP 3382552 A1 EP3382552 A1 EP 3382552A1 EP 17199338 A EP17199338 A EP 17199338A EP 3382552 A1 EP3382552 A1 EP 3382552A1
Authority
EP
European Patent Office
Prior art keywords
trace
data
hardware
program code
computing system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP17199338.9A
Other languages
English (en)
French (fr)
Inventor
Thomas NORRIE
Naveen Kumar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of EP3382552A1 publication Critical patent/EP3382552A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/348—Circuit details, i.e. tracer hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Definitions

  • This specification relates to analyzing execution of program code.
  • Distributed hardware components can be respective processor cores of two or more Central Processing Units (CPUs) (or Graphics Processing Units (GPUs)) that cooperate and interact to execute portions of a larger software program or program code.
  • CPUs Central Processing Units
  • GPUs Graphics Processing Units
  • one innovative aspect of the subject matter described in this specification can be embodied in a computer-implemented method executed by one or more processors, the method including, monitoring execution of program code by a first processor component, the first processor component being configured to execute at least a first portion of the program code; and monitoring execution of the program code by a second processor component, the second processor component being configured to execute at least a second portion of the program code.
  • the method further includes, detecting, by a computing system, that a trigger condition is satisfied based on at least one of: i) identifying an occurrence of an operand in at least the first portion of the program code or the second portion of the program code, the operand including a first parameter value used to initiate one or more trace events, or ii) determining that a current time of at least one clock of the computing system indicates a predefined time value used to initiate one or more trace events.
  • the method includes, initiating, by the computing system, at least a first trace event that generates trace data, the trace data identifying respective hardware events occurring across distributed processor units that include at least the first processor component and the second processor component. For each of the respective hardware events, the trace data comprises at least a hardware event time stamp. The method further includes, using, by the computing system, the trace data to generate a correlated set of trace data that indicates at least a time ordered sequence of the respective hardware events that are generated when the trigger condition is satisfied.
  • the first trace event is a synchronized trace event that generates trace data identifying hardware events occurring across the distributed processor units, the trace data also identifying a unique trace identifier for respective hardware events, and wherein the hardware events include a plurality of synchronized hardware events, and two hardware events are synchronized when the events share a global hardware event time stamp.
  • detecting that the trigger condition is satisfied comprises: detecting, by the computing system, that one of: i) the first parameter value of the operand exceeds a first bound value of a register, or ii) the predefined time value indicated by the current time exceeds a first bound value of a register; and responsive to detecting that the trigger condition is satisfied, initiating, by the computing system, a second trace event that generates trace data, wherein the trace data identifies at least one attribute that is shared among the respective hardware events occurring across the distributed processor units.
  • the method further includes: detecting, by the computing system, that one of: a second parameter value of the operand exceeds a second bound value of the register, or a second predefined time value indicated by the current time exceeds a second bound value of the register; and responsive to detecting, stopping, by the computing system, the second trace event when the second parameter value of the operand exceeds the second bound value, or when the second predefined time value exceeds the second bound value.
  • the operand further includes at least one of: a parameter indicating a particular sequence step of the program code; or a global control parameter that indicates a particular performance state of the distributed processor units; and the predefined time value includes at least one of: a particular time value indicated by a global time clock of the distributed processor units; or a particular time value of a predefined time window associated with the global time clock.
  • the operand has a first binary data structure and the first parameter value of the first operand corresponds to a trace-mark
  • the predefined time value has a second binary data structure and the current time is indicated by a global time clock
  • the global time clock is used by the distributed processor units to generate one or more hardware event time stamps.
  • the method further includes: inserting, by a compiler of the computing system, the operand of the trigger condition into at least the first portion of program code executed by the first processor component; and inserting, by the compiler of the computing system, at least one predefined time value of the trigger condition into at least the second portion of program code executed by the second processor component.
  • initiating at least one of the first trace event or the second trace event includes: generating, by the computing system, a first control signal received by a first count register of the first processor core, the first control signal causing data associated with a first hardware event to be stored in the first count register; and generating, by the computing system, a second control signal received by a second count register of the second processor core, the second control signal causing data associated with a second hardware event to be stored in the second count register.
  • the data associated with one of the first hardware event or the second hardware event comprises at least one of: a number of bytes written to a particular memory buffer of a particular processor core of the distributed processor units; or a number of instructions executed by a particular processor core of the distributed processor units.
  • the method further includes: identifying, by the computing system, an occurrence of a second operand in at least a portion of the program code executed by the first or second processor components, the second operand including a second parameter value; determining, by the computing system, that a filter condition is satisfied based on the second parameter value of the second operand one of: exceeding a particular bound value of a register or being below a particular bound value of the register; and responsive to determining that the filter condition is satisfied, filtering, by the computing system, one or more trace events, wherein filtering the one or more trace events comprises precluding storage of trace data associated with one or more hardware events.
  • a hardware event collection system including: one or more processors including one or more processor cores; one or more machine-readable storage units for storing instructions that are executable by the one or more processors to perform operations comprising: monitoring execution of program code by a first processor component, the first processor component being configured to execute at least a first portion of the program code; and monitoring execution of the program code by a second processor component, the second processor component being configured to execute at least a second portion of the program code.
  • the method further includes, detecting, by a computing system, that a trigger condition is satisfied based on at least one of: i) identifying an occurrence of an operand in at least the first portion of the program code or the second portion of the program code, the operand including a first parameter value used to initiate one or more trace events, or ii) determining that a current time of at least one clock of the computing system indicates a predefined time value used to initiate one or more trace events.
  • the method includes, initiating, by the computing system, at least a first trace event that generates trace data, the trace data identifying respective hardware events occurring across distributed processor units that include at least the first processor component and the second processor component. For each of the respective hardware events, the trace data comprises at least a hardware event time stamp. The method further includes, using, by the computing system, the trace data to generate a correlated set of trace data that indicates at least a time ordered sequence of the respective hardware events that are generated when the trigger condition is satisfied.
  • one innovative aspect of the subject matter described in this specification can be embodied in a computer-implemented method executed by one or more processors, the method including, monitoring execution of program code by a processor component, the processor component being configured to execute at least a first portion of the program code.
  • the method further includes, detecting, by a computing system, that a trigger condition is satisfied based on at least one of: i) identifying an occurrence of an operand in at least the first portion of the program code, the operand including a first parameter value used to initiate one or more trace events, or ii) determining that a current time of at least one clock of the computing system indicates a predefined time value used to initiate the one or more trace events.
  • the method further includes, generating, by the computing system, a control signal received by a count register of the processor component, the control signal causing count data associated with a hardware event to be stored in the count register; and generating, by the computing system, a data structure that indicates one or more performance attributes associated with the executing program code, the data structure being generated based on one or more count parameters of the stored count data.
  • the count register is one of multiple performance counters configured to store count data about the performance of one or more processor components of the computing system, and wherein at least one performance counter includes one of: an activity counter, a stall counter, statistical counter, or a sampling counter.
  • the one or more count parameters indicates one of: i) a number of instructions received by a particular processor component; ii) a number of instructions processed by the particular processor component; iii) a number of instructions executed by the particular processor component; or iv) a number of memory reads, or a number of memory writes, performed by the particular processor component.
  • a performance attribute associated with the executing program code comprises one of: i) a stall frequency of a particular processor component executing the program code; ii) an indication that utilization of the particular processor component is below a threshold utilization; or iii) an indication that a data storage queue used by the particular processor component is at, or below, a queue occupancy threshold.
  • implementations of this and other aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.
  • a system of one or more computers can be so configured by virtue of software, firmware, hardware, or a combination of them installed on the system that in operation cause the system to perform the actions.
  • One or more computer programs can be so configured by virtue of having instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
  • the subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages.
  • the described hardware tracing system enhances computational efficiency by using dynamic triggers that execute through hardware knobs/features.
  • the triggers enable synchronized capture of events based, in part, on a global time counter, embedded logical operands, and hardware registers, rather than purely through coded sequences which typically require system resources to monitor and execute event capture.
  • system memory use is optimized when hardware triggers are tuned to capture short duration events and synchronized global captures that occur simultaneously instead of as uncorrelated inefficient event captures. Controls for shorter duration synchronized event capture mitigates information overload thereby enabling some memory resources to remain unused and available for other system processes.
  • a computing system monitors execution of program code executed by a first processor core and execution of program code executed by a second processor core.
  • the computing system stores a timeline of hardware events in a memory buffer. The stored events occur across distributed processor units that include at least the first and second processor cores.
  • the timeline includes, for each of the hardware events, an event time stamp and metadata characterizing the hardware event.
  • the system generates a data structure including hardware events from the timeline.
  • the system stores the data structure in a memory bank of a host device and uses the data structure to assess performance of the program code executed by the first or second processor cores.
  • this specification describes approaches for hardware event tracing in a distributed computing system, shown in FIGS. 1-4 .
  • This specification further describes approaches for synchronized hardware event collection based on one or more trigger mechanisms, shown in FIGS. 5-7 .
  • aspects of the computing systems described in this specification relate at least to coordinated/synchronous collection of tracing data and event counting.
  • at least one aspect includes systems and methods for synchronized collection of hardware performance counter data and trace event data within a standalone as well as a distributed system.
  • Synchronized event collection enhances analysis of both performance data and debugging data of distributed program code. The enhanced analysis is achieved, in part, through correlation of events that occur in response to execution of connected software components/modules analyzed by system 100.
  • FIG. 1 illustrates a block diagram of an example computing system 100 for distributed hardware tracing.
  • distributed hardware system tracing corresponds to storage of events that occur within components and sub-components of an example processor micro-chip.
  • a distributed hardware system (or tracing system) corresponds to a collection of processor micro-chips that cooperate to execute respective portions of a software/program code configured for distributed execution amongst the collection of processor micro-chips.
  • different processor chips of system 100 can form respective nodes of the distributed hardware system.
  • a single processor chip can include one or more processor cores and hardware features that can each form respective nodes of the processor chip.
  • a processor chip in the context of a central processing unit (CPU), can include at least two nodes and each node can be a respective core of the CPU.
  • a processor chip in the context of a graphical processor unit (GPU), can include at least two nodes and each node can be a respective streaming multiprocessor of the GPU.
  • Computing system 100 can include multiple processor components.
  • the processor components can be at least one of a processor chip, a processor core, a memory access engine, or at least one hardware component of the overall computing system 100.
  • a processor component such as a processor core
  • a processor component can be a fixed-function component configured to execute at least one specific operation based on at least one issued instruction of the executing program code.
  • a processor component such as a memory access engine (MAE)
  • MAE can be configured to execute program code at a lower level of detail or granularity than program code executed by other processor components of system 100.
  • program code executed by a processor core can cause an MAE descriptor to be generated and transmitted/sent to the MAE. After receipt of the descriptor, the MAE can execute a data transfer operation based on the MAE descriptor.
  • data transfers executed by the MAE can include, for example, moving data to and from certain components of system 100 via certain data paths or interface components of the system, or issuing data requests onto an example configuration bus of system 100.
  • each tensor node of an example processor chip of system 100 can have at least two "front-ends" which can be hardware blocks/features that process program instructions.
  • a first front-end can correspond to first processor core 104
  • a second front-end can correspond to second processor core 106.
  • the first and second processor cores may also be described herein as first front-end 104 and second front-end 106.
  • a trace chain can be a specific physical data communication bus that trace entries can be put onto for transmission to an example chip manager within system 100.
  • Received trace entries can be data words/structures including multiple bytes and multiple binary values or digits.
  • the descriptor "word" indicates a fixed-sized piece of binary data that can be handled as a unit by hardware devices of an example processor core.
  • the processor chips of the distributed hardware tracing system are multi-core processors (i.e., having multiple cores) that each execute portions of program code in respective cores of the chip.
  • portions of program code can correspond to vectorized computations for inference workloads of an example multi-layer neural network. While in alternative implementations, portions of program code can correspond generally to software modules associated with conventional programming languages.
  • Computing system 100 generally includes a node manager 102, a first processor core (FPC) 104, a second processor core (SPC) 106, a node fabric (NF) 110, a data router 112, and a host interface block (HIB) 114.
  • system 100 can include a memory mux 108 that is configured to perform signal switching, multiplexing, and de-multiplexing functions.
  • System 100 further includes a tensor core 116 that includes FPC 104 disposed therein.
  • Tensor core 116 can be an example computational device configured to perform vectorized computations on multi-dimensional data arrays.
  • Tensor core 116 can include a vector processing unit (VPU) 118, that interacts with a matrix unit (MXU) 120, transpose unit (XU) 122, and reduction and permutation unit (RPU) 124.
  • VPU vector processing unit
  • MXU matrix unit
  • XU transpose unit
  • RPU reduction and permutation unit
  • computing system 100 can include one or more execution units of a conventional CPU or GPU, such as load/store units, arithmetic logic units (ALU's) and vector units.
  • ALU's arithmetic logic units
  • the components of system 100 collectively include a large set of hardware performance counters as well as support hardware that facilitates completion of tracing activity within the components.
  • program code executed by respective processor cores of system 100 can include embedded triggers used to simultaneously enable multiple performance counters during code execution.
  • detected triggers cause trace data to be generated for one or more trace events.
  • the trace data can correspond to incremental parameter counts that are stored in the counters and that can be analyzed to discern performance characteristics of the program code.
  • Data for respective trace events can be stored in an example storage medium (e.g., a hardware buffer) and can include a timestamp that is generated responsive to detection of the trigger.
  • trace data can be generated for a variety of events occurring within hardware components of system 100.
  • Example events can include inter-node and cross-node communication operations, such as direct memory access (DMA) operations and sync flag updates (each described in more detail below).
  • system 100 can include a globally synchronous timestamp counter generally referred to as Global Time Counter ("GTC").
  • GTC Global Time Counter
  • system 100 can include other types of global clocks, such as a Lamport Clock.
  • the GTC can be used for precise correlation of program code execution and performance of software/program code that executes in a distributed processing environment. Additionally, and related in part to the GTC, in some implementations system 100 can include one or more trigger mechanisms used by distributed software programs to start and stop data tracing in a distributed system in a highly coordinated manner.
  • a host system 126 compiles program code that can include embedded operands that trigger, upon detection, to cause capture and storage of trace data associated with hardware events.
  • host system 126 provides the compiled program code to one or more processor chips of system 100.
  • program code can be compiled (with embedded triggers) by an example external compiler and loaded to the to one or more processor chips of system 100.
  • the compiler can set one or more trace bits (discussed below) associated with certain triggers that are embedded in portions of software instructions.
  • the compiled program code can be a distributed software program that is executed by the one or more components of system 100.
  • Host system 126 can include a monitoring engine 128 configured to monitor execution of program code by one or more components of system 100.
  • monitoring engine 128 enables host system 126 to monitor execution of program code executed by at least FPC 104 and SPC 106.
  • host system 126 can monitor, via monitoring engine 128, performance of the executing code at least by receiving periodic timelines of hardware events based on generated trace data.
  • system 126 can include multiple hosts (or host subsystems) that are associated with multiple processor chips or chip cores of system 100.
  • cross-node communications may cause host system 126 to monitor data traffic at one or more intermediate "hops" as data traffic traverses a communication path between FPC 104 and an example third processor core/node.
  • FPC 104 and the third processor core may be the only cores executing program code at given time period.
  • a data transfer from FPC 104 to the third processor core can generate trace data for an intermediate hop at SPC 106 as data is transferred from FPC 104 to the third processor core.
  • data from a first processor chip going to a third processor chip may need to traverse a second processor chip, and so execution of the data routing operation may cause trace entries to be generated for routing activity in the second chip.
  • the components of system 100 can interact to generate timelines of hardware events that occur in a distributed computer system.
  • the hardware events can include intra-node and cross-node communication events.
  • Example nodes of a distributed hardware system and their associated communications are described in more detail below with reference to FIG. 2 .
  • a data structure is generated that identifies a collection of hardware events for at least one hardware event timeline.
  • the timeline enables reconstruction of events that occur in the distributed system.
  • event reconstruction can include correct event ordering based on analysis of time stamps generated during occurrence of a particular event.
  • an example distributed hardware tracing system can include the above described components of system 100 as well as at least one host controller associated with a host system 126. Performance or debugging of data obtained from a distributed tracing system can be useful when the event data is correlated in, for example, a time-ordered or sequenced manner.
  • data correlation can occur when multiple stored hardware events corresponding to connected software modules are stored and then sequenced for structured analysis by host system 126. For implementations including multiple host systems, correlation of data obtained via the different hosts may be performed, for example, by the host controller.
  • FPC 104 and SPC 106 are each distinct cores of a multi-core processor chip; while in other implementations, FPC and SPC 104, 106 are respective cores of distinct multi-core processor chips.
  • system 100 can include distributed processor units having at least FPC 104 and SPC 106.
  • distributed processor units of system 100 can include one or more hardware or software components configured to execute at least a portion of a larger distributed software program or program code.
  • Data router 112 is an inter-chip interconnect (ICI) providing data communication paths between the components of system 100.
  • router 112 can provide communication coupling or connections between FPC 104 and SPC 106, and between the respective components associated with cores 104, 106.
  • Node fabric 110 interacts with data router 112 to move data packets within the distributed hardware components and sub-components of system 100.
  • Node manager 102 is a high-level device that manages low-level node functions in multi-node processor chips. As discussed in more detail below, one or more nodes of a processor chip can include chip managers controlled by node manager 102 to manage and store hardware event data in local entry logs.
  • Memory mux 108 is a multiplexing device that can perform switching, multiplexing, and de-multiplexing operations on data signals provided to an example external high bandwidth memory (HBM) or data signals received from the external HBM.
  • HBM high bandwidth memory
  • an example trace entry (described below) can be generated, by mux 108, when mux 108 switches between FPC 104 and SPC 106.
  • Memory mux 108 can potentially impact performance of a particular processor core 104, 106 that is not able to access mux 108.
  • trace entry data generated by mux 108 can aid in understanding resulting spikes in latencies of certain system activities associated with the respective cores 104, 106.
  • hardware event data e.g., trace points discussed below
  • originating within mux 108 can be grouped, in an example hardware event timeline, along with event data for node fabric 110. Event grouping can occur when certain tracing activity causes event data for multiple hardware components to be stored in an example hardware buffer (e.g., trace entry log 218, discussed below).
  • performance analysis hardware encompasses FPC 104, SPC 106, mux 108, node fabric 110, data router 112, and HIB 114.
  • Each of these hardware components or units include hardware performance counters as well as hardware event tracing facilities and functions.
  • VPU 118, MXU 120, XU 122 and RPU 124 do not include their own dedicated performance hardware. Rather, in such implementations, FPC 104 can be configured to provide the necessary counters for VPU 118, MXU 120, XU 122 and RPU 124.
  • VPU 118 can include an internal design architecture that supports localized high bandwidth data processing and arithmetic operations associated with vector elements of an example matrix-vector processor.
  • MXU 120 is a matrix multiplication unit configured to perform, for example, up to 128x128 matrix multiplies on vector data sets of multiplicands.
  • XU 122 is a transpose unit configured to perform, for example, up to 128x128 matrix transpose operations on vector data associated with the matrix multiply operations.
  • RPU 124 can include a sigma unit and a permute unit.
  • the sigma unit executes sequential reductions on vector data associated with the matrix multiply operations. The reductions can include sums and various types of compare operations.
  • the permute unit can fully permute or replicate all elements of vector data associated with the matrix multiply operations.
  • program code executed by the components of system 100 can be representative of machine learning, neural network inference computations, and/or one or more direct memory access functions.
  • Components of system 100 can be configured to execute one or more software programs including instructions that cause a processing unit(s) or device(s) of the system to execute one or more functions.
  • the term "component" is intended to include any data processing device or storage device such as control status registers or any other device able to process and store data.
  • System 100 can generally include multiple processing units or devices that can include one or more processors (e.g., microprocessors or central processing units (CPUs)), graphics processing units (GPUs), application specific integrated circuits (ASICs), or a combination of different processors.
  • processors e.g., microprocessors or central processing units (CPUs)
  • GPUs graphics processing units
  • ASICs application specific integrated circuits
  • system 100 can each include other computing resources/devices (e.g., cloud-based servers) that provide additional processing options for performing computations related to hardware tracing functions described in this specification.
  • the processing units or devices can further include one or more memory units or memory banks (e.g., registers/counters). In some implementations, the processing units execute programmed instructions stored in memory to devices of system 100 to perform one or more functions described in this specification.
  • the memory units/banks can include one or more non-transitory machine-readable storage mediums.
  • the non-transitory machine-readable storage medium can include solid-state memory, magnetic disk, and optical disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (e.g., EPROM, EEPROM, or Flash memory), or any other tangible medium capable of storing information.
  • FIG. 2 illustrates a block diagram of example trace chains and respective example nodes 200, 201 used for distributed hardware tracing executed by system 100.
  • the nodes 200, 201 of system 100 can be different nodes within a single multi-core processor.
  • node 200 can be a first node in a first multi-core processor chip and node 201 can be a second node in a second multi-core processor chip.
  • system 100 can include multiple nodes.
  • cross-node data transfers can generate trace data at intermediate hops along an example data path that traverse multiple nodes.
  • intermediate hops can correspond to data transfers which pass through distinct nodes in a particular data transfer path.
  • trace data associated with ICI traces/hardware events can be generated for one or more intermediate hops that occur during cross-node data transfers which pass through one or more nodes.
  • node 0 and node 1 are tensor nodes used for vectorized computations associated with portions of program code for inference workloads.
  • a tensor is a multi-dimensional geometric object and example multi-dimensional geometric objects include matrices and data arrays.
  • node 200 includes a trace chain 203 that interacts with at least a subset of the components of system 100.
  • node 201 includes a trace chain 205 that interacts with at least a subset of the components of system 100.
  • nodes 200, 201 are example nodes of the same subset of components, while in other implementations, nodes 200, 201 are respective nodes of distinct component subsets.
  • Data router/ICI 112 includes a trace chain 207 that generally converges with trace chains 203 and 205 to provide trace data to chip manager 216.
  • nodes 200, 201 can each include respective component subsets having at least FPC 104, SPC 106, node fabric 110, and HIB 114.
  • Each component of nodes 200, 201 includes one or more trace muxes configured to group trace points (described below) generated by a particular component of the node.
  • FPC 104 includes a trace mux 204
  • node fabric 110 includes trace muxes 210a/b
  • SPC 106 includes trace muxes 206a/b/c/d
  • HIB 214 includes trace mux 214
  • ICI 212 includes trace mux 212.
  • a trace control register for each trace mux allows individual trace points to be enabled and disabled.
  • their corresponding trace control registers can include individual enable bits as well as broader trace mux controls.
  • the trace control registers can be conventional control status registers (CSR) that receive and store trace instruction data.
  • CSR control status registers
  • tracing can be enabled and disabled based on CSR writes executed by system 100.
  • tracing can be dynamically started and stopped, by system 100, based on the value of a global time counter (GTC), based on the value of an example trace-mark register in the FPC 104 (or core 116), or based on the value of an example trace-mark register in SPC 106.
  • GTC global time counter
  • FPC 104 can use a trace control parameter to define a trace window associated with event activity occurring within core 116.
  • the trace control parameter allows the trace window to be defined in terms of lower and upper bounds for the GTC as well as lower and upper bounds for the trace-mark register.
  • system 100 can include functions that enable reduction of the number of trace entries that are generated, such as trace event filtering features.
  • FPC 104 and SPC 106 can each include filtering features which limit the rate at which each core sets a trace bit in an example generated trace descriptor (described below).
  • HIB 114 can include similar filtering features such as an example DMA rate limiter that limits trace bits associated with capture of certain DMA trace events. Additionally, HIB 114 can include controls (e.g., via an enable bit) for limiting which queues source DMA trace entries.
  • a descriptor for a DMA operation can have a trace bit that is set by an example compiler of host system 126.
  • the trace bit When the trace bit is set, hardware features/knobs that determine and generate trace data are used to complete an example trace event.
  • a final trace bit in the DMA can be a logical OR operation between a trace bit that is statically inserted by the compiler and a trace bit that is dynamically determined by a particular hardware component.
  • the compiler generated trace bit can provide a mechanism, apart from filtering, to reduce an overall amount of trace data that is generated.
  • a compiler of host system 126 may decide to only set trace bits for one or more remote DMA operations (e.g., a DMA across at least two nodes) and clear trace bits for one or more local DMA operations (e.g., a DMA within a particular tensor node, such as node 200). In this manner, an amount of trace data that is generated can be reduced based on tracing activity being limited to cross-node (i.e., remote) DMA operations, rather than tracing activity that includes both cross-node and local DMA operations.
  • At least one trace event initiated by system 100 can be associated with a memory access operation that includes multiple intermediate operations occurring across system 100.
  • a descriptor e.g., an MAE descriptor
  • a descriptor for the memory access operation can include a trace bit that causes data associated with the multiple intermediate operations to be stored in one or more memory buffers.
  • the trace bit can be used to "tag" intermediate memory operations and generate multiple trace events at intermediate hops of the DMA operation as data packets traverse system 100.
  • ICI 112 can include a set of enable bits and a set of packet filters that provide control functionality for each ingress and egress port of a particular component of node 200, 201. These enable bits and packet filters allow ICI 112 to enable and disable trace points associated with particular components of nodes 200, 201. In addition to enabling and disabling trace points, ICI 112 can be configured to filter trace data based on event source, event destination, and trace event packet type.
  • each trace control register for processor cores 104, 106 and HIB 114 can also include an "everyone" trace mode.
  • This "everyone" trace mode can enable tracing across an entire processor chip to be controlled by either trace mux 204 or trace mux 206a. While in the everyone trace mode, traces muxes 204 and 206a can send an "in-window" trace control signal that specifies whether or not that particular trace mux, either mux 204 or mux 206a, is in a trace window.
  • the in-window trace control signal can be broadcast or universally transmitted to all other trace muxes, for example, within a processor chip or across multiple processor chips.
  • the broadcast to the other trace muxes can cause all tracing to be enabled when either mux 204 or mux 206a is executing tracing activity.
  • trace muxes associated with processor cores 104, 106, and HIB 114 each include a trace window control register that specifies when and/or how the "everyone trace" control signal is generated.
  • tracing activity in trace muxes 210a/b and trace mux 212 is generally enabled based on whether a trace bit is set in data words for DMA operations or control messages that traverses ICI/data router 112.
  • DMA operations or control messages can be fixed-size binary data structures that can have a trace bit within the binary data packets set based on certain circumstances or software conditions.
  • the trace bit will be set in that particular DMA.
  • control messages for data writes to another component within system 100 will have the trace bit set if FPC 104 is in a trace window and a trace point that causes trace data to be stored is enabled.
  • zero-length DMA operations provide an example of a broader DMA implementation within system 100.
  • some DMA operations can produce non-DMA activity within system 100.
  • Execution of the non-DMA activity can also be traced (e.g., generate trace data) as if the non-DMA activity were a DMA operation (e.g., DMA activity including non-zero-length operations).
  • a DMA operation initiated at a source location but without any data (e.g., zero-length) to be sent or transferred could instead send a control message to the destination location.
  • the control message will indicate that there is no data to be received, or worked with, at the destination, and the control message itself would be traced by system 100 as a non-zero-length DMA operation would be traced.
  • zero-length DMA operations can generate a control message, and a trace bit associated with the message is set only if the DMA would have had the trace bit set, i.e., had the control message not had a zero-length.
  • DMA operations initiated from host system 126 will have the trace bit set if HIB 114 is in a trace window.
  • trace chain 203 receives trace entry data for the component subset that aligns with node 0, while trace chain 205 receives trace entry data for the component subset that aligns with node 1.
  • Each trace chain 203, 205, 207 are distinct data communication paths used by respective nodes 200, 201 and ICI 112 to provide trace entry data to an example trace entry data log 218 of a chip manager 216.
  • the endpoint of trace chains 203, 205, 207 is chip manager 216 where trace events can be stored in example memory units.
  • At least one memory unit of chip manager 216 can be 128-bit wide and can have a memory depth of at least 20,000 trace entries. In alternative implementations, at least one memory unit can have a larger or smaller bit-width and can have a memory depth capable of storing more or fewer entries.
  • chip manager 216 can include at least one processing device executing instructions to manage received trace entry data. For example, chip manager 216 can execute instructions to scan/analyze time stamp data for respective hardware events of trace data received via trace chains 203, 205, 207. Based on the analysis, chip manager 216 can populate trace entry log 218 to include data that can be used to identify (or generate) a time-ordered sequence of hardware trace events.
  • the hardware trace events can correspond to movement of data packets occurring at the component and sub-component level when processing units of system 100 execute an example distributed software program.
  • hardware units of system 100 may generate trace entries (and corresponding timestamps) that populate an example hardware trace buffer in a non-time-ordered manner (i.e., out-of-order).
  • chip manager 216 can cause multiple trace entries, having generated time-stamps, to be inserted into entry log 218. Respective trace entries, of the multiple inserted trace entries, may not be time-ordered relative to one another.
  • non-time-ordered trace entries can be received by an example host buffer of host system 126.
  • host system 126 can execute instructions relating to performance analysis/monitoring software to scan/analyze time stamp data for the respective trace entries. The executed instructions can be used to sort the trace entries and to construct/generate a timeline of hardware trace events.
  • trace entries can be removed from entry log 218 during a tracing session via a host DMA operation.
  • host system 126 may not DMA entries out of trace entry log 218 as quickly as they are added to the log.
  • entry log 218 can include a predefined memory depth. If the memory depth limit of entry log 218 is reached, additional trace entries may be lost. In order to control which trace entries are lost, entry log 218 can operate in first-in-first-out (FIFO) mode, or, alternatively, in an overwrite recording mode.
  • FIFO first-in-first-out
  • the overwrite recording mode can be used, by system 100, to support performance analysis associated with post-mortem debugging.
  • program code can be executed for a certain time-period with tracing activity enabled and overwrite recording mode enabled.
  • monitoring software executed by host system 126 can analyze the data contents of an example hardware trace buffer to gain insight into hardware events that occurred before the program crash.
  • post-mortem debugging relates to analysis or debugging of program code after the code has crashed or has generally failed to execute/operate as intended.
  • trace entries are moved to a memory of host system 126 in response to a DMA operation using processing features of HIB 114.
  • a trace point is the generator of a trace entry and data associated with the trace entry received by chip manager 216 and stored in trace entry log 218.
  • a multi-core multi-node processor microchip can include three trace chains within the chip such that a first trace chain receives trace entries from a chip node 0, a second trace chain receives trace entries from a chip node 1, and a third trace chain receives trace entries from an ICI router of the chip.
  • Each trace point has a unique trace identification number, within its trace chain, that it inserts into the header of the trace entry.
  • each trace entry identifies the trace chain it originated from in a header indicated by one or more bytes/bits of the data word.
  • each trace entry can include a data structure having defined field formats (e.g., header, payload, etc.) that convey information about a particular trace event.
  • Each field in a trace entry corresponds to useful data applicable to the trace point that generated the trace entry.
  • each trace entry can be written to, or stored within, a memory unit of chip manager 216 associated with trace entry log 218.
  • trace points can be enabled or disabled individually and multiple trace points can generate the same type of trace entry although with different trace point identifiers.
  • each trace entry type can include a trace name, trace description, and a header that identifies encodings for particular fields and/or a collection of fields within the trace entry.
  • the name, description, and header collectively provide a description of what the trace entry represents. From the perspective of chip manager 216, this description can also identify the particular trace chain 203, 205, 207 that a specific trace entry came in on within a particular processor chip.
  • fields within a trace entry represent pieces of data (e.g., in bytes/bits) relevant to the description and can be a trace entry identifier used to determine which trace point generated a particular trace entry.
  • trace entry data associated with one or more of the stored hardware events can correspond, in part, to data communications that occur: a) between at least a node 0 and node 1; b) between at least components within node 0; and c) between at least components within node 1.
  • stored hardware events can correspond, in part, to data communications that occur between at least one of: 1) FPC 104 of node 0 and FPC 104 of node 1; FPC 104 of node 0 and SPC 106 of node 0; 2) SPC 106 of node 1 and SPC 106 of node 1.
  • FIG. 3 illustrates a block diagram of an example trace mux design architecture 300 and an example data structure 320.
  • Trace mux design 300 generally includes a trace bus input 302, a bus arbiter 304, and a local trace point arbiter 306, a bus FIFO 308, at least one local trace event queue 310, a shared trace event FIFO 312, and a trace bus out 314.
  • Mux design 300 corresponds to an example trace mux disposed within a component of system 100.
  • Mux design 300 can include the following functionality.
  • Bus in 302 can relate to local trace point data that is temporarily stored within bus FIFO 308 until such that time arbitration logic (e.g., arbiter 304) can cause the trace data to be placed unto an example trace chain.
  • time arbitration logic e.g., arbiter 304
  • One or more trace points for a component can insert trace event data into at least one local trace event queue 310.
  • Arbiter 306 provides first level arbitration and enables selection of events from among the local trace events stored within queue 310. Selected events are place in shared trace event FIFO 312 which also functions as a storage queue.
  • Arbiter 304 provides second level arbitration that receives local trace events from FIFO queue 312 and merges the local trace events onto a particular trace chain 203, 205, 207 via trace bus out 314.
  • trace entries may be pushed into local queues 310 faster than they can be merged to shared FIFO 312, or, alternatively, trace entries may be pushed into shared FIFO 312 faster than they can be merged onto trace bus 314. When these scenarios occur, the respective queues 310 and 312 will become full with trace data.
  • system 100 when either queue 310 or 312 becomes full with trace data, system 100 can be configured so that the newest trace entries are dropped and not stored to, or merged to, a particular queue. In other implementations, rather than dropping trace entries when certain queues fill up (e.g., queues 310, 312), system 100 can be configured to stall an example processing pipeline until queues that are filled once again have available queue space to receive entries.
  • a processing pipeline that uses queues 310, 312 can be stalled until a sufficient, or threshold, number of trace entries are merged onto trace bus 314.
  • the sufficient or threshold number can correspond to a particular number merged trace entries that result in available queue space for one or more trace entries to be received by queues 310, 312. Implementations in which processing pipelines are stalled, until downstream queue space becomes available, can provide higher-fidelity trace data based on certain trace entries being retained rather than dropped.
  • local trace queues are as wide as required by the trace entry, such that each trace entry takes only one spot in local queue 310.
  • shared trace FIFO queue 312 can use a unique trace entry line encoding such that some trace entries can occupy two locations in shared queue 312.
  • the full packet is dropped so that no partial packets appear in trace entry log 218.
  • a trace is a timeline of activities or hardware events associated with a particular component of system 100. Unlike performance counters (described below), which are aggregate data, traces contain detailed event data that provide insight into hardware activity occurring during a specified trace window.
  • the described hardware system enables extensive support for distributed hardware tracing, including generation of trace entries, temporary storage of trace entries in hardware managed buffer, static and dynamic enabling of one or more trace types, and streaming of trace entry data to host system 126.
  • traces can be generated for hardware events executed by components of system 100, such as, generating a DMA operation, executing a DMA operation, issuing/execution of certain instructions, or updating sync flags.
  • tracing activity can be used to track DMAs through the system, or to track instructions executing on a particular processor core.
  • System 100 can be configured to generate at least one data structure 320 that identifies one or more hardware events 322, 324 from a timeline of hardware events.
  • data structure 320 arranges one or more hardware events 322, 324 in a time ordered sequence of events that are associated with at least FPC 104 and SPC 106.
  • system 100 can store data structure 320 in a memory bank of a host control device of host system 126.
  • Data structure 320 can be used to assess performance of program code executed by at least processor cores 104 and 106.
  • a particular trace identification (ID) number (e.g., trace ID '003) can be associated with multiple hardware events that occur across the distributed processor units.
  • the multiple hardware events can correspond to a particular memory access operation (e.g., a DMA), and the particular trace ID number is used to correlate one or more hardware events.
  • a single trace ID for a DMA operation can include multiple time steps corresponding to multiple different points in the DMA.
  • trace ID '003 can have an "issued” event, an "executed” event, and a "completed” event that are identified as being some time apart relative to each other.
  • the trace ID can be further used for determining a latency attribute of the memory access operation based on the correlation and with reference to the time steps.
  • generating data structure 320 can include, for example, system 100 comparing event time stamps of respective events in a first subset of hardware events with event time stamps of respective events in a second subset of hardware events. Generating data structure 320 can further include, system 100 providing, for presentation in the data structure, a correlated set of hardware events based, in part, on the comparison between the first subset of events and the second subset of events.
  • data structure 320 can identify at least one parameter that indicates a latency attribute of a particular hardware event 322, 324.
  • the latency attribute can indicate at least a duration of the particular hardware event.
  • data structure 320 is generated by software instructions executed by a control device of host system 126.
  • structure 320 can be generated responsive to the control device storing trace entry data to a memory disk/unit of host system 126.
  • FIG. 4 is a block diagram 400 indicating example trace activity for a direct memory access (DMA) trace event executed by system 100.
  • DMA direct memory access
  • data for an example DMA operation originating from a first processor node to a second processor node can travel via ICI 112 and can generate intermediate ICI/router hops along the data path.
  • the DMA operation will generate trace entries at each node within a processor chip, and along each hop, as the DMA operation traverses ICI 112. Information is captured by each of these generated trace entries to reconstruct a temporal progression of the DMA operations along the nodes and hops.
  • An example DMA operation can be associated with the process steps depicted in the implementation of FIG. 4 .
  • a local DMA transfers data from a virtual memory 402 (vmem 402) associated with at least one of processor cores 104, 106 to HBM 108.
  • the numbering depicted in diagram 400 correspond to the steps of table 404 and generally represents activities in node fabric 110 or activities initiated by node fabric 110.
  • the steps of table 404 generally describe associated trace points.
  • the example operation will generate six trace entries for this DMA.
  • Step one includes the initial DMA request from the processor core to node fabric 110 which generates a trace point in the node fabric.
  • Step two includes a read command in which node fabric 110 asks the processor core to transfer data which generates another trace point in node fabric 110.
  • the example operation does not have a trace entry for step three when vmem 402 completes a read of node fabric 110.
  • Step four includes node fabric 110 performing a read resource update to cause a sync flag update in the processor core which generates a trace point in the processor core.
  • Step five includes a write command in which node fabric 110 notifies memory mux 108 of the forthcoming data to be written to the HBM. The notification via the write command generates a trace point in node fabric 110, while at step six, completion of the write to HBM also generates a trace point in node fabric 110.
  • node fabric 110 performs a write resource update to cause a sync flag update in the processor core which generates a trace point in the processor core (e.g., in FPC 104).
  • node fabric 110 can perform an acknowledge update ("ack update") where data completion for the DMA operation is signaled back to the processor core.
  • the ack update can generate trace entries that are similar to trace entries generated by the write resource update.
  • a first trace entry is generated when a DMA instruction is issued in a node fabric 110 of the originating node. Additional trace entries can be generated in node fabric 110 to capture time used to read data for the DMA and writing the data to outgoing queues.
  • node fabric 110 can packetize DMA data into smaller chunks of data. For data packetized into smaller chunks, read and write trace entries can be produced for a first data chunk and a last data chunk. Optionally, in addition to the first and last data chunks, all data chunks can be set to generate trace entries.
  • the first data and the last data chunk can generate additional trace entries at ingress and egress points in each intermediate hop along ICI/router 112.
  • trace entries similar to the previous node fabric 110 entries are generated (e.g., read/write of first and last data chunks) at the destination node.
  • a final step of the DMA operation can include executed instructions associated with the DMA causing an update to a sync flag at the destination node. When the sync flag is updated a trace entry can be generated indicating completion of the DMA operation.
  • DMA tracing is initiated by FPC 104, SPC 106, or HIB 114 when in each component is in trace mode such that trace points can be executed.
  • Components of system 100 can enter trace mode based on global controls in FPC 104 or SPC 106 via a trigger mechanism.
  • the trace points trigger in response to the occurrence of a specific action or condition associated with execution of program code by the components of system 100.
  • portions of the program code can include embedded trigger functions that are detectable by at least one hardware component of system 100.
  • the components of system 100 can be configured to detect a trigger function associated with portions of program code executed by at least one of FPC 104 or SPC 106.
  • the trigger function can correspond to at least one of: 1) a particular sequence step in a portion or module of the executed program code; or 2) a particular time parameter indicated by the GTC used by the distributed processor units of system 100.
  • a particular component of system 100 can initiate, trigger, or execute at least one trace point (e.g., a trace event) that causes trace entry data associated with one or more hardware events to be stored in at least one memory buffer of the hardware component.
  • trace point e.g., a trace event
  • stored trace data can then be provided to chip manager 216 by way of at least one trace chain 203, 205, 207.
  • FIGS. 1-4 have illustrated approaches for hardware event tracing in a distributed computing system.
  • FIGS. 5-7 describe approaches for synchronized hardware event collection in a distributed computing system.
  • the synchronized collection of hardware events can be based, at least in part, on one or more trigger mechanisms.
  • FIG. 5 illustrates an example data structure for a global time counter (GTC) 502 and tables 504 and 506 that indicate usage scenarios of the GTC 502 by an example computing system for distributed hardware tracing (e.g., system 100).
  • GTC 502 is a 64-bit value that includes a 60-bit counter and a 4-bit offset.
  • GTC 502 can be a fixed-sized piece of binary data having a size, in bits, that ranges from fewer than 64 bits to more than 64 bits.
  • the data structure associated with GTC 502 applies to a global master counter as well as to local time counters (LTCs) described below with reference to the implementation of FIG. 6 .
  • the upper 60 bits of GTC 502 correspond to an actual time counter that increments by one per cycle, except when "catching up” or “catching down” to address GTC phase variations (described below).
  • LTC local time counter
  • the local GTC 502 it is possible for the local GTC 502 to not "tick" for several cycles in order to "catch-down" to a master global GTC 502.
  • the lower four "offset" bits are used to compensate for GTC phase variations that can occur during program code execution.
  • the last four bits can be incremented in these circumstances to, in part, maintain differentiation between timestamps for local hardware event activities whose GTC's would otherwise be identical.
  • the 4-bit offset of GTC 502 are clear and, thus, unused.
  • the offset bits can count up to 15 and then stop. While, in alternative implementations, the offset bits can count to any integer value as needed by a particular counter design. In some instances, the offset bits are cleared when the upper 60 bits of GTC 502 start ticking again.
  • the executed program code can configure or set-up a GTC by configuring one or more processor chips of system 100.
  • Configuring the processor chips can include designating a global master GTC for the system as well as designating local master GTCs (i.e., LTCs) for respective nodes or components of system 100.
  • the components can include hardware knobs/features that executing program code/software uses to compute and compensate for clock latencies and to perform manual tuning of one or more local GTCs (i.e., LTCs of FIG. 6 ). LTC compensation for clock latencies and manual tuning are preformed relative to the master GTC, so as to minimize or mitigate phase variations.
  • system 100 can include an auto-pilot mode for latency compensation in which component hardware features determine link latencies automatically by way of a "ping-and-echo" mechanism.
  • system 100 can include a link/software stack that includes a portion, or subset, of program code used to adjust parameter values of an example control/status register (CSR).
  • CSR control/status register
  • control signals generated in response to execution of the link stack program code causes one or more parameter values to written to the CSR.
  • CSR parameter values can be used to configure various aspects of GTC 502, 602 or LTCs.
  • the one or more parameters can include: 1) a GTC_config parameter that causes selection of a master global GTC, local master GTC, or a local slave GTC and selection of an update sample size; 2) a GTC_sync parameter used to reset a master GTC or clear a "ping" measurement; 3) a GTC_latency_compensation_control parameter that configures manual latency compensations; 4) a GTC_link_ping parameter that indicates a minimum ping latency; 5) a GTC_count parameter that indicates an actual GTC value; and/or 6) a GTC_max_diff parameter that indicates a maximum observed difference between a local GTC and the master GTC.
  • a global master GTC 502 and one or more local GTCs 502 can be used by system 100 to obtain event time-stamps and to determine sequenced ordering among hardware events occurring within in the system.
  • GTC 502 can be used to determine latencies of activities.
  • a particular GTC 502 can exhibit phase variations, hence, determined latencies may be inaccurate by one or more cycles.
  • the rate at which a certain GTC 502 increments can vary depending upon whether a local GTC is different from the global master, i.e., when there are phase variations.
  • a master global GTC 502 increments once per cycle and can be used to count latencies and order of local activities (e.g., of a certain component) just as well as a particular components LTC.
  • a master GTC 502 may count slower than a certain LTC. In these instances, the offset bits of GTC 502 continue to increment once per local clock cycle.
  • an extended GTC (“GTC-ext") can be defined for use by system 100.
  • GTC-ext can be constructed by adding the top 60 bits (GTC:top) and the bottom four offset bits (GTC:offset), while in other implementations, the program code executing in a particular processor can compute GTC-ext to equal GTC:top summed with a fractional GTC:offset value.
  • a GTC-ext parameter can be used to determine event ordering as well as latencies of local operations.
  • Tables 504, 506 indicate usage scenarios in which the GTC-ext parameter may prove useful when determining hardware event ordering and latency of event operations.
  • Table 504 describes example GTC usage for determining order between activities or hardware events.
  • the rate at which a GTC 502 increments, during the course of an activity being analyzed may not be relevant when using GTC 502 to determine global order, e.g., the order of one or more activities between at least two distinct computing nodes (e.g., distinct nodes that each have a master GTC).
  • GTC-ext can be used to differentiate between two local activities, or between when two local activities initiate writes to remote resources, as shown by feature 508 of table 504.
  • Table 506 describes example GTC usage for computing latency of local activities/events or activities that span two or more nodes.
  • system parameters may not indicate whether a GTC 502 at a particular chip is ticking at a normal rate (i.e., in sync with a designated master global clock) or ticking at a rate that is off-phase with the designated master global.
  • LTC can used for event latency determination of local activities, as shown by feature 510 of table 506. While, in other implementations, GTC or GTC-ext can be used to measure latencies of one or more operations.
  • hardware trace events that occur at various nodes or components of system 100 can include a GTC parameter.
  • GTC when traced hardware events/activities span multiple nodes of system 100, latencies associated with local activities should be computed via GTC rather than a LTC.
  • use of GTC or GTC-ext can be the preferred counter/clock solution because LTC's across two or more distinct nodes may not be synchronized or clocking/ticking at the same rate.
  • FIG. 6 illustrates a block diagram of example time counters and one or more counters associated with respective components of an example computing system for distributed hardware tracing (e.g., system 100).
  • the time counters can include global time counter (GTC) 602 and multiple local time counters (LTC) that are each associated with respective components of system 100.
  • GTC global time counter
  • LTC local time counters
  • FIG. 6 depicts a single LTC block coupled to particular components of system 100, in alternative implementations, each component can include one or multiple local time counters/LTCs.
  • FIG. 6 depicts a single master GTC 602, this feature can also correspond to, or be representative of a particular LTC that is selected to function as the global master.
  • GTC 602 corresponds to counter selection logic implemented by host system 126 to select a particular LTC to function as a global master clock/counter.
  • system 100 can select an example node of ICI 112 to function as a global master clock and the example node's LTC ticks by one per clock cycle.
  • GTC 602 is a global time counter that functions as a global master clock and that broadcasts a particular time parameter to the components of system 100.
  • GTC 602 can be a globally synchronous clock used to correlate hardware events that occur across system 100.
  • GTC 602 can have small phase variations across system 100, but can be configured to avoid long term time-drift.
  • GTC 602 can tick or count based on an example oscillator of a particular processor chip (e.g., an oscillator selected to be the global master).
  • an oscillator of a particular processor chip e.g., an oscillator selected to be the global master.
  • GTC 602 may increment (i.e., tick) faster or slower than a local clock (LTC) at a processor chip that is not the global master.
  • LTC local clock
  • a current master value of GTC 602 can be broadcast out to all nodes of ICI 112.
  • Example ICI nodes can correspond to the one or more components of system 100.
  • Receiving nodes can compute a difference between its local value of an example GTC used for local operations specific to the particular component/node. A minimum difference between the received master value and the local GTC value over an example sampling period can be used to update the local GTC. Over time, phase variations between the master value and the local GTC values, if any, may be "caught-up" based on counter adjustments implemented using the one or more offset bits discussed above.
  • components of system 100 can each include one or more performance counters, and collective sets, or subsets, of performance counters within system 100 are described herein as multiple counters 600.
  • FPC 104 can include multiple counters 604
  • SPC 106 can include multiple counters 606
  • mux memory (HBM) 108 can include multiple counters 608
  • node fabric 110 can include multiple counters 610
  • ICI 112 can include multiple counters 612
  • HIB 114 can include multiple counters 614.
  • performance analysis of program code executing by one or more processors can be enabled/disabled based on use of one or more hardware performance counters associated with particular components of the system.
  • These performance counters can correspond to the multiple respective counters of FIG. 6 and can include at least one of the following: 1) activity counters; 2) stall counters; 3) statistical counters; and 4) sampling counters.
  • system 100 includes various other types of performance counters that can programmed to increment and store specified count data associated with technical aspects of the executing program code.
  • hardware support for tracing activity can include functions related to, for example: capture of instruction tracing event data; capture of memory mux tracing event data; capture of DMA tracing event data; and capture of event data in trace buffers.
  • At least a subset of multiple counters 600 can be CSRs or count registers that are accessible by host system 126 via HIB 114.
  • These count registers/CSRs can be storage devices that are configured to store various types of count data/information that identifies instructions received, processed, or executed by a particular hardware component, as well as a variety of other types of data/information associated with technical aspects of executing program code.
  • the data is stored in the form counts or increments associated with particular instructions or processor operations (e.g., a count parameter).
  • multiple counters 600 of system 100 can correspond to hundreds or thousands of performance counters/count registers.
  • activity counters can be used to store and analyze data associated with utilization parameters for different hardware units. Activity counters can be also used to analyze portions of executing program code or to analyze quantities or types of data being transferred during code execution.
  • some processor cores can include activity counters that are used to derive instruction mix in various streams of instructions.
  • an activity counter can be configured to store counts associated with execution of particular instruction types in an example instruction stream.
  • activity counters can include sub-sets of counters such as: issue counters that are incremented upon issuance of certain instruction types; memory activity counters that are available on memory paths and that are incremented in response to, e.g., reads/writes associated with memory transfers between (e.g., between mux 108 and a VMEM 402); and one or more other general activity counters that are incremented in response to the occurrence of instructions such as interrupts, sync flags, and alarm counters.
  • issue counters that are incremented upon issuance of certain instruction types
  • memory activity counters that are available on memory paths and that are incremented in response to, e.g., reads/writes associated with memory transfers between (e.g., between mux 108 and a VMEM 402)
  • one or more other general activity counters that are incremented in response to the occurrence of instructions such as interrupts, sync flags, and alarm counters.
  • these counters can provide stall counts indicating a number of cycles a certain hardware unit/component was stalled due to a particular stall reason instead of doing useful work associated with instruction processing or data computations. For example, when utilization of a particular hardware unit is below a threshold utilization, or the program code is not performing at a desired threshold performance level, the stall counters can be used by, system 100, to obtain pertinent stall information for conducting root-cause analysis of utilization and performance issues (e.g., below threshold utilization/performance).
  • stall counters can provide pertinent information related to: stalls based on detection of certain normally available memory paths that are indicated as unavailable; stalls based on delayed execution of one or more sync flag instructions; and/or stalls due to one or more normally available execution units (e.g., XU 122 or RPU 124) that are indicated as unavailable.
  • normally available execution units e.g., XU 122 or RPU 124.
  • FPC 104 can include at least one scalar unit that provides scalar quantities for vectorized computations performed by VPU 118.
  • Stall counters associated with the scalar unit can provide pertinent information for stalls that are due to one or more hazards that can occur within the scalar unit.
  • various hazard types can occur and FPC 104 can include stall counters for each hazard type.
  • Example hazard types can include DMA delay hazards, scalar fence delay hazards, and/or scalar delay instruction hazard.
  • components of system 100 can include one or more data queues (e.g., storage mediums) and activity counters can be configured to provide information related to queue utilization.
  • activity counters for the queues may not be sufficient to provide all information about how well queues are being utilized by executing program code.
  • statistical counters can be available in one or more components to acquire certain data counts such that computations relating to average queue occupancy and time spent in certain queues can be determined.
  • queue statistical counters can provide statistical counts relating to queue occupancy, queue insertion status, queue full status, or queue at threshold occupancy status. In some instances, when the queue statistical counter is active, an occupancy counter associated with a component queue is incremented based on the current occupancy of the queue in each processor/instruction cycle.
  • an active queue statistical counter when an active queue statistical counter provides counts relating to queue full status, the counter is incremented (e.g., by one) in cycles in which a queue is fully occupied. Further, when an active queue statistical counter provides counts relating to queue insertion status, the counter is incremented in response to data chunks being placed into (i.e., queue insertion) the queue. Further still, for queue at threshold occupancy status, the counter can increment (e.g., by one) in each cycle in which the current queue occupancy is greater than a particular queue threshold occupancy.
  • components of system 100 can include sets of sampling counters that can be periodically read from host system 126 to generate data structures (e.g., structures 320 or 620).
  • the data structures can include sampled statistics about hardware events, trace activity, or detailed data processing information for activities/events occurring in distributed processor units of system 100.
  • data structures generated based on sampled statistics can include, e.g., structure 320 (described above) or structure 620 (described below).
  • the generated data structures are used to build one or more monitoring tools used by monitoring engine 128, of host system 126, to analyze performance of program code executed by the components of system 100.
  • components of system 100 can initiate event tracing based on global controls associated with one or more trigger mechanisms.
  • multiple counters 600 can be enabled, disabled, or otherwise controlled to initiate trigger mechanisms that cause trace points to execute and generate trace entries including specific data related to one or more hardware events.
  • trace entries relating to hardware events are populated with event data based, at least in part, on counts data aggregated by one or more of the multiple counters 600 described above.
  • the global controls generally include use of CSR controls (i.e., specific CSR hardware features/knobs) as well as trigger mechanisms that permit counters to be incremented and that permit traces to be generated in a coordinated and synchronized manner.
  • CSR controls i.e., specific CSR hardware features/knobs
  • trigger mechanisms that permit counters to be incremented and that permit traces to be generated in a coordinated and synchronized manner.
  • coordinated and synchronized control can occur across the distributed processor units of system 100.
  • synchronized tracing can be enabled, in part, through use of a globally synchronous counter that is used as a global master clock (e.g., GTC 602).
  • system 100 triggers synchronized event tracing based on a particular time parameter indicated by a global time clock of the distributed processor units (e.g., time parameter 09:01.13).
  • system 100 can use global master clock values of GTC 602 as a trigger to start and stop all counters and tracing precisely for the duration of a certain operation.
  • an example software compiler of system 100 can embed or insert, within the executing program code, instructions including operands or parameter values for a trigger mechanism that is based on a specific predefined time window associated with GTC 602.
  • the predefined time window can include an example trace duration that has a trace event start-time (e.g., a first GTC 602 time parameter) and a trace event end-time (e.g., a second GTC 602 time parameter that is later in time than the first GTC time parameter).
  • the components of system 100 can include multiple performance counters 600.
  • performance counter controls can include mechanisms to enable and disable the counters, as well as, to clear the counters and to pause the counters.
  • some hardware units can include statistical counters that have associated selectors (e.g., CSRs) used to select a subset of hardware blocks within the hardware unit whose events are counted.
  • tracing can be enabled and disabled based on CSR writes executed by system 100. In some instances, tracing can be dynamically started and stopped, by system 100, based on the value of an example trace-mark (TM) register in FPC 104 (or core 116), or based on the value of an example TM register in SPC 106.
  • TM trace-mark
  • an example trace control parameter can be used to define a particular trace window.
  • the trace control parameter can permit trace windows to be defined in terms of lower and upper bounds of GTC 602 (e.g., start time & stop time clock values), and lower and upper bounds of an example trace-mark register in FPC 104 or an example trace-mark register in SPC 106.
  • program code executing within system 100 can include trigger processing logic for triggering trace events each processor cycle within one of FPC 104 or SPC 106.
  • the trigger logic is associated with a special "set trace-mark" instruction that can be inserted, by the executing software/program code, into one or more instruction streams.
  • the trigger logic when an example instruction to set a trace-mark is issued within FPC 104, can include analyzing a trace-mark operand of the instruction and comparing a parameter value of the operand to values of an example trace-mark window. This analysis and comparison is used to determine whether the operand parameter value is either equal to a lower bound value, or falls within the lower bound value and an upper bound value of a particular trace-mark window.
  • a trigger can be fired (e.g., trigger condition satisfied) and FPC 104 can enter a tracing or counting mode and enable one or more counters of multiple counters 604.
  • FPC 104 exits the tracing/counting mode when a subsequent "set trace-mark" instruction includes an operand parameter value that causes a stop counting trigger to fire based on the operand value being either equal to, or outside of, the upper bound of an example trace-mark window.
  • system 100 can detect that a trigger condition is satisfied based on at least one of: i) identifying an occurrence of an example trace-mark operand in at least a first portion of the executing program code.
  • the trace-mark operand can include a parameter value (e.g., a code step sequence/value) that is used to initiate one or more trace events and/or performance counting.
  • System 100 can also detect that a trigger condition is satisfied based on a determination that a current time GTC 602 indicates a predefined time value that is used to initiate one or more trace events and/or performance counting.
  • a processor component of system 100 can generate a control signal that is received by a count register of the processor component.
  • the control signal can cause various count data associated with one or more hardware events to be stored in the count register.
  • system 100 can be configured or programmed to generate, e.g., via host system 126, a data structure that indicates one or more performance attributes associated with the executing program code. For example, the data structure can be generated based on one or more count parameters of the stored count data.
  • the count register is one of multiple performance counters 600 configured to store count data about the performance of one or more processor components of the system 100.
  • the set trace-mark instruction can include a 32-bit trigger operand that identifies a distributed software construct (e.g., a computational step in an example neural network inference workload).
  • FPC 104 can include is a special purpose CSR, identified in the program code as "tracemark_limits.”
  • tracemark_limits identified in the program code as "tracemark_limits.”
  • 32-bit operands are described in this example code sequence, in alternative implementations, trigger operands or register limit operands/parameter values can be binary data structures having fewer than 32-bits or more than 32-bits.
  • This special purpose CSR can encode at least two 32-bit values.
  • a first encoded 32-bit value can correspond to a lower trace-mark limit used to start tracing/counting, while a second encoded 32-bit value can correspond to an upper trace-mark limit used to stop tracing/counting.
  • the first and second encoded values correspond to computational steps in a distributed software program/construct, such as an example neural network inference workload, or any other distributed program code.
  • the 32-bit operand value is compared to the first and second encoded values in the tracemark_limits register. Based on this comparison, if the trigger operand equals/matches, or has a higher value than, the start value (i.e., the first encoded value), performance analysis activity is triggered. Likewise, if the trigger operand matches, or has a higher value than, the stop value (i.e., the second encoded value), on-going performance analysis activity is stopped.
  • GTC 602 when GTC 602 is used as a trigger (e.g., for FPC 104 or SPC 106), the upper and lower bounds of example GTC/LTC trigger registers for a particular component can be evaluated against a current value of GTC 602. Hence, a current time parameter or value of GTC 602 can be compared to a lower bound of an example predefined time-window to execute tracing activity using a GTC trigger. Similarly, after execution of the GTC trigger to begin counting activity, a current time parameter or value of GTC 602 can be compared to the upper bound of the GTC trigger register to determine if GTC 602 matches, or falls outside of, the upper bound value. In response to GTC 602 at least matching the upper bound value, a stop counting trigger will fire to cause the component to exit counting mode.
  • a stop counting trigger will fire to cause the component to exit counting mode.
  • SPC 106 includes a counterpart to the set trace-mark instruction of FPC 104.
  • trigger processing logic for SPC 106 can function in the same, or substantially similar, manner as in FPC 104.
  • a trace-mark parameter can be included as an operand to one or more instructions issued by SPC 106.
  • trigger evaluation of the operand occurs at each instruction issue, and the evaluation logic can be substantially similar to the manner in which counting is enabled in FPC104 (e.g., using a trace-mark operand).
  • tracing is enabled.
  • the trace-mark operand included in the trace-mark instruction is outside of the lower and upper bounds of the trace window, tracing is disabled.
  • system 100 can include an "everyone" trace mode.
  • this everyone trace mode can cause tracing across an entire processor chip to be controlled by, for example, a control signal generated by a component of FPC 104 or SPC 106.
  • the control signal can be a global control parameter that indicates a particular performance state of the distributed processor units of system 100. In some instances, the particular performance state corresponds to the "everyone" trace mode.
  • one or more hardware components can be programmed or configured to initiate event tracing in response to activation of the "everyone" trace mode, or to simply disregard a propagating control signal indicating the everyone trace mode.
  • system 100 can include a signaling mechanism to propagate an everyone trace control signal, system 100 can also include mechanisms to cause at least one hardware component to ignore the control signal.
  • a user e.g., a performance analyst of system 100 may want to use HIB 114 to track data packets that indicate all host communications.
  • the user can insert, e.g., via an external compiler, an example program instruction to cause HIB 114 to enter an "always trace" mode, while also using the everyone trace mode to capture certain single step sequences of data from other hardware components of system 100.
  • HIB 114 can disregard the everyone trace control signal used to generate single step sequence trace data from other hardware components.
  • trace points can trigger in response to the occurrence of a specific action or condition relating to execution of program code by the components of system 100.
  • a distributed software program can include multiple software modules that each include shared or overlapping code sequences or steps.
  • processor cores 104, 106 can each receive and execute portions of a distributed software program and each program portion can include an example code sequence 1-100.
  • system 100 can be configured to include one or more trigger conditions/mechanisms that have, or that are based on, a particular sequence step of the distributed program code.
  • system 100 can be configured to trigger a trace point in response to each of processor cores 104, 106 arriving at a certain coded sequence/step (e.g., code sequence step 33) during code execution.
  • portions of the executed distributed program code can include embedded trigger functions that are detectable by at least one hardware component of system 100.
  • system 100 can be configured to detect that one or more trigger conditions are satisfied based identifying occurrences of operands in at least a portion of the program code executed by one of FPC 104 or SPC 106. Responsive to detecting that at least one trigger condition is satisfied, system 100 can initiate one or more trace events that generate trace entries/trace data or counts data.
  • the generated trace entries can include at least one attribute that is shared among respective hardware events occurring across the distributed processor units (e.g., a shared time stamp or code sequence step).
  • generated trace entries 622 can correspond to a synchronized trace event and the trace data can include unique trace identifiers for respective hardware events and a global hardware event time stamp (e.g., 09:01.13) shared among at least two respective hardware events.
  • a global hardware event time stamp e.g. 09:01.13
  • at least one attribute shared among respective hardware events can be the hardware event time stamp.
  • trace entries 624 at least one attribute that is shared among respective hardware events can be the code sequence or trace-mark step.
  • trace entries can include a timestamp header or field.
  • the timestamp header can include a 48-bit timestamp that identifies the time that the trace entry was generated. In some instances, the timestamp header can correspond to a low 48 bits of GTC 502.
  • a compiler of system 100 can insert one or more operands for multiple trigger conditions into portions of program code executed by example processor cores of system 100.
  • a compiler associated with FPC 104 can insert, or embed, one or more operands for trigger conditions into portions of program code executed by FPC 104.
  • a compiler associated with SPC 106 can insert, or embed, one or more operands for trigger conditions in portions of program code executed by SPC 106.
  • system 100 is configured to detect the one or more triggers conditions and, responsive to detecting the conditions, initiate at least one trace event.
  • initiating the at least one trace event can include system 100 providing, for example, a first control signal to a first performance counter/register (e.g., a CSR such as an activity counter) of FPC 104.
  • This first control signal can cause data associated with at least one hardware event to be stored in the first performance counter.
  • initiating the at least one trace event can further include system 100 providing, for example, a second control signal to a second performance counter/register (e.g., a CSR such as a statistic counter) of SPC 106.
  • This second control signal can cause data associated with at least one hardware event to be stored in the second performance counter.
  • the data associated with the at least one hardware event can include one of: 1) a number of bytes written to a particular memory buffer of a certain processor core of the distributed processor units of system 100; or 2) a number of instructions executed by a certain processor core of the distributed processor units of system 100.
  • the described tracing system includes hardware based trigger-action mechanisms.
  • the triggers can be configured early to fire based on software semantics.
  • operands for trigger conditions can be inserted or embedded at prologues and epilogues of software components (e.g., at functions, loop-headers, or other opportune places in a distributed software system).
  • the insertion of operands for trigger conditions is done by a compiler in system 100, while in other instances, triggers and trigger operands can be embedded/inserted by programmers prior to code execution by system 100, or can be embedded, during real-time code execution, by host system 126.
  • a condition indicating when the trigger is to fire can be setup across a distributed hardware system (e.g., in each chip/node of system 100) by performance analysis software executing on host system 126.
  • a distributed hardware system e.g., in each chip/node of system 100
  • performance analysis software executing on host system 126.
  • hardware tracing and performance counting is performed in a particular hardware unit, and similar trigger conditions are setup to stop trace data collection.
  • a trigger in system 100 can be a monotonically increasing value that is an operand to an instruction.
  • the instruction can be inserted at prologues and epilogues of important software constructs by an example compiler of a processor core.
  • a trigger condition can be setup by writing to an example register in a hardware component. For evaluating or detecting the trigger, each time a trigger instruction is encountered, the hardware component can compare the value in this register with the operand value of the trigger condition in the instruction.
  • a trigger condition should be setup well in advance of certain coded sequence steps such that none of the processor chips/nodes in the distributed system will pre-maturely arrive at the trigger condition.
  • hardware trigger implementation requires propagating a trigger signal within different components of an example processor chip/node.
  • At least one benefit of the trigger-action mechanism enables a distributed software program to execute an activity (e.g., code sequence step 33) on a first node at a time very different from a related activity (e.g., code sequence step 33) at another (second) node.
  • system 100 can maintain accurate collection of hardware performance data for identical or substantially related activities that are executed by different hardware components or processor nodes at different time periods.
  • an example trigger use case can include system 100 collecting multiple sets of trace data without reprogramming, resetting, or reinserting a particular trigger condition.
  • the executing program code can include software constructs that generate an instruction sequence in which the same operand to set a trace-mark appears multiple times.
  • the same set trace-mark operand can appear multiples times when a processor of system 100 executes a certain portion of the program code in a loop.
  • event tracing can begin and end in accordance with iterations of the program loop.
  • a trigger condition can be satisfied, e.g., trigger fires and event tracing starts, based on an operand value that appears at the beginning of a loop iteration.
  • a trigger condition can be no longer satisfied, e.g., event tracing stops, based on an operand value that appears at the end of the loop iteration.
  • the beginning of a loop iteration and the end of a loop iteration can correspond to boundaries of a program loop for a given software construct.
  • a tracing session can begin and end at each execution of the software construct (e.g., each loop iteration).
  • appropriate trigger operand values can be determined in the following manner.
  • a distributed software program can include software modules that each include shared or overlapping code sequences or steps.
  • a performance analyst can read or analyze, via a computing console of system 100, a CSR value of a trace-mark register to determine, for example, a current code sequence or step number.
  • the analyst repeatedly reads the CSR value to determine an average rate of increase of the sequence or steps.
  • the determined rate of increase can be used to predictively set one or more triggers conditions based on occurrences of, e.g., a trace-mark operand values.
  • a performance analyst can read or analyze the system/machine (or hardware component) clock speed to predict or determine a rate at which the GTC increases. The analyst can then use the determined rate to set one or more trigger conditions based on an occurrence of a particular GTC value.
  • FIG. 7 is a process flow diagram of an example process 700 for distributed hardware tracing using computing system 100 and the one or more nodes 200, 201 of system 100.
  • process 700 can be implemented using one or more of the above-mentioned computing resources of systems 100 including resources of nodes 200, 201.
  • Process 700 begins at block 702 and includes computing system 100 monitoring execution of program code executed by a first processor core.
  • the first processor core is configured to execute at least a first portion of the program code that is monitored.
  • system 100 monitors execution of the program code executed by a second processor core.
  • the second processor core is configured to execute at least a second portion of the program code that is monitored.
  • system 100 detects that at least one trigger condition is satisfied. In some implementations, system 100 detects that the trigger condition is satisfied based on identifying an occurrence of an operand in at least a portion of the program code executed by one of the first processor core or the second processor core. In some implementations, program code executing within system 100 includes trigger processing logic for triggering trace events.
  • the trigger logic is associated with a "set trace-mark" instruction that is inserted into one or more instruction streams.
  • the trigger logic can include identifying the occurrence of a trace-mark operand of the instruction, analyzing the trace-mark operand, and comparing the operand to values of an example trace-mark window. In some instances, this analysis and comparison is used to detect that the first trigger condition is satisfied.
  • the trigger logic is associated with a predefined time value that can be inserted into one or more instruction streams an external user of system 100 or by an example compiler of the system.
  • the trigger logic can include determining that a current time of at least one clock of the computing system indicates a predefined time value used to initiate one or more trace events.
  • determining that the current time indicates a predefined time value can include receiving the predefined time value and comparing the predefined time value to time values of an example predefined time window.
  • system 100 initiates at least a first trace event that generates trace data.
  • the generated trace data identifies respective hardware events occurring across distributed processor units that include at least the first processor core and the second processor core.
  • system 100 can initiate a synchronized trace event that generates trace data identifying hardware events occurring across FPC 104 and SPC 106.
  • the trace data identifies a unique trace identifier for respective hardware events.
  • the hardware events include multiple synchronized hardware events, and at least two hardware events of the multiple synchronized events are synchronized when the events share a global hardware event time stamp.
  • multiple trigger conditions can be associated with the executing program code.
  • a particular trigger condition can be satisfied based on identifying an occurrence of a particular operand in at least a portion of the program code executed by at least the first or second processor core.
  • the particular operand can include one of multiple parameter values that can each be used to initiate a second trace event of the one or more trace events.
  • detecting that the particular trigger condition is satisfied can include, system 100 detecting that a particular parameter value exceeds a first bound value of a register.
  • system 100 responsive to detecting that the particular trigger condition is satisfied, system 100 initiates a trace event generating trace data that identifies at least one attribute that is shared among respective hardware events occurring across the distributed processor units.
  • an attribute of the respective hardware events can include at least a source memory address, a destination memory address, or a sequence/program compute step. Whereas at least one shared attribute can include a particular sequence step or program step of the program code.
  • one or more trigger conditions can be associated with at least one of: 1) a particular sequence step of the program code; 2) a global control parameter that indicates a particular performance state of the distributed processor units; 3) a current time or particular time parameter indicated by a global time clock/counter of the distributed processor units; or 4) a predefined time window associated with the global time clock.
  • system 100 can also detect that the particular parameter value of the particular operand, or a particular predefined time value, exceeds a second bound value of the register. In some instances, responsive to this detection, system 100 can stop the second trace event when the particular parameter value of a certain operand, or a certain predefined time value, exceeds the second bound value of the register.
  • system 100 provides, to a host device, a correlated set of trace data that includes the respective hardware events.
  • the correlated set of trace data indicates at least a time ordered sequence of the respective hardware events that are generated when the first trigger condition is satisfied.
  • the trace data comprises at least a hardware event time stamp for the hardware event, and metadata characterizing the hardware event.
  • the correlated set of trace data corresponds, at least in part, to data structure 620.
  • computing system 100 uses the correlated set of trace data to analyze performance of the program code executed by at least the first processor core and the second processor core.
  • data structure 620 i.e., corresponding to the correlated trace data
  • host system 126 is used by host system 126 to analyze performance of the program code executed by at least processor cores 104 and 106.
  • data structure 620 can be used by host system 126 to analyze performance of at least one component of system 100.
  • host system 126 can analyze data structure 620 to detect or determine if there is a performance issue associated with execution of a particular software module of the program code.
  • An example issue can include the software module failing to complete execution of certain instruction streams within an allotted execution time window, or below a threshold latency.
  • the user, or host device/system 126 can detect or determine if a particular component of system 100 is operating above or below a threshold performance level.
  • An example issue relating to component performance can include a particular hardware component generating result data that is outside acceptable threshold result parameter ranges.
  • the generated result data may be inconsistent with result data generated by other related components of system 100 that execute substantially similar instructions/operations.
  • a first component of system 100 can be required to complete an operation and to generate a result.
  • a second component of system 100 can be required to complete a substantially similar operation and to generate a substantially similar result.
  • Analysis of a correlated set of trace data can indicate that the second component generated a result that is considerably different than the result generated by the first component.
  • an example data structure of correlated trace entries may indicate result parameter values of the second component which are outside of acceptable parameter ranges.
  • Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.
  • Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non transitory program carrier for execution by, or to control the operation of, data processing apparatus.
  • the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.
  • the computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.
  • the processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output(s).
  • the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application specific integrated circuit), or a GPGPU (General purpose graphics processing unit).
  • special purpose logic circuitry e.g., an FPGA (field programmable gate array), an ASIC (application specific integrated circuit), or a GPGPU (General purpose graphics processing unit).
  • Computers suitable for the execution of a computer program include, by way of example, can be based on general or special purpose microprocessors or both, or any other kind of central processing unit.
  • a central processing unit will receive instructions and data from a read only memory or a random access memory or both.
  • the essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Debugging And Monitoring (AREA)
  • Advance Control (AREA)
  • Testing And Monitoring For Control Systems (AREA)
EP17199338.9A 2017-03-29 2017-10-31 Synchrone hardware-ereignis-sammlung Pending EP3382552A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/472,932 US10365987B2 (en) 2017-03-29 2017-03-29 Synchronous hardware event collection

Publications (1)

Publication Number Publication Date
EP3382552A1 true EP3382552A1 (de) 2018-10-03

Family

ID=60201424

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17199338.9A Pending EP3382552A1 (de) 2017-03-29 2017-10-31 Synchrone hardware-ereignis-sammlung

Country Status (12)

Country Link
US (3) US10365987B2 (de)
EP (1) EP3382552A1 (de)
JP (3) JP7196083B2 (de)
KR (3) KR102295511B1 (de)
CN (2) CN115168147A (de)
BR (1) BR112019015427B1 (de)
DE (2) DE102017125180A1 (de)
GB (1) GB2561043B (de)
HK (1) HK1259155A1 (de)
SG (1) SG11201906749UA (de)
TW (2) TWI681332B (de)
WO (1) WO2018182783A1 (de)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3430767B1 (de) * 2016-03-16 2020-09-23 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und vorrichtung zur verarbeitung von echtzeit-netzwerkereignissen
US9875167B1 (en) 2017-03-29 2018-01-23 Google Inc. Distributed hardware tracing
US10365987B2 (en) 2017-03-29 2019-07-30 Google Llc Synchronous hardware event collection
US11144087B2 (en) * 2018-08-10 2021-10-12 Nvidia Corporation Efficient performance monitoring of integrated circuit(s) having distributed clocks
CN109981349B (zh) * 2019-02-27 2022-02-25 华为云计算技术有限公司 调用链信息查询方法以及设备
GB2583103B (en) 2019-04-16 2022-11-16 Siemens Ind Software Inc Tracing instruction execution
CN110046116B (zh) * 2019-04-23 2020-08-21 上海燧原智能科技有限公司 一种张量填充方法、装置、设备及存储介质
CN110311863B (zh) * 2019-05-09 2020-08-21 北京邮电大学 一种路由路径确定方法及装置
US11294750B2 (en) * 2019-07-15 2022-04-05 Micron Technology, Inc. Media management logger for a memory sub-system
CN114258538B (zh) * 2019-08-16 2024-04-12 谷歌有限责任公司 片上操作的显式调度
US11630919B1 (en) * 2019-09-30 2023-04-18 Amazon Technologies, Inc. Management of sensitive data using static code analysis
CN111160558B (zh) * 2019-12-13 2023-04-28 合肥本源量子计算科技有限责任公司 量子芯片控制器、量子计算处理系统和电子设备
EP3839740A1 (de) * 2019-12-20 2021-06-23 GrAl Matter Labs S.A.S. Nachrichtenbasiertes verarbeitungssystem und verfahren zum betrieb davon
EP4110431A4 (de) * 2020-02-27 2023-08-02 Siemens Healthcare Diagnostics Inc. Automatische validierung von sensorspuren mittels maschinenlernen
US11100166B1 (en) 2020-12-21 2021-08-24 Coupang Corp. Systems and methods for automatically updating guaranteed computing counters
US20220198110A1 (en) * 2020-12-23 2022-06-23 Intel Corporation Debugging architecture for system in package composed of multiple semiconductor chips
EP4296906A4 (de) * 2021-03-31 2024-03-27 Huawei Technologies Co., Ltd. Synchronisationsverfahren und -vorrichtung
KR102648657B1 (ko) * 2021-10-06 2024-03-15 에스케이텔레콤 주식회사 무선통신시스템에서 원거리 통신을 위한 통신 장치 및 이를 위한 방법
US11966745B2 (en) 2021-11-15 2024-04-23 Google Llc Sparse SIMD cross-lane processing unit
US11972263B2 (en) 2021-11-22 2024-04-30 Google Llc Cooperative instruction prefetch on multicore system
WO2023128009A1 (ko) * 2021-12-30 2023-07-06 리벨리온 주식회사 뉴럴 프로세싱 장치 및 그의 동기화 방법
US11977499B2 (en) * 2022-03-22 2024-05-07 Google Llc Streaming transfers and ordering model
US20240201729A1 (en) * 2022-12-16 2024-06-20 Cirrus Logic International Semiconductor Ltd. Event logging based on global clock in system with multiple components
US11899516B1 (en) 2023-07-13 2024-02-13 T-Mobile Usa, Inc. Creation of a digital twin for auto-discovery of hierarchy in power monitoring

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134676A (en) * 1998-04-30 2000-10-17 International Business Machines Corporation Programmable hardware event monitoring method
US20060005083A1 (en) * 2004-06-30 2006-01-05 International Business Machines Corporation Performance count tracing
US20100083237A1 (en) * 2008-09-26 2010-04-01 Arm Limited Reducing trace overheads by modifying trace operations
US20110314342A1 (en) * 2010-06-21 2011-12-22 Arm Limited Tracing speculatively executed instructions
US20120179898A1 (en) * 2011-01-10 2012-07-12 Apple Inc. System and method for enforcing software security through cpu statistics gathered using hardware features
US20120226837A1 (en) * 2011-03-02 2012-09-06 Texas Instruments Incorporated Method and System of debugging Multicore Bus Transaction Problems
US8762951B1 (en) * 2007-03-21 2014-06-24 Oracle America, Inc. Apparatus and method for profiling system events in a fine grain multi-threaded multi-core processor

Family Cites Families (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4598364A (en) 1983-06-29 1986-07-01 International Business Machines Corporation Efficient trace method adaptable to multiprocessors
JPH0283749A (ja) 1988-09-21 1990-03-23 Hitachi Ltd マイクロプロセッサの内部割込み制御方式
JPH04148439A (ja) 1990-10-12 1992-05-21 Nec Corp 情報処理装置のトレース方式
JPH04242455A (ja) 1991-01-16 1992-08-31 Nec Ibaraki Ltd プロセッサ間通信トレース回路
JPH05128079A (ja) 1991-10-31 1993-05-25 Nec Corp マルチプロセツサシステムにおけるトレース方式
JPH07200352A (ja) 1993-12-28 1995-08-04 Hitachi Ltd データプロセッサ、プログラム翻訳方法、及びデバッグツール
US6128415A (en) 1996-09-06 2000-10-03 Polaroid Corporation Device profiles for use in a digital image processing system
US5682328A (en) 1996-09-11 1997-10-28 Bbn Corporation Centralized computer event data logging system
US5796939A (en) * 1997-03-10 1998-08-18 Digital Equipment Corporation High frequency sampling of processor performance counters
US6189140B1 (en) 1997-04-08 2001-02-13 Advanced Micro Devices, Inc. Debug interface including logic generating handshake signals between a processor, an input/output port, and a trace logic
US6256775B1 (en) 1997-12-11 2001-07-03 International Business Machines Corporation Facilities for detailed software performance analysis in a multithreaded processor
US6233531B1 (en) 1997-12-19 2001-05-15 Advanced Micro Devices, Inc. Apparatus and method for monitoring the performance of a microprocessor
US6098169A (en) 1997-12-23 2000-08-01 Intel Corporation Thread performance analysis by monitoring processor performance event registers at thread switch
EP0992907B1 (de) * 1998-10-06 2005-09-28 Texas Instruments Inc. Verwaltung eines FIFO zur Abalufverfolgung
US6353924B1 (en) * 1999-02-08 2002-03-05 Incert Software Corporation Method for back tracing program execution
JP2000348007A (ja) 1999-06-03 2000-12-15 Nec Corp マルチプロセッサシステムのための動作トレース時刻同期方式およびその方法
US6530076B1 (en) 1999-12-23 2003-03-04 Bull Hn Information Systems Inc. Data processing system processor dynamic selection of internal signal tracing
US6725391B2 (en) * 2000-03-02 2004-04-20 Texas Instruments Incorporated Clock modes for a debug port with on the fly clock switching
US6789182B1 (en) 2000-11-13 2004-09-07 Kevin Jay Brothers System and method for logging computer event data and physical components of a complex distributed system
US6813731B2 (en) 2001-02-26 2004-11-02 Emc Corporation Methods and apparatus for accessing trace data
US6769054B1 (en) 2001-02-26 2004-07-27 Emc Corporation System and method for preparation of workload data for replaying in a data storage environment
US6988155B2 (en) 2001-10-01 2006-01-17 International Business Machines Corporation Aggregation of hardware events in multi-node systems
US7080283B1 (en) 2002-10-15 2006-07-18 Tensilica, Inc. Simultaneous real-time trace and debug for multiple processing core systems on a chip
US7069176B2 (en) 2003-08-07 2006-06-27 Arm Limited Trace source correlation in a data processing apparatus
JP2005165825A (ja) 2003-12-04 2005-06-23 Canon Inc トレース情報記録装置
US7529979B2 (en) 2003-12-12 2009-05-05 International Business Machines Corporation Hardware/software based indirect time stamping methodology for proactive hardware/software event detection and control
GB0420442D0 (en) 2004-09-14 2004-10-20 Ignios Ltd Debug in a multicore architecture
US9038070B2 (en) 2004-09-14 2015-05-19 Synopsys, Inc. Debug in a multicore architecture
US7543161B2 (en) 2004-09-30 2009-06-02 International Business Machines Corporation Method and apparatus for tracking variable speed microprocessor performance caused by power management in a logically partitioned data processing system
US7673050B2 (en) 2004-12-17 2010-03-02 Microsoft Corporation System and method for optimizing server resources while providing interaction with documents accessible through the server
US7418629B2 (en) 2005-02-11 2008-08-26 International Business Machines Corporation Synchronizing triggering of multiple hardware trace facilities using an existing system bus
JP2006318412A (ja) 2005-05-16 2006-11-24 Toshiba Corp 半導体装置
US8079037B2 (en) * 2005-10-11 2011-12-13 Knoa Software, Inc. Generic, multi-instance method and GUI detection system for tracking and monitoring computer applications
JP2008234191A (ja) 2007-03-19 2008-10-02 Toshiba Corp ハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法
US8181185B2 (en) * 2007-05-31 2012-05-15 Intel Corporation Filtering of performance monitoring information
US20110246521A1 (en) * 2007-08-06 2011-10-06 Hui Luo System and method for discovering image quality information related to diagnostic imaging performance
JP4658182B2 (ja) 2007-11-28 2011-03-23 株式会社荏原製作所 研磨パッドのプロファイル測定方法
US8301759B2 (en) 2008-10-24 2012-10-30 Microsoft Corporation Monitoring agent programs in a distributed computing platform
WO2010097875A1 (ja) 2009-02-24 2010-09-02 パナソニック株式会社 データ処理装置、方法
JP5326708B2 (ja) 2009-03-18 2013-10-30 富士通株式会社 演算処理装置および演算処理装置の制御方法
US8572581B2 (en) 2009-03-26 2013-10-29 Microsoft Corporation Measurement and reporting of performance event rates
US8464089B2 (en) 2009-06-10 2013-06-11 Panasonic Corporation Tracing apparatus and tracing system
US8554892B2 (en) 2009-06-22 2013-10-08 Citrix Systems, Inc. Systems and methods for n-core statistics aggregation
US8407528B2 (en) * 2009-06-30 2013-03-26 Texas Instruments Incorporated Circuits, systems, apparatus and processes for monitoring activity in multi-processing systems
JP2011013867A (ja) * 2009-06-30 2011-01-20 Panasonic Corp データ処理装置、性能評価解析システム
US20110047358A1 (en) * 2009-08-19 2011-02-24 International Business Machines Corporation In-Data Path Tracking of Floating Point Exceptions and Store-Based Exception Indication
US8495604B2 (en) * 2009-12-30 2013-07-23 International Business Machines Corporation Dynamically distribute a multi-dimensional work set across a multi-core system
GB2478328B (en) * 2010-03-03 2015-07-01 Advanced Risc Mach Ltd Method, apparatus and trace module for generating timestamps
JP2011243110A (ja) 2010-05-20 2011-12-01 Renesas Electronics Corp 情報処理装置
US8607202B2 (en) 2010-06-04 2013-12-10 Lsi Corporation Real-time profiling in a multi-core architecture
US20120042212A1 (en) 2010-08-10 2012-02-16 Gilbert Laurenti Mixed Mode Processor Tracing
US20120226839A1 (en) 2011-03-02 2012-09-06 Texas Instruments Incorporated Method and System for Monitoring and Debugging Access to a Bus Slave Using One or More Throughput Counters
US8943248B2 (en) 2011-03-02 2015-01-27 Texas Instruments Incorporated Method and system for handling discarded and merged events when monitoring a system bus
US10642709B2 (en) 2011-04-19 2020-05-05 Microsoft Technology Licensing, Llc Processor cache tracing
US8683268B2 (en) 2011-06-20 2014-03-25 International Business Machines Corporation Key based cluster log coalescing
US8713370B2 (en) * 2011-08-11 2014-04-29 Apple Inc. Non-intrusive processor tracing
US8935574B2 (en) * 2011-12-16 2015-01-13 Advanced Micro Devices, Inc. Correlating traces in a computing system
US9454462B2 (en) 2012-03-16 2016-09-27 International Business Machines Corporation Run-time instrumentation monitoring for processor characteristic changes
US9237082B2 (en) 2012-03-26 2016-01-12 Hewlett Packard Enterprise Development Lp Packet descriptor trace indicators
US9021311B2 (en) 2012-08-28 2015-04-28 Freescale Semiconductor, Inc. Method and apparatus for filtering trace information
US9645870B2 (en) 2013-06-27 2017-05-09 Atmel Corporation System for debugging DMA system data transfer
US20160117196A1 (en) 2013-07-31 2016-04-28 Hewlett-Packard Development Company, L.P. Log analysis
JP6122749B2 (ja) 2013-09-30 2017-04-26 ルネサスエレクトロニクス株式会社 コンピュータシステム
TWI514145B (zh) 2013-10-21 2015-12-21 Univ Nat Sun Yat Sen 可儲存除錯資料的處理器、其快取及控制方法
US9684583B2 (en) 2013-11-05 2017-06-20 Texas Instruments Incorporated Trace data export to remote memory using memory mapped write transactions
JP2015114675A (ja) * 2013-12-09 2015-06-22 三菱電機株式会社 アプリケーションソフトウェア加速試験装置および試験方法
JP6258159B2 (ja) 2014-08-26 2018-01-10 株式会社東芝 プログラム情報生成システム、方法、及びプログラム
US20160070636A1 (en) 2014-09-04 2016-03-10 Home Box Office, Inc. Conditional wrapper for program object
EP3035249B1 (de) 2014-12-19 2019-11-27 Intel Corporation Verfahren und Vorrichtung für verteilte und kooperative Berechnung in künstlichen neuronalen Netzen
CN106033385A (zh) 2015-03-19 2016-10-19 启碁科技股份有限公司 用于追踪程序执行状态的方法与多核心处理系统
US11232848B2 (en) 2015-04-30 2022-01-25 Hewlett Packard Enterprise Development Lp Memory module error tracking
US20160378636A1 (en) 2015-06-26 2016-12-29 Intel Corporation Software-Initiated Trace Integrated with Hardware Trace
CN105354136B (zh) 2015-09-25 2018-06-15 华为技术有限公司 一种调试方法、多核处理器和调试设备
US9858167B2 (en) 2015-12-17 2018-01-02 Intel Corporation Monitoring the operation of a processor
US20170371761A1 (en) 2016-06-24 2017-12-28 Advanced Micro Devices, Inc. Real-time performance tracking using dynamic compilation
US9965375B2 (en) 2016-06-28 2018-05-08 Intel Corporation Virtualizing precise event based sampling
US10175980B2 (en) * 2016-10-27 2019-01-08 Google Llc Neural network compute tile
US9959498B1 (en) * 2016-10-27 2018-05-01 Google Llc Neural network instruction set architecture
US10127283B2 (en) 2016-10-31 2018-11-13 International Business Machines Corporation Projecting effect of in-flight streamed data on a relational database
US10365987B2 (en) 2017-03-29 2019-07-30 Google Llc Synchronous hardware event collection
US9875167B1 (en) 2017-03-29 2018-01-23 Google Inc. Distributed hardware tracing
KR101988558B1 (ko) 2017-06-07 2019-06-12 현대오트론 주식회사 멀티 코어를 갖는 마이크로콘트롤러 유닛을 감시하는 감시장치 및 그것의 동작 방법

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134676A (en) * 1998-04-30 2000-10-17 International Business Machines Corporation Programmable hardware event monitoring method
US20060005083A1 (en) * 2004-06-30 2006-01-05 International Business Machines Corporation Performance count tracing
US8762951B1 (en) * 2007-03-21 2014-06-24 Oracle America, Inc. Apparatus and method for profiling system events in a fine grain multi-threaded multi-core processor
US20100083237A1 (en) * 2008-09-26 2010-04-01 Arm Limited Reducing trace overheads by modifying trace operations
US20110314342A1 (en) * 2010-06-21 2011-12-22 Arm Limited Tracing speculatively executed instructions
US20120179898A1 (en) * 2011-01-10 2012-07-12 Apple Inc. System and method for enforcing software security through cpu statistics gathered using hardware features
US20120226837A1 (en) * 2011-03-02 2012-09-06 Texas Instruments Incorporated Method and System of debugging Multicore Bus Transaction Problems

Also Published As

Publication number Publication date
CN115168147A (zh) 2022-10-11
KR20210107174A (ko) 2021-08-31
DE102017125180A1 (de) 2018-10-04
SG11201906749UA (en) 2019-08-27
US11232012B2 (en) 2022-01-25
HK1259155A1 (zh) 2019-11-29
KR102493495B1 (ko) 2023-01-27
JP2024050667A (ja) 2024-04-10
KR20230017927A (ko) 2023-02-06
KR102584961B1 (ko) 2023-10-04
CN108694109B (zh) 2022-07-22
TWI808280B (zh) 2023-07-11
JP2023036719A (ja) 2023-03-14
BR112019015427A2 (pt) 2020-03-31
JP2020512613A (ja) 2020-04-23
CN108694109A (zh) 2018-10-23
JP7427759B2 (ja) 2024-02-05
TW202403538A (zh) 2024-01-16
GB201717925D0 (en) 2017-12-13
WO2018182783A1 (en) 2018-10-04
US20220129364A1 (en) 2022-04-28
GB2561043A (en) 2018-10-03
TW202011177A (zh) 2020-03-16
KR102295511B1 (ko) 2021-08-27
TW201837699A (zh) 2018-10-16
GB2561043B (en) 2021-01-13
US11921611B2 (en) 2024-03-05
US20200019483A1 (en) 2020-01-16
JP7196083B2 (ja) 2022-12-26
BR112019015427B1 (pt) 2022-01-11
US20180285233A1 (en) 2018-10-04
US10365987B2 (en) 2019-07-30
KR20190096427A (ko) 2019-08-19
DE202017106508U1 (de) 2018-02-05
TWI681332B (zh) 2020-01-01

Similar Documents

Publication Publication Date Title
US11921611B2 (en) Synchronous hardware event collection
US11650895B2 (en) Distributed hardware tracing
TWI851297B (zh) 用於收集關於類神經網路運算之事件資料之方法、事件收集系統及非暫態電腦可讀儲存裝置

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190327

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201023

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS