Why doesn't shared variable drive output port in VHDL when using concurrent assignment of shared variable to signal?

[matrixofdynamism]

Here is the test case, a shared variable x_i drives and output port o_x.

library ieee;
use ieee.std_logic_1164.all;

entity test_2 is
port (
o_x : out std_logic
  );
end entity;

architecture beh of test_2 is
shared variable x_i : std_logic;
begin

process
begin
x_i := '1';
wait for 10 ns;
x_i := '0';
wait for 10 ns;
x_i := '1';
wait;
end process;

  o_x <= x_i;

end architecture;

When the simulation is run, x_i changes as we expect. However, o_x stays in 'X' state.
Why doesn't x_i get assigned to o_x in this case? It would be great if Jim Lewis could answer this one.

 

[barry]

I’ve never used shared variables, but I would suspect that either:
1) the assignment of o_x needs to be inside a process.
2) you need to tell the simulator you’re using VHDL 93 (or later)

 

[FvM]

I’ve never used shared variables, but I would suspect that either:
1) the assignment of o_x needs to be inside a process.
2) you need to tell the simulator you’re using VHDL 93 (or later)

Pre VHDL93 simulator setting gives syntax error for shared variable. Assignment in process makes no difference, at least in Modelsim.

I doubt that the behaviour of shared variable in this context is completely specified in VHDL language reference. Why are you using a shared variable? It doesn't seem to serve a specific purpose here.

 

[barry]

I strongly suspect the OP is thinking like a software programmer, not hardware engineer...

But, there's another error that I'm surprised didn't get flagged:

end architecture;

is wrong. It should be :

end beh;

 

[TrickyDicky]

X_i is not a signal, hence it has no 'events to trigger the process infered by the one line assignment. You basically have this:

process
begin
     o_x <= x_i;
     wait;
end process;

--- Updated Dec 13, 2022 ---

I strongly suspect the OP is thinking like a software programmer, not hardware engineer...

But, there's another error that I'm surprised didn't get flagged:

end architecture;

is wrong. It should be :

end beh;

Wrong. Both architecturearχtecture and arch_name are optional. So you can do any of the following:

architecture beh of my_ent is
begin
end;   -- fine
end architecture;  -- fine
end beh;  -- fine
end architecture beh; --fine

 

[barry]

X_i is not a signal, hence it has no 'events to trigger the process infered by the one line assignment. You basically have this:

process
begin
     o_x <= x_i;
     wait;
end process;

--- Updated Dec 13, 2022 ---

Wrong. Both architecturearχtecture and arch_name are optional. So you can do any of the following:

architecture beh of my_ent is
begin
end;   -- fine
end architecture;  -- fine
end beh;  -- fine
end architecture beh; --fine

I have never, ever seen

end architecture

in practice or in any VHDL documentation.

 

[FvM]

Thanks to TrickyDicky for remembering the concept of equivalent process statement to describe the execution of concurrent signal assignments. It completely explains the observed behaviour.

The only place where I have used shared variables (and where it serves a purpose, I think) is to model dual port RAM, there the variable is read in clock sensitive processes, thus no simulation mismatch occurs.

 

[TrickyDicky]

I have never, ever seen

end architecture

in practice or in any VHDL documentation.

Direct from VHDL 2008 LRM:

architecture_body ::= 
    architecture identifier of entity_name is architecture_declarative_part 
    begin 
        architecture_statement_part 
    end [ architecture ] [ architecture_simple_name ] ;

 

[barry]

Direct from VHDL 2008 LRM:

architecture_body ::=
    architecture identifier of entity_name is architecture_declarative_part
    begin
        architecture_statement_part
    end [ architecture ] [ architecture_simple_name ] ;

I stand corrected. But I’m still going to use the name; it’s usually shorter than the word “architecture”

 

[dpaul]

The only place where I have used shared variables (and where it serves a purpose, I think) is to model dual port RAM, there the variable is read in clock sensitive processes, thus no simulation mismatch occurs.

I second this.
The OP seems to be trying to create some exotic implementation for shared variable.

@matrixofdynamism You wanted Jim Lewis to answer this Q, but did you make an effort to find out and understand what Jim has to say regarding shared variables at his webpage?

VHDL: Shared Variables, Protected Types, and Memory Modeling – Open Source VHDL Verification Methodology

osvvm.org

Lastly would you please want to close the case?