Method, medium and product for SystemC system performance analysis

Abstract

The invention discloses a method, a medium and a product for SystemC system performance analysis. The method comprises the following steps: defining a group of transaction marking API (Application Program Interface) functions, including a starting function and an ending function; calling a starting function at the starting point of the transaction in the SystemC system, and calling an ending function at the ending point of the transaction; in the simulation execution process of the SystemC system, in response to calling of a starting function and an ending function, transaction information associated with a transaction is captured and recorded, and the transaction information comprises a starting timestamp, an ending timestamp, a grouping identifier and a transaction name of the transaction; grouping the transactions according to the grouping identifiers of the transactions to generate one or more transaction groups; and generating an independent timeline track for each transaction group, and drawing graphic elements representing the duration of the transaction on the timeline track according to the start and end times of each transaction to generate a grouped transaction active timeline graph.

Description

Technical Field

[0001] This disclosure relates to the field of system-on-a-chip design, and more specifically to methods for performance analysis of SystemC systems, computer-readable storage media, and computer program products. Background Technology

[0002] SystemC, a widely used language library for system-level design, modeling, and verification, provides a unified hardware-software co-design environment for modeling complex on-chip systems. In SystemC-based systems, system behavior is typically abstracted into multiple concurrently executing transactions, such as read / write requests from the processor, data transfers by the Direct Memory Access (DMA) controller, and computational tasks from hardware accelerators. The interleaved execution of these transactions on the SystemC simulation timeline reflects the system's concurrent behavioral characteristics. When debugging or performing performance analysis on such systems, designers need not only to observe changes in low-level signals but also to understand the interactions between modules, concurrent behavior, and data flow from a higher level of transaction abstraction. Summary of the Invention

[0003] In one aspect, this application discloses a method for performance analysis of a SystemC system, characterized by comprising: defining a set of transaction marking API functions, including a start function for marking the start of a transaction and an end function for marking the end of a transaction, wherein the start function and the end function include a transaction name parameter and a transaction group identifier parameter; calling the start function at the start point of a transaction in the SystemC system and calling the end function at the end point of a transaction; during the simulation execution of the SystemC system, in response to the calls to the start function and the end function, capturing and recording transaction information associated with the transaction, the transaction information including the start timestamp and end timestamp of the transaction, the transaction group identifier, and the transaction name of the transaction; grouping the transactions according to the transaction group identifier to generate one or more transaction groups; and generating an independent timeline track for each transaction group, and plotting graphical elements representing the duration of the transaction on the timeline track according to the start time and end time of each transaction to generate a grouped transaction active timeline diagram.

[0004] In other respects, this application discloses a computer-readable storage medium storing instructions and a computer program product including instructions. These instructions, when executed by one or more processors, cause the processors to perform the methods described in this application. Attached Figure Description

[0005] When read in conjunction with the accompanying drawings, various aspects of this disclosure are best understood through the following detailed description. It should be noted that, in accordance with standard practice in the art, the features are not drawn to scale. In fact, for clarity of discussion, the dimensions of the features may be arbitrarily increased or decreased.

[0006] Figure 1 This is a flowchart illustrating a method for SystemC system performance analysis according to an embodiment of this application.

[0007] Figure 2 The illustration shows a code example of a start function for marking the start of an AXI (Advanced Extensible Interface, AXI) read transaction according to one embodiment of this application.

[0008] Figure 3 The illustration shows a code example of an end function for marking the end of an AXI read transaction according to one embodiment of this application.

[0009] Figure 4 The illustration shows a code example for multi-stage event marking in an AXI read transaction according to an embodiment of this application.

[0010] Figure 5 An example of a grouped transaction activity timeline generated according to one embodiment of this application is illustrated.

[0011] Figure 6 This is a schematic diagram of a computing device that can be implemented according to an embodiment of the present invention. Detailed Implementation

[0012] The following disclosure provides numerous different embodiments or examples for implementing various features of the provided subject matter. Specific examples of components and arrangements are described below to simplify this disclosure. Of course, these are merely examples and not limiting.

[0013] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not need to be performed in the order presented.

