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

I definitely agree with this idea. A traceback to the entity will be 
incomplete if your design contains multiple instances of the entity. I 
think a complete call stack (to the root of the design) would be better. 

The call from the entity into the package's function/operator will occur 
in a concurrent statement or a sequential statement. Both of those have 
optional labels that could uniquely identify the defective function call 
within an architecture. I don't recall if the LRM defines an implicit 
value for those labels when they are omitted, but the simulator I use 
definitely assigns default labels for each concurrent statement that is 
based on the line number. These labels may be a useful, unique part of the 
call stack if the LRM standardizes an implicit value for an unlabeled 
statement.

Paul

Paul.Butler@ni.com | (512) 683-8743 | National Instruments | Austin, TX





From:   Srinivasan Venkataramanan <svenka3@gmail.com>
To:     vhdl-200x@eda.org, 
Date:   10/10/2014 09:48 AM
Subject:        Re: [vhdl-200x] Change to "report" statements
Sent by:        owner-vhdl-200x@eda.org



Martin,
  I couldn't agree more! Especially when it emerges from numeric_std 
(during pre-reset for instance) it is lot of noise indeed. On backward 
compatibility - well many users rely on "log file comparison" (and many 
EDA tool regressions are built that way too), so I believe that would be 
desired.

A traceback till the *entity* will be very handy.

While we are at it, can you also please include the "report" available as 
part of PSL part of VHDL? It is quite primitive and doesn't allow computed 
strings/expressions that makes it very difficult to build 
custom/meaningful error messages. 

Thanks
Srini

On Fri, Oct 10, 2014 at 4:01 PM, Martin.J Thompson <
Martin.J.Thompson@trw.com> wrote:
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, and is 
believed to be clean. 


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


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