Defined ranges

[rickman]

I am using a subtype to define a range as used in a SLV declaration.

subtype INST_RNG is natural range 23 downto 0;
signal CTPCurCmd : std_logic_vector (INST_RNG);

But if I try to use the same subtype to define a sub-range in an
assignment, I get this error message.

# Error: COMP96_0263: IRIG_FPGA_TB.vhd : (504, 68): Type names are not
allowed as primaries.


Is this just a limitation of the tool I am using or is this a language
issue? Is there a better way to define ranges so the parts of an
array can be dealt with symbolically?

Rick

 

On Jun 5, 12:30 am, rickman <gnu...@gmail.com> wrote:

I am using a subtype to define a range as used in a SLV declaration.

subtype INST_RNG is natural range 23 downto 0;
signal CTPCurCmd : std_logic_vector (INST_RNG);

But if I try to use the same subtype to define a sub-range in an
assignment, I get this error message.

# Error: COMP96_0263: IRIG_FPGA_TB.vhd : (504, 68): Type names are not
allowed as primaries.

Is this just a limitation of the tool I am using or is this a language
issue? Is there a better way to define ranges so the parts of an
array can be dealt with symbolically?

Rick

Without an example of what you mean by "define a sub-range in an
assignment", I'm working in the dark. However, on first blush, this
sounds like a tool error: using a type mark as a discrete range in a
slice name (which I what I'm guessing you want), is allowed. In
particular, the LRM grammar says

slice_name uses a discrete_range
discerete_range can be a discrete_subtype_indication
a subtype_indication can be a type_mark, which is a simple identifier
denoting a type or subtype.

The message implies that the compiler isn't looking for the discrete
range interpretation, it's only trying to parse as an expression,
which has "primary" as one of the underlying constituents.

The Modelsim 6.0a compiler accepts the following without error: (note
that I made up an assignment)

library IEEE;
use IEEE.std_logic_1164.all;

entity test is
end test;

architecture test of test is
subtype INST_REG is natural range 0 to 23;
signal CTPCurCmd : std_logic_vector(INST_REG);
signal foo : std_logic_vector(INST_REG);
begin -- test
foo(INST_REG) <= CTPCurCmd(INST_REG);
end test;


Hope this helps,

- Kenn

 

[rickman]

On Jun 5, 7:15 am, kennheinr...@sympatico.ca wrote:

On Jun 5, 12:30 am, rickman <gnu...@gmail.com> wrote:



I am using a subtype to define a range as used in a SLV declaration.

subtype INST_RNG is natural range 23 downto 0;
signal CTPCurCmd : std_logic_vector (INST_RNG);

But if I try to use the same subtype to define a sub-range in an
assignment, I get this error message.

# Error: COMP96_0263: IRIG_FPGA_TB.vhd : (504, 68): Type names are not
allowed as primaries.

Is this just a limitation of the tool I am using or is this a language
issue? Is there a better way to define ranges so the parts of an
array can be dealt with symbolically?

Rick

Without an example of what you mean by "define a sub-range in an
assignment", I'm working in the dark. However, on first blush, this
sounds like a tool error: using a type mark as a discrete range in a
slice name (which I what I'm guessing you want), is allowed. In
particular, the LRM grammar says

slice_name uses a discrete_range
discerete_range can be a discrete_subtype_indication
a subtype_indication can be a type_mark, which is a simple identifier
denoting a type or subtype.

The message implies that the compiler isn't looking for the discrete
range interpretation, it's only trying to parse as an expression,
which has "primary" as one of the underlying constituents.

The Modelsim 6.0a compiler accepts the following without error: (note
that I made up an assignment)

library IEEE;
use IEEE.std_logic_1164.all;

entity test is
end test;

architecture test of test is
subtype INST_REG is natural range 0 to 23;
signal CTPCurCmd : std_logic_vector(INST_REG);
signal foo : std_logic_vector(INST_REG);
begin -- test
foo(INST_REG) <= CTPCurCmd(INST_REG);
end test;

Hope this helps,

- Kenn

Opps... The error was staring me in the face and I didn't see it. I
got too wrapped up in the literal of the message and didn't really
understand it. The signal name I was using was of the type, not the
signal! Duh!

I guess I need to knock off work earlier... before my vision gets
blurry... :^)

Rick