# Output timing is odd in 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.

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.

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.

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.

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!

• Context around the snippet will help : I'm guessing it's in a case statement in a clocked process, ... in which case everything happens right after a clock edge. – user_1818839 Feb 5 '14 at 21:49
• You probably want to read up about sequential vs concurrent processes. – mng Feb 5 '14 at 22:02
• @BrianDrummond It is indeed inside of a process and a case statement, but it is not clocked. – krb686 Feb 6 '14 at 1:13
• @mng Thanks, fantastic resource! So I'm pretty sure this MUST be sequential then, because how else would I separate the "ALUctrl" signal into multiple cases? – krb686 Feb 6 '14 at 1:14
• I'm also confused though by the fact that some of the test cases seem to update concurrently while others don't. For instance the logical test cases prior to the addition updated concurrently. I'll update the question to show what I mean. – krb686 Feb 6 '14 at 1:17

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.