4

I'd like to be able to continuously force a signal down in my testbench hierarchy. Here is a simple example illustrating how I've been doing this in my test benches.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity double_inverter is
port(
  a : in std_logic;
  z : out std_logic
);
end double_inverter;

architecture x of double_inverter is
 signal b : std_logic;
begin

  b <= not a;
  z <= not b;

end architecture x;


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity inverter_tb is
end inverter_tb;

architecture y of inverter_tb is
  signal z : std_logic;
  signal clk : std_logic := '0';
begin

  clk <= not clk after 5 ns;

  dut : entity work.double_inverter
  port map(
    a => '0',
    z => z
  );

  continuous_stim : process(clk)
  begin

    << signal dut.b : std_logic >> <= force clk;

  end process;

end architecture y;

This works in Modelsim 10.4b i.e. signal b in the double_inverter instance will be set by clk and not signal a, but is there a better way to control external name signals?

Thanks for your help.

Michael Grover
  • 87
  • 1
  • 9
  • *...is there a better way...* Better in what way? A VHDL driver force and external names reveals the mechanism used by simulators, typically provided by console commands or executing scripts depending on VHPI/VPI/PLI/DLI. It theoretically improves portability of verification constructs depending on testbenches instead of simulator platform scripts in the growing face of 'other language solutions' using VHP, etc.. Would you rather write VHDL testbench programs or use other verification solutions? You're asking for opinion while a simple example may not drive the choice. –  Jul 06 '17 at 00:01
  • Is there a better way to do this in VHDL-2008? Sometimes I'll have a situation where I would like to be able to force a signal deep in my testbench hierarchy to another signal, like "clk" in this example. VHDL-2008 gives you the ability to reach deep into your hierarchy with external names. I wanted to know how to drive these external names with other signals in the test bench, but the only examples in the LRM and on the web showed external names being driven by '1' or '0', not explicit signals. I just tried something and it works, but is it a good or even acceptable way of doing it? Thanks. – Michael Grover Jul 06 '17 at 17:17
  • Primaries as expressions (named objects here) can provide values for assignment. Examples aren't all inclusive. For a signal see IEEE Std 1076-2008 10.5.2.2 Executing a simple assignment statement, 9. Expressions, 9.1 General (the EBNF for primary and paragraph 3). –  Jul 06 '17 at 20:47

1 Answers1

4

In some situations you can use is an alias to the external name:

alias dut_b is <<signal dut.b : std_logic >> ;

Since we think of signals being declared in an architecture, our instinct is to put the alias in the architecture. However, in this situation, it is not allowed because the DUT has not been elaborated yet.

You may be allowed to put it in the process - I would have to do some research to check if the language allows this. My concern is that processes do not allow signal declarations, so I am not confident that it will allow aliases to signals in a process - no harm in trying it and letting us know if it worked.

Generally when I am using something like this, I put it in a architecture declarative region of a component that creates the test cases and is instanced by the testbench. To avoid issues with elaboration order, I make sure to instance my DUT first in the testbench and typically the component that generates the test cases last (with the transaction based models in the middle) - VHDL elaborates designs in the order they are instantiated.

Jim Lewis
  • 3,601
  • 10
  • 20
  • Thanks for your answer, Jim. Just tried your suggestion to put the alias in the process region and it did work. Also, for those who care, Modelsim will actually allow you to put an alias to an external name in the top testbench architecture declarative region, it will just send a warning that the dut object has not been elaborated yet. Probably not the cleanest thing to do, though... – Michael Grover Jul 06 '17 at 17:25
  • See IEEE Std 1076-2008 8. Names, 8.1 General paragraphs 6 & 7, an external name is not locally static. See 8.7 External names para 3 b) post 5. and para 4, external names can be evaluated during elaboration of the alias declaration (14.4.2.6 Alias declarations and 6.6.2 Object aliases, 14.2 Elaboration of a design hierarchy para 15 - also see the NOTE, 14.4.1). Modelsim historically warns of non-portability while advocating for new features but is not currently participating in the standard revision process. –  Jul 06 '17 at 20:36