Integer in port declaration?

[Lenny]

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?image=simnotokgf8.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,8);
end process;
end Behavioral;
-- End OK_CODE

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

Lenny

 

[Martin Thompson]

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!)

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?image=simnotokgf8.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,8);

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

 

[KJ]

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

 

[yves.770905]

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

 

[yves.770905]

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

 

[KJ]

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

 

[Mike Treseler]

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

 

[Mike Treseler]

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

 

[yves.770905]

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

 

[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