[0014] SystemC, a C++-based hardware modeling library, is widely used in system-level design, modeling, and verification in the field of complex system-on-chip (SoC) design. In a typical SoC development process, designers abstract system behavior into multiple concurrently executing transactions, such as read / write requests from the processor, data transfers from the DMA controller, and computational tasks from hardware accelerators. These transactions are interwoven on the simulation timeline of a SystemC-based system (referred to as a "SystemC system" in this paper), reflecting the system's concurrent behavioral characteristics. When debugging or performing performance analysis on such systems, designers need not only to observe changes in underlying signals but also to understand the interactions, concurrent behaviors, and data flows between modules from a higher level of transaction abstraction.

[0015] Traditional debugging or performance analysis methods for SystemC systems mainly include signal waveform debugging and log file output debugging. For signal waveform debugging, designers use simulators to generate waveform files in VCD (Value Change Dump) or FSDB (Fast Signal Database) format, observing the level changes of underlying signals in a waveform viewer. This method remains at the register transfer level or signal level, with a low level of abstraction. When transaction-level concepts are mapped to the underlying implementation, they are often broken down into hundreds or thousands of signal transitions. Designers need to expend considerable effort to reconstruct macroscopic transaction behavior from massive amounts of microscopic signals, making it difficult to intuitively grasp the start time, duration, and completion status of transactions, and even more difficult to clearly identify concurrent overlaps, sequential dependencies, or resource blocking relationships between transactions. For log file output debugging, designers insert printf or cout statements into the SystemC code to output custom transaction information as a text log. While this method can capture high-level transaction semantic information, its output is a linear text stream, which is fundamentally contradictory to the inherent concurrency of the system. The intertwined output of logs from multiple concurrent transactions forces designers to rely on manual parsing of timestamps to reconstruct the timeline. At the same time, the idle periods of the system are represented as information blind spots in the logs, making it impossible to intuitively present the waiting, blocking, and scheduling processes of transactions. Furthermore, a large amount of log output will significantly increase simulation I / O overhead, thereby slowing down the simulation speed.

[0016] In summary, the existing technology lacks an effective tool that can automatically extract transaction information during the simulation execution of a SystemC system and display the transaction activity in an intuitive, grouped timeline chart, resulting in time-consuming and labor-intensive system-level debugging and performance analysis processes.

[0017] According to an embodiment of this application, a method for debugging or performance analysis of a SystemC system is provided. By inserting a lightweight marker function into the SystemC source code, the start time, end time and other key attribute information of transactions are automatically captured and recorded during simulation execution. Transactions are grouped according to user-specified grouping identifiers, and finally a clear and intuitive timeline chart of grouped transaction activity is automatically generated for debugging or performance analysis of the SystemC system.

[0018] Figure 1 This is a schematic flowchart of a method 100 for SystemC system performance analysis according to an embodiment of this application. Method 100 can be performed by a system or device for SystemC system performance analysis (e.g., described below). Figure 1 In the illustrated embodiment, method 100 may include operations 110 to 150 for automatically generating clear and intuitive timeline graphs of grouped transaction activity for the SystemC system to facilitate system debugging or performance analysis by designers. In other embodiments, methods for SystemC system performance analysis may include more or fewer or different operations, and this disclosure is not limited in this respect.

[0019] At operation 110, a set of transaction marking application programming interface (API) functions are defined. These API functions may include, for example, a start function to mark the beginning of a transaction and an end function to mark the end of a transaction. The start and end functions may include transaction name parameters and transaction group identifier parameters. For example, the parameters of a transaction start function may include a first group identifier pid, a second group identifier tid, the transaction name, and other optional attributes; this start function could be represented as void trans_begin(int pid, int tid, const char* name,...). Correspondingly, the parameters of the transaction end function may include the same first group identifier pid and second group identifier tid as the start function; this end function could be represented as void trans_end(int pid, int tid). The following will combine... Figure 2 and Figure 3 The code examples shown illustrate how to define the start and end functions of a transaction.

