Output timing is odd in VHDL

vhdl

Alright I've been creating some cool stuff in VHDL but I've run into a quirky problem.

I'm creating an ALU, and attempting to write a test-bench for it, but for some reason the timing is off and my signals don't get updated properly.

When I test some logic functions they work properly, but when I reach addition it fails. My inputs update, but the addition of the two inputs doesn't update until the next cycle.

Here is a snippet of the code: "0010" is the control signal for addition.

enter image description here

Here are the signals' values during that cycle: A_ext is in blue, and B_ext is in red, yet the sum vector (brown arrow) has an incorrect value. Its value is actually the sum of A_ext and B_ext from the previous cycle.

enter image description here

And here is the transition to the next cycle. You can see at the brown arrow that now sum has updated to the correct value from the previous cycle.

enter image description here

So I'm a bit confused. Is this a problem with the way my code is written, or this timing normal in VHDL and there is no way to change it?

Edit

As I said in the comment below, some of the test cases seem to update concurrently however they are in the same process and case statement as the addition test case, the test-bench cases are all coded the same way!

Notice the following picture. The red arrow points to the first test case, which is:

11111111 (top signal) AND 00000000 (2nd signal)

The result is correctly 00000000 (bottom signal).

The 2nd test case (brown arrow) is

1001100010011000.... OR 1000100110001001...

which correctly results in 1001100110011001…

If the output was updating on the next cycle for EVERY test case, then the output signal above the brown arrow would be the output for the first test case, 00000000…, but it's not.

enter image description here

Here is a larger segment of the code. I've been using 33 bit signals, A_ext and B_ext, for the addition of the 32-bit signals, A and B because to be quite honest I don't know any other way to do it and catch the carryout bit but if someone does know a better way, I'm all for it!

enter image description here

Best Answer

As David says, if you're using this unclocked style, it is CRITICAL that you get the sensitivity list correct. The immediate updates are from inputs that ARE in the sensitivity list; the mysterious delays are from inputs that aren't - therefore the process sleeps until something else wakes it up.

This Q&A and this webpage give the rationale behind how and why signal assignment occurs in delta cycles; understanding this is ABSOLUTELY KEY to understanding VHDL an all too often overlooked.

Alternatively if your simulator supports VHDL-2008, turn on that support and replace process(ALUctrl,A,B) with process(all) and let the tools build the correct sensitivity list for you.

Related Solutions

VHDL simulation does not work

There are a number of style issues here and one major problem.

Fru1tbat has pointed out that you never initialise MainCounter : one way to do so would be to drive the Reset input with a simple waveform :

RESET <= '0', '1' after 100 ns, '0' after 200 ns;

in the parallel execution region (after the architecture "begin") would do so. Note that this is for simulation only, and it would be MUCH better to make RESET an input port and drive it from your simulation testbench.

Secondly (and this is the major problem, waiting to bite you randomly in real hardware) the RESET clause in process COUNT should be simplified to ONLY clear MainCounter on reset. Then the wrapround clear should be moved into the clocked part of the process:

if Reset = '1' then 
   MainCounter <= (others => '0');
elsif rising_edge(Clk) then
   if MainCounter >= 12345 then
      MainCounter <= (others => '0');
   else
      MainCounter <= MainCounter + 1;
   end if;
end if;

The reason for this is subtle if you're not used to hardware design : as expressed, you have a pile of asynchronous logic waiting to clear the counter if it momentarily transitions to a high number while counting. So counting from X"7FFF" to X"8000" it will probably momentarily pass through X"FFFF" ... and reset itself.

By moving that logic to the clocked part, it will only reset if the temporary state persists until the next clock edge : and the timing analysis tools will report timing failure if that is even a possibility.

Now the warnings : Metavalues at 0 ns are basically harmless. Metavalues persisting AFTER reset is complete are a different matter...

And the style issues :

You can compare Unsigned against simple integer literals (because numeric_std overloads comparison operators with mixed operand types) and that would make the code MUCH more readable. Better : use constant declarations instead of magic numbers. (As you discovered, you can't assign an integer literal to an unsigned; because assignment is not an operator. There are to_unsigned and to_integer conversion functions for that purpose)

There is no need for parentheses around boolean expressions e.g. in if-statements. Some C programmers use them out of habit, but it looks needlessly cluttered to me.

Your SLOW process is unclocked, despite the clock in its sensitivity list... I prefer simple clocked processes; they avoid the problems that plague combinational processes such as SLOW - which will not work correctly unless you add all the RHS signals (here - only Maincounter) to the sensitivity list.

Electronic – VHDL test bench file not accepting all set of inputs

This is because of your "wait 0ns" at the begining, the simulation is running in loop so you are changing a and b at the same time if you don't wait...

Using wait 10ns before the first initialization can solve your problem or indeed putting a wait at the end of your third variables.

Best Answer

Related Solutions

VHDL simulation does not work

Electronic – VHDL test bench file not accepting all set of inputs

Related Topic