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

Hi Paul,

Sorry, I wasn’t very clear… I’, not I advocate a full traceback (as it’s a much bigger change) personally,  but if it were to be implemented, a traceback needs to be sufficient to guide the user to a specific instance.

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.

Cheers,
Martin

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Paul Butler
Sent: 10 October 2014 16:55
To: vhdl-200x@eda.org
Cc: owner-vhdl-200x@eda.org
Subject: 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<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, and is
believed to be clean.