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

Question

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;

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.