Use for 'simple_name attribute

i've used the 'simple_name attribute in the following manner:


variable v_my_var : integer;
variable v_line : line;

--- lots of code

write(v_line , v_my_var'simple_name & string'(" = ") );
write(v_line , integer'image(v_my_var) );
writeline(output , v_line);

The benefit is that if the name v_may_var changes, then the write
function calls must also change, and the label in the print statement
keeps in synch with the actual variable name.

If the code was this:

write(v_line , string'("v_my_var' = ") );
write(v_line , integer'image(v_my_var) );
writeline(output , v_line);

and the name v_my_var changed, then nothing ( except the keen eyes of
the coder ) would prevent the printed variable label from remaining
the outdated name. Any comments?

Reuven wrote:
> i've used the 'simple_name attribute in the following manner:
> ...
> and the name v_my_var changed, then nothing ( except the keen eyes of
> the coder ) would prevent the printed variable label from remaining
> the outdated name.

> Any comments?

I would prefer to use a simulation wave or list for debugging
or an assertion for verification.

-- Mike Treseler

On Aug 19, 3:32 pm, Reuven <rpaley...@gmail.com> wrote:
> i've used the 'simple_name attribute in the following manner:
>
> variable v_my_var : integer;
> variable v_line : line;
>
> --- lots of code
>
> write(v_line , v_my_var'simple_name & string'(" = ") );
> write(v_line , integer'image(v_my_var) );
> writeline(output , v_line);
>
> The benefit is that if the name v_may_var changes, then the write
> function calls must also change, and the label in the print statement
> keeps in synch with the actual variable name.
>
> If the code was this:
>
> write(v_line , string'("v_my_var' = ") );
> write(v_line , integer'image(v_my_var) );
> writeline(output , v_line);
>
> and the name v_my_var changed, then nothing ( except the keen eyes of
> the coder ) would prevent the printed variable label from remaining
> the outdated name. Any comments?

How would v_my_var get changed everywhere other than a search and
replace? Wouldn't that also change it in the write statement?

Rick

On Aug 25, 1:19 pm, rickman <gnu...@gmail.com> wrote:
> On Aug 19, 3:32 pm, Reuven <rpaley...@gmail.com> wrote:
>
>
>
> > i've used the 'simple_name attribute in the following manner:
>
> > variable v_my_var : integer;
> > variable v_line : line;
>
> > --- lots of code
>
> > write(v_line , v_my_var'simple_name & string'(" = ") );
> > write(v_line , integer'image(v_my_var) );
> > writeline(output , v_line);
>
> > The benefit is that if the name v_may_var changes, then the write
> > function calls must also change, and the label in the print statement
> > keeps in synch with the actual variable name.
>
> > If the code was this:
>
> > write(v_line , string'("v_my_var' = ") );
> > write(v_line , integer'image(v_my_var) );
> > writeline(output , v_line);
>
> > and the name v_my_var changed, then nothing ( except the keen eyes of
> > the coder ) would prevent the printed variable label from remaining
> > the outdated name. Any comments?
>
> How would v_my_var get changed everywhere other than a search and
> replace? Wouldn't that also change it in the write statement?
>
> Rick

I think the general problem being addressed here, is that a *single*
change (of variable name) typically requires *two* edits (a use, and a
string) to keep the debug code in sync. This always leaves the door
open to missing one of those changes due to the inevitable typing
faults and then your debug info becomes misleading or useless. If you
do a global search and replace, you're probably safe, but people don't
always do blind S&R.

In the "C" language, I can make use of macros to achieve the nicer
scenario where there's only one change to be made in the debug
statmenent, something akin to

#define DEBUG_INTEGER(var) printf("%s=%d", #var, var)

then I can write

DEBUG_INTEGER(fifo_level_a);

and it's pretty clear that the printf will always be "in sync with
itself". In contrast, writing

printf("fifo_level_a = %d", fifo_level_b)

may still compile, but will likely mislead you (hint: look at the _a
versus _b).

The OP's solution still has the drawback that you need to update the
variable name in two places, but has the distinguishing property that
you get a compile time error that the variable doesn't exist if (or
when :-) you forget to edit the SIMPLE_NAME prefix.

I wonder if you could make some creative use of dynamic parsing of the
hierarchical name returned by the E'INSTANCE_NAME attribute, buried
inside an entity or block, and called using the same mechanisms of the
dynamic callback approach described in Bergeron's testbenches book, to
try to limit the change to a single mapped port name, achieving both
type-safety and singular interface name, as the "C" example above.

- Kenn

On Aug 25, 1:07 pm, kennheinr...@sympatico.ca wrote:
> The OP's solution still has the drawback that you need to update the
> variable name in two places, but has the distinguishing property that
> you get a compile time error that the variable doesn't exist if (or
> when :-) you forget to edit the SIMPLE_NAME prefix.

You will only get a compile time error if the original variable
declaration was replaced by that of the new variable. If an additional
variable was declared and substituted for the original, you would get
no compiler error, but the debug message would still be incorrect. Not
a perfect solution, but perhaps still helpful...

Andy

On Aug 25, 4:07 pm, Andy <jonesa...@comcast.net> wrote:
> On Aug 25, 1:07 pm, kennheinr...@sympatico.ca wrote:
>
> > The OP's solution still has the drawback that you need to update the
> > variable name in two places, but has the distinguishing property that
> > you get a compile time error that the variable doesn't exist if (or
> > when :-) you forget to edit the SIMPLE_NAME prefix.
>
> You will only get a compile time error if the original variable
> declaration was replaced by that of the new variable. If an additional
> variable was declared and substituted for the original, you would get
> no compiler error, but the debug message would still be incorrect. Not
> a perfect solution, but perhaps still helpful...
>
> Andy

Agreed, there are still lots of ways it could fail, especially
considering various scoping and visibility scenarios - there could
still be names visible from packages in a separate file, for example.

And scratch my earlier rambling about blocks, mapping, and the
E'PATH_NAME and E'INSTANCE_NAME attributes. Neither attribute follows
the hierarchy of the VHDL net through the association element; they
only convey the static scoping. Too bad.

- Kenn