28 

13.3   Source Code Profiling

The built-in source code profiling facility allows the user to run any Covered command and understand performance metrics about the internal Covered source code, such as how many times a given function was called, how much wall-clock time was spent executing a given function, how many times a function allocated and deallocated memory from the heap, etc. This information can be useful in understanding where performance bottlenecks are during a given Covered command run. This feature does not provide the end-user any useful information about the design that they are testing.

13.3.1  Building Covered for Profiling

Because internal source code profiling is not a function of obtaining Verilog code coverage and adds a performance penalty for being compiled in and used, Covered requires the user to specify an option to the configuration/build process to enable this feature. To enable internal source code profiling, simply specify the --enable-profiling option to the configure script. This will cause Covered to compile in profiling capabilities and enable the use of the -P global option.

Note

If the user has not specified the --enable-profiling option to the configuration script but proceeds to specify the -P global option, Covered will emit a warning message that it is unable to do profiling due to the lack of the --enable-profiling option being specified. It will then proceed to ignore the -P option.

13.3.2  Using Source Code Profiling

Once Covered has had profiling functionality configured and built into it, the user may optionally enable profiling for any command by specifying the -P [filename] global option. If the -P option is specified without a filename associated with it, the profiling report generated from the command run will be output to a file called "covered.prof" in the same directory where Covered was run. If a filename is associated with the -P option, the contents of the profiling report will be output to that file.

Note

The specified filename can be anything except "score", "merge" or "report" as this name will be interpreted by Covered's command-line parser to indicate the type of command being run. If one of these command keywords are specified after the -P option, it is assumed that the user has not specified a filename and the contents of the profiling report will be sent to the default file of "covered.prof".

13.3.3  Understanding the Profiling Report

After a command has been run with the global -P option specified, a report file will contain several profiling statistics, including the following:

1. The amount of time spent running the entire command
2. The number of times each executed function was called
3. The total amount of wall clock time spent executing each function
4. The average amount of time spent executing each function
5. The number of times each function allocated heap memory
6. The number of times each function deallocated heap memory

In addition to providing this information on a per function basis, the profiling report also provides the information in three different sections with each function ordered from most to least by the following statistic columns:

1. The number of times each executed function was called
2. The total amount of wall clock time spent executing each function
3. The average amount of time spent executing each function

By ordering this information, it will help the users and developers determine where the performance bottlenecks in execution are for a given command run.

[  Contents  |  First Page  |  Previous Page  |  Home  |  Next Page  |  Last Page  ]