[vhdl-200x] RE: Change to "report" statements

I often write and use overloaded standard functions, e.g. to_integer(), in various packages (usually where the type is defined).

While I would like to know from which process the function was executed I still need to know where the offending function is defined. Knowing the complete call sequence (process->package-subprogram->package-subprogram...) would be even better.

I'm not sure this is a language issue, rather than a tool issue, unless we want to define a standard attribute ('called_from_process) to access that information.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX



From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Martin.J Thompson
Sent: Friday, October 10, 2014 5:32 AM
To: vhdl-200x@eda.org
Subject: EXTERNAL: [vhdl-200x] Change to "report" statements

Hi all,

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.

Some questions for discussion:
* What downsides might there be to such a change?
* If implemented, should it be configurable to allow previous behaviour?
* Are there times when you actually want the current behaviour?
* Would a full traceback (a la Python maybe) be better, or at least a traceback through other calls as far as the entity containing the report?

Thanks,
Martin

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.