In the comment thread on an answer to this question: Wrong outputs in VHDL entity it was stated:
"With integers you don't have control or access to the internal logic representation in the FPGA, while SLV lets you do tricks like utilizing the carry chain efficiently"
So, in what circumstances have you found it neater to code using a vector of bits representation than using integer s in order to access the internal representation? And what advantages did you measure (in terms of chip area, clock frequency, delay, or otherwise.)?
Best Answer
I've written the code suggested by two other posters in both
vector
andinteger
form, taking care to have both versions operate in as similar way as possible.I compared the results in simulation and then synthesised using Synplify Pro targetting Xilinx Spartan 6. Code samples below are pasted from working code, so you should be able to use them with your favourite synthesiser and see if it behaves the same.
Downcounters
Firstly, the downcounter, as suggested by David Kessner:
Vector architecture:
Integer architecture
Results
Code-wise, the integer one seems preferable to me as it avoid the
to_unsigned()
calls. Otherwise, not much to choose.Running it through Synplify Pro with
top := 16#7fff_fffe#
produces 66 LUTs for thevector
version and 64 LUTs for theinteger
version. Both versions make much use of the carry-chain. Both report clock speeds in excess of 280MHz. The synthesiser is quite capable of establishing good use of the carry chain - I verified visually with the RTL viewer that similar logic is produced with both. Obviously an up-counter with comparator will be bigger, but that'd be the same with both integers and vectors again.Dividing by 2**n counters
Suggested by ajs410:
Vector architecture
Integer architecture
You have to jump through some hoops to avoid just using
to_unsigned
and then picking bits off which would clearly produce the same effect as above:Results
Code-wise, in this case, the
vector
version is clearly better!In terms of synthesis results, for this small example, the integer version (as ajs410 predicted) does produce 3 extra LUTs as part of the comparators, I was too optimistic about the synthesiser, although it is working with an awfully obfuscated piece of code!
Other uses
Vectors are a clear win when you want arithmetic to wrap-around (counters can be done as a single line even):
vs
although at least it's clear from that code that the author intended a wrap around.
Something I've not used in real-code, but pondered:
The "naturally-wrapping" feature can also be utilised for "computing through overflows". When you know that the output of a chain of additions/subtractions and multiplications is bounded, you don't have to store the high bits of the intermediate calculations as (in 2-s complement) it'll come out "in the wash" by the time you get to the output. I'm told that this paper contains a proof of this, but it looked a bit dense for me to make a quick assessment! Theory of Computer Addition and Overflows - H.L. Garner
Using
integer
s in this situation would cause simulation errors when they wrapped, even though we know they'll unwrap in the end.And as Philippe pointed out, when you need a number bigger than 2**31 you have no choice but to use vectors.