How to use incremental profiling to analyze reasons for slow simulation speeds with circuit-level models (CLMs)

Yes, there is. You can use the $xmodel$cktsim_profile() system function to perform incremental profiling on the XMODEL CLM simulation runtimes. For instance, when you insert the following line to your top-level testbench module, XMODEL outputs the incremental profile statistics at user-defined time intervals.

initial $xmodel$cktsim_profile("interval=", 600, "num_cluster=", 20);

Here the "interval=" argument of the $xmodel$cktsim_profile() system function defines the time interval of the incremental profiling in units of seconds (the default value is -1, meaning no incremental profiling), and the "num_cluster=" argument defines the number of most time-consuming circuit clusters to be reported (the default value is 10). The above example instructs XMODEL to report the incremental profiling results every 600 seconds, displaying up to 10 most time-consuming circuit clusters.

Here is an example of the incremental profiling results:

------------------------------------------------------------
INCREMENTAL PROFILE AT TIME=3187131 (2018-11-23 18:21:21)
------------------------------------------------------------
RUNTIME STATISTICS:
    PROCESS_EVENT: 2282 iterations (total: 2282), 4.389 seconds (total: 4.389)
    MNA2TF: 3292 iterations (total: 3293), 2.107 seconds (total: 2.108)
    DC SOLVER: 195 iterations (total: 196), 0.900 seconds (total: 0.901)
    PRE_SAMPLE: 15023 iterations (total: 15024), 0.088 seconds (total: 0.088)
    COMPUTE_OUTPUT: 15023 iterations (total: 15024), 1.159 seconds (total: 1.159)
    VERIFY_LEVEL: 15023 iterations (total: 15024), 0.200 seconds (total: 0.200)
    VERIFY_FIND_CROSS: 14698 iterations (total: 14698), 0.618 seconds (total: 0.618)
    PRE_VERIFY_LEVEL: 8951 iterations (total: 8951), 0.032 seconds (total: 0.032)
                                                                                                                                  
TOP-20 CLUSTER STATISTICS:
    #0: CLUSTER #70592 containing tb_test.VBLEQ (# poles: 5~35):
       205 iterations (total: 205), 1.084 seconds (total: 1.084)
    #1: CLUSTER #233162 containing tb_test.u_OSC1.n1d (# poles: 15~16):
       530 iterations (total: 530), 0.478 seconds (total: 0.478)
……

The first line starting with "INCREMENTAL PROFILE AT TIME…" displays the current simulation time and wall clock time, from which you can tell the progress rate of the simulation. The "RUNTIME STATISTICS" section displays both the incremental and total number of iterations and execution times of various operations performed by the XMODEL CLM engine. If the simulation slows down at a certain time interval, you can look for operations of which number of iterations or execution time increases sharply during that interval. The "TOP-XX CLUSTER STATISTICS" section lists the circuit clusters that consumed the most times during the last time interval. From this list, you can tell which part of your circuit made the simulation slow.

There are largely two factors that can slow down the XMODEL CLM simulation.

1. First, when a circuit cluster is large containing many nodes and energy storage elements (e.g. capacitors and inductors), it may take long to extract transfer functions from the circuit. In this case, you may find the MNA2TF operation consuming large portion of the total execution time. The circuit clusters that have more than 100 poles and consumed the longest time are the possible culprits. Once you identify the problematic circuit cluster, possible remedies include partitioning the cluster into smaller ones by inserting isolation buffers, and reducing its pole count by removing capacitances or setting level_ac option to 0.

2. Second, the simulation progress can become slow when the number of events being triggered increases. In this case, you may find the number of the COMPUTE_OUTPUT iterations rising sharply. The circuit clusters with high iteration counts during the time interval are the possible culprits. Once you identify the problematic circuit cluster, analyze the cause for the increased number of events. The events could be triggered by the input signals, or by the internal transistors switching. Depending on the cause, you may apply proper remedies.