(r2) ReportCallingPath < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>ReportCallingPath (revision 2) (raw view)~~EditAttach~~
---+ Report Calling Path of Subprogram

<br />%TOC%

---++ Proposal Details
   * Who Updates: Main.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 string which includes the name so that it can be passed to the report statement.

---+++ Code Examples
---++ Use Cases

Debugging large function collections like a strings package, could be solved more effectively.<br />Big function collections have intra package function calls, so it's hard to distinguish which<br />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<br />debugging process.

-- Main.PatrickLehmann - 2016-02-18
---++ Arguments FOR

-- Main.PatrickLehmann - 2016-02-18 The user is not dependent on a vendor tools debugging and trace capabilities.
---++ Arguments AGAINST

---++ General Comments

Not every report statement should polute the output/logfile. Many report statements with<br />a NOTE severity level are intended outputs with no need for a calling path / traceback.<br />This could be solved by introducing a verbosity level like the severity level.

report "Generic 'BITS' must be a power of two!"<br /> severity FAILURE<br /> verbosity [LINE_NUMBER|CALL_PATH|FULL_TRACEBACK];

-- Main.PatrickLehmann - 2016-02-18
---++ Supporters

-- Main.PeterFlake - 2014-11-13

-- Main.MortenZilmer - 2015-01-21

-- Main.PatrickLehmann - 2016-02-18
Topic revision: r1 - 2020-02-17 - 15:34:59 - TWikiGuest
P1076/Ballots