Shared variables and protected types

Discussion in 'VHDL' started by biaunm@gmail.com, Apr 4, 2012.

  1. Guest

    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!
     
    , Apr 4, 2012
    #1
    1. Advertising

  2. 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
     
    Paul Uiterlinden, Apr 5, 2012
    #2
    1. Advertising

  3. Guest

    On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
    > 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:
    > 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
     
    , Apr 6, 2012
    #3
  4. Tricky Guest

    On Friday, April 6, 2012 12:04:41 AM UTC+1, wrote:
    > On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
    > > 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:
    > > 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.
     
    Tricky, Apr 9, 2012
    #4
  5. Bill Guest

    On Apr 9, 9:13 am, Tricky <> wrote:
    > On Friday, April 6, 2012 12:04:41 AM UTC+1, wrote:
    > > On Thursday, April 5, 2012 8:32:25 AM UTC-6, Paul Uiterlinden wrote:
    > > > 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:
    > > > 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.
     
    Bill, Apr 11, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andreas Klemt
    Replies:
    2
    Views:
    582
    Andreas Klemt
    Jul 5, 2003
  2. Joe Fallon
    Replies:
    3
    Views:
    785
    =?Utf-8?B?Z3V5?=
    Jul 16, 2004
  3. Guest

    shared? protected? friend?

    Guest, Nov 29, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    8,532
    Scott Allen
    Nov 29, 2004
  4. Imran Aziz
    Replies:
    1
    Views:
    556
    Stefan
    Aug 22, 2005
  5. Tricky
    Replies:
    5
    Views:
    1,178
Loading...

Share This Page