stumped on syntax yet again!

S

Shannon

Guest
Ok, here is the relevant code snipits:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

HWID : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
RAM_addr : OUT UNSIGNED(9 DOWNTO 0);

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF
STD_LOGIC_VECTOR(HWID'RANGE);
SIGNAL regs : reg_type;
SIGNAL data_in : STD_LOGIC_VECTOR(HWID'RANGE);

Line 156: RAM_addr <= UNSIGNED("00" & data_in);

and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match. It seems
very clear that RAM_addr is unsigned, "00" is SLV, and data_in is
SLV. "&" can only have one possible meaning. I'm sure that I'm doing
something else wrong that you guys will point out in less than a
second! ;)

Shannon
 
Shannon wrote:

Line 156: RAM_addr <= UNSIGNED("00" & data_in);
and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match.
Click to expand...
Make arrays of subtypes, not base types.

The problem is inside the parens.
"00" is an anonymous type that could be an reg_type *element*.

STD_LOGIC_VECTOR(HWID'RANGE) is an anonymous subtype.

The LRM does not require the compiler to think further.
That's just the way it is.

Simplest fix is to declare and use subtypes for the
various STD_LOGIC_VECTOR widths.

-- Mike Treseler
 
Shannon wrote:

That didn't change anything so I'm obviously not understanding the
term "anonymous subtype". Any hints?
Click to expand...

Line 156: RAM_addr <= UNSIGNED("00" & data_in);
Click to expand...
RAM_addr <= my_address_subtype'("00" & data_in);
 
Mike Treseler a écrit :
Shannon wrote:

That didn't change anything so I'm obviously not understanding the
term "anonymous subtype". Any hints?


Line 156: RAM_addr <= UNSIGNED("00" & data_in);

RAM_addr <= my_address_subtype'("00" & data_in);
Click to expand...
I recently had a similar problem (though I was only using SLVs) and
fixed it by pulling the litteral constant out of the cast :

RAM_addr <= "00" & unsigned(data_in);

In this case the context is clear : "00" must be unsigned to make the
assignment valid.
I still don't understand why the context is unclear when concatenating a
litteral constant and a std_logic_vector.

Nicolas
 
On May 7, 10:57 am, Mike Treseler <mike_trese...@comcast.net> wrote:
Shannon wrote:
Line 156:  RAM_addr <= UNSIGNED("00" & data_in);
and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match.

Make arrays of subtypes, not base types.

The problem is inside the parens.
"00" is an anonymous type that could be an reg_type *element*.

STD_LOGIC_VECTOR(HWID'RANGE) is an anonymous subtype.

The LRM does not require the compiler to think further.
That's just the way it is.

Simplest fix is to declare and use subtypes for the
various STD_LOGIC_VECTOR widths.

       -- Mike Treseler
Click to expand...
Thanks for the help Mike. I guess I still don't understand. I tried
googling for "anonymous subtype" but I didn't find any helpful
information.

I tried declaring a subtype by doing:

subtype hwid_type IS STD_LOGIC_VECTOR(7 DOWNTO 0);

and then:

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF hwid_type;
SIGNAL data_in : hwid_type;

That didn't change anything so I'm obviously not understanding the
term "anonymous subtype". Any hints?

Shannon
 
Nicolas Matringe wrote:
I recently had a similar problem (though I was only using SLVs) and
fixed it by pulling the litteral constant out of the cast :

RAM_addr <= "00" & unsigned(data_in);
Click to expand...
Yes. Of course. That's the ticket.


I still don't understand why the context is unclear when concatenating a
literal constant and a std_logic_vector.
Click to expand...
The parser is not saying that "00" won't '&' with data_in.
It's saying that it is possible that "00"
was *meant* to be an element of another type in scope.
Which would be a type error.
So it is a type error.
Hmmm.

-- Mike Treseler
 
Shannon wrote:

If "00" is a vague type in this case why can't I cast it to make the
error go away?
Click to expand...
Declare it as a constant to give it a type.

That's good practice in any case.
I often declare zero constants for this:

RAM_addr <= my_adr_zero_c + data_in;

-- Mike Treseler
 
On May 7, 1:26 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
Nicolas Matringe wrote:

I recently had a similar problem (though I was only using SLVs) and
fixed it by pulling the litteral constant out of the cast :

RAM_addr <= "00" & unsigned(data_in);

Yes. Of course. That's the ticket.

I still don't understand why the context is unclear when concatenating a
literal constant and a std_logic_vector.

The parser is not saying that "00" won't '&' with data_in.
It's saying that it is possible that "00"
was *meant* to be an element of another type in scope.
Which would be a type error.
So it is a type error.
Hmmm.

     -- Mike Treseler
Click to expand...
RAM_addr is of type UNSIGNED not 'my_address_subtype'
So I tried:

RAM_addr <= UNSIGNED(my_address_subtype'("00" & data_in));

but then I'm back to the original errors again.

Nicolas's solution worked although I still don't understand why my
original line is wrong.

Thanks all!

Shannon
 
On May 7, 1:34 pm, Shannon <sgo...@sbcglobal.net> wrote:
On May 7, 1:26 pm, Mike Treseler <mike_trese...@comcast.net> wrote:





Nicolas Matringe wrote:

I recently had a similar problem (though I was only using SLVs) and
fixed it by pulling the litteral constant out of the cast :

RAM_addr <= "00" & unsigned(data_in);

Yes. Of course. That's the ticket.

I still don't understand why the context is unclear when concatenating a
literal constant and a std_logic_vector.

The parser is not saying that "00" won't '&' with data_in.
It's saying that it is possible that "00"
was *meant* to be an element of another type in scope.
Which would be a type error.
So it is a type error.
Hmmm.

     -- Mike Treseler

RAM_addr is of type UNSIGNED not 'my_address_subtype'
So I tried:

RAM_addr <= UNSIGNED(my_address_subtype'("00" & data_in));

but then I'm back to the original errors again.

Nicolas's solution worked although I still don't understand why my
original line is wrong.

Thanks all!

Shannon- Hide quoted text -

- Show quoted text -
Click to expand...
If "00" is a vague type in this case why can't I cast it to make the
error go away? For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);

Shannon
 
Shannon <sgomes@sbcglobal.net> writes:

If "00" is a vague type in this case why can't I cast it to make the
error go away? For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);
Click to expand...
You should be able to, certainly I have in the past. Does it not work?

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
Shannon wrote:

No, it doesn't work. It results in the same original errors. I'm
thinking it still doesn't work because in order to cast it as a SLV it
needs to know what it is casting it FROM. (i.e. it can't figure out
what "00" is in order to re-cast it.)
Click to expand...
I think that's about right.
Note that these fussy rules only apply
when I fail to declare my own constants
and subtypes.

-- Mike Treseler
 
On May 8, 2:49 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
Shannon <sgo...@sbcglobal.net> writes:
If "00" is a vague type in this case why can't I cast it to make the
error go away?  For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);

You should be able to, certainly I have in the past.  Does it not work?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html
Click to expand...
No, it doesn't work. It results in the same original errors. I'm
thinking it still doesn't work because in order to cast it as a SLV it
needs to know what it is casting it FROM. (i.e. it can't figure out
what "00" is in order to re-cast it.)

Shannon
 
Shannon
Ok, here is the relevant code snipits:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

HWID : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
RAM_addr : OUT UNSIGNED(9 DOWNTO 0);

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF
STD_LOGIC_VECTOR(HWID'RANGE);
SIGNAL regs : reg_type;
SIGNAL data_in : STD_LOGIC_VECTOR(HWID'RANGE);

Line 156: RAM_addr <= UNSIGNED("00" & data_in);

and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match. It seems
very clear that RAM_addr is unsigned, "00" is SLV, and data_in is
SLV. "&" can only have one possible meaning. I'm sure that I'm doing
something else wrong that you guys will point out in less than a
second! ;)

Shannon
Click to expand...
What tool is this? It may be a bug. Here is why I think so, maybe
someone can straighten out my thoughts:

You are wrong and the tool is correct in that the type of the expression,
"00" & data_in, can be either std_logic_vector or reg_type (concatenation
is implicitly defined for all array types). For example, if NUM_REGS is
two, the following would be legal:
regs <= data_in & data_in ;

OTOH, the type conversion UNSIGNED can only convert arrays of std_logic
to type unsigned. Since the type reg_type is not an array of std_logic,
it should not be a potential match to the overload resolution.

Perhaps one of our resident compiler people could comment?

I would say report it as a bug.

The work around Nicolas gave you:
RAM_addr <= "00" & unsigned(data_in);

works because there is no other path the tool can consider for the &.

Cheers,
Jim
 
The compiler can't figure out which "&" operator to use.
The rules in 7.3.5 Type conversion prohibit the target type
from being used to figure out the expression type.

Every array type comes with 4 implicit "&" operators:
"&"[array,array RETURN array]
"&"[array,elem RETURN array]
"&"[elem,array RETURN array]
"&"[elem,elem RETURN array]

VHDL uses only the base type when doing operator overloading
(figuring out which operator to use). This includes using
only the base type of the "elem" in the above.

--========================================================================
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

HWID : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
RAM_addr : OUT UNSIGNED(9 DOWNTO 0);

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF STD_LOGIC_VECTOR(HWID'RANGE);
SIGNAL regs : reg_type;
SIGNAL data_in : STD_LOGIC_VECTOR(HWID'RANGE);

Line 156: RAM_addr <= UNSIGNED("00" & data_in);
--========================================================================

Take the expression ("00" & data_in). Remember, we can't
use the enclosing type conversion target type UNSIGNED because
of the 7.3.5 rules. The type of data_in is clearly std_logic_vector.
Now we must figure out the type of "00" and which of these 8 to call:

In this testcase, 8 relevant "&" operators are visible.
1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector]
1b) "&"[std_logic_vector,std_ulogic RETURN std_logic_vector]
1c) "&"[std_ulogic,std_logic_vector RETURN std_logic_vector]
1d) "&"[std_ulogic,std_ulogic RETURN std_logic_vector]
2a) "&"[reg_type,reg_type RETURN reg_type]
2b) "&"[reg_type,std_logic_vector RETURN reg_type]
2c) "&"[std_logic_vector,reg_type RETURN reg_type]
2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type]

