How do we hierarchially access the signals internal to DUT?
I had used the syntax: $root.<tb_top>.<dut_inst>.<dut_subblock>.signal
but I got the error
** Error: : (vlog-7027) Hierarchical reference not allowed from within a package.
Please suggest me a way to do the same.
Hi Antri,
I think you are trying to access signals that is defined inside the packages. Thats why the error message is shouting out clearly… Hierarchical access of signals from within the package is not allowed,…
Correct me If i am wrong…
Thanks,
Desperado → :)
The signals are not defined inside any package. On getting the error message, I had even checked the same. But, I found no packages for DUT.
–Anita
You will get these messages if you are trying to hierarchically reference a signal from a package or$unit. $unit is treated like a special unnamed package.
The proper (an reusable) way to access internal signals of the DUT is to create an interface. In this case, I mean the software programming concept of an interfacethat separates the testbench functionality from the DUT. There are several ways to accomplish this, some of which uses the SV interfaceconstruct.
The approach I like to recommend is the abstract class interface, where the testbench classes have an abstract class reference to a concrete class handle. That concrete class is constructed in either an SV interface or module, and bound into the DUT using the bind statement
I have attached an example of this
Thanks dave_59 for the information. The attachment was quite useful.
But, I am not using $unit anywhere.
The way I was trying to access the internal DUT signal was:
$root.dut.sub_block<SUB_BLOCK>.signal and I was getting errors.
But I found in a document at http://www.vmmcentral.org/pdfs/lungu_final.pdf that the following statement was used for the same purpose. So, where can the problem be? Is it something that VMM supports and OVM doesnot?
temp=$root.dut.stats_swif.mem_data[id];
This has nothing to do with VMM versus OVM. It is a SystemVerilog issue.
The problem is a combination of where the statement is located and where the signals that statement is trying to reference are located. The error message is going to show up where the statement is located.Where is that? I assume the statement is in a class. Where is the class?
Dave
Yes the statement is inside a class. And the class is getting created inside another class. But the dut instance is created in top.sv which is a module.
As I cannot give top.dut.signal, I am using $root.dut.signal.
Where is the class defined? It doesn’t matter where it is constructed(created). If it is not defined inside a package/module/interface/program, then the only other place it could be is in $unit
How do we hierarchially access the signals internal to DUT?
I had used the syntax: $root.<tb_top>.<dut_inst>.<dut_subblock>.signal
but I got the error
** Error: : (vlog-7027) Hierarchical reference not allowed from within a package.
Please suggest me a way to do the same.
I vaguely recall Questa older version (6.5a --) used to throw similar error, but got fixed in later releases. Which version are you using?
If you can show a full testcase it is lot easier to point out. Try mimicking it with XBUs or so.
Srini
www.cvcblr.com/blog
In reply to dave_59:
Hi,
I am also facing the same problem. Can I have example code on how to access DUT internal signals? I initially had access from a class which is part of package. After reading this post, understood that is not supported. Can somebody help me with this?
Thanks
A.Sunitha
In reply to dave_59:
Attached is one example of accessing internal signals using a bind. This is for UVM, but the same principals apply.
In reply to sunitha80:
Dave, I would think a much simpler way of achieving the same result would be to remove the abstract class and the class inside the interface and just get a handle to the interface. Once you have a handle to the interface you can do all sorts of operations using the VIF.signal. You can even have the interface self register itself by instantiating the interface in a module, binding the module and having an initial block inside the module to do the registration of the interface. The draw back to your method is every signal you want to probe has to have some type of wrapper function/task.
In reply to ktmills:
Hi,
April 28, 2010 - 12:37pm → this post from dave-59 says there is an attachment. I am unable to view the attachement. Can somebody help me to locate attachment?
Regards, Siva
In reply to dave_59:
Attachments from the old OVMWorld site were lost in the migration to the verification forum. I re-attached it to that post, as well as posting a newer, UVM version to this post as well.