[0020] Figure 2 The illustration shows a code example of a start function for marking the start of an AXI read transaction according to one embodiment of this application. Figure 2As shown, the parameters of the start function `trans_begin` include a first group identifier `pid`, a second group identifier `tid`, a transaction name `name`, and a series of optional key-value pair attributes. `pid` can be used to identify the initiator of the transaction, such as a hardware module like a CPU core or DMA controller. In the subsequent generation of the transaction activity timeline, transactions with the same `pid` can be grouped into the same level track. `tid` can be used to identify the specific task, thread, or data stream within the same initiator. `tid` combined with `pid` can be used to implement hierarchical grouping of transactions. The transaction name is used to identify the type or function of the transaction. In the generated transaction timeline, different colors or labels can be assigned to graphical elements based on the transaction name for visual differentiation. In addition, optional attributes, such as address `addr`, burst length `len`, and transfer size `size`, are passed in as key-value pairs. These attributes are recorded as transaction metadata and can be used in subsequent analysis for filtering, statistics, or detailed viewing of the specific characteristics of the transaction.

[0021] According to embodiments of this application, the start function can be called at the beginning of a transaction to, for example, send a "transaction start" event to the runtime data collection engine. When this function is called, the runtime data collection engine records the current simulation timestamp as the start time of the transaction and packages all passed parameters (including group identifier, transaction name, and optional attributes) into a transaction trace record, storing it in a thread-safe global buffer. This information will be used in subsequent processing to generate transaction stripes in the timeline graph.

[0022] Figure 3 The illustration shows a code example of an end function for marking the end of an AXI read transaction according to one embodiment of this application. Figure 3 As shown, the parameters of the end function `trans_end` include the first group identifier `pid` and the second group identifier `tid`. These two parameters are consistent with the `pid` and `tid` values ​​in the corresponding `trans_begin` call to ensure that the start and end of the transaction can be correctly matched. When this function is called at the end point of the transaction, the runtime data collection engine records the current simulation timestamp as the end time of the transaction and matches it with the previously recorded corresponding start event using the `pid` and `tid` identifiers. If the match is successful, a complete transaction lifecycle record is formed, including the transaction's start time, end time, duration, and all attributes. According to the embodiments of this application, when generating the transaction active timeline chart subsequently, the start and end points of each transaction stripe are determined by this pair of calls to the start and end functions.

[0023] At operation 120, the start function is called at the beginning of the transaction in the SystemC system, and the end function is called at the end of the transaction.

[0024] According to embodiments of this application, operation 120 can also be called code instrumentation, which is executed by the instrumentation API module. Code instrumentation refers to inserting additional code fragments into the source code or target code while ensuring that the original logic of the program remains unchanged, so as to collect specific information such as execution path, variable values, and performance data during program runtime. Specifically, lightweight trans_begin and trans_end marker function calls can be inserted into the critical code paths of the SystemC system. This instrumentation operation is lightweight, adding function calls only at the boundary points of the transaction lifecycle without changing the original transaction execution logic. Its purpose is to collect the start and end times, identification information, and attribute parameters of the transaction, providing raw data for subsequent transaction-level visualization analysis. In addition, according to embodiments of this application, each trans_begin call should have a corresponding trans_end call, and the pid and tid identifiers of the two should be consistent; otherwise, the transaction cannot be correctly matched, making it impossible to guarantee the integrity of the transaction lifecycle. The pid and tid identifiers can be defined by the user according to the analysis requirements for logical grouping of transactions.

[0025] At operation 130, during the simulation execution of the SystemC system, in response to the calls to the start and end functions, transaction information associated with the transaction is captured and recorded. This transaction information may include the start and end timestamps of the transaction, the group identifier of the transaction, and the transaction name of the transaction.

[0026] According to an embodiment of this application, operation 130 can be executed by a runtime data collection engine, which can be embedded in the simulation process of the SystemC system and is responsible for capturing, filtering, and caching transaction information associated with transactions. During the simulation execution of the SystemC system, when a marker function inserted by the user through code instrumentation is called, the runtime data collection engine will immediately respond and perform data acquisition operations. Specifically, when the trans_begin function is called, the system can first obtain the current simulation time by calling the sc_time_stamp() function provided by the SystemC kernel. This time accurately reflects the moment when the transaction occurs on the simulation timeline, ensuring the accuracy of hardware timing analysis. Subsequently, the runtime data collection engine can capture the first group identifier pid, the second group identifier tid, the transaction name name, and all optional key-value pair attributes passed to the marker function, and record the corresponding event type according to whether the start function or the end function is called. For the trans_end function, the runtime data collection engine will also obtain the current simulation timestamp and record it in combination with the passed pid and tid identifiers so that it can be matched with the corresponding start event to form a complete transaction lifecycle.