In the items labeled with "2", the type "reg_type" really means
the anonymous base type of the constrained array subtype "reg_type".

From these 8 concatenation operators, we need to pick the 1 that
will work, else we have an ambiguity (error).

The right operand "data_in" type being std_logic_vector, there
remain 4 possible choices:

1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector]
1c) "&"[std_ulogic,std_logic_vector RETURN std_logic_vector]
2b) "&"[reg_type,std_logic_vector RETURN reg_type]
2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type]

Looking at the left operand string literal "00" (which is necessarily
some 1-dim array type), we can further prune this down to 2 choices (and
know that "00" is std_logic_vector):

1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector]
2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type]

We can't decide which one of these 2 "&" operators to call. Overloading
occurs on the base type, and we can't use the RETURN type at all
when we're in a type conversion expression. The number of elements
of the constrained array subtype "reg_type" is irrelevant, any
length error would occur separate and after the overload resolution
has occurred. Basically, we don't know if ("00" & data_in) means,
"make an even longer std_logic_vector value", or "make a 2-element array value
of type "reg_type" (which would be an error because every element
of such a value has to be the same length as the other, and has to be the
same length as the actual element subtype of the array); the 2-element
interpretation must be considered even if the "reg_type" doesn't
define exactly two elements, and regardless of the length of the
element subtype.

