Shared variables and protected types

[biaunm]

I am using VHDL-2002. I am working with code that violates the following mandate in the LRM: "The base type of the subtype indication of a shared variable declaration must be a protected type." (LRM 4.3.1.3)

My simulator (Aldec Active HDL) is letting it slide with a warning:

# Warning: COMP96_0564: pcie_bfm_for_vpx_combo_fpga_pcie_v6.vhd : (583, 10): Shared variable is not of a protected type. (IEEE Std 1076-2002, 4.3.1.3)


I actually prefer the behavior that the simulator allows (even though the LRM seems to be calling for a hard error). The reason is that I find in mostcases my shared variables divide along two lines, (1) stuff that needs atomicity/mutual-exclusion and (2) stuff that is not susceptible to shared-variable update error--often because of conditions that have been established using the atomicity/mutual-exclusion aspects of the first category.

Hence, I find the introduction of protected types into VHDL to be valuable for the realization of category (1) but the requirement that all shared variables must be protected types to be very limiting and awkward relative to category (2).

So, what I am hoping to find out here is whether the behavior of letting shared variables that are not protected types get by with a mere warning is also the behavior of most other simulators. If so, I would consider this to be a default feature of VHDL and go ahead and, where appropriate, design solutions that use shared variables that are not of a protected type.

If you have thoughts on this and especially if you can report the behavior of specific simulators, I hope that you will respond to the thread. Thank you!

 

[Paul Uiterlinden]

I am using VHDL-2002. I am working with code that violates the following
mandate in the LRM: "The base type of the subtype indication of a shared
variable declaration must be a protected type." (LRM 4.3.1.3)

My simulator (Aldec Active HDL) is letting it slide with a warning:

# Warning: COMP96_0564: pcie_bfm_for_vpx_combo_fpga_pcie_v6.vhd :
# (583, 10): Shared variable is not of a protected type. (IEEE Std
# 1076-2002, 4.3.1.3)


I actually prefer the behavior that the simulator allows (even though the
LRM seems to be calling for a hard error). The reason is that I find in
most cases my shared variables divide along two lines, (1) stuff that
needs atomicity/mutual-exclusion and (2) stuff that is not susceptible to
shared-variable update error--often because of conditions that have been
established using the atomicity/mutual-exclusion aspects of the first
category.

Be careful: protected types do not solve issues of mutual-exclusion, other
than the mutual-exclusion you get because of the functions/procedures of
the protected type are guaranteed to be atomic.

If you have two processes that update the data of a protected type at exact
the the same time with different data, the outcome is undetermined.

Example:

architecture a of e is
shared variable v: some_prot_type;
begin
p1: v.put(1);
p2: v.put(2);

p3: process is
begin
wait for 0 ns;
report "v=" & integer'image(v.get)
wait;
end process p3;
end architecture a;

The is no way of telling whether value 1 or 2 will be shown.

Hence, I find the introduction of protected types into VHDL to be valuable
for the realization of category (1) but the requirement that all shared
variables must be protected types to be very limiting and awkward relative
to category (2).

So, what I am hoping to find out here is whether the behavior of letting
shared variables that are not protected types get by with a mere warning
is also the behavior of most other simulators. If so, I would consider
this to be a default feature of VHDL and go ahead and, where appropriate,
design solutions that use shared variables that are not of a protected
type.

If you have thoughts on this and especially if you can report the behavior
of specific simulators, I hope that you will respond to the thread. Thank
you!

ModelSim 10.1 says:

** Warning: sharedvar_notprot.vhd(5): (vcom-1236) Shared variables must be
of a protected type.


But I don not rely on it just being a warning. If I need a shared variable
that I only want to set and read, I create the protected type with
procedure "put" and impure function "get".

Alternatively, you could use the -93 option. In that language version plain
shared vaiables where allowed. But then you might miss other language
features.

 

[biaunm]

Be careful: protected types do not solve issues of mutual-exclusion, other
than the mutual-exclusion you get because of the functions/procedures of
the protected type are guaranteed to be atomic.

Oh, sure, it is clear that critical sections are implemented under the atomicity guaranted by method calls but that use of protected types does not free you from thinking about how to design a correct shared-data system. Thanks for mentioning it, though.

If you have two processes that update the data of a protected type at exact
the the same time with different data, the outcome is undetermined.

Example:

architecture a of e is
shared variable v: some_prot_type;
begin
p1: v.put(1);
p2: v.put(2);

p3: process is
begin
wait for 0 ns;
report "v=" & integer'image(v.get)
wait;
end process p3;
end architecture a;

The is no way of telling whether value 1 or 2 will be shown.


ModelSim 10.1 says:

** Warning: sharedvar_notprot.vhd(5): (vcom-1236) Shared variables must be
of a protected type.