[0027] Furthermore, the captured information can be recorded in a global, thread-safe data structure to ensure data integrity in a multi-threaded simulation environment. Since the SystemC simulation model contains a large number of concurrently executing processes, these processes may simultaneously call the marking function and write data to the same global data structure at the same time or within a very short period. If this data structure is not thread-safe, contention may occur, leading to data overwriting, record loss, or even program crashes. Therefore, the runtime data collection engine of this invention can employ a dedicated thread-safe mechanism. For example, a mutex lock can be used to protect the write operation of shared data, ensuring that only one thread can access the data structure at a time; a lock-free circular buffer combined with atomic operations can be used to achieve more efficient high-concurrency writes; or an independent local buffer can be allocated to each simulation thread, with each thread writing to its own buffer without locking, and the data from all threads merged into global storage when the simulation ends or the buffer is full.

[0028] According to some embodiments of this application, in addition to basic start and end events, it can also support capturing event information at intermediate event points within the transaction lifecycle. In these embodiments, an event function `trans_event` can be defined to mark intermediate event points within the transaction lifecycle. When the event function is called at a specified event point within the transaction lifecycle, the runtime data collection engine can similarly capture and record event information associated with the event occurring at that specified event point, such as the current simulation timestamp, group identifier, event name, and related key-value pair attributes, and can mark the recorded event type as "event". These event records can be associated with the corresponding transaction using the same pid and tid identifiers. When subsequently generating a transaction activity timeline, they can be presented as graphical markers within transaction stripes, enabling designers to gain a deeper understanding of the internal details of transaction execution. The following will combine... Figure 4 To describe in more detail how to use event functions to capture event information at certain intermediate event points within the transaction lifecycle.

[0029] Figure 4The illustration shows a code example for multi-stage event marking in an AXI read transaction according to an embodiment of this application. The figure shows an example AXI read transaction processing function, demonstrating how the event function `trans_event` captures transient information of some key stages during the transaction's lifecycle. At the start of the AXI read transaction, `trans_begin` is first called to mark the start point of the transaction. For example, the first group identifier `pid=2` passed to this start function can indicate that the transaction initiator is the second CPU core, the second group identifier `tid=1001` can indicate the 1001st task thread within that CPU core, and the transaction name "AXI_READ" indicates that this is an AXI read transaction. Simultaneously, the transaction's starting address `start_addr` and burst length `burst_len` can be recorded via key-value pairs. These attributes will be stored as transaction metadata for subsequent analysis and filtering.

[0030] According to this embodiment, when the transaction enters the address phase, the code calls the first `trans_event`, named "ADDR_PHASE_START," and records the sent read address `araddr`, burst length minus one `arlen`, and transfer size `arsize` via key-value pairs. This event marks the precise moment when the address channel handshake begins, allowing designers to observe the delay from the start of the transaction to the address being sent. Subsequently, the function `send_read_address`, which actually sends the read address, is executed, completing the address channel handshake. After the address is sent, the transaction enters the data waiting phase, and the code can call the second `trans_event`, named "WAIT_DATA_START," for example, to indicate the start of waiting for data to return from the slave device. At this time, the master device may enter a blocked state due to waiting. When the data-ready_event is triggered, the waiting ends, and then the third `trans_event`, named "WAIT_DATA_END," can be called, recording the number of clock cycles elapsed during the waiting period via the `wait_cycles` attribute. By using this pair of wait start and wait end event flags, designers can precisely measure device response latency to analyze potential system performance bottlenecks. Furthermore, during the data reception phase, the code can process bursty data transmissions in a loop. For each data burst, the event function named "DATA_BEAT" can be called, recording the current burst number via the `beat_idx` attribute, the actual data value of that burst via the `data` attribute, and whether it is the last burst via the `last` attribute. This fine-grained event logging allows designers to observe not only the duration of the entire data transmission but also the specific arrival time and value of each data burst, which is crucial for analyzing data channel behavior and detecting data anomalies. Before a transaction is about to end, the code can call the event function named "COMPLETION_CHECK," recording the status information and total number of bytes transmitted before transaction completion via the `status` and `total_bytes` attributes. This event serves as a final checkpoint before transaction completion, facilitating verification that the transaction completed as expected. Finally, the end function `trans_end` can be called to mark the end of the transaction, thus completing the recording of the entire transaction lifecycle.

