Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Integer in port declaration?

Reply
Thread Tools

Integer in port declaration?

 
 
Lenny
Guest
Posts: n/a
 
      07-03-2007
Hi all

I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
vhdl language.

My question is: it's possible to declare an integer in port statement?
Reading a book (I'm a newbie in vhdl it seems to be legal, so I did
it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
simulator) showed me an unknown state for this port; the vhdl list is:

-- NOT_OK code (simple counter)
entity Tmr1 is
port(clk, reset: IN std_logic;
seg1: OUT integer range 0 to 9);
end Tmr1;

architecture Behavioral of Tmr1 is
begin
process(clk, reset)
variable un: integer range 0 to 10;
begin
if (reset='1') then
un:=0;
elsif rising_edge(clk) then
un:=un+1;
if un=10 then un:=0;
end if;
end if;
seg1<=un;
end process;
end Behavioral;

-- end NOT_OK code

Behavioral simulation is OK, but logic simulation shows a strange
unknown in seg1. Here you could see the simulation:
http://img112.imageshack.us/my.php?i...imnotokgf8.png

Using std_logic_vector type intead of integer in port declaration solved
the problem:

--OK_CODE (simple counter)
library IEEE;
use ieee.std_logic_arith.all;
use IEEE.STD_LOGIC_1164.ALL;

entity Tmr1 is
port(clk, reset: IN std_logic;
seg1: OUT std_logic_vector(7 downto 0));
end Tmr1;

