Requirement Name

Proposal Details

  • Who Updates:
  • Date Proposed:2014-10-17
  • Date Last Updated:
  • Priority:
  • Complexity:Easy
  • Focus:

Current Situation

The report statement - when executed within a subprogram - contains the instance path to said subprogram. In many cases this is not useful information to the user. For eaxmple, the numeric_std package issues warning for metavalues input to arithmetic operators, but it is very difficult to find out where these have come from.

Requirement

That the report statement should include the instance path to the statement within an instance of an entity currently being "executed" within simulator. The statement within an instance could be flagged either by line number or by label (if one is available). For example "/top/dut/block/process_name/line_nnn" or "/top/dut/block/line_nnn".

Implementation details

This information should be readily available to the simuator, so this functionality should be relatively easy to implement. No doubt a switch to reverty to the previosu behaviour will be provided.

Also note that the current LRM specifies only a minimum report statement, there's nothing to stop a vendor implementing more detailed reporting already, but none have.

Arguments FOR

Ease of tracking down source of warnings.

Arguments AGAINST

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

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

-- DavidKoontz (reflector 2014-10-13)


-- DavidKoontz - 2014-10-17 And this makes the second time. Please do not reproduce my remarks from the email reflector in support or oposition of your proposals as if signed, it's inappropriate. In this case it's not 'Your signature to copy/paste'.

General Comments

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.

-- Srinivasan Venkataramanan (reflector 2014-10-10)

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.

-- Paul Butler (reflector 2014-10-10)


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.

-- AndyJones (reflector 2014-10-10)


Supporters

-- MartinThompson - 2014-10-17

Opposers


This topic: P1076 > WebHome > Vhdl2019CollectedRequirements > ChangeReportPath
Topic revision: r3 - 2020-02-17 - 15:34:28 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback