# How to bring out internal signals of a lower module to a top module in VHDL?

How can I bring out the internal signals of my VHDL source code to my testbench so that I can view them as waveforms? I use Active HDL. I would like to know if there is any tool independent method of achieving my objective. Any help is appreciated.

I get this error now.

My source code is

entity SPI_DAC is
Port (
-- inputs and oututs
)
end SPI_DAC;

architecture Behavioral of SPI_DAC is
--These are my internal signals
signal ch1_byte_data_sent       : STD_LOGIC_VECTOR(23 downto 0)     := x"000000";
signal ch1_byte_cmd_sent        : STD_LOGIC_VECTOR(23 downto 0)     := x"000000";
--and a few other signals
begin
--functionality
end Behavioral;


My testbench code is

entity tb_spi_dac is
end tb_spi_dac;

architecture behavioral of tb_spi_dac is
component spi_dac
port(
--declaration, inputs and outputs
);
end component;
begin
uut: spi_dac port map(
--map ports
);
--stimulus process
end;

• When you start your simulation your simulator will elaborate all elements. Afterwards it looks for the links you made by using external names. It seems to me that your path is wrong. I edited my answer to give more detail on the construction of paths. Without knowledge about your design I cannot say whats wrong with your path. – Thomas S. Aug 20 '14 at 5:49
• Like I said in my answer you have to use the label not the entity name. The correct path should be .tp_spi_dac.uut.ch1_byte_data_sent. – Thomas S. Aug 25 '14 at 7:32
• Your suggestions solved my problem @ThomasS. Thanks a lot! I had a problem with the version of VHDL, which I solved after watching the video as suggested by David. I know writing thank you notes is not recommend, but thanks Thomas for correcting my edit (I really was confused with this markdown formatting). – Suhasini Aug 25 '14 at 9:34

What you are looking for is called external names (or hierarchical names) in VHDL. They can be used to circumvent scope/hierarchy visibility. The syntax is like the example below.

<<signal path_name : std_logic_vector(7 downto 0)>>


You can also access constants and variables with external names. You have to change the type in the external type though. You can use external names directly for read/write access. However you should use aliases to improve readability.

alias signal_name is
<<signal path_name : std_logic_vector(7 downto 0)>>;


The external name has to contain the path to the element you want to access. The path can be either absolute or relative. The individual elements in your path are separated by dots. Note that you have to provide the labels of the instance/process/entity/... and not the name. Absolute path start with a . followed by the name of your top level. For relative paths you can use ^ to move up in the hierarchy. When using constants/signals from some package you can also use @ to move to a library.

An example for an absolute path is

.tb_name.instance_label.sub_instance_label.signal_name


To access the same element from the testbench with relative names you can use

instance_label.sub_instance_label.signal_name


When you want to access some testbench signal/constant from the sub_instance you can use

^.^.constant_name


To access some other constant in a config package located in the config library you can use

@config.pkg_name.other_constant_name


You can use your simulators design/library browser like David pointed out to find the correct path name.

This feature was added in VHDL-2008 so it should be supported by all tools that already have VHDL-2008 support (including ActiveHDL I think). Most simulators do not use VHDL-2008 by default but provide a command line argument or configuration option to enable it.

• I tried what you suggested. alias ch1_byte_data_sent is <<signal .TB_SPI_DAC.SPI_DAC.ch1_byte_data_sent : STD_LOGIC_VECTOR(23 downto 0)>> := x"000000"; I get an "Identifier or string literal expected" error when I do this. Any ideas why I get the error? (Sorry for any mistakes with the post, my first time here!) – Suhasini Aug 19 '14 at 7:52
• My answer might be not clear enough. When using alias you have to write the assignment in a new statement. The advantage is that you can use the alias name instead of the long external name. – Thomas S. Aug 19 '14 at 8:27

How can I bring out the internal signals of my VHDL source code to my testbench so that I can view them as waveforms?

A test bench implies simulation - an entity without any ports is generally not synthesis eligible.

While I've never used Active-HDL I understand it has a design browser that should allow you to pick signals down in your hierarchy to display in your waveform See Aldec's Compilation and Simulation video (5:02, min:sec).

And about now I get the impression the video may cause confusion, perhaps in this particular case.

At 2:22 from the end the video shows a do file (macro) which controls the simulation:

Where we see every signal in the top level of the design has been added to the waveform display with the wave command. It should also be possible to specify a signal in anywhere in the design hierarchy.

The basic idea is a lot of simulators allow you to schedule signals (and some allow variables) to be collected for waveform display.

This short video simply doesn't show signals for subsidiary hierarchy levels. (There's a lot stuffed in a short video presentation).

I would like to know if there is any tool independent method of achieving my objective.

As noted above your objective seems to be to view internal signals as waveforms.

Now for the bad news - there is no standardization for simulator features or interfaces, scheduling signals for waveform dump, etc.. These are all implementation defined.

It's pretty much guaranteed you can dump signals anywhere in a design hierarchy to a waveform viewer or waveform dump file with any implementation that simulates, the method for doing so is implementation defined.

The good news is they tend to copy concepts from each other such as do files, which you could generate programmatically for portability, using a common database describing functional verification on multiple implementation platforms, overcoming differences in syntax and semantics. There'd likely also be differences in command line interface syntax for invoking the tools programmatically.

The idea of portability not embracing multiple GUI's gracefully.

Tools like xilinx has option to view internal signals.

Simple tool-independent method is declaring seperate output lines and connecting the internal signals to these lines.

• I do not wish to meddle with my input and output ports; so cannot declare any new output lines. I declared the signals in my testbench but am unable to see any output on the waveform (shows only my initialized value of zero without implementing the funcionality). Is there any other way to do it? – Suhasini Aug 19 '14 at 5:57

If you have declared the signals in the testbench but are unable to see any output, you may have a problem in the instantiation statement where you instantiate the entity to be tested. Check whether you instantiated it correctly, using an entity instantiation statement or component instantiation. Make sure that the signals in your testbench are connected to the entity under test. If that doesn't solve the problem, post the testbench code so that we can help.

• What Thomas said, addresses my problem exactly. I resolved the error I mentioned earlier, which had arisen due to the default being set to VHDL 1993 in the Active-HDL provided with Lattice's iCEcube2 design software. Now I face a fatal elaboration error when I try to initialize simulation. I am trying to find why this occurs, I hope it is not a limited license issue. – Suhasini Aug 19 '14 at 15:15
• Can you show us that message? – rick Aug 19 '14 at 17:11