Report Calling Path of Subprogram
Proposal Details
- Who Updates: PatrickLehmann
- Date Proposed:
- Date Last Updated: 2016-Feb-19
- Priority:
- Complexity:
- Focus:
Current Situation
One of my peeves with VHDL as it stands is that report statement include “the name of the design unit containing the port statement”. In many cases, the design unit is a package containing a multi-purpose procedure, such as numeric_std. One of the times this causes me much annoyance is when I get warnings of metavalues from numeric_std, the report statement gives me no clue as to which part of my design is “defective”. I care not where the report statement is, I care what lead to it.
I would prefer that the report statement contained the instance path(+line number of the code) of the
entity which lead up to it.
Requirement
I was thinking more of the instance_path being to an instance of an entity, such as /DUT/level1/inst_1_of_level_2/process_name/line99 or some such… instead of just the path to the subprogram which reported.
Also there is a related requirement for the path name of a protected type instance.
It seems this could be generalized by providing a function that returns the calling path as a string and passes it to report.
6/30/2016 see also
PathnameSharedVarSubprograms
Implementation details
There are two approaches to satisfying this requirement: (1) Enhance the tool to include more information in the report statement. (2) Provide a method to get a string with the call stack information that can be passed to the report statement or other methods of printing
Option 1: Enhance the report statement
Debugging large function collections like a strings package, could be solved more effectively.
Big function collections have intra package function calls, so it's hard to distinguish which
other function/process/constant initializer/ ... called that function with a faulty parameter.
A more verbose report statement especially for error and failure reports could ease the
debugging process.
--
PatrickLehmann - 2016-02-18
Not every report statement should polute the output/logfile. Many report statements with
a NOTE severity level are intended outputs with no need for a calling path / traceback.
This could be solved by introducing a verbosity level like the severity level.
report "Generic 'BITS' must be a power of two!"
severity FAILURE
verbosity [LINE_NUMBER|CALL_PATH|FULL_TRACEBACK];
--
PatrickLehmann - 2016-02-18
Option 2: Provide a method to get the call back stack information
Rather than implement a feature that only works only with report, lets instead create a tool box feature that can be used by any statement that works with type string. For report, it would be called as follows:
report "Yada Yada" & to_string(MySubprogram'CALL_SIMPLE_NAME) ;
So in essence, we need a set of attributes that get the call stack information:
- E'CALL_SIMPLE_NAME -- names of subprogram in the form of a simple name
- E'CALL_INSTANCE_NAME -- names of the subprogram in the form of an instance name
- E'CALL_PATH_NAME -- names of the subprogram in the form of a path name.
Next we need a to_string function that converts the call stack information to a string.
The language defined to_string prints the file name, the line number, and the path for all items on the call stack in the following format:
file_name:line_number:path {file_name:line_number:path}
The further benefit of this approach is that if a different format is needed (such as line feeds rather than spaces), you simply provide an alternative to to_string that formats the call stack. Options for these sort of things can be provided by your favorite open source library.
Arguments FOR
--
PatrickLehmann - 2016-02-18 The user is not dependent on a vendor tools debugging and trace capabilities.
Arguments AGAINST
Supporters
--
PeterFlake - 2014-11-13
--
MortenZilmer - 2015-01-21
--
PatrickLehmann - 2016-02-18