Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Shared variables and protected types

Reply
Thread Tools

Shared variables and protected types

 
 
biaunm@gmail.com
Guest
Posts: n/a
 
      04-04-2012

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!
 
Reply With Quote
 
 
 
 
Paul Uiterlinden
Guest
Posts: n/a
 
      04-05-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

>
> 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.

--
Paul Uiterlinden
www.aimvalley.nl

 
Reply With Quote
 
 
 
 
biaunm@gmail.com
Guest
Posts: n/a
 
      04-05-2012
On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> (E-Mail Removed) wrote:
>
> >
> > 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.


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.
>
> > 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".


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 Uiterlinden
> www.aimvalley.nl



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

biaunm



On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> (E-Mail Removed) wrote:
>
> >
> > 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.
>
> --
> Paul Uiterlinden
> www.aimvalley.nl


 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      04-09-2012
On Friday, April 6, 2012 12:04:41 AM UTC+1, (E-Mail Removed) wrote:
> On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> > (E-Mail Removed) wrote:
> >
> > >
> > > 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 thoughthe
> > > 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.

>
> 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.
> >
> > > 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 mustbe
> > 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 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.
>
> >
> > 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 Uiterlinden
> > www.aimvalley.nl

>
>
> Paul, thanks much for responding and for the data on ModelSim!
>
> biaunm
>
>
>
> On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> > (E-Mail Removed) wrote:
> >
> > >
> > > 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 thoughthe
> > > 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 mustbe
> > 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.
> >
> > --
> > Paul Uiterlinden
> > www.aimvalley.nl


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.
 
Reply With Quote
 
Bill
Guest
Posts: n/a
 
      04-11-2012
On Apr 9, 9:13*am, Tricky <(E-Mail Removed)> wrote:
> On Friday, April 6, 2012 12:04:41 AM UTC+1, (E-Mail Removed) wrote:
> > On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> > > (E-Mail Removed) wrote:

>
> > > > 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 havebeen
> > > > 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/proceduresof
> > > 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 atexact
> > > 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".

>
> > 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.

>
> > > Alternatively, you could use the -93 option. In that language versionplain
> > > 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 Uiterlinden
> > >www.aimvalley.nl

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

>
> > biaunm

>
> > On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
> > > (E-Mail Removed) wrote:

>
> > > > 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 havebeen
> > > > 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/proceduresof
> > > the protected type are guaranteed to be atomic.

>
> > > If you have two processes that update the data of a protected type atexact
> > > 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 versionplain
> > > shared vaiables where allowed. But then you might miss other language
> > > features.

>
> > > --
> > > Paul Uiterlinden
> > >www.aimvalley.nl

>
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why do shared variables HAVE to be a protected type? Tricky VHDL 5 04-01-2009 09:52 PM
Global Shared functions, shared variables Imran Aziz ASP .Net 1 08-22-2005 06:43 PM
Shared Public Variables and Shared Methods Joe Fallon ASP .Net 3 07-16-2004 07:11 AM
Re: Class public shared Variables vs. Application Variables in ASP.NET avnrao ASP .Net 0 05-07-2004 05:28 AM
Difference between "Protected WithEvents myClassName" And "Protected myClassName" ? Andreas Klemt ASP .Net 2 07-05-2003 12:51 AM



Advertisments