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?

 

[Jonathan Bromley]

On Fri, 20 Mar 2009 09:40:05 -0700 (PDT), Tricky wrote:

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?

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

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?

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

Unfortunately, not all VHDL simulators implement protected
types. So it's probably wise for ModelSim to issue only a
warning, else it would fail to run code that runs
"correctly" on other tools.

In practice, of course, it is rather unlikely to get
incoherent behaviour from old-fashioned shared variables
and most people get away with using them just fine.
However, there is many a promising career that
has been ruined by the tiny difference between
"unlikely" and "impossible"....
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Tricky wrote:

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

 

[Mike Treseler]

Tricky wrote:

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

 

[Tricky]

On 20 Mar, 16:45, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Fri, 20 Mar 2009 09:40:05 -0700 (PDT), Tricky wrote:
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?

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?

 

[Alan Fitch]

Tricky wrote:

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?

Hi Tricky,
you can put a shared variable in a package declaration - it's
certainly a good approach to share it

I had a play with shared variable and used a structure like this:

-- compile this into lib1 say
package p1 is
type sT is protected
impure f;
end protected;
end;

package body p1 is

type sT is protected body
impure f is
begin
end;
end protected body;

end package body;

-- compile this anywhere
library lib1;
use lib1.p1.all;

package p2 is
shared variable s : sT;
end package;

then use p2 whereever you need your shared variable.

In principle you could put that all in one package, but I was trying to
achieve a high degree of encapsulation hence the rather contorted structure.

It was quite disappointing to discover that certain tools didn's support
protected mode types :-(

regards
Alan



--
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

 

[Paul]

Jonathan Bromley wrote:

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.

--
Paul