I'm still trying to get used to some of the quirks of VHDL and I'm having a bit of an issue. First off, I understand that shift operators like rol, ror, ssl, srl, etc. are not synthesizeable. The purpose of this lab is to use a golden model to check against a synthesizeable version of the same thing in a testbench.
Now, the purpose of this program is to convert thermometer code into a 3-bit binary number. So, in other words, thermometer code "00000001" = "001", "00000011" = "010", "00000111" = "011", etc. I'm basically trying to count the number of 1's in the string from right to left. There will be no case where a '0' is placed between the string of 1's, so the vector "00011101" is invalid and will never occur.
I've devised a non-synthesizeable (and so far, non-compile-able) algorithm that I can't figure out how to get working. Basically, the idea is to read the thermometer code, shift it right and increment a counter until the thermometer code equals zero, and then assign the counter value to the 3-bit std_logic_vector. Below is the code I've done so-far.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity therm2bin_g is
port(therm : inout std_logic_vector(6 downto 0); -- thermometer code
bin : out std_logic_vector(2 downto 0); -- binary code
i : integer range 0 to 7);
end therm2bin_g;
architecture behavioral_g of therm2bin_g is
begin
golden : process(therm)
begin
while(therm /= "00000000") loop
therm <= therm srl 1;
i = i + 1;
end loop;
bin <= std_logic'(to_unsigned(i,3));
end process golden;
behavioral_g;
Best Answer
There are a few little syntactic problems with this code but overall it's not far off and it'll be a useful way into distinguishing between synthesisable and non-synthesisable - which really isn't what you are expecting!
1) The port map
Points to note here:
therm
andbin
have both a mode and a type;i
has only a type. Asbin
is only a copy ofi
you don't really need both in the port list. You can declarei
internally as a signal, or even in the process as a variable.bin
represents an Unsigned number. So good style is to make it Unsigned; or even Integer, and convey more of the design intent to the reader. Both of these are perfectly synthesizable. Integer may give you a 32-bit integer, so make itbin : out natural range 0 to 7;
and you will get a 3 bit unsigned integer! The lesson here is that if you're doing lots of unnecessary type conversions, STOP: think, and you will find a way to use the type system instead of fight it.therm
has been declared "inout
" but it is really an input to the process. (The fact that you are modifying it internally is an implementation detail, you REALLY don't want to expose the modified version to the outside world!) In fact, "inout
" really doesn't do what you think it does. Its real purpose is only for data buses and similar, where you communicate both ways on the same signal. If you use it as you are, then whatever drives the original value ontherm
will still drivetherm
, and your modified values will conflict with that to produce "X
", i.e. unknown value (Or in real hardware, possibly overheat and burn out!).So eliminate
i
, makebin
Unsigned or a subtype of Natural, and maketherm
an input.2) You need a local copy of
therm
you can modify. Declare it locally as a signal.And
i
needs to be declared locally too. It could be a signal too, but let's make it a variable in the process instead.3) The loop.
First we need to copy the input into the internal signal, then we can modify it in the loop.
To simplify it, you could make therm_int unsigned, and write
while therm_int /= 0 loop
(losing the silly C-style parentheses in the process)There is another problem here. Think of a process as like a little program in C (but without some of C's stupider "features") - variables work rather as you expect - BUT - signals are essentially designed for inter-process communication in a parallel processing system. If you think in C terms, the closest equivalent is a pipe opened on stdout and looped back into stdin! You can write to a pipe but nothing happens until you flush it...
In VHDL, the flush will only happen when the process suspends itself. As written, it cannot suspend itself until the loop ends and it reaches "
end process
". And it cannot end the loop until "therm_int = 0
". And it cannot change the value seen ontherm_int
until it suspends ... this is an infinite loop.To understand why VHDL signals work this way, see this Q&A
The simplest way round this is to make
therm_int
another process variable and use variable assignment:=
instead of signal assignment<=
for it.And now it should work.
4) Synthesis.
But what isn't synthesisable about it?
Only this: You used a
while
loop instead of afor
loop!Think about that for a moment: you cannot generally predict how many cycles a
while
loop will take. For synthesis, that means you have to generate an unknowable quantity of hardware!But you could place an upper bound on the iterations, and generate hardware to cater for that upper bound. In fact a
for
loop is automatically bounded, and synthesis tools can handle that.So write the loop as
and synthesise it. Notes :
for j in therm_int'range loop
; why j? Well we don't want to hide youri
variable! And note thattherm_int'range
automatically equates to(6 downto 0)
or however you declaredtherm_int
. This bombproofs your code against changes to the size oftherm_int
or accidental buffer overflows. It's one little example of what I meant by using the type system instead of fighting it.While we're at it, let's eliminate the shift, which is unnecessary!
As written, this will synthesise to generate enough hardware to implement the task in a single clock cycle. In general, that would lead to rather slow clock cycles, and you would want to ration the work (perhaps a single loop iteration per clock). But that's another story...