"Type of temp_label_index is incompatible with type of lbl_data."
I've been futzing with this for an hour now what's the answer???
; lbl_data : in std_logic_vector(7 downto 0)
subtype t_lbl_r is integer range 0 to 15; -- 16 labels are
availabe for now.
signal temp_label_index : t_lbl_r;
if (lbl_data /= x"00") then
temp_label_index <= lbl_data(3 downto 0); ----<<< error here
PC <= the_label(temp_label_index); --lbl
this also doesn't work:
"The expression can not be converted to type integer."
temp_label_index <= integer(unsigned(lbl_data(3 downto 0)));
"Type of xxx is incompatible with type of yyy." typecasting error.
Started by ●February 16, 2009
Reply by ●February 16, 20092009-02-16
On Mon, 16 Feb 2009 12:24:42 -0800 (PST), jleslie48 wrote:>"Type of temp_label_index is incompatible with type of lbl_data."Wrong-group alarm: take VHDL language questions to comp.lang.vhdl.>I've been futzing with this for an hour now what's the answer???(1) Get a Doulos Golden Reference Guide, or something like it; (2) Trawl comp.lang.vhdl for references to "numeric_std"; (3) Be aware that VHDL is a (very) strongly typed language.> ; lbl_data : in std_logic_vector(7 downto 0)std_logic_vector is just a bag-o-bits with no numeric meaning.> subtype t_lbl_r is integer range 0 to 15; > signal temp_label_index : t_lbl_r;That's a numeric value that has no bag-o-bits meaning (although you, I and a synthesis tool all think it has).>if (lbl_data /= x"00") thenThat's OK, literal comparison of one bag-o-bits with another.> temp_label_index <= lbl_data(3 downto 0); ----<<< error hereOf course it's an error; they have totally different data types. Blast these hooligan C programmers; their wretched BCPL-inspired bit-picking will be the death of us.>this also doesn't work: >"The expression can not be converted to type integer."Ahah. Long may the angels continue to dance on the pinhead. Confuse at your peril "type conversion" and "type conversion function" (details below).>temp_label_index <= integer(unsigned(lbl_data(3 downto 0)));So... unsigned is a type that has the same footprint (array of std_logic indexed by natural) as std_logic_vector, therefore it is "closely related" and it's ok to say unsigned(some_std_logic_vector_value) and you get the exact same bag-o-bits but now it has unsigned type. And unsigned type HAS a numeric meaning. But integer and unsigned are NOT closely related, so you need a TYPE CONVERSION FUNCTION to convert one to another: temp_label_index <= to_integer(unsigned(lbl_data(3 downto 0))); (spot the three additional characters in "to_integer"). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See the well-informed discussion on the very recent thread unsigned(), unsigned'(), to_unsigned() on comp.lang.vhdl; and many other such over the past few years. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
Reply by ●February 16, 20092009-02-16
On Feb 16, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote:> On Mon, 16 Feb 2009 12:24:42 -0800 (PST), jleslie48 wrote: > >"Type of temp_label_index is incompatible with type of lbl_data." > > Wrong-group alarm: take VHDL language questions to comp.lang.vhdl. > > >I've been futzing with this for an hour now what's the answer??? > > (1) Get a Doulos Golden Reference Guide, or something like it; > (2) Trawl comp.lang.vhdl for references to "numeric_std"; > (3) Be aware that VHDL is a (very) strongly typed language. > > > ; lbl_data : in std_logic_vector(7 downto 0) > > std_logic_vector is just a bag-o-bits with no numeric meaning. > > > subtype t_lbl_r is integer range 0 to 15; > > signal temp_label_index : t_lbl_r; > > That's a numeric value that has no bag-o-bits meaning > (although you, I and a synthesis tool all think it has). > > >if (lbl_data /= x"00") then > > That's OK, literal comparison of one bag-o-bits with another. > > > temp_label_index <= lbl_data(3 downto 0); ----<<< error here > > Of course it's an error; they have totally different > data types. Blast these hooligan C programmers; their > wretched BCPL-inspired bit-picking will be the death of us. > > >this also doesn't work: > >"The expression can not be converted to type integer." > > Ahah. Long may the angels continue to dance on the > pinhead. Confuse at your peril "type conversion" and > "type conversion function" (details below). > > >temp_label_index <= integer(unsigned(lbl_data(3 downto 0))); > > So... unsigned is a type that has the same footprint > (array of std_logic indexed by natural) as std_logic_vector, > therefore it is "closely related" and it's ok to say > unsigned(some_std_logic_vector_value) > and you get the exact same bag-o-bits but now it has > unsigned type. And unsigned type HAS a numeric meaning. > But integer and unsigned are NOT closely related, so you > need a TYPE CONVERSION FUNCTION to convert one to another: > > temp_label_index <= to_integer(unsigned(lbl_data(3 downto 0))); > > (spot the three additional characters in "to_integer"). > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > See the well-informed discussion on the very recent thread > unsigned(), unsigned'(), to_unsigned() > on comp.lang.vhdl; and many other such over the > past few years. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Ratta fracken, muda, friggen.... (he says under his breath) 10 points for Gryffindor... works.
Reply by ●February 16, 20092009-02-16
On Feb 16, 3:43=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote:> > See the well-informed discussion on the very recent thread > =A0 unsigned(), unsigned'(), to_unsigned() > on comp.lang.vhdl; and many other such over the > past few years.Jon, The problem you are seeing is due to the strong typing of VHDL and is intended to prevent you from shooting yourself in the foot. The above is, in a nutshell, what you need to learn to deal with this. After you fight... I mean *learn* the rules associated with this I'll let you tell me if it is worth it. I think if I had learned Verilog first, I would have never used VHDL. But I am pretty used to it now so no big deal. Still, there are millions of lines of code running the Internet or even satellites that have never been "protected" by strong typing. I think there are any number of other things that are much more important to correct design than strong typing. Rick
Reply by ●February 17, 20092009-02-17
rickman wrote: (snip)> I think if I had learned Verilog first, I would have never used VHDL. > But I am pretty used to it now so no big deal. Still, there are > millions of lines of code running the Internet or even satellites that > have never been "protected" by strong typing. I think there are any > number of other things that are much more important to correct design > than strong typing.I learned Verilog first. I can now usually read VHDL, but I don't claim to be able to write it. It does seem so wordy to me. -- glen
Reply by ●February 17, 20092009-02-17
On Feb 16, 7:53 pm, rickman <gnu...@gmail.com> wrote:> On Feb 16, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > > > > > See the well-informed discussion on the very recent thread > > unsigned(), unsigned'(), to_unsigned() > > on comp.lang.vhdl; and many other such over the > > past few years. > > Jon, > > The problem you are seeing is due to the strong typing of VHDL and is > intended to prevent you from shooting yourself in the foot. The above > is, in a nutshell, what you need to learn to deal with this. After > you fight... I mean *learn* the rules associated with this I'll let > you tell me if it is worth it. > > I think if I had learned Verilog first, I would have never used VHDL. > But I am pretty used to it now so no big deal. Still, there are > millions of lines of code running the Internet or even satellites that > have never been "protected" by strong typing. I think there are any > number of other things that are much more important to correct design > than strong typing. > > RickI have no problems with the rules of conversion, I just have to unlearn a bunch of lazy habits that C lets you get away with. in C, if its an 8 bit storage location, that's all that really matters, 8 bits is 8 bits. I actually had the right solution here: temp_label_index <= integer(unsigned(lbl_data(3 downto 0))); I had simply misread my textbook, and used integer instead of TO_integer. I'm not even sure what "tempvar <= integer(xyz)" will do. I thought the reserved word integer was for variable declaration. It must have another definition in this context that is different. also from my reading I came across: d <= signed'("00" & c); what does the ' character do?
Reply by ●February 17, 20092009-02-17
On Tue, 17 Feb 2009 07:26:02 -0800 (PST), jleslie48 wrote:>I'm not even sure what "tempvar <= integer(xyz)" will do. I thought >the reserved word integer >was for variable declaration. It must have another definition in this >context that is different. >also from my reading I came across: > d <= signed'("00" & c); > >what does the ' character do?PLEASE read, carefully, the thread on comp.lang.vhdl that I cited:> See the well-informed discussion on the very recent thread > � unsigned(), unsigned'(), to_unsigned() > on comp.lang.vhdl; and many other such over the > past few years.In (very) brief: * type_name(expression) is a TYPE CONVERSION. It is a type-cast, like "(type_name)expression" in C, but it works only between "closely related types": std_logic_vector <-> unsigned, signed integer <-> real any array type <-> any other array type with the same element type and the same index (subscript) type * type_name'(expression) is a TYPE QUALIFICATION. It is useful only when the type of "expression" is ambiguous: for example, is "1001" a string or a std_logic_vector? string'("1001") disambiguates. Type qualification cannot do any conversion; "expression" MUST be a valid example of "type_name" otherwise it doesn't work. NOTE: I said "type_name" above; strictly speaking I should have said "type mark" but that's language-lawyer pedant stuff. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
Reply by ●February 17, 20092009-02-17
On Feb 17, 10:26 am, jleslie48 <j...@jonathanleslie.com> wrote:> > I actually had the right solution here: > > temp_label_index <= integer(unsigned(lbl_data(3 downto 0))); > > I had simply misread my textbook, and used integer instead of > TO_integer. > > I'm not even sure what "tempvar <= integer(xyz)" will do. I thought > the reserved word integer > was for variable declaration. It must have another definition in this > context that is different. > also from my reading I came across: > d <= signed'("00" & c); > > what does the ' character do?Jonathan gave you a reference above that looks to be very good. Search google groups on "unsigned(), unsigned'(), to_unsigned()" In a nutshell, the to_xxx function is just that, a function that is defined to convert between various data types that are not closely related. If that function is not defined, it won't work. That is why Jonathan said to "(2) Trawl comp.lang.vhdl for references to "numeric_std";" numeric_std provides for conversions between the signed and unsigned types and other, not closely related types. unsigned () allows the conversion of closely related types, that is types that really don't need any conversion between them. I believe this is equivalent to type casting in C (if I remember enough about type casting in C). No conversion is made, so the types must have a common element(s) and be defined according to http://tams-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#ambiguous_expressions unsigned' is used when the item used is not of a definite type. This establishes the type. What does that mean??? A string can be several different types for example. Often the usage of a string is clear from the context (meaning clear according to the rules VHDL works under). But sometimes the type is not clear. An example is when a function is defined with overloaded parameter types such as bit vector and slv. These types are not closely related, so the tool does not know when function you intend. So the xxx' gives the tool a hint and it is now happy and stops throwing errors at you. (not quite the same as throwing arrows at you) Do the search and read the other thread. Also check out the FAQ, that is a great source of *good* information if you don't already use it. This whole typing issue is where I have had the most trouble with VHDL myself. That is one of many reasons why I limit my coding style. Staying within my self imposed white lines keeps me from having to remember all sorts of details about a rather Daedalian language. Oh, one other caution, the fact that you program works with any given tool does not mean it has been written correctly with respect to the rules of VHDL. Tools often have "features" where they accept constructs that are not actually correct and won't work on other tools. But maybe that has gone by the wayside. I haven't been pushing that issue in a while. Rick
Reply by ●February 17, 20092009-02-17
On Tue, 17 Feb 2009 08:49:31 -0800 (PST), rickman wrote: [...]>Oh, one other caution, the fact that you program works with any given >tool does not mean it has been written correctly with respect to the >rules of VHDL. Tools often have "features" where they accept >constructs that are not actually correct and won't work on other >tools. But maybe that has gone by the wayside. I haven't been >pushing that issue in a while.To be fair to the tools, it is rare these days to get significant differences among VHDL _simulators_ except on truly trivial matters - for example, ModelSim tolerates time literals without a space between the number and the unit, such as 10ns, while VHDL officially demands the space like 10 ns. But we have had some interesting discussions recently about illegal VHDL constructs that got through XST compilation without error or warning. So Rick's caution is noteworthy. And it is ALWAYS a good idea to compile and elaborate your code in a simulator before letting the synthesis tool loose on it, even if you're one of those scary people who don't believe in simulation... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
Reply by ●February 18, 20092009-02-18
On Feb 17, 4:19=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote:> But we have had some interesting discussions recently about > illegal VHDL constructs that got through XST compilation > without error or warning. =A0So Rick's caution is noteworthy. > And it is ALWAYS a good idea to compile and elaborate your > code in a simulator before letting the synthesis tool > loose on it, even if you're one of those scary people who > don't believe in simulation... > -- > Jonathan Bromley, ConsultantThat is always a good idea. I often will run synthesis on my code while still in the simulation stage just because the two tools with catch different types of errors. No point in finding an error in synthesis after you are done with simulation because you will just have to go back and verify your simulation again to make sure your fix didn't break anything. Rick
