# Range-limited integers or unsigned/signed in VHDL

In VHDL the Integer type is defined as a 32-bit signed integer. Most guidelines recommend that it must be constrained when used for synthesis if don't want a full 32-bit bus. My question is regarding your experience with various synthesis tools and the following piece of code. My assumption is that the non-dependent signals would be optimized away, but there might be other issues.

signal x : integer;

process(x) is
constant alpha : integer := 12;
variable y : integer;
begin
y := (alpha*y + (100-alpha)*x) / 100;
result <= to_signed( y, 16);
end process;

• FYI, VHDL integers are NOT 32-bit signed integers, although they may be for some specific implementation. They are integers with an implementation defined range, with the given minimums of [-(231)+1,(231)-1]; notice this is one less than the range of 2's-compliment 32-bit integers.
– wjl
Sep 19, 2011 at 19:41

Which bits are you expecting to be optimised away?

y depends on itself and x, both of which are full-width integers.

The multipliers will get a few low-order bits optimised to zero, and the fact that the high 3 bits of y are 'lost' when you multiply by 12 reduces the size of the y register slightly.

But it won't drop the bits > 16 if that's what you're expecting.

PS: The divide by 100 is probably going to be quite large in LUT terms - you'd be better off with 128 (or some other power of 2) as your base scaling.

• So the essence of my question is really: What does to_{un}signed do if the input value won't fit in the output value? The "divide by 100" statement is of cause incorrect. Power of two would of cause make more sense. Sep 20, 2011 at 7:25
• signed and unsigned vectors wrap if the value doesn't fit in. In simulation, integers will assert. In synthesis, integers will (usually) wrap much like vectors. Sep 20, 2011 at 11:51

Yes, if you didn't range constrain your signals it would create a 32-bit wide bus-- and then some signals would be optimized away. That being said, I rarely find a use for integer types in VHDL (for synthesis). I HIGHLY recommend using slv unless there is just something that absolutely must be integer.

The big reason for using slv instead of integer is that with slv you have better access to the individual bits, and therefore can optimize your code easier. And by "optimize your code", I mean that you can write your algorithms in more optimal ways that the synthesizer cannot do automatically. You "could" do some of this with integers and lots of typecasting to slv and back, but the integer type doesn't offer any great advantages that makes this stuff worth bothering with.

• I think this is a different level of abstraction. In the FPGA world the statement y <= x*x would infer one of the hard multipliers in the FPGA, whereas mult0 : component mymult port map (clk, x, x, y); where mymult is your custom algorithm would chose your own version. Your answer is a good advice on how to implement algorithms in VHDL, but I was asking for best-practice for the use of Integers vs Signed/Unsigned in VHDL. (Thanks anyway :-) ) Sep 20, 2011 at 7:30
• Why use slv not signed/unsigned? Sep 20, 2011 at 11:49
• @trondd I said "use SLV unless there is something that absolutely must be integer". That is best-practice. Your example of a multiplier IS a reason to use integer. I've do exactly that, and without range restrictions too. For a mult, you take the SLV, convert it to an int, multiply it, and convert it back to SLV. For many fixed point DSP applications this is the only way to maintain control over your word sizes to get the exact results you are expecting.
– user3624
Sep 20, 2011 at 13:52
• @Martin Thompson The general convention in the industry is to use slv, so that's what I've done the most of. Signed/unsigned doesn't seem to offer much over slv so I just haven't used them. There could be some cool feature of signed/unsigned, but I haven't found it yet (and I wasn't looking either).
– user3624
Sep 20, 2011 at 13:54
• @David Kessner: Ahh, I take it you use ieee.std_logic_arith etc.? Not the convention where I'm (and many others) concerned - I like my types "strong" :) parallelpoints.com/node/3 Sep 20, 2011 at 14:03