There are at least 2 ways to make this work:

This effectively tells the expression of the type conversion
to UNSIGNED that "you are of type std_logic_vector", eliminating
choice 2d from the list:
RAM_addr <= UNSIGNED(std_logic_vector'("00" & data_in));

This converts data_in to UNSIGNED, bringing into play the 4 "&"
operators for type UNSIGNED, changing the interpretation of "00"
so that it's of type UNSIGNED, and chosing the
"&"[unsigned,unsigned RETURN unsigned] concatenation operator:
RAM_addr <= "00" & UNSIGNED(data_in);



Shannon wrote:
On May 7, 10:57 am, Mike Treseler <mike_trese...@comcast.net> wrote:

Shannon wrote:

Line 156: RAM_addr <= UNSIGNED("00" & data_in);
and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match.

Make arrays of subtypes, not base types.

The problem is inside the parens.
"00" is an anonymous type that could be an reg_type *element*.

STD_LOGIC_VECTOR(HWID'RANGE) is an anonymous subtype.

The LRM does not require the compiler to think further.
That's just the way it is.

Simplest fix is to declare and use subtypes for the
various STD_LOGIC_VECTOR widths.

-- Mike Treseler


Thanks for the help Mike. I guess I still don't understand. I tried
googling for "anonymous subtype" but I didn't find any helpful
information.

I tried declaring a subtype by doing:

subtype hwid_type IS STD_LOGIC_VECTOR(7 DOWNTO 0);

and then:

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF hwid_type;
SIGNAL data_in : hwid_type;

That didn't change anything so I'm obviously not understanding the
term "anonymous subtype". Any hints?

Shannon
Click to expand...
 
On May 8, 2:24 pm, Jim Lewis <j...@synthworks.com> wrote:
Shannon





Ok, here is the relevant code snipits:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

HWID       : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
RAM_addr   : OUT   UNSIGNED(9 DOWNTO 0);

TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF
STD_LOGIC_VECTOR(HWID'RANGE);
SIGNAL     regs    : reg_type;
SIGNAL     data_in : STD_LOGIC_VECTOR(HWID'RANGE);

Line 156:  RAM_addr <= UNSIGNED("00" & data_in);

and the error is:

Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"

I have no idea why it thinks "reg_type" is a possible match.  It seems
very clear that RAM_addr is unsigned, "00" is SLV, and data_in is
SLV.  "&" can only have one possible meaning.  I'm sure that I'm doing
something else wrong that you guys will point out in less than a
second!  ;)

Shannon

What tool is this?  It may be a bug.  Here is why I think so, maybe
someone can straighten out my thoughts:

You are wrong and the tool is correct in that the type of the expression,
"00" & data_in, can be either std_logic_vector or reg_type (concatenation
is implicitly defined for all array types).  For example, if NUM_REGS is
two, the following would be legal:
    regs        <= data_in & data_in ;

OTOH, the type conversion UNSIGNED can only convert arrays of std_logic
to type unsigned.  Since the type reg_type is not an array of std_logic,
it should not be a potential match to the overload resolution.

Perhaps one of our resident compiler people could comment?

I would say report it as a bug.

The work around Nicolas gave you:
   RAM_addr <= "00" & unsigned(data_in);

works because there is no other path the tool can consider for the &.

Cheers,
Jim- Hide quoted text -

- Show quoted text -
Click to expand...
You don't have to convince me that it's a bug! hehehe But I always
want to understand WHY things are the way they are. The thing I
learned here was "scope". I had no idea it was using the concept of
scope to resolve ambiguous situations.

Personally I think type casting it as an SLV should have worked.

Shannon
 
Shannon wrote:
On May 8, 2:24 pm, Jim Lewis <j...@synthworks.com> wrote:
Shannon





Ok, here is the relevant code snipits:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
HWID : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
RAM_addr : OUT UNSIGNED(9 DOWNTO 0);
TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF
STD_LOGIC_VECTOR(HWID'RANGE);
SIGNAL regs : reg_type;
SIGNAL data_in : STD_LOGIC_VECTOR(HWID'RANGE);
Line 156: RAM_addr <= UNSIGNED("00" & data_in);
and the error is:
Error (10327): VHDL error at xFace.vhd(156): can't determine
definition of operator ""&"" -- found 2 possible definitions
Error (10647): VHDL type inferencing error at xFace.vhd(156): type of
expression is ambiguous - "reg_type" or "std_logic_vector" are two
possible matches
Error (10411): VHDL Type Conversion error at xFace.vhd(156): can't
determine type of object or expression near text or symbol "UNSIGNED"
I have no idea why it thinks "reg_type" is a possible match. It seems
very clear that RAM_addr is unsigned, "00" is SLV, and data_in is
SLV. "&" can only have one possible meaning. I'm sure that I'm doing
something else wrong that you guys will point out in less than a
second! ;)
Shannon
What tool is this? It may be a bug. Here is why I think so, maybe
someone can straighten out my thoughts:

You are wrong and the tool is correct in that the type of the expression,
"00" & data_in, can be either std_logic_vector or reg_type (concatenation
is implicitly defined for all array types). For example, if NUM_REGS is
two, the following would be legal:
regs <= data_in & data_in ;

OTOH, the type conversion UNSIGNED can only convert arrays of std_logic
to type unsigned. Since the type reg_type is not an array of std_logic,
it should not be a potential match to the overload resolution.

Perhaps one of our resident compiler people could comment?

I would say report it as a bug.

The work around Nicolas gave you:
RAM_addr <= "00" & unsigned(data_in);

works because there is no other path the tool can consider for the &.

Cheers,
Jim

You don't have to convince me that it's a bug! hehehe But I always
want to understand WHY things are the way they are. The thing I
learned here was "scope". I had no idea it was using the concept of
scope to resolve ambiguous situations.

Personally I think type casting it as an SLV should have worked.

Shannon
Click to expand...
Unfortunately I agree with James' and Rob's analysis.
I don't like it, but there must be some reason for the
restriction.

Jim
 
Shannon <sgomes@sbcglobal.net> writes:

On May 8, 2:49 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
Shannon <sgo...@sbcglobal.net> writes:
If "00" is a vague type in this case why can't I cast it to make the
error go away?  For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);

You should be able to, certainly I have in the past.  Does it not work?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

No, it doesn't work. It results in the same original errors. I'm
thinking it still doesn't work because in order to cast it as a SLV it
needs to know what it is casting it FROM. (i.e. it can't figure out
what "00" is in order to re-cast it.)
Click to expand...
OK, so I missed James' detailed message, which had the second paren
in the right place (ie two parens after data_in, not one after
"00")... sorry about that!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
On May 9, 1:52 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
Shannon <sgo...@sbcglobal.net> writes:
On May 8, 2:49 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
Shannon <sgo...@sbcglobal.net> writes:
If "00" is a vague type in this case why can't I cast it to make the
error go away?  For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);

You should be able to, certainly I have in the past.  Does it not work?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

No, it doesn't work.  It results in the same original errors.  I'm
thinking it still doesn't work because in order to cast it as a SLV it
needs to know what it is casting it FROM.  (i.e. it can't figure out
what "00" is in order to re-cast it.)

OK, so I missed James' detailed message, which had the second paren
in the right place (ie two parens after data_in, not one after
"00")... sorry about that!

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html- Hide quoted text -

- Show quoted text -
Click to expand...
Great stuff! Thanks for the detailed explaination. This group is a
wonderful resource.

I think I followed James's explaination but I have one remaining
question.

If I (properly) used a subtype to declare my array:

subtype hwid_type IS STD_LOGIC_VECTOR(7 DOWNTO 0);
TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF hwid_type;
SIGNAL data_in : hwid_type;

Then wouldn't "reg_type" resolve down to SLV and thereby remove the
ambiguity? To refer back to James's list we would have:


1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector]
2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type]

