Why do shared variables HAVE to be a protected type?

[Tricky]

I asked this because Im just writing a function that has memory of
certain variables, so subsequent calls use the previous data (dont
worry, its for testbenching only) and to do this, I obviously have to
use shared variables.

Now, I ask the question above, because this function will sit in a
package, and the shared variables will only sit in the package body,
so nothing external to the package has access to the shared variables.
Whats wrong with using unprotected shared variables here?

I know modelsim only throws a warning, and my doulos golden reference
guide also tells me I "must" use a protected type for a shared
variable, so why doesnt modelsim throw an Error instead of a warning?
sims and unprotected shared variables work fine together - I assume
this is something to do with different versions of the language spec,
VHDL 2000 and 2002?

 

[Mike Treseler]

Why do shared variables HAVE to be a protected type?

I asked this because Im just writing a function that has memory of
certain variables, so subsequent calls use the previous data (dont
worry, its for testbenching only) and to do this, I obviously have to
use shared variables.

I sometimes "share" regular variables across
testbench procedures by declaring them all
in the same test process.

Now, I ask the question above, because this function will sit in a
package, and the shared variables will only sit in the package body,
so nothing external to the package has access to the shared variables.
Whats wrong with using unprotected shared variables here?

Multiple processes can use the same package.

I know modelsim only throws a warning, and my doulos golden reference
guide also tells me I "must" use a protected type for a shared
variable, so why doesnt modelsim throw an Error instead of a warning?

vhdl93 style shared variables are given a pass
by modelsim so that I don't have to rewrite all of my
old sims at once


-- Mike Treseler

 

[Tricky]

Any process can access the shared variables.  To get
coherent behaviour you need the mutex that shared
variables provide.

But that was the point, Im only declaring them inside the package
body, not the package header. So only the functions inside the package
body can see them - no processes should have access to them, unless
you can put processes in packages now?

 

[Mike Treseler]

But that was the point, Im only declaring them inside the package
body, not the package header. So only the functions inside the package
body can see them - no processes should have access to them, unless
you can put processes in packages now?

Whether the shared variable is changed directly or indirectly
by a testbench process, the problem is the same.

If no process can affect the variable, then it is useless.

-- Mike Treseler

 

[JohnDuq]

I've heard of those write-only registers... 8)

 

[Paul]

Actually VHDL-93 vs. VHDL >= 2000. VHDL-93 shared variables
were unprotected, and known to be unsafe. Like sharp knives,
guns and WMDs, unsafe things can be extremely useful when
deployed with care by the right people

Even protected shared variables are unsafe. Let's assume 'count' is a
shared protected variable and has some accessors like inc, set and
get. Then write something along these lines:

p1: process is
begin
count.set(1);
wait;
end process p1;

p2: process is
begin
count.set(2);
wait;
end process p2;

p3: process is
variable v1, v2: natural;
begin
v1 := count.get;
wait for 1 ns;
v2 := count.get;
wait;
end process p3;

After 1 ns, what are the values of v1 and v2?

v1 can either be 0 (asuming that is the initial value of count),
1 or 2.

v2 can either be 1 or 2.

There are of course good uses to shared (protected) variables. But
undeterminism can be introduced all too easy.

The way in which protected types are save is that their accessor
subprograms are executed atomically. Its flow of execution cannot be
interrupted by the execution of another process that also accesses
the same shared variable. At least, that is what I remember. Correct
me if I'm wrong.