Globally static expression

[ALuPin@web.de]

Hi,

I am using the following globally static expression:

CASE ((InputAddressRegisterReg(13 DOWNTO 1) & '0') AND
cREGADDRGeneralRangeMask) IS
.....

When trying to compile that VHDL module with Modelsim I get the error
message:
Error: f:/sim/sim_msd/../../Src/Src_rtl/ProcInterface/
ProcInterface.vhd(930): (vcom-1014) Array type case expression must be
of a locally static subtype.

When putting it to synthesis with Synplify it is no problem at all.
Hardware is working fine.
So how can I solve that simulation "mismatch" ?

Rgds
Andre

 

[Andy]

On Jun 23, 7:41 am, "ALu...@web.de" <ALu...@web.de> wrote:

Hi,

I am using the following globally static expression:

CASE ((InputAddressRegisterReg(13 DOWNTO 1) & '0') AND
cREGADDRGeneralRangeMask) IS
....

When trying to compile that VHDL module with Modelsim I get the error
message:
Error: f:/sim/sim_msd/../../Src/Src_rtl/ProcInterface/
ProcInterface.vhd(930): (vcom-1014) Array type case expression must be
of a locally static subtype.

When putting it to synthesis with Synplify it is no problem at all.
Hardware is working fine.
So how can I solve that simulation "mismatch" ?

Rgds
Andre

Assign a variable with that expression, and use the variable in the
case statement.

Because the language defines the case statement as requiring mutually
exclusive and exhaustive choices, the compiler has to "know" the size
of your expression in the case statement, at compile time. The "and"
function return type is an unconstrained vector, and is defined in a
package, so the compiler does not know how wide the vector is when it
compiles this file, so the compiler cannot guarantee mutual exclusive
and exhaustive choices. Putting it in a container (variable) that is
known solves the problem.

The synthesis tool (synplify) should not accept the code either; enter
a bug report.

Andy

 

[ALuPin@web.de]

Hi Andy,

thank your for your answer.

The "and"
function return type is an unconstrained vector, and is defined in a
package, so the compiler does not know how wide the vector is when it
compiles this file,

What exactly is the unconstrained vector in the code shown ?

("cREGADDRGeneralRangeMask" has a constant definition:
CONSTANT cREGADDRGeneralRangeMask: std_logic_vector(13 DOWNTO 0) :=
"00000000111111"

Rgds
Andre

 

[KJ]

On Jun 23, 9:57 am, "ALu...@web.de" <ALu...@web.de> wrote:

Hi Andy,

thank your for your answer.

The "and"
function return type is an unconstrained vector, and is defined in a
package, so the compiler does not know how wide the vector is when it
compiles this file,

What exactly is the unconstrained vector in the code shown ?

("cREGADDRGeneralRangeMask" has a constant definition:
  CONSTANT cREGADDRGeneralRangeMask: std_logic_vector(13 DOWNTO 0) :> "00000000111111"

Rgds
Andre

The 'not globally static expression' is in the case statement in your
original posting...not in your definition of the constant

CASE ((InputAddressRegisterReg(13 DOWNTO 1) & '0') AND
cREGADDRGeneralRangeMask) IS

KJ

 

[ALuPin@web.de]

Hi KJ,

yes of course. I posted the CONSTANT definition to make clear that the
second part of the expression is constant.
I tried different Synplify / SynplifyPro versions. None of them
complains about the not locally static expression.


Rgds,
Andre

 

[KJ]

On Jun 23, 10:52 am, "ALu...@web.de" <ALu...@web.de> wrote:

Hi KJ,

I tried different Synplify / SynplifyPro versions. None of them
complains about the not locally static expression.

But that does not mean that Synplify is correct in their
interpretation. I think Andy is correct, if you want another opinion
outside of the newsgroup by the experts that have their LRMs in hand
you can also try...

http://www.eda-stds.org/vasg/bugrep.htm#bugrepform

What is says there is...
"If you're experiencing a problem, issue, ambiguity or inconsistent
treatment of VHDL by different vendors which may be due to a language
issue, please fill out and submit the following issue report form."

I think I got an answer back in about a day or so on something I asked
about a long while back.

In any case, as a way to get going, follow Andy's suggestion. To
contribute to trying to improve whichever tool is not compliant though
you should also take Andy's advice about submitting a bug report to
the offending vendor. Having the backing of the experts at eda-
stds.org/vasg on which tool is wrong will give you some more clout.
Keeping the vendors honest in their interpretation of the language is
partly the users job as well.

Kevin Jennings

 

[ALuPin@web.de]

Hi Kevin,

thank you for the link, I have filled out and submitted the issue
report.
Apart from that I will contact Synplicity.

Rgds
Andre

 

[ALuPin@web.de]

Same module compiled with Precision leads to the following error
message:

"... Incomplete choice in Case Statement. Design compilation failed,
unsupported or non-rtl constructs detected"

Rgds
Andre