[0031] According to this embodiment, through the insertion of the aforementioned series of event functions, the AXI read transaction will appear as a continuous transaction stripe from trans_begin to trans_end on the timeline graph. Within this stripe, there are multiple event markers at corresponding time positions: address phase start marker, data start waiting marker, data end waiting marker, multi-step data arrival marker, and pre-completion check marker. Designers can quickly identify bottlenecks in the transaction execution process by observing the distribution and spacing of these event markers. For example, if the interval between the start and end of data wait is too long, it indicates a large response delay from the slave device; if the intervals between data steps are uneven, it may reflect data channel congestion or arbitration delay. This multi-granularity event recording mechanism allows the technical solution of this invention to not only provide a macroscopic view at the transaction level but also to delve into the microscopic analysis within the transaction when needed, further improving the efficiency of system debugging and performance analysis.

[0032] At operation 140, transactions are grouped according to their grouping identifiers to generate one or more transaction groups. According to embodiments of this application, operation 140 can be executed by a data post-processing engine. As described above, the start and end functions of a transaction can include a transaction name parameter and a transaction grouping identifier parameter, wherein the transaction grouping identifier parameter can include a first grouping identifier pid and a second grouping identifier tid. The first grouping identifier pid is used to identify the transaction initiator, and the second grouping identifier tid is used to identify the task or thread associated with the transaction within the transaction initiator. Accordingly, according to some embodiments of this application, grouping transactions according to their grouping identifiers can include: grouping transactions into a first-level group based on the first grouping identifier, and grouping transactions into a second-level group within the first-level group based on the second grouping identifier, to form one or more transaction groups with a hierarchical structure.

[0033] According to some embodiments of this application, after the simulation execution process of the SystemC system ends, the collected raw transaction records can first undergo data post-processing and grouping, and then be transformed into structured data for visualization analysis. First, the post-processing engine can read the transaction information captured and recorded by the runtime data collection engine. This transaction information can include all transaction start events, end events, and intermediate event information captured during the simulation. Then, the post-processing engine can associate multiple events of the same transaction using the same grouping identifiers pid and tid, thereby reconstructing the complete lifecycle of each transaction. Next, transactions can be hierarchically grouped according to the grouping identifiers. For example, all transactions can be divided into different top-level groups based on the first grouping identifier pid, where each pid represents an independent transaction initiator, such as a CPU core, a DMA controller, or a hardware acceleration module. Then, within each pid group, further subdivision is performed based on the second grouping identifier tid, where each tid represents a specific task, thread, or data stream within that initiator. This two-level grouping mechanism ultimately forms transaction groups with a clear hierarchical structure. For example, (pid=1, tid=1024) represents all transactions initiated by task 1024 on CPU0, and (pid=2, tid=2001) represents all transactions processed by channel 2001 on the DMA controller. This grouping method provides the data structure foundation for the subsequent generation of multi-track timeline charts.

[0034] Furthermore, within each (pid, tid) group, the post-processing engine can sort and organize all transactions within that group in chronological order. Since a task or thread may initiate the same type of transaction multiple times, these transactions appear as sequential or partially overlapping sequences on the timeline. By sorting by time, the start time, end time, duration of each transaction, and the dependencies between transactions can be clearly presented. For transactions containing intermediate events, the post-processing engine can also attach the corresponding event records to the transaction, forming an event sequence within the transaction, where each event is associated with a precise timestamp and key-value pair attributes.

[0035] At operation 150, an independent timeline track is generated for each transaction group, and on this timeline track, graphical elements representing the duration of the transaction are plotted according to the start and end times of each transaction to generate a grouped transaction active timeline chart.

[0036] According to an embodiment of this application, operation 150 can be performed by a plotting engine. Specifically, the plotting engine can first read the post-processed and grouped transaction dataset to obtain all unique group identifier combinations (pid, tid). For each such combination, the plotting engine can create an independent timeline track in the final generated graph. For example, these tracks can be arranged sequentially from top to bottom along the Y-axis, with each track corresponding to a specific task or thread within a specific transaction initiator. The number of tracks depends on the total number of groups; for example, if there are multiple CPU cores and DMA channels, the graph will present dozens or even hundreds of parallel timeline tracks, each carrying the transaction execution history of the corresponding task thread.

