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

But 'instance_name doesn't give you the instance of the entity (from within subprogram), it gives you the instance_path of the subprogram, which is not helpful in many cases.  If there were an attribute which allowed one to get 'entity_instance_path, that would be more useful to me for example.

While I agree that the minimum is what the standard specifies, I don't see anything changing to be more useful (to me and others) without increasing said minimum.  Maybe I'm naïve, but I don't see how it can be a huge overhead at the point at which a report is called for the simulator to trawl its existing datastructures and find out what entity is currently at the front of the schedule?

Cheers,
Martin

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of David Koontz
Sent: 10 October 2014 19:18
To: VHDL IEEE
Subject: Re: [vhdl-200x] Change to "report" statements

"The report message consists of at least the following ..."

For finding the hierarchical path to a declared entity there's 'INSTANCE_NAME.

There isn't a defined mechanism for finding a call trace, nor limiting how far back it goes.  There is no requirement for a call stack for dynamically elaborated subprogram calls other than language definition superimposed on implementation.

The burden overhead sounds potentially high as well either requiring "calls" be stack organized or involve passing a tag, or 'INSTANCE_NAME which is less precise, and more verbose. I'd imagine any non stack trace implementation would impact simulator performance, A string on a 'stack' more so than an integer tag. Both also likely ABI issues for the host system for an implementation (as does a stack trace).

The passed tag or INSTANCE_NAME methods are the equivalent of uniquely declaring return values in expressions or the expressions themselves and function calls are dynamically elaborated by copying the values of interface elements.

The standard doesn't deal with 'hidden things' other than implicit declarations. and their visibility is limited by scope.

Unfortunately (or perhaps fortunately) this is an implementation issue. The minimum requirement is specified for a report statement, not the maximum.


On 11 Oct 2014, at 4:55 am, Paul Butler <paul.butler@ni.com<mailto:paul.butler@ni.com>> wrote:


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<mailto:Paul.Butler@ni.com> | (512) 683-8743 | National Instruments | Austin, TX





From:        Srinivasan Venkataramanan <svenka3@gmail.com<mailto:svenka3@gmail.com>>
To:        vhdl-200x@eda.org<mailto: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<mailto: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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.


--
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<http://www.mailscanner.info/>, and is
believed to be clean.


--
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.