but reg_type is really a subtype of SLV. So in fact 1a and 2d would
be equivalent.

(I know I'm wrong. I'm just looking for that last little bit of
understanding)

Shannon
 
Sorry, "reg_type" is not "really a subtype of SLV", it is a subtype
of a distinct type (an anonymous array type) whose element subtype
is the constrained array subtype "hwid_type".
The element *type* is still "std_logic_vector" however, and
overloading occurs using only base types, never subtypes.

Shannon wrote:
On May 9, 1:52 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

Shannon <sgo...@sbcglobal.net> writes:

On May 8, 2:49 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

Shannon <sgo...@sbcglobal.net> writes:

If "00" is a vague type in this case why can't I cast it to make the
error go away? For example:

RAM_addr <= UNSIGNED(STD_LOGIC_VECTOR'("00") & data_in);

You should be able to, certainly I have in the past. Does it not work?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

No, it doesn't work. It results in the same original errors. I'm
thinking it still doesn't work because in order to cast it as a SLV it
needs to know what it is casting it FROM. (i.e. it can't figure out
what "00" is in order to re-cast it.)

OK, so I missed James' detailed message, which had the second paren
in the right place (ie two parens after data_in, not one after
"00")... sorry about that!

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html- Hide quoted text -

- Show quoted text -


Great stuff! Thanks for the detailed explaination. This group is a
wonderful resource.

I think I followed James's explaination but I have one remaining
question.

If I (properly) used a subtype to declare my array:

subtype hwid_type IS STD_LOGIC_VECTOR(7 DOWNTO 0);
TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF hwid_type;
SIGNAL data_in : hwid_type;

Then wouldn't "reg_type" resolve down to SLV and thereby remove the
ambiguity? To refer back to James's list we would have:


1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector]
2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type]

but reg_type is really a subtype of SLV. So in fact 1a and 2d would
be equivalent.

(I know I'm wrong. I'm just looking for that last little bit of
understanding)

Shannon
Click to expand...
 
rickman wrote:

function sllint (x, sh : natural) return natural is
begin
return x*(2**sh);
end sllint;

I am not clear on what happens when I shift the value of Addr left by
2 and significant bits extend beyond the defined range.
Click to expand...
The function, as written, will return x*(2**sh)
up to the natural range. It knows nothing about
any other range unless you add a parameter
to to function.

I would use numeric_std.unsigned and the shift_left
function, and to_integer(my_uns, my_len) as needed.

-- Mike Treseler
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top