[0037] On each timeline track, the plotting engine can draw graphical elements representing the duration of each transaction within that group, based on the start and end times. For each transaction, the plotting engine can locate its start timestamp on the X-axis and draw a horizontal bar from the start to the end of the transaction, with the bar's length proportional to the transaction's duration. These horizontal bars can be rectangular bars, rounded bars, or graphical elements with other visual styles. Furthermore, to enhance readability, the plotting engine can assign different colors, patterns, or labels to the graphical elements corresponding to each transaction based on its name, visually distinguishing different transactions.

[0038] Furthermore, the plotting engine can generate interactive hypertext markup language formats, supporting interactive operations such as displaying detailed information on mouse hover, zooming on click, and panning by dragging. This allows the system to respond to user interactions with graphical elements on a grouped transaction activity timeline chart, displaying detailed transaction information associated with the corresponding graphical element. This detailed transaction information can include the transaction's attribute set or event information. For example, when a user hovers the mouse over a transaction bar, the plotting engine can pop up an information box displaying detailed information about the transaction, including the transaction name, start time, end time, duration, and transaction attributes of all records. Similarly, hovering over an event marker can display the event name, occurrence time, and related attributes. This interactive functionality allows designers to quickly delve into micro-details from a macro view, further enhancing the flexibility and efficiency of data analysis.

[0039] Figure 5The diagram illustrates an example of a grouped transaction activity timeline generated according to an embodiment of this application. The left side of the diagram vertically lists multiple transaction group identifiers, such as cfg_M, cfg_S, cmd, and multiple DDR channel transaction modules, each group corresponding to an independent timeline track. The horizontal axis represents the simulation timeline, extending from 0ms to 15ms. On each group's timeline track, the lifecycle of each transaction within that group is plotted as horizontal bars. The starting position and length of the bars correspond to the start time and duration of the transaction, respectively. For example, on the cmd group track, multiple cmd_cpy transaction bars are clearly seen arranged sequentially, intuitively demonstrating the sequential execution process of the command copy operation. Furthermore, request and response transaction bars on multiple DDR channel tracks appear alternately, reflecting the parallel access behavior of the multi-channel DDR controller, while the blank areas on each track clearly show the idle periods of the corresponding modules. Overall, this timeline diagram presents the execution status of multiple concurrent transactions in system-level modeling in an intuitive graphical way, enabling designers to clearly understand the interactions between modules, the concurrency relationships of transactions, and the timing behavior of the system.

[0040] In summary, the technical solution provided in this application transforms low-level signal waveforms into a high-level transaction view, enabling designers to quickly understand system behavior and locate performance bottlenecks and concurrency issues. The generated transaction activity timeline chart intuitively and graphically displays the temporal relationships of transaction concurrency, sequence, overlap, and idle time, overcoming the shortcomings of traditional text logs in visualizing the time dimension. It also focuses system performance analysis on the transaction layer, filtering out low-level signal details, which is more in line with the thinking of system-level designers. Furthermore, by grouping transactions using user-defined PID and tid identifiers, flexible analysis of system behavior from multiple dimensions such as modules, threads, and task types can be achieved. The lightweight code instrumentation marking function design has only a minimal impact on the original simulation performance and does not require modification of the simulation kernel, exhibiting significant advantages of low invasiveness and high practicality.

[0041] Figure 6 This is a schematic diagram of a computing device that can be implemented according to embodiments of the present invention, and can be used to implement the system or device described above for SystemC system performance analysis. For example... Figure 6 As shown, computing device 600 may include bus 602 or other communication mechanism for transmitting information, and one or more hardware processors 604 coupled to bus 602 for processing information. The one or more hardware processors 604 may include, for example, one or more general-purpose microprocessors.

[0042] like Figure 6As shown, in some embodiments, computing device 600 may further include main memory 606 coupled to bus 602. Main memory 606 is used to store information and instructions executed by one or more processors 604, such as random access memory (RAM), cache, and / or other dynamic storage devices. Main memory 606 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by one or more processors 604. These instructions, when stored in storage media accessible to one or more processors 604, can cause computing device 600 to become a dedicated machine customized to perform the operations specified in the instructions. Storage device 608 may include non-volatile and / or volatile storage media. Non-volatile storage media may include, for example, optical discs or magnetic disks. Volatile storage media may include dynamic memory. Common forms of storage media may include, for example, floppy disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, DRAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, or their networking versions.

[0043] like Figure 6 As shown, in some embodiments, computing device 600 may further include one or more communication interfaces 610 coupled to bus 602. Communication interface 610 may provide bidirectional data communication coupling to one or more network links connected to one or more networks. As another example, communication interface 610 may be a local area network (LAN) card to provide data communication connectivity to a LAN-compatible (or WAN component communicating with a WAN) network. Wireless links may also be implemented.

[0044] The execution of certain operations can be distributed across processors rather than residing within a single machine, but rather deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0045] Each of the processes, methods, and algorithms described herein may be embodied in code modules executed by one or more computer systems or computer processors including computer hardware, and may be fully or partially automated by these code modules. The processes and algorithms may be implemented, partially or fully, in dedicated circuit systems.

[0046] When the functions disclosed herein are implemented as software functional units and sold or used as stand-alone products, they may be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, may be embodied in the form of a software product. The software product may be stored in a storage medium and includes several instructions that cause a computing device (which may be a personal computer, server, network device, etc.) to perform all or some steps of the methods of the embodiments of this application. The storage medium may include a flash drive, portable hard disk drive, ROM, RAM, magnetic disk, optical disk, other media operable to store program code, or any combination thereof.

[0047] Specific embodiments further provide a system including a processor and a computer-readable storage medium storing instructions executable by the processor to cause the system to perform operations corresponding to steps in any method of the embodiments disclosed above. Specific embodiments further provide a computer-readable storage medium storing instructions executable by one or more processors to cause the one or more processors to perform operations corresponding to steps in any method of the embodiments disclosed above.

[0048] The embodiments disclosed herein can be implemented via a cloud platform, server, or server cluster (collectively referred to below as the "Service System") that interacts with a client. The client can be a terminal device or a client registered by a user at the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can have the platform application installed.

[0049] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Additionally, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and their associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in an order other than that specifically disclosed, or multiple blocks or states may be combined into a single block or state. Example blocks or states may be executed sequentially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The exemplary systems and components described herein may be configured differently than described. For example, components may be added to, removed from, or rearranged compared to the disclosed example embodiments.

[0050] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. The algorithm may be included in program code or instructions stored in memory (e.g., the aforementioned computer-readable storage medium). This algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not explicitly turn the computer into an execution function but may learn from training data to produce a predictive model of the execution function.

[0051] The various operations of the exemplary methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors can constitute an engine of processor implementation that operates to perform one or more of the operations or functions described herein.

[0052] Similarly, the methods described herein may be implemented at least in part by a processor, wherein one or more specific processors are instances of hardware. For example, at least some operations of the methods may be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors may also be operable to support the execution of relevant operations in a “cloud computing” environment or as the execution of relevant operations in a “Software as a Service” (SaaS) context. For example, at least some operations may be performed by a group of computers (as an example of a machine containing processors), wherein these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0053] The execution of certain operations can be distributed across processors rather than residing within a single machine, and can be deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0054] Throughout this specification, multiple instances may be implemented as components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of these individual operations may be performed simultaneously, and not necessarily in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as composite structures or components. Similarly, structures and functions presented as single components may be implemented as single components. These and other variations, modifications, additions, and improvements fall within the scope of this document.

[0055] As used herein, "or" is inclusive rather than exclusive unless explicitly indicated by the context. Therefore, in this document, "A, B, or C" means "A, B, A and B, A and C, B and C, or A, B, and C" unless explicitly indicated by the context. Furthermore, "and" is combined and separate unless explicitly indicated by the context. Therefore, in this document, "A and B" means "A and B, combined or separate" unless explicitly indicated by the context. Additionally, multiple instances of resources, operations, or structures described herein may be provided as a single instance. Furthermore, the boundaries between various resources, operations, engines, and data storage devices are somewhat arbitrary and specific operations are illustrated within the context of a particular illustrative configuration. Other functional assignments are foreseeable and fall within the scope of various embodiments of this disclosure. Generally, structures and functions presented as individual resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as single resources. These and other changes, modifications, additions, and improvements fall within the scope of the embodiments of this disclosure as expressed in the appended claims. Therefore, this specification and drawings should be considered illustrative rather than restrictive.