architecture Behavioral of Tmr1 is
begin
process(clk, reset)
variable un: integer range 0 to 10;
begin
if (reset='1') then
un:=0;
elsif rising_edge(clk) then
un:=un+1;
if un=10 then un:=0; end if;
end if;
seg1<=conv_std_logic_vector(un,;
end process;
end Behavioral;
-- End OK_CODE

Any explaination? Dealing with integers in port statement is not allowed?!?

Lenny
 
Reply With Quote
 
 
 
 
Martin Thompson
Guest
Posts: n/a
 
      07-03-2007
Lenny <(E-Mail Removed)> writes:

> Hi all
>
> I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
> vhdl language.
>
> My question is: it's possible to declare an integer in port statement?
> Reading a book (I'm a newbie in vhdl it seems to be legal, so I did
> it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
> simulator) showed me an unknown state for this port; the vhdl list is:
>


It's OK to use integers and other non-logic types in *internal*
entities, but if you use them on the top-level entity to represent
actual device pins, the tools will turn them into std_logic_vectors,
and then when you run the "logic simulation" (I'm not familiar with
ISE's simulator, but that sounds like a gate-level simulation?), you
find they don't match any more.

Feel free to use integers inside the FPGA, but convert them to
std_logic_vectors "at the pins", as you've discovered:

I see you've used std_logic_arith below, you're better off with
numeric_std (search the archives, there's many threads on this!)

<snip NOT OK code>

> Behavioral simulation is OK, but logic simulation shows a strange
> unknown in seg1. Here you could see the simulation:
> http://img112.imageshack.us/my.php?i...imnotokgf8.png
>
> Using std_logic_vector type intead of integer in port declaration solved
> the problem:
>


Yes.

> --OK_CODE (simple counter)
> library IEEE;
> use ieee.std_logic_arith.all;


Don't use std_logic_arith it's non-standard (even though the
"ieee." implies it is!) - search the archives or the VHDL FAQ for
more details.

Do this instead:
use ieee.numeric_std.all;
> use IEEE.STD_LOGIC_1164.ALL;
>
> entity Tmr1 is
> port(clk, reset: IN std_logic;
> seg1: OUT std_logic_vector(7 downto 0));
> end Tmr1;
>
> architecture Behavioral of Tmr1 is
> begin
> process(clk, reset)
> variable un: integer range 0 to 10;
> begin
> if (reset='1') then
> un:=0;
> elsif rising_edge(clk) then
> un:=un+1;
> if un=10 then un:=0; end if;
> end if;
> -- not this seg1<=conv_std_logic_vector(un,;

And this:
seg1<=std_logic_vector(to_unsigned(un,seg1'range)) ;
> end process;
> end Behavioral;
> -- End OK_CODE
>
> Any explaination? Dealing with integers in port statement is not allowed?!?
>


Not on the pins

HTH!

Martin

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      07-03-2007

"Lenny" <(E-Mail Removed)> wrote in message
news:4689f3b0$0$17944$(E-Mail Removed) ...
> Hi all
>
> I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
> vhdl language.
>
> My question is: it's possible to declare an integer in port statement?
> Reading a book (I'm a newbie in vhdl it seems to be legal, so I did
> it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
> simulator) showed me an unknown state for this port; the vhdl list is:
>


It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
started incrementing the most significant bit instead of the least (bug
2...or maybe the X folks simply like to count that way). Then when it
couldn't count beyond 1 it went unknown (bug 3).

The interesting thing is that it must've kept counting somewhat correctly
since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
could be that ISE fumbled somewhat with handling variables (try changing
'un' from a variable to a signal and see if you get the same result).
Another thing that might've confused it is the integer range on 'seg1' is 0
to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
range).

Although perfectly legit, using anything other than
std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
the design is generally discouraged. One reason is that it creates an
inconsistency in the basic data type (i.e. std_logic_vector or integer) for
the unit under test in a testbench. The main reason though is that the
synthesis vendors sometimes do a poor job of supporting the language and you
need to stoop to their level to get your job done. One out here is to
switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
know why you won't be using their parts.

Your code is fine as is, decide whether using brand X is worth the hassles
on something this simple or not.

KJ


 
Reply With Quote
 
yves.770905@gmail.com
Guest
Posts: n/a
 
      07-03-2007
KJ,

Why do you think this is a bug?
It's all a matter of encoding and representation. You can represent an
integer with whatever code you can think of. Sure it is recommended by
IEEE 1076.6 that a synthesis tool converts integers into a
corresponding vector of bits and should have an unsigned binary
representation.
But it is not a bug doing it in another way.

Kind regards,

Yves

On 3 jul, 12:13, "KJ" <(E-Mail Removed)> wrote:
> "Lenny" <(E-Mail Removed)> wrote in message
>
> news:4689f3b0$0$17944$(E-Mail Removed) ...
>
> > Hi all

>
> > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
> > vhdl language.

>
> > My question is: it's possible to declare an integer in port statement?
> > Reading a book (I'm a newbie in vhdl it seems to be legal, so I did
> > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
> > simulator) showed me an unknown state for this port; the vhdl list is:

>
> It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
> 10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
> started incrementing the most significant bit instead of the least (bug
> 2...or maybe the X folks simply like to count that way). Then when it
> couldn't count beyond 1 it went unknown (bug 3).
>
> The interesting thing is that it must've kept counting somewhat correctly
> since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
> could be that ISE fumbled somewhat with handling variables (try changing
> 'un' from a variable to a signal and see if you get the same result).
> Another thing that might've confused it is the integer range on 'seg1' is 0
> to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
> range).
>
> Although perfectly legit, using anything other than
> std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
> the design is generally discouraged. One reason is that it creates an
> inconsistency in the basic data type (i.e. std_logic_vector or integer) for
> the unit under test in a testbench. The main reason though is that the
> synthesis vendors sometimes do a poor job of supporting the language and you
> need to stoop to their level to get your job done. One out here is to
> switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
> know why you won't be using their parts.
>
> Your code is fine as is, decide whether using brand X is worth the hassles
> on something this simple or not.
>
> KJ



 
Reply With Quote
 
yves.770905@gmail.com
Guest
Posts: n/a
 
      07-03-2007
KJ,

Why do you think this is a bug?
It's all a matter of encoding and representation. You can represent an
integer with whatever code you can think of. Sure it is recommended by
IEEE 1076.6 that a synthesis tool converts integers into a
corresponding vector of bits and should have an unsigned binary
representation.
But it is not a bug doing it in another way.

Kind regards,

Yves

On 3 jul, 12:13, "KJ" <(E-Mail Removed)> wrote:
> "Lenny" <(E-Mail Removed)> wrote in message
>
> news:4689f3b0$0$17944$(E-Mail Removed) ...
>
> > Hi all

>
> > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
> > vhdl language.

>
> > My question is: it's possible to declare an integer in port statement?
> > Reading a book (I'm a newbie in vhdl it seems to be legal, so I did
> > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
> > simulator) showed me an unknown state for this port; the vhdl list is:

>
> It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
> 10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
> started incrementing the most significant bit instead of the least (bug
> 2...or maybe the X folks simply like to count that way). Then when it
> couldn't count beyond 1 it went unknown (bug 3).
>
> The interesting thing is that it must've kept counting somewhat correctly
> since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
> could be that ISE fumbled somewhat with handling variables (try changing
> 'un' from a variable to a signal and see if you get the same result).
> Another thing that might've confused it is the integer range on 'seg1' is 0
> to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
> range).
>
> Although perfectly legit, using anything other than
> std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
> the design is generally discouraged. One reason is that it creates an
> inconsistency in the basic data type (i.e. std_logic_vector or integer) for
> the unit under test in a testbench. The main reason though is that the
> synthesis vendors sometimes do a poor job of supporting the language and you
> need to stoop to their level to get your job done. One out here is to
> switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
> know why you won't be using their parts.
>
> Your code is fine as is, decide whether using brand X is worth the hassles
> on something this simple or not.
>
> KJ



 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-03-2007
On Jul 3, 9:07 am, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> KJ,
>
> Why do you think this is a bug?
> It's all a matter of encoding and representation. You can represent an
> integer with whatever code you can think of. Sure it is recommended by
> IEEE 1076.6 that a synthesis tool converts integers into a
> corresponding vector of bits and should have an unsigned binary
> representation.
> But it is not a bug doing it in another way.
>
> Kind regards,
>
> Yves

OK, it's a possible then...while it's easy to say that the tools 'can'
represent integers in whatever way they prefer, one can also say that
a given tool will represent integer in a single particular way and if
it does not represent them in that fashion under certain conditions
then it's a bug.

So, if there is some ISE documentation that defines how integers are
represented and it does not agree with what the original poster
showed, then it is a bug. If ISE chooses to represent integers in the
sort of 'one-hot' fashion that it appears to be then it's not a
bug....but certainly a feature that one would need to have control
over. The appearance is that an integer in the range from 'a' to 'b'
would likely result in a std_logic_vector(a to b). Anyone know if
that is what ISE actually does?

KJ

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      07-03-2007
(E-Mail Removed) wrote:

> Why do you think this is a bug?
> It's all a matter of encoding and representation. You can represent an
> integer with whatever code you can think of. Sure it is recommended by
> IEEE 1076.6 that a synthesis tool converts integers into a
> corresponding vector of bits and should have an unsigned binary
> representation.
> But it is not a bug doing it in another way.


One-hot encoding would be valid, but something else is going on.
The count has only two values.

John:
ISE comes with an oem version of modelsim.
Try that on the gate netlist.

-- Mike Treseler
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      07-03-2007
Mike Treseler wrote:

> One-hot encoding would be valid, but something else is going on.
> The count has only two values.

three
>

 
Reply With Quote
 
yves.770905@gmail.com
Guest
Posts: n/a
 
      07-04-2007
On 3 jul, 15:42, KJ <(E-Mail Removed)> wrote:
> On Jul 3, 9:07 am, "(E-Mail Removed)" <(E-Mail Removed)>
> wrote:> KJ,
>
> > Why do you think this is a bug?
> > It's all a matter of encoding and representation. You can represent an
> > integer with whatever code you can think of. Sure it is recommended by
> > IEEE 1076.6 that a synthesis tool converts integers into a
> > corresponding vector of bits and should have an unsigned binary
> > representation.
> > But it is not a bug doing it in another way.

>
> > Kind regards,

>
> > Yves

>
> OK, it's a possible then...while it's easy to say that the tools 'can'
> represent integers in whatever way they prefer, one can also say that
> a given tool will represent integer in a single particular way and if
> it does not represent them in that fashion under certain conditions
> then it's a bug.
>
> So, if there is some ISE documentation that defines how integers are
> represented and it does not agree with what the original poster
> showed, then it is a bug. If ISE chooses to represent integers in the
> sort of 'one-hot' fashion that it appears to be then it's not a
> bug....but certainly a feature that one would need to have control
> over. The appearance is that an integer in the range from 'a' to 'b'
> would likely result in a std_logic_vector(a to b). Anyone know if
> that is what ISE actually does?
>
> KJ


Why would a tool need to represent integers always in the same
fashion?
Do you always want an integer to be encoded in the same way?
I actually don't care how it is being encoded, as long as the
resulting circuit is operating as I want it to operate within spec.
If the synthesis tool instantiates a 4 bit counter, or a 10 bit
register, is all the same, but it might very much affect the
performance of the circuit how it is implemented.

If you on the other hand want to get an integer on a toplevel port,
then I would convert it to an unsigned or a std_logic_vector, so that
I know the exact representation of each number.

Regards,

Yves

 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-04-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> On 3 jul, 15:42, KJ <(E-Mail Removed)> wrote:
>> On Jul 3, 9:07 am, "(E-Mail Removed)" <(E-Mail Removed)>
>> wrote:> KJ,

<snip>
>> So, if there is some ISE documentation that defines how integers are
>> represented and it does not agree with what the original poster
>> showed, then it is a bug. If ISE chooses to represent integers in the
>> sort of 'one-hot' fashion that it appears to be then it's not a
>> bug....but certainly a feature that one would need to have control
>> over. The appearance is that an integer in the range from 'a' to 'b'
>> would likely result in a std_logic_vector(a to b). Anyone know if
>> that is what ISE actually does?
>>
>> KJ

>
> Why would a tool need to represent integers always in the same
> fashion?

If the documentation said it represents integers in only one way. I don't
know what the ISE documentation has to say about how it represents integers,
if it uses only one form or multiple forms.

> Do you always want an integer to be encoded in the same way?

What I would want is for the documentation to reflect how integers are
encoded so that if I had a need to know how it is encoded then I would have
it.

> I actually don't care how it is being encoded,

And most of the time, I wouldn't care either

> as long as the
> resulting circuit is operating as I want it to operate within spec.

But what if it doesn't?

> If the synthesis tool instantiates a 4 bit counter, or a 10 bit
> register, is all the same, but it might very much affect the
> performance of the circuit how it is implemented.

And if performance is a problem, now suddenly you might be concerned about
how integers get represented within the tool and would like (and rightly
expect) the documentation to reflect how it is encoded so perhaps you could
do something about it. Making the assumption that nobody ever needs to know
how things get encoded while true in many cases, in others it is not.

>
> If you on the other hand want to get an integer on a toplevel port,
> then I would convert it to an unsigned or a std_logic_vector, so that
> I know the exact representation of each number.
>

And that is a part of the reason why std_logic/std_ulogic and their vector
formats are the preferred types for top level interfaces. Preferred though
does not imply that that is the only legal format.

I don't think we're disagreeing that ISE can represent integers in whatever
fashion they so choose and still adhere to the language standard, all I've
been saying from the start is that the representation of an integer at the
top level should be consistent with the ISE documentation for how integers
are represented...otherwise it's a bug in ISE regardless of whether you
could (or should) have converted those integers to unsigned or
std_logic_vector.

In any case, none of this has to do with the original poster's real issue
about why the counter doesn't count when integers are brought out to the top
level.

KJ


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How do I add an Integer to another Integer? Sebastian Stelzer Java 6 04-07-2010 07:03 PM
CType(x,Integer) vs. Integer.Parse(x) =?Utf-8?B?Sm9l?= ASP .Net 7 02-07-2006 02:30 AM
how do I make Class.forName("Integer") returning java.lang.Integer? Johannes Zellner Java 22 12-19-2005 11:22 AM
How do I add an Integer to another Integer? Sebastian Stelzer Java 2 10-15-2004 01:17 PM
No Math.min(Integer, Integer)? =?ISO-8859-1?Q?Thomas_Gagn=E9?= Java 0 07-29-2003 07:46 PM



Advertisments