On Apr 5, 2012, at 4:51 AM, René Doß wrote:
> code:
> if signed(path_a) > signed(path_b) then
> compare(2) <= '1';
> else
>
> accident:
> In a situation is path_a="UUUUUU". The greather than is undefined. The
> warning is correct.
>
>
> My interesting is now:
> What is the code linie in my code and what signal is incorrect?
The numeric_std function ">" (in this case) can't peer into where it was called
from.
I did a little research and found I was mistaken previously.
The arguments L and R to function ">" are class constant, and it requires a
signal to see where the driver is (by using S'DRIVING).
This occurs because (IEEE Std 1076-1993, Section 2 Subprograms and packages,
Subprogram declarations):
2.1.1.1 Constant and variable parameters
For parameters of class constant or variable, only the values of the actual or
formal are transferred into or out of the subprogram call. The manner of such
transfers, and the accompanying access privileges that are granted for constant
and variable parameters, are described in this subclause.
and
2.1.1 Formal parameters
...
Formal parameters of subprograms may be constants, variables, signals, or
files. In the first three cases, the mode of a parameter determines how a given
formal parameter may be accessed within the subprogram. The mode of a formal
parameter, together with its class, may also determine how such access is
implemented. In the fourth case, that of files, the parameters have no mode.
For those parameters with modes, the only modes that are allowed for formal
parameters of a procedure are in, inout, and out. If the mode is in and no
object class is explicitly specified, constant is assumed. If the mode is inout
or out, and no object class is explicitly specified, variable is assumed.
For those parameters with modes, the only mode that is allowed for formal
parameters of a function is the mode in (whether this mode is specified
explicitly or implicitly). The object class must be constant,signal, or file.
If no object class is explicitly given,constant is assumed.
...
NOTE--Attributes of an actual are never passed into a subprogram: references to
an attribute of a formal parameter are legal only if that formal has such an
attribute. Such references retrieve the value of the attribute associated with
the formal.
The information is not present in the function ">" to find where in your VHDL
design hierarchy it was called from - only the value of the type conversions
are passed in this case and no attributes. There is no programatic way to
trace back calls without resorting to a debugger or violating the standard by
adding attributes.
We also can't use S'DRIVING (14.1) to determine the location of the driver.
That only works for modes inout, out or buffer and would point to the package
path name formal. The same holds true for L, R and ">" for E'INSTANCE_NAME or
E'PATH_NAME ("Package-based paths identify items declared within packages.
Full-instance-based paths identify items within an elaborated design
hierarchy",..."In a full path instance element, the architecture simple name
must denote an architecture associated with the entity interface designated by
the entity simple name; furthermore, the component instantiation label (and the
commercial at following it) are required unless the entity simple name and the
architecture simple name together denote the root design entity.", 14.1 text
following E'INSTANCE_NAME specification, same holds true for E'PATH_NAME).
If we specified a compliant mode these would return the package path name and
the assertion statement already tells us the line number in
numeric_std-body.v93. We can't get the instance path for a package element.
We're also not allowed to change the interface to the function ">" in any
event.
We are essentially blocked by the standard from providing what you want in a
VHDL design specification (your code or the numeric_std package referencing
calling parameters).
You could imagine we might generate a named entity map that included the calls
to ">", there could easily be more than one. Distinguishing which one
generated the error can't be handled legally by VHDL compliant simulator
("Attributes of an actual are never passed into a subprogram").
This sort of leaves three alternatives, write your own numeric standard
equivalent using mode inout where you need to peer at external driver values
(and not use type conversion losing the name of the driver), use a debugger
or adding a debugger element to the simulator. (There's also the case of
turning off NO_WARNING and ignoring the problem).
Adding something debugger-ish to ghdl could entail an instance stack trace,
where instance names of named entities other than package elements are stored
on a stack and popped off when departing the particular design element in
execution flow.
IIR stands for Internal Intermediate Representation and represents the elements
of a design hierarchy that are passed between an analyzer and a simulator for
VHDL whether or not these elements are mapped into machine code and/or
optimized.
Some number of these simulator elements would have to be modified to operate an
instance trace stack. The good news is that for purposes of telling where a
subprogram were called from you'd only need to locate the last stack element.
The bad news is that to get more information (line number for the particular
subprogram call) you'd need to push those too, as well as storing the calling
line numbers).
Likewise you could modify your calling conventions to push the information on
the stack along with subprogram call parameters. It seems this would be best
suited for a 'debug' mode. I'd be reluctant to do so all the time in my own
analyzer/simulator. In this particular case you'd be invoking it for assertion
warnings, which are not necessarily fatal. There is nothing 'wrong' to debug.
As you pointed out the assertion warnings are perfectly valid, operating as
written and intended. They can be ignored either by setting the NO_WARNING
constant TRUE or by ghdl simulator option:
4.1 Simulation options
--ieee-asserts=POLICY
Select how the assertions from ‘ieee’ units are handled. POLICY can be ‘enable’
(the default), ‘disable’ which disables all assertion from ‘ieee’ packages and
‘disable-at-0’ which disables only at start of simulation.
This option can be useful to avoid assertion message from ‘ieee.numeric_std’
(and other ‘ieee’ packages).
If you look through the function ">" in this case (numeric_std-body.v93 lines
1014 through 1038, and function TO_01 lines 2490 through 2514) you'd find that
the greater than operator returns FALSE for invalid input values (in this case
in either path_a or path_b). The impact of this says you can't count on the
results when an assertion warning occurs for functional verification. The way
to deal with this is insure you initialize any values that can propagate an
unknown to arithmetic evaluation and contemplate using the
--assert-level=warning simulator flag to abort simulation for such a warning
during functional verification. To weed out the don't care start up cases you
can use --ieee-asserts=disable-at-0, although it would be safer to provide
reset and default values that are defined.
What it boils down to is you can't bend VHDL to how your design model is
implemented, you're going to have to alter your design or alter how you
evaluate simulation for purposes of verification. This can also imply doing
your own numeric packages which would naturally inhibit portability.
If you wanted the most possibly correct implementation you could implement
arithmetic functions that can return 'X's. It'd be wonderful for pointing
out something you have to fix in your design model.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