[0056] The terms “comprising” or “including” are used to indicate the presence of a subsequently claimed feature, but do not preclude the addition of other features. Unless otherwise specifically stated or otherwise understood in the context in which they are used, conditional language such as “may,” “can,” “may,” and “can” is generally intended to convey that certain embodiments include certain features, components, and / or steps that are not included in other embodiments. Therefore, this conditional language is generally not intended to imply that one or more embodiments require features, components, and / or steps in any way, or that one or more embodiments must include logic for determining whether such features, components, and / or steps are included in or performed in any particular embodiment, with or without user input or prompts.

[0057] Although the general outline of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broad scope of embodiments of this disclosure. Where more than one embodiment is disclosed, these embodiments of the subject matter may be referred to individually or collectively herein as the term "invention," this is for convenience only and is not intended to automatically limit the scope of this application to any single disclosure or concept.

[0058] The embodiments illustrated herein are described in detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Therefore, “implementation” is not intended to be limiting, and the scope of the various embodiments is defined only by the appended claims and their full scope.

Claims

1. A method for performance analysis of SystemC systems, characterized in that, include: Define a set of application programming interface functions for transaction marking, including a start function for marking the start of a transaction and an end function for marking the end of a transaction, wherein the start function and the end function include a transaction name parameter and a transaction group identifier parameter; The start function is called at the beginning of a transaction in the SystemC system, and the end function is called at the end of the transaction. During the simulation execution of the SystemC system, in response to the calls to the start function and the end function, transaction information associated with the transaction is captured and recorded. This transaction information includes the start timestamp and end timestamp of the transaction, the group identifier of the transaction, and the transaction name of the transaction. The transactions are grouped according to their grouping identifiers to generate one or more transaction groups; and An independent timeline track is generated for each transaction group, and graphical elements representing the duration of the transaction are plotted on this timeline track according to the start and end times of each transaction to generate a grouped transaction active timeline chart.

2. The method according to claim 1, characterized in that, The transaction group identifier parameter includes a first group identifier and a second group identifier. The first group identifier is used to identify the transaction initiator, and the second group identifier is used to identify the task or thread associated with the transaction within the transaction initiator.

3. The method according to claim 2, characterized in that, Grouping transactions according to their grouping identifier includes: The transactions are grouped into a first-level group based on the first group identifier, and then grouped into a second-level group within the first-level group based on the second group identifier, to form one or more transaction groups with a hierarchical structure.

4. The method according to claim 1, characterized in that, The transaction marking application programming interface function also includes an event function for marking event points within the transaction's lifecycle, the event function including an event name parameter.

5. The method according to claim 4, characterized in that, The method further includes: The event function is invoked at a designated event point within the lifecycle of the transaction; In response to the call of the event function, capture and record event information associated with the event occurring at the set event point; The event information is presented on the active timeline of the grouped transactions.

6. The method according to claim 5, characterized in that, The event information includes one or more of the following: the event type, the event name, the start and end timestamps of the event, and additional attributes of the event.

7. The method according to claim 1, characterized in that, Capturing and recording transaction information associated with the transaction includes writing the transaction information into a thread-safe global event data buffer for the SystemC system.

8. The method according to claim 1, characterized in that, Drawing graphical elements representing the duration of a transaction includes assigning different colors, patterns, or labels to the graphical elements based on the transaction name of the transaction, in order to visually distinguish different transactions.

9. The method according to claim 1, characterized in that, The method further includes: in response to a user's interactive operation on a graphical element on the grouped transaction active timeline, displaying detailed transaction information associated with the transaction corresponding to the graphical element, the detailed transaction information including the attribute set of the transaction or the event information of the transaction.

10. A computer-readable storage medium storing instructions, characterized in that, When executed by one or more processors, the instructions cause the one or more processors to perform the method according to any one of claims 1-9.

11. A computer program product, the computer program product comprising instructions, characterized in that, When executed by one or more processors, the instructions cause the one or more processors to perform the method according to any one of claims 1-9.

Images