Question

I want to describe an entity that can either function normally or be put in a test mode. The general design I have is a top level entity that wraps the “real” entity and a test entity.

I am trying to figure out the best way to express this in VHDL, but I get the feeling I’m overcomplicating things.

Consider a small top-level entity (realistically, there are many more I/Os):

entity toplevelobject is
    port (
        in1 : inout std_logic;
        in2 : inout std_logic;
        out1 : out std_logic;
        out2 : out std_logic;
        testline : in std_logic;
        testclk : in std_logic;
    );

end toplevelobject;

This is supposed to switch between the real functionality and the test mode depending on the state of “testline” (high means test). Note that the test module actually uses everything but clk as an output, even in_*.

architecture test_passthrough of toplevelobject is
    -- This is the actual module
    component real_module
    port (
        in1 : in std_logic;
        in2 : in std_logic;
        out1 : out std_logic;
        out2 : out std_logic;
        clk : in std_logic;
        -- Note absence of "testline"
    );
    end component;

    -- This is the test module, which will just put the clk
    -- signal out on all pins, or play a tune, or something
    component test_module
    port (
        in1 : out std_logic;
        in2 : out std_logic;
        out1 : out std_logic;
        out2 : out std_logic;
        testclk : in std_logic;
        -- Note absence of "testline"
    );
    end component;

    signal real_in1, real_in2 : std_logic;
    signal real_out1, real_out2 : std_logic;

    signal test_in1, test_in2 : std_logic;
    signal test_out1, test_out2 : std_logic;

begin

    real_0 : real_module port map (
        in1 => real_in1,
        in2 => real_in2,
        out1 => real_out1,
        out2 => real_out2,
        clk => clk,
    );

    test_0 : test_module port map (
        in1 => test_in1,
        in2 => test_in2,
        out1 => test_out1,
        out2 => test_out2,
        testclk => clk,
    );

    -- Ports that are outputs on both don't need
    -- much special attention

    out1 <= real_out1 when testline = '0' else test_out1;
    out2 <= real_out2 when testline = '0' else test_out2;

end test_passthrough;

So I have a few questions:

• For the inout ports, should I have one big process with a case ... when statement that switches on testline? Or a process for each I/O with an if statement? Theoretically I figure that many smaller processes are executed concurrently instead of sequentially, but will it actually make a difference to simulation or synthesis? For example:

  passthrough_in1 : process(testline, in1, test_in1) is
  begin
      if testline = '0' then
          real_in1 <= in1;
      else
          in1 <= test_in1;
      end if;
  end process passthrough_in1;
  

…vs…

    passthrough_all : process(in1, test_in1, in2, test_in2, testline) is

        case testline is
            when '0' =>
                real_in1 <= in1;
                real_in2 <= in2;
            when '1' =>
                in1 <= test_in1;
                in2 <= test_in2;
        end case;

    end process passthrough_all;

• Is this a sane approach or is there something simpler?
• I’m confused about sensitivity — do I need passthrough_in1 (or even passthrough_all to be sensitive to anything other than testline?
• Do I need the real_in1/test_in1 to select between the two wrapped entities? Or is there another way to say “if testline is high, connect test_module output in_1 to the toplevelobject I/O in_1?

Answer 1

If I understand you correctly your testmodule drives the (badly named – I assume in the real code they make more sense 🙂 in1,2 ports?

If so, you need to do something like this:

real_in1 <= in1;
in1 <= test_in1 when testline = '1' else 'Z';

That way in non-test-mode the in1 signal will be driven by a ‘Z’, so the external proper in1 signal can override it.

You can represent this in various other ways (like the processes that you described), all of which should come out being equal in the simulator. The downside of the “all in one process” option is that you’ll need to keep what might end up as an enormous sensitivity list up to date. Doing it one process per signal is just a long winded way of what I did above.

To save some code and copy/paste effort, you could potentially push those two lines of code into an entity of their own and then instance it many times – in that case, I’d put the instance and port map all on one line, but that would offend some coding standards…

This all assumes I’ve understood the problem correctly!