Getting the current instance name
Kai Troester
In a package I have a procedure which should print the time, the
instance and a message (I don't want to use the assert statements). My
problem is getting the name of the instance which is calling this
procedure without passing an additional parameter beside the message.
For time one can use 'now', but for the instance ? Does somebody have a
clue ?
Thanx, Kai
--
----- Dipl. Ing. Kai Troester -------------------------------------
Design Engineer -- System Design
IMMS - Institute of microelectronics and mechatronic systems
Langewiesener Strasse 22, 98693 Ilmenau, Germany
Tel: +49(3677)6783-52 | Fax: +49(3677)6783-38
mailto:kai.tr...@imms.de | http://www.imms.de/~troester
-------------------------------------------------------------------
Srinivasan Venkataramanan
There are predefined attributes
X'path_name
X'instance_name
in VHDL-93!
Try them out. (I read from Ashenden's book that they are ill-defined by
the LRM, don't know the current status though)
HTH,
Srini
In article <3A1BC2F0...@imms.de>,
--
Srinivasan Venkataramanan
ASIC Design Engineer
Chennai, India
Sent via Deja.com http://www.deja.com/
Before you buy.
Kai Troester
>
> Hi,
> There are predefined attributes
>
> X'path_name
>
> X'instance_name
>
> in VHDL-93!
>
> Try them out. (I read from Ashenden's book that they are ill-defined by
> the LRM, don't know the current status though)
I already tryed these, but either I need an additional parameter to
pass, or I get the 'path_name of the package.
Srinivasan Venkataramanan
I guess that's due to the fact that the "procedure" which writes out
this value resides inside a package (I didn't read that line
before..). For items declared within a package the "path_name" and
"instance_name" would return the same string i.e. the
library.package.item
Sorry couldn't help much. If you do find a way around, kindly let us
(me) know :-)
BTW, what do you mean by "I don't want to use assert/report" - then
how do you get it displayed - through write ?? (to std_lout)
Srini
--
Posted from sindhu.rrsycore.co.in [202.54.34.66]
via Mailgate.ORG Server - http://www.Mailgate.ORG
e...@riverside-machines.com.nospam
wrote:
>Hi
>
>In a package I have a procedure which should print the time, the
>instance and a message (I don't want to use the assert statements). My
>problem is getting the name of the instance which is calling this
>procedure without passing an additional parameter beside the message.
>For time one can use 'now', but for the instance ? Does somebody have a
>clue ?
You'll have to pass an additional parameter [can you use a
preprocessor to do this? ie. #define debug(x) debug2((x),
(x)'PATH_NAME)].
The problem is that 'PATH/INSTANCE_NAME applied to anything in a
subprogram returns the path to the point where the subprogram body was
declared (whether or not it's in a package, so you'll have this
problem for any procedure). I guess this restriction is to allow
compilers to statically determine all PATH/INSTANCE_NAMEs. The names
would be dynamic if they did what you wanted.
Evan
Srinivasan Venkataramanan
In article <3a1e49db...@news.dial.pipex.com>,
e...@riverside-machines.com.NOSPAM wrote:
> On Wed, 22 Nov 2000 13:58:24 +0100, Kai Troester <troe...@imms.de>
<snip>
> The problem is that 'PATH/INSTANCE_NAME applied to anything in a
> subprogram returns the path to the point where the subprogram body was
> declared (whether or not it's in a package, so you'll have this
> problem for any procedure). I guess this restriction is to allow
> compilers to statically determine all PATH/INSTANCE_NAMEs. The names
> would be dynamic if they did what you wanted.
>
I am not sure if I understand the reasoning well here. I thought it
would be possible to "freeze" the "instance name" during Elaboration
(When the complete design hierearchy is known). So why should it be
known during Compilation itself (as an example Generics can be changed
during elaboration - isn't it?)
I would really like to see the "INSTANCE_NAME" attribute to *exactly*
report the instance name and not just a path name.
Thanks for any more insight.
Regards,
Srini
RoLm
>
> I am not sure if I understand the reasoning well here. I thought it
> would be possible to "freeze" the "instance name" during Elaboration
> (When the complete design hierearchy is known). So why should it be
> known during Compilation itself (as an example Generics can be changed
> during elaboration - isn't it?)
>
> I would really like to see the "INSTANCE_NAME" attribute to *exactly*
> report the instance name and not just a path name.
>
> Thanks for any more insight.
>
> Regards,
> Srini
>
at elaboration the heirarchy is known but for attributes 'instance_name
and 'path_name, that doesn't buy you anything. unfortunately, the
hierarchy is not commuted into these attributes, specifically in the
case of ports to a sub program.
use the following code for example:
entity deja is
end entity deja;
architecture bhv of deja is
signal sig1 : bit;
procedure test (
signal in1 : in bit) is
begin
report in1'instance_name;
end procedure test;
begin -- architecture bhv
main: process is
begin -- process main
test (sig1);
report sig1'instance_name;
wait;
end process main;
end architecture bhv;
running this code produces the following output:
# ** Note: :deja(bhv):test:in1
# ** Note: :deja(bhv):sig1
which is what one should expect because the 'instance_name in the
procedure is for the port IN1, not the parameter passed to it! 8)
in order to get the instance_name of the signal into the procedure, you
need another parameter. for example, changing the procedure to:
procedure test (
signal in1 : in bit;
constant in1_inst : in string) is
begin
report in1_inst;
end procedure test;
and the function call to:
test (sig1, sig1'instance_name);
gives the output:
# ** Note: :deja(bhv):sig1
# ** Note: :deja(bhv):sig1
i hope this helps, ciao! 8)
RoLm
e...@riverside-machines.com.nospam
>>
>> I am not sure if I understand the reasoning well here. I thought it
>> would be possible to "freeze" the "instance name" during Elaboration
>> (When the complete design hierearchy is known). So why should it be
>> known during Compilation itself (as an example Generics can be changed
>> during elaboration - isn't it?)
This was just my guess as to why it's implemented this way. In
general, you can't determine a complete hierarchical path to a named
item until runtime. Consider that subprograms are only elaborated at
runtime. It could be a real headache for a simulator to work out a
path to an item in a recursive procedure, for example, at runtime.
Evan
bk...@hotmail.com
> Hi
>
> In a package I have a procedure which should print the time, the
> instance and a message (I don't want to use the assert statements). My
> problem is getting the name of the instance which is calling this
> procedure without passing an additional parameter beside the message.
> For time one can use 'now', but for the instance ? Does somebody have a
> clue ?
>
> ----- Dipl. Ing. Kai Troester -------------------------------------
> Design Engineer -- System Design
> IMMS - Institute of microelectronics and mechatronic systems
> Langewiesener Strasse 22, 98693 Ilmenau, Germany
> Tel: +49(3677)6783-52 | Fax: +49(3677)6783-38
> mailto:kai.tr...@imms.de | http://www.imms.de/~troester
> -------------------------------------------------------------------
$display("dbg instance name %m at %d", $time);
An example how to print an instance name in systemc is also available on this site.
The importance of such debug information is when a design contains many instances of the very same component.
First text IO library has to be called and line variable should be declared. Please refer to print example to see details.
Next you have to select between two options: One is: instance name only in debug string and the other option gives more information such as entry and architecture names.
Syntax example is given below:
if(newByte = '1') then
write (my_line, string'("path "));
write (my_line, clk'path_name);--short
write (my_line, string'(" "));
writeline(output, my_line);
write (my_line, string'("inst "));
write (my_line, clk'instance_name);--long
write (my_line, string'(" "));
writeline(output, my_line);
Please see a detailed explication at
http://bknpk.ddns.net/my_web/MiscellaneousHW/vhdl_path_name_print.html
diog...@gmail.com
The only way to get the calling location is through a passed parameter on the calling stack.
There is a proposal to pass the calling_path in a hidden fashion on the call stack (as an attribute which is a basic operation). That would require a significant amount of overhead putting some potentially long string on the calling stack impacting performance tremendously.
You could abstract that away to making a call a pseudo object, where you only pass an index that tells you were to find it. Not sure if a 32 bit value would be large enough. Somewhere there'd be a table of instance paths, path names, calling paths and the calling overhead for the index would still be enough to significantly impact performance when all operators are functions and all other operations of a type are basic operations. You could exempt predefined operators, but VHDL would still pay a heavy price because of it's strong typing.
The value proposition doesn't appear to be there leaving user space solutions.
The alternative would be either to bite the bullet and pass the path as a parameter or restructure to use the equivalent of a POSIX logging call allowing the calling location to report the path. For the former you could use default values allowing the parameters to only be passed for debugging. The default values would be a zero length string for the path and a possibly a boolean for determining whether or not report the path.
Detecting error conditions is tough for function calls, strong typing doesn't allow in band error reporting, requiring either a returned record or mirror functions returning an error condition separately. The idea here is to determine when the calling location reports it's instance path.
What this boils down to is that VHDL isn't like other languages. It serves for hardware descriptions that can be readily formally proven and that relies on strong typing. Despite rumors to the contrary it isn't a general purpose programming language, you can't bend it to other purposes readily. For instance you couldn't implement a VHDL simulator in VHDL without describing the simulation cycle in terms of hardware. The good news is you could put it in an FPGA.