Basic Problem

[DrummerD]

Hi,

I'm fairly new to VHDL, and have a question about a simple process. In order to make this easier to address, I've created a simplified version of the process. Essentially, I have an entity with one input (std_logic_vector) and one ouput, (std_logic). All I want to do is to have my output value toggle between '0' and '1' upon ANY change in the input vector. It was my understanding, from the reading that I've done, that by placing the input value in the sensitivity list of a process, and then toggling the value in that process, that it should have this effect. For some reason it doesn't, so I must be missing something conceptually. Here's my code, any help would be greatly appreciated.

ENTITY toggle IS
PORT
( input : IN STD_LOGIC_VECTOR(7 downto 0);
enable : BUFFER STD_LOGIC);
END toggle;

ARCHITECTURE toggle_architecture OF toggle IS
BEGIN
process(input)
variable temp : STD_LOGIC := '0';
begin
if temp = '0' THEN
temp := '1';
else
temp := '0';
end if;

enable <= temp;
end process;
END toggle_architecture;

I've had many cases now where the code just doesn't seem to do what it logically suggests. If there are any good resources on the web relating to common problems or misconceptions with VHDL that anybody knows of, that would also be very helpful.

Thanks again,
Adam

 

[Nilak]

try replacing temp with input and taking the variable temp declaration off.

 

[Nilak]

oh yeah, and since input is a byte long, you'll have to create a component (if else) and instantiate it into the architecture.

 

[DrummerD]

Thanks, but I'm not quite sure what you mean, or how this addresses what I'm trying to do.

 

[VHDLguy]

Conceptually you are kind of right, but in practice it works differently. As far as simulation is concerned the sensitivity list causes the process to run. However what you consider an event and what the simulator considers an event is slightly different. The simulator could possibly see a 8 changes in input where you only see 1. The reason being is that each signal could change at a different delta which unless you are really watching for it, you will not see it. You would not want your logic running some random amount of times (up to 8), so obviously the way you have coded is not quite right.

So to put that into persepective, the sensitivity list is not used in the fashion that you are trying to use it. it is only used to indicate the signals that should trigger the process to run. So each time an event occurs the process runs with the current information that it knows and eventually after everything has settled down there will be a resulting answer. You can imagine this is the exact same thing happening with real logic if (1) you have an and/or gate tree and some of the logic feeds back on itself, or (2) different inputs change at slightly different times. Both situations cause ripple effects in the logic, and eventually the logic settles down. the VHDL wil do the same thing.

if you are trying to create combinatorial logic (ie non clocked c <= a and b ) then you would put ALL signals that are used in your process in the sensitivity list. If you didn't put 'b' in my above example, then c would only change when a changes, so a would effectivly be an input and an enable for a latch.

if you are creating clocked logicm then you have some choices
1. No sensitivity list, in which case you must have a wait statement to wait for the clock event right at the start. Any reset logic must be synchronous (ie after the wait statement).
2. a sensitivity list with your reset signals (if you want async reset) and clock. So it would be:
example_proc : process (reset, clk)
begin
if reset = '1' then
-- do your async reset stuff


elsif clk'event and clk = '1' then
-- sync logic in here


end if;


So now. Getting back to your example, I am sure you can appreciate the fact that you must know the "previous" setting of input to know if anything changed. Given that you almost certainly need to have a clock, that way you can compare the input at the current clock to the input on the previous clock. You may be able to build some kind of feedback loop with gates, but unless you really really need too it is much easier to use a clock.

so in the sync part of the process that I wrote above you could have
input_last <= input;
if diff /= "11111111" then
enable <= not enable;
end if;

then outside of any process you could have the following combinatorial logic.
diff <= input_last xor input;

Note that depending on the packages you are using (and the vector type - unsigned, std_logic_vector etc) you could also make diff a std_logic and it would indicate that all 8 bits of input_last and input are the same. Actually now that I think about it, maybe that is the more common situation, maybe what I wrote above is less likely to work.

of course this example may not meet the exact timing that you require. but it is an example.

And with that example if you want to create a combinatorial logic loop that creates your desired result with no clock then you can probably do it now.

--

http://www.lateralsands.com/