0
\$\begingroup\$

How do I set internal/private latches deep inside entities for testing purposes ?

simple example

I have an entity deep inside my architecture which I cannot easily manipulate with an internal signal counter which acts as a latch I would like test in a testbench. I would like to start the test with the counter at a specific value.

library IEEE;
use IEEE.Std_logic_1164.all;
use IEEE.numeric_std.all;

entity thingy is
    port (
        clk : in std_logic;
        S   : out unsigned(7 downto 0)
    );
end entity;

architecture thingy_arch of thingy is
    signal counter : unsigned(7 downto 0) := (others => '0');
begin
    S <= counter;

    process (clk) begin
        if rising_edge(clk) then
            counter <= counter + 1;
        end if;
    end process;
end architecture;

I have tried to use : alias internal is << variable t.counter : unsigned(7 downto 0) >>; to drive it during testbench process but it only drives the latch to "XX…X".

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

Examining internal signals

You have to bring internal signals of interest out on top-level ports for a testbench to be able to access them.

This is a strength of VHDL. Architecture contents cannot be accessed by other architectures, only through the ports made public in an entity.

You can add a wrapper top-level entity/architecture around your current top-level design entity. The latter would become the second-level entity. The top-level entity would contain ports for the pins of the target device only. The second-level entity can contain the same ports plus your test interface ports. The testbench would instantiate the second-level entity. The synthesis tools would use the top-level entity and all below.

The downside of the wrapper is that you're not simulating the actual full design. This may be insignificant in a personal project but it's not allowed for design qualification by many companies/organisations because you're not testing the full design.

You can also have top-level ports for test values that go to unused and unconnected pins on the real board. Make sure you enable internal pull-ups on such unconnected input pins.

Changing internal signal values

Changing an internal signal cannot be done from VHDL unless you add a mechanism to your design to do so from the top-level ports.

You can take a register's value from a constant defined in a package. Then you can have two versions of the package, one for synthesis, one for simulation, with relevant values for testbench or target device. It doesn't allow for testbench control of the values, though. Again, formal design qualification procedures may not allow this.

In ModelSim, you can use a force command to change internal flip-flop values. But its execution would have to be synchronised with the right moment(s) in your testbench's execution, which usually makes it impractical.

Don't use default signal values

You should never use initial values for signals and instead implement a reset, as explained in this answer. If you add a reset input port, that can be controlled by the testbench.

\$\endgroup\$
4
  • \$\begingroup\$ Thank you for your proposal but there seems to be a misunderstanding. The kind of values I want to set to the internals are for simulation and testing purposes only, and are not part of the normal usage of the component. \$\endgroup\$
    – NRagot
    Apr 7, 2022 at 12:26
  • \$\begingroup\$ @NRagot, no misunderstanding at all - I see what you're trying to do, it's a common predicament in VHDL development. There's one design, which is used for synthesis and that has to be testbenched in simulation to prove the design. Have modified the answer but the constraints of the situation are the same. \$\endgroup\$
    – TonyM
    Apr 7, 2022 at 12:47
  • \$\begingroup\$ @NRagot, no misunderstanding at all - I see what you're trying to do, it's a common predicament in VHDL development. There's one design, which is used for synthesis and that has to be testbenched in simulation to prove the design. Have modified the answer but the constraints of the situation are the same. I do a lot of VHDL/FPGA/CPLD/ASIC development so I understand the restriction you're trying to bypass. \$\endgroup\$
    – TonyM
    Apr 7, 2022 at 13:01
  • \$\begingroup\$ Thank you very much for expanding on your answer, it does make much more sens now. \$\endgroup\$
    – NRagot
    Apr 7, 2022 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.