User Guide: DSim Profiling

Modified on Thu, 11 Jul at 11:43 AM

User Guide: DSim Profiling

The profiling feature provides several reports enabling some analysis of the design wrt the impact of the HDL code on the overall execution time of the simulation.

Profiling has some limitations and although it provides significant value it is not a full featured profiling tool.

Options

Option	Description
`-profile`	Enable cpu time profiling for the entire simulation reporting at the given level.
`-profile-start <time>`	Start profiling at the given simulation time
`-profile-end <time>`	End profiling at the given simulation time
`-gen-profile`	Compile time option to instrument code to track number of times a function is called during simulation. Results reported when -profile is used

Specifing the -profile* options causes DSim to sample the running functions during the simulation. See the Sampling section below for details.

The profiling start/stop indicators take precedence:

If -profile is not given then the default reporting level is 0 and the profiling window will be dictated by the the -profile-start and -profile-end times
If -profile is used then level will be the reporting level and the profiling window will be dictated by the the -profile-start and -profile-end times
If no start/end options are given but -profile level is provided, the profiling window will be the entire simulation, and the reporting level will be as given.

Levels:

0 - Only user defined code is reported profiled % time values are wrt to a total that does not include time spent in "system" functions.
1 - Both user code and "system" functions are recorded. The time "system" functions are reported as an single aggregated entry in the report. % time values are wrt a total that includes time spent in "system" functions.
2 - Both user code and "system" functions are recorded. The time "system" functions are reported in a semi-aggregated way in the report. % time values are wrt a total that includes time spent in "system" functions.
3 - Both user code and "system" functions are recorded. No aggretation is done. % time values are wrt a total that includes time spent in "system" functions.

Sampling

DSim uses a sampling approach to produce the base data for the profile. The running simulation is sampled at a rate of 100 samples/second and for each sample the running function address is used to look up the function name.

Profiling a short run can be misleading because the total number of samples is not sufficient to reflect what is really happening. For example, if I see 5 hits on one function and 10 hits on another, that doesn't necessarily mean that the second function takes up twice the run time as the first. We could be unlucky as to where the samples fall. If, however, you see 50 vs 100 samples that's more convincing. Another approach to gain confidence in the profile accuracy wrt specific functions is to run the test multiple times.

The longer the profiling run the more accurate the data. That said there could obviously be different behaviours in different parts of the simulation and in that case using the start/end options can be useful to isolate those different parts.

Profile Reports:

Several reports are printed at the end of the simulation. Usint -gen-profile option during compilation instruments the image to count the number of times a function is called and then the reports will have a #Calls column. The function table is aggregated to the level specified as discussed above.

The following line is printed just before the reports:

=N:[Profile] DSim profile report

That is followed by these reports in table format

A detailed view of Functions aggregated to the level specified
A summary by Module/Entity(Arch)/Package
A summary by Functional Area

File/Line references

The profiler attempts to associate each entry in the Functions table back to an input file and line number. However, that is not always possible because DSim has certain optimizations which result in merging user defined code. When a function representing merged code is sampled it is not possible to related it back to the input file and line number.

If the -noopt option is provided the simulation runtime will suffer but the profiling information will be attributable to specific position in the input files.

User provided library code is also profiled and if the function symbols are availble the function names will be reported, although not the original file/line numbers. If the symbols are not available in the library then only the library name will be reported.

Minimum %time

Entries for which the %time is 0.01% are note reported.

Variability

Due to variablity in the load on the machine and the nature of sampling, the results will differ between runs but the largest contributors to runtime should still be reported at the top of the tables.