shared variable

[Schüle Daniel]

Hello all,

where is the right place do declare *shared variable*?


architecture X of X is
-- here?
shared variable v: integer;
begin
P1: process
begin
--read/write v and vv
--read/write v and vv
end process;

P2: process
-- or here?
shared variable vv: integer;
begin
--read/write v and vv
--read/write v and vv
end process;
end;


the reason I ask it here, I encountered both
one actually works and the other stands in book.

Regards, Daniel

 

[john Doef]

Schüle Daniel a écrit :

Hello all,

where is the right place do declare *shared variable*?


architecture X of X is
-- here?
shared variable v: integer;
begin
P1: process
begin
--read/write v and vv
--read/write v and vv
end process;

P2: process
-- or here?
shared variable vv: integer;
begin
--read/write v and vv
--read/write v and vv
end process;
end;


the reason I ask it here, I encountered both
one actually works and the other stands in book.
Declaring a shared variable within a process is somewhat dummy because

the variable
is not shared!

JD.

 

[KJ]

Shared variable get declared where a signal would be declared

architecture X of X is
-- here?
shared variable v: integer; <-- That's the spot!
begin

end;

KJ

 

[Schüle Daniel]

john Doef schrieb:

Schüle Daniel a écrit :

Hello all,

where is the right place do declare *shared variable*?


architecture X of X is
-- here?
shared variable v: integer;
begin
P1: process
begin
--read/write v and vv
--read/write v and vv
end process;

P2: process
-- or here?
shared variable vv: integer;
begin
--read/write v and vv
--read/write v and vv
end process;
end;


the reason I ask it here, I encountered both
one actually works and the other stands in book.
Declaring a shared variable within a process is somewhat dummy because
the variable
is not shared!

I agree

it's just that syntax and semantic are different issues
take for example function deklaraion in old C
void f();
f is not said to accept no parameters

JD.

 

[Andy]

Also like a signal, a shared variable can be declared in a package
(visible to those who use the package) or package body (visible only to
the rest of the package body).

The latter is used to implement protected access mechanisms (procedures
or functions) that use the shared variable, but the variable itself
remains invisible to the users of the package.

Shared variables are not synthesizable; global signals (i.e. those
declared in packages) are also usually not supported by synthesis.

Andy

 

[Ralf Hildebrandt]

Schüle Daniel wrote:

where is the right place do declare *shared variable*?

In a package.

The reason is simple: You want to share the variable. A package is the
only thing, that can be shared by several entity/architecture pairs.
Everywhere you include this packed this shared variable is visible and
can be read and written.

Ralf

 

[Andy]

If the shared variable is only used in the processes of one instance of
an architecture, then it should be defined in that architecture.
Otherwise multiple instances of that architecture would share the same
variable (data), which is not what you wanted.

If on the other hand, you do want multiple instances of the same
architecture to use the same variable (data), then define it in a
package.

As a general rule, declare storage objects at the lowest (most local)
scope consistent with their use.

Andy


Ralf Hildebrandt wrote:

Schüle Daniel wrote:

where is the right place do declare *shared variable*?

In a package.

The reason is simple: You want to share the variable. A package is the
only thing, that can be shared by several entity/architecture pairs.
Everywhere you include this packed this shared variable is visible and
can be read and written.

Ralf

 

[Matthias Alles]

Shared variables are not synthesizable; global signals (i.e. those
declared in packages) are also usually not supported by synthesis.

Actually Xilinx supports shared variables for modelling dual port RAMs
with two write ports:

architecture syn of generic_dual_w_port_ram is

type RAMtype is array (0 to nr_of_words-1) of
std_logic_vector(bitwidth-1 downto 0);
shared variable RAM : RAMtype;

begin

process (CLK_A)
begin
if CLK_A'event and CLK_A = '1' then
if EN_A = '1' then
if WE_A = '1' then
RAM(conv_integer(ADDR_A)) := DI_A;
end if;
DO_A <= RAM(conv_integer(ADDR_A));
end if;
end if;
end process;


process (CLK_B)
begin
if CLK_B'event and CLK_B = '1' then
if EN_B = '1' then
if WE_B = '1' then
RAM(conv_integer(ADDR_B)) := DI_B;
end if;
DO_B <= RAM(conv_integer(ADDR_B));
end if;
end if;
end process;

end syn;


Matthias

 

[Mike Treseler]

Andy wrote:

If the shared variable is only used in the processes of one instance of
an architecture, then it should be defined in that architecture.
Otherwise multiple instances of that architecture would share the same
variable (data), which is not what you wanted.

Yes. I learned this one the hard way.

Only package a shared variable if you don't mind
model instances overwriting each other.
Architecture scope keeps instances separated.

If I were writing this model today, I would
use just one process and plain variables.

That would make the model synthesizable as a side effect.


-- Mike Treseler

 

[Schüle Daniel]

[...]

thx for responses so far
I found out that an entity may also contain shared variable

entity test is
shared variable i: integer;
end;

I suppose that then all processes in all architectures of test
have access to it.

Regards, Daniel

 

[Andy]

Well, yes, all architectures would see the same one, but only one of
them is ever bound to that instance of that entity, so multiple
instances of the entity/architecture would still see different shared
variables. In that respect, there is no difference between declaring it
in the entity or declaring it in the architecture. It does reduce code
bulk, but only marginally.

Andy

Schüle Daniel wrote:

thx for responses so far
I found out that an entity may also contain shared variable

entity test is
shared variable i: integer;
end;

I suppose that then all processes in all architectures of test
have access to it.

Regards, Daniel