But I don not rely on it just being a warning. If I need a shared variable
that I only want to set and read, I create the protected type with
procedure "put" and impure function "get".

Sure, that is fine for your simple example but once the shared-data system gets somewhat more complex--typically the case for, e.g., a real verification environment--then this gets awkward fast. You may have a shared variablethat is a record or an array of records, for instance. Then making subprograms to set and get all of those fields just gets unweildy. Performance canalso be expected to suffer.

Alternatively, you could use the -93 option. In that language version plain
shared vaiables where allowed. But then you might miss other language
features.

This points to another significant aspect and history lesson. The VHDL sheppards who introduced protected types into VHDL-2000 did it in a non-backward-compatible fashion. Maybe they should have introduced "sync variables" (or pick your name) for the shared objects that have to correspond to protected types. Alternatively, they could have made it optional for shared variables to be protected types, which would have made offical the de facto situation we now have where the simulators apparently just "wink" at the infractions.


Paul, thanks much for responding and for the data on ModelSim!

biaunm

 

[Tricky]

Oh, sure, it is clear that critical sections are implemented under the atomicity guaranted by method calls but that use of protected types does not free you from thinking about how to design a correct shared-data system. Thanks for mentioning it, though.


Sure, that is fine for your simple example but once the shared-data system gets somewhat more complex--typically the case for, e.g., a real verification environment--then this gets awkward fast. You may have a shared variable that is a record or an array of records, for instance. Then making subprograms to set and get all of those fields just gets unweildy. Performance can also be expected to suffer.


This points to another significant aspect and history lesson. The VHDL sheppards who introduced protected types into VHDL-2000 did it in a non-backward-compatible fashion. Maybe they should have introduced "sync variables" (or pick your name) for the shared objects that have to correspond to protected types. Alternatively, they could have made it optional for shared variables to be protected types, which would have made offical the de facto situation we now have where the simulators apparently just "wink" at the infractions.



Paul, thanks much for responding and for the data on ModelSim!

biaunm

Yes, that was perhaps a bit clumsy. Modelsim has a compile time option thatallows strict checking of VHDL 2002 rules, including the shared variable thing. But this is disabled by default.

Personally, I think if you have to return entire arrays of arrays, you're probably not using the protected type correctly. You should add methods for idividual element access.

I personally love protected types and what you can do with them. I have a protected type that I call "image_agnostic_t" that allows me to read a greyscale/colour/alpha channel bitmap without caring what the source file is, and can access the data in each of the 3 ways via the methods and the associated array types. I never need to worry whether the source is greyscale or colour or alpha channel again.

Also great for containing event queues (like a PCIe packet queue) but limited in the fact you cannot have access types as the parameters on a protected type method.

 

[Bill]

Oh, sure, it is clear that critical sections are implemented under the atomicity guaranted by method calls but that use of protected types does not free you from thinking about how to design a correct shared-data system. Thanks for mentioning it, though.

Sure, that is fine for your simple example but once the shared-data system gets somewhat more complex--typically the case for, e.g., a real verification environment--then this gets awkward fast. You may have a shared variable that is a record or an array of records, for instance. Then making subprograms to set and get all of those fields just gets unweildy. Performancecan also be expected to suffer.

This points to another significant aspect and history lesson. The VHDL sheppards who introduced protected types into VHDL-2000 did it in a non-backward-compatible fashion. Maybe they should have introduced "sync variables" (or pick your name) for the shared objects that have to correspond to protected types. Alternatively, they could have made it optional for shared variables to be protected types, which would have made offical the de facto situation we now have where the simulators apparently just "wink" at the infractions.

Paul, thanks much for responding and for the data on ModelSim!

Yes, that was perhaps a bit clumsy. Modelsim has a compile time option that allows strict checking of VHDL 2002 rules, including the shared variablething. But this is disabled by default.

Personally, I think if you have to return entire arrays of arrays, you'reprobably not using the protected type correctly. You should add methods for idividual element access.

I personally love protected types and what you can do with them. I have aprotected type that I call "image_agnostic_t" that allows me to read a greyscale/colour/alpha channel bitmap without caring what the source file is, and can access the data in each of the 3 ways via the methods and the associated array types. I never need to worry whether the source is greyscale orcolour or alpha channel again.

Also great for containing event queues (like a PCIe packet queue) but limited in the fact you cannot have access types as the parameters on a protected type method.- Hide quoted text -

- Show quoted text -

The image_agnostic_t protected type sounds interesting but I have to
admit to not having much familiarity with the corresponding "channel
bitmap" type of application. That said, I get the impression that what
you like about the protected type for this case is that it
approximates a class structure (albeit non-extensible) that combines
data and methods. It wasn't clear that atomicity is a requirement for
your application but, of course, atomicity was the exact reason for
introducing protected types into VHDL.