Appendix D: Profiler for Performance Analysis

Profiler is an Xcelium tool that measures where CPU time is spent during simulation. The profiler generates a run-time profile file (xmprof.out) that contains simulation run-time information that is useful for finding performance bottlenecks and for tuning a design description for better simulation performance. This information can be used to modify your designs for better simulation.

You can invoke the profiler using the -profile option with xrun. When the simulator exits, the profiler writes the profile to the xmprof.out file in the current or run directories.

Each profile begins with a header that provides general information. The information contained in the header can reveal performance problems such as insufficient physical memory for the size of the simulation, or low CPU utilization due to a busy machine or waiting for I/O.

After the header, the profile is divided into three main sections: Mixed-signal simulation summary, Digital Simulation Profile Results, and Analog Simulation Profile Results. The tables in those sections share the following column headers:

The following are some examples of the simulation summary of mixed-signal, digital, and analog designs.

Mixed-Signal Simulation Summary

The mixed-signal simulation summary shows how simulation time divides between the analog solver and the digital solver. For example, the following report shows that 97% of the hits occurred in the analog solver.

------------------------------------------------------------
Mixed-signal simulation summary (1766 hits total)
------------------------------------------------------------

%hits #hits domain
 97.0 1713 Analog
  3.0 53 Digital
------------------------------------------------------------

Digital Simulation Profile Results

The digital simulation profile results section summarizes information for the digital solver in three different ways: Stream Counts, Most Active Modules (behavioral), and Stream Type Summary Counts. 

Stream Counts

The Stream Counts section provides information about time spent in individual generated code streams. These code streams correspond to specific HDL source constructs. They include

• always blocks

• initial blocks

• Continuous assignments

• Tasks and functions

• Non-blocking assignments

• Quasi-continuous assignments

• Parallel block sub-processes (statements inside fork/join)

• Logic primitives for gates and UDPs (because logic primitives share the same code between different instances, the profiler cannot indicate which gate instances are taking up the most time)

The beginning of the Stream Counts section is the first place to look for inefficiency. If a few streams are taking up most of the simulation time, simulation cannot be sped up significantly without reducing the time in those streams.

The following is an example of a Stream Counts section.

------------------------------------------------------------
Stream Counts (53 hits total)
------------------------------------------------------------

%hits #hits #inst name
28.3     15 [   ] Library function minnow (time callbacks)
24.5     13 [   ] tcl_functions
15.1      8 [   ] Method SSS_KM_CL2TA (method)
15.1      8 [   ] outside engine
5.7       3 [   ] Method SSS_KM_FINDRFT (method)
3.8       2 [  1] Always stmt (file: /net/mach111/cds/ams/ldv51/tools/affirma_ams/etc/connect_lib/elect2logic.v, line: 69 in connectLib.elect2logic    [module])
3.8       2 [   ] Library function rtl_analog_demand
1.9       1 [   ] Method SSS_MT_SA_PROCESS (method)
1.9       1 [   ] ssslib snare support

The example of the Stream Counts section shown above contains a category called outside engine. This category, and another called engine support, are catch-all categories for activities that cannot be otherwise categorized.

Most Active Modules

The Most Active Modules section of the profile summarizes the stream counts by module. For each module listed, the profile lists the sum of the counts in all of the streams.

The following example shows a Most Active Modules section.

------------------------------------------------------------
Most Active Modules (behavioral)
------------------------------------------------------------

%hits #hits #inst name
  3.8     2 [  1] connectLib.elect2logic:module (file: /net/mach111/cds/ams/ldv51/tools/affirma_ams/etc/connect_lib/elect2logic.v line: 60)

Stream Type Summary Counts

The Stream Type Summary Counts section summarizes the stream counts by the type of stream or other activity. For example, there might be a total for logic primitives, timing checks, always or initial statements, non-blocking assignments, continuous assignments, and so on.

The summary makes it easier to identify widespread inefficiencies in the simulation. For example, large amounts of time spent on probing, file I/O, and PLI show up most clearly in this section.

The following example shows a Stream Type Summary Counts section:

------------------------------------------------------------
Stream Type Summary Counts (53 hits total)
------------------------------------------------------------

%hits #hits #inst name
32.1     17 [   ] System tasks/functions or library functions
24.5     13 [   ] VCD/SHM variable dumping
22.6     12 [   ] Standard methods (mostly fanout propagation)
15.1      8 [   ] Outside engine
3.8       2 [  3] Always statements
1.9       1 [   ] Support for VPI callbacks (or UI)

Analog Simulation Profile Results

The Events and Operators section of the Analog Simulation Profile Results reports performance measurements for analog constructs, including, for Verilog^®-AMS

• transition

• @cross

• Accessing digital variables and nets from an analog context

and including, for VHDL-AMS

• S'ramp

• Q'above

• Accessing digital variables and nets from an analog context, with or without break statements.

The following example shows an Events and Operators section.

------------------- Events and Operators -------------------
------------------------------------------------------------

%cost #hits type instance
4.4   135 dVar       top.dac:dacOut (file: AMS_lib/daconv.vhd line: 22)
4.4   135 dVar       top.dac:dacOut'DELAYED (file: AMS_lib/daconv.vhd line: 37)
4.4   135 filter     top.dac (file: ../../../../.././AMS_lib/daconv.vhd line: 37)
0.5    15 filter     top.sh (file: AMS_lib/samplehold.vams line: 38)

Related Topic

• xrun Command-Line Options for Mixed-Signal Designs