Shared variable cannot be declared before the protected type body

P

Paul Uiterlinden

Since the availability of PROTECTED SHARED variables in VHDL I have been
using them. Below is an example of a global failure counter that can be
incremented and read (but not set or reset). To make it globally available,
it is put in a package. My verification components will increment this
counter when errors are encountered. The counter is read in the testbench
at the end of the simulation to produce a PASS/FAIL message.

So far, so good.

Until version 6.3b of ModelSim arrived.

Now I get this error message:

** Error: errcount_pkg.vhd(6): (vcom-1257) Shared
variable "global_failure_counter" of protected
type "global_failure_counter_type" cannot be declared before the protected
type body.

This is the code:

PACKAGE errcount_pkg IS
TYPE global_failure_counter_type IS PROTECTED
PROCEDURE inc;
IMPURE FUNCTION value RETURN natural;
END PROTECTED global_failure_counter_type;
SHARED VARIABLE global_failure_counter : global_failure_counter_type;
END PACKAGE errcount_pkg;

PACKAGE BODY errcount_pkg IS
TYPE global_failure_counter_type IS PROTECTED BODY
VARIABLE count : natural;

PROCEDURE inc IS
BEGIN
count := count + 1;
END PROCEDURE inc;

IMPURE FUNCTION value RETURN natural IS
BEGIN
RETURN count;
END FUNCTION value;
END PROTECTED BODY global_failure_counter_type;
END PACKAGE BODY errcount_pkg;

The release notes have the following to say:

VHDL Defects Repaired in 6.3b
* In prior releases the VHDL compiler allowed a variable of a protected
type to be created prior to declaring the body. This is common if a
package is used to declare the protected type header and a shared
variable of that type is also declared within the package header. The
simulation could crash or generate incorrect results when this
happened. The vcom switch -allowProtectedBeforeBody allows the old
behavior but the simulator can still crash or generate incorrect
results.

So I can use this switch. But everytime I have a crash I will wonder if it
is caused by this kind of code (although I have been using this style for
quite some while).

I could split the package in two and put the shared variable in the second
package, but I don't want to do that, really. Alternatively, I could move
the shared variable to the body, and use additional wrapper subprograms.
Not very attractive either.

What I would like to know first, is whether my code is compliant with the
standards or not.

As I do not have the 2002 LRM, I cannot check whether this code style is
really not allowed, or Mentor Graphics is taking a short cut by opting the
easy way out.

Any ideas whether my code is IEEE Std 1076-2002 compliant or not?

Oh, wait a minute, there is the much forgotten verror command:

% verror 1257
vcom Message # 1257:
IEEE Std 1076-1993 12.3.1.2 Type declarations:
Elaboration of a protected type body has no effect other than to
establish that the body, from then on, can be used during the
elaboration of objects of the protected type.
In particular (but not exclusively), this rule prevents a package
declaration from containing both a protected type declaration and a
(shared) variable declaration of that type; this is because a protected
type body cannot be declared in a package declaration
Use the "-allowProtectedBeforeBody" compiler switch to disable this
check; however, indeterminate results are possible if this rule is
violated.

This seems pretty convincing, but if anyone has ideas to share, I would like
them to hear.
 
J

Jim Lewis

Paul,
Paul Butler submitted a similar issue to ISAC a while back.
The following link contains the ISAC analysis of the situation:
http://www.eda-stds.org/isac/IRs-VHDL-2002/IR2119.txt

Note that the ISAC analysis concludes with:
Should compelling use cases be identified, a requirement
for language enhancement may be forwarded to the VASG.

So perhaps you could submit your example to ISAC through
the link at:
http://www.eda-stds.org/vasg/#Enhancements

Please reference IR2119 when you do.

You, as a senior member of the VHDL community, can get a free
copy of the standard in return for donating some of your time
and helping work on the next set of revisions :). The
technical work is currently being worked through Accellera - your
participation would be valued.

Best,
Jim
 
P

Paul Uiterlinden

Jim said:
Paul,
Paul Butler submitted a similar issue to ISAC a while back.
The following link contains the ISAC analysis of the situation:
http://www.eda-stds.org/isac/IRs-VHDL-2002/IR2119.txt

Ah, thanks for this link!
Note that the ISAC analysis concludes with:
Should compelling use cases be identified, a requirement
for language enhancement may be forwarded to the VASG.

So perhaps you could submit your example to ISAC through
the link at:
http://www.eda-stds.org/vasg/#Enhancements

Please reference IR2119 when you do.

I will do that.
You, as a senior member of the VHDL community, can get a free
copy of the standard in return for donating some of your time
and helping work on the next set of revisions :). The
technical work is currently being worked through Accellera - your
participation would be valued.

Oh my, so many toys, so little